Introducción

La industria del software es una de las industrias más grandes y exitosas de la historia.. Pero las aplicaciones de software se encuentran entre los objetos fabricados más caros y propensos a errores de la historia.. El software necesita estimaciones precisas de los horarios, costos, y calidad. Estos son difíciles de lograr si las métricas fundamentales son incorrectas y distorsionan la realidad.. A partir de 2014 La industria del software trabaja bajo una variedad de medidas y métricas no estándar y altamente inexactas, agravadas por prácticas de medición muy descuidadas.. Los errores en las medidas y métricas del software provocan errores en las estimaciones del software.. Las siguientes son descripciones de los temas de métricas de software más preocupantes en orden alfabético desde mi punto de vista. Dos de ellos son generalizados y problemáticos.:

• El costo por defecto penaliza la calidad
• Las líneas de código penalizan los lenguajes de alto nivel y hacen que los requisitos y el diseño sean invisibles

Métricas problemáticas

Costo por defecto las métricas penalizan la calidad y hacen que el software con más errores parezca el más barato. No existen normas ISO u otras para calcular el costo por defecto.. El costo por defecto no mide el valor económico de la calidad del software. La leyenda urbana que cuesta 100 veces más para corregir defectos posteriores al lanzamiento que defectos tempranos no es cierto y se basa en ignorar los costos fijos. Debido a los costos fijos de escribir y ejecutar casos de prueba, el costo por defecto aumenta constantemente porque se encuentran cada vez menos defectos. Esto es causado por una regla estándar de la economía de fabricación.: “si un proceso tiene un alto porcentaje de costos fijos y hay una reducción en las unidades producidas, el costo por unidad sube.Esto explica por qué el costo por defecto parece aumentar con el tiempo a pesar de que los costos reales de reparación de defectos son planos y no cambian mucho.. Por supuesto, hay defectos muy preocupantes que son costosos y consumen mucho tiempo., pero estos son comparativamente raros.

Densidad de defectos las métricas miden la cantidad de errores publicados para los clientes. No hay normas ISO u otras para calcular la densidad de defectos. Un método cuenta solo los defectos de código publicados. Un método más completo incluye errores que se originan en los requisitos y el diseño, así como defectos en el código., y también incluye “correcciones incorrectas” o errores en las propias reparaciones de defectos. Puede haber más de un 300% variación entre contar solo errores de código y contar errores de todas las fuentes.

Métricas de puntos de función fueron inventados por IBM alrededor 1975 y colocado en el dominio público alrededor de 1978. Las métricas de puntos de función miden la productividad económica utilizando tanto “horas de trabajo por punto de función" y "puntos de función por mes". También son útiles para normalizar datos de calidad como "defectos por punto de función".. Sin embargo, existen numerosas variaciones de puntos de función y todas producen resultados diferentes.: Automático, contraproducente, CÓSMICO, Rápido, FISM, IFPUG, Mark II, NESMA, sin ajustar, etc. Existen normas ISO para CÓSMICO, FISM, IFPUG, Mark II y NESMA. Sin embargo, a pesar de las normas ISO, los cinco producen recuentos diferentes.. Los partidarios de cada variante de punto de función afirman que la "precisión" es una virtud, pero no hay un átomo de cesio o una forma independiente de determinar la precisión, por lo que estas afirmaciones son falsas.. Por ejemplo, los puntos de función COSMIC producen conteos más altos que los puntos de función IFPUG para muchas aplicaciones, pero eso no indica "precisión" ya que no hay una forma objetiva de saber la precisión..

Métricas de objetivo/pregunta (GQM) fueron inventados por el Dr.. Víctor Basili de la Universidad de Maryland. El concepto es atractivo. La idea es especificar algún tipo de objetivo o meta tangible, y luego pensar en preguntas que deben responderse para lograr el objetivo. Este es un buen concepto para toda la ciencia y la ingeniería y no solo para el software.. sin embargo, ya que cada empresa y proyecto tiende a especificar metas únicas método GQM no se presta a herramientas de estimación paramétrica ni a la recopilación de datos de referencia. No sería difícil fusionar GQM con métricas de puntos de función y otras métricas de software efectivas, como la eficiencia de eliminación de defectos.. Por ejemplo, varias metas útiles podrían ser “¿Cómo podemos lograr potenciales de defecto de menos de 1.0 por punto de función?" o "¿Cómo podemos lograr tasas de productividad de 100 puntos de función por mes?” Otro buen objetivo que en realidad debería ser un objetivo para todas las empresas y todos los proyectos de software en el mundo sería “¿Cómo podemos lograr más que 99% en la eficiencia de eliminación de defectos?"

Líneas de código (LOC) las métricas penalizan los lenguajes de alto nivel y hacen que los lenguajes de bajo nivel se vean mejor de lo que son. Métricas LOC también hacer que los requisitos y el diseño sean invisibles. No existen estándares ISO u otros para contar las métricas LOC. Alrededor de la mitad de los artículos y artículos de revistas usan LOC físico y la otra mitad usa LOC lógico.. La diferencia entre los recuentos de LOC físicos y lógicos puede superar 500%. Las métricas LOC hacen que los requisitos y el diseño sean invisibles y también ignoran los requisitos y los defectos de diseño, que superan en número a los defectos de código. Aunque existen benchmarks basados ​​en LOC, los errores intrínsecos de las métricas LOC las hacen poco confiables. Debido a la falta de estándares para contar LOC, Los puntos de referencia de diferentes proveedores para las mismas aplicaciones pueden contener resultados muy diferentes..

punto de la historia Las métricas se utilizan ampliamente para proyectos ágiles con "historias de usuarios". Puntos de historia no tienen un estándar ISO para contar o cualquier otro estándar. Son muy ambiguos y pueden variar tanto como 400% de empresa a empresa y de proyecto a proyecto. Hay pocos puntos de referencia útiles que utilizan puntos de historia.. Obviamente, los puntos de la historia no se pueden usar para proyectos que no utilizan historias de usuarios, por lo que no tienen valor para las comparaciones con otros métodos de diseño..

Deuda técnica es una nueva métrica y se está extendiendo rápidamente. Es una brillante metáfora desarrollada por Ward Cunningham. El concepto de "deuda técnica” es que los temas aplazados durante el desarrollo en interés de la velocidad de programación costarán más después del lanzamiento de lo que habrían costado inicialmente. Sin embargo, no existen normas ISO para la deuda técnica y el concepto es muy ambiguo.. Puede variar por más 500% de empresa a empresa y de proyecto a proyecto. Peor, la deuda técnica no incluye todos los costos asociados con la mala calidad y los atajos de desarrollo. Deuda técnica omite proyectos cancelados, daños o perjuicios emergentes a los usuarios, y los costos de los litigios por mala calidad.

Puntos de casos de uso son utilizados por proyectos con diseños basados ​​en "casos de uso" que a menudo utilizan Rational Unified Process de IBM (RUP). No hay estándares ISO para casos de uso.. Puntos de casos de uso son ambiguas y pueden variar en más de 200% de empresa a empresa y de proyecto a proyecto. Obviamente, los casos de uso no sirven para medir proyectos que no utilizan casos de uso., por lo que tienen muy pocos datos de referencia.

Definición de la productividad del software

Por más de 200 años la definición económica estándar de productividad ha sido, “Bienes o servicios producidos por unidad de trabajo o gasto.Esta definición se utiliza en todas las industrias., pero ha sido difícil de usar en la industria del software. Para el software existe ambigüedad en lo que constituye nuestro “bienes o servicios."

La unidad más antigua para los "bienes" de software era un "línea de código” o LOC. Más recientemente, los bienes de software se han definido como “puntos de función". Incluso definiciones más recientes de bienes incluyen “puntos de la historia" y "puntos de casos de uso". los pros y contras de estas unidades se han discutido en gran medida en la literatura.

Otro tema importante tomado de la economía de fabricación tiene un gran impacto en productividad del software que aún no se entiende bien ni siquiera en 2014: costes fijos.

Una ley básica de la economía de fabricación que es válida para todas las industrias, incluido el software, es la siguiente: “Cuando un proceso de desarrollo tiene un alto porcentaje de costos fijos, y hay una disminución en el número de unidades producidas, el costo por unidad sube."

Cuando un "línea de código” se selecciona como la unidad de fabricación y se cambia de un lenguaje de bajo nivel, como ensamblador, a un lenguaje de alto nivel, como Java, habrá una reducción en el número de unidades desarrolladas.

Pero las tareas no codificadas de requisitos y diseño actúan como costos fijos. Por lo tanto, el costo por línea de código aumentará para lenguajes de alto nivel.. Esto significa que LOC no es una métrica válida para medir la productividad económica..

Para el software hay dos definiciones de productividad que coinciden con los conceptos económicos estándar:

1. Producir una cantidad específica de unidades entregables para el menor número de horas de trabajo.
2. Producir la mayor cantidad de unidades entregables en un período de trabajo estándar, como una hora, mes, o año.

en definición 1 los bienes entregables son constantes y las horas de trabajo son variables.

en definición 2 los bienes entregables son variables y los períodos de trabajo son constantes.

Definición de la calidad del software

Como todos sabemos el tema de “calidad” es algo ambiguo en todas las industrias. Las definiciones de calidad pueden abarcar la calidad estética subjetiva y también unidades cuantitativas precisas, como el número de defectos y sus niveles de gravedad..

A lo largo de los años, el software ha probado una serie de definiciones alternativas de calidad que en realidad no son útiles.. Por ejemplo, una definición para la calidad del software ha sido “conformidad con los requisitos."

Los requisitos en sí mismos están llenos de errores o fallas que comprenden aproximadamente 20% de los defectos generales encontrados en las aplicaciones de software. Definir la calidad como la conformidad con una fuente importante de errores es un razonamiento circular y claramente inválido.. Necesitamos incluir errores de requisitos en nuestra definición de calidad..

Otra definición de calidad ha sido “aptitud para el uso.Pero esta definición es ambigua y no se puede predecir antes de que se lance el software., o incluso medido bien después del lanzamiento.

Otra definición para la calidad del software ha sido una serie de palabras que terminan en “…utilidad”, como confiabilidad y mantenibilidad.. Por loables que sean estos atributos, todos son ambiguos y difíciles de medir. Más, son difíciles de predecir antes de que se construyan las aplicaciones.

Una definición efectiva para la calidad del software que puede predecirse antes de que se construyan las aplicaciones y luego medirse después de que se entreguen las aplicaciones es: “La calidad del software es la ausencia de defectos que harían que la aplicación dejara de funcionar, o hacer que produzca resultados incorrectos."

Porque los defectos entregados afectan la confiabilidad, mantenibilidad, usabilidad, aptitud para el uso, conformidad con los requisitos, y también la satisfacción del cliente cualquier definición efectiva de la calidad del software debe reconocer la importancia central de lograr bajos volúmenes de defectos entregados. La calidad del software es imposible sin niveles bajos de defectos entregados sin importar la definición que se use.

 

Sobre el Autor:

Alcaparras jones es CTO de Análisis de Namcook, una empresa que construye riesgo avanzado, calidad, y herramientas de estimación de costos. Esta publicación de blog se publicó originalmente en el blog Namcook Analytics.

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.