Introducción
Esta es la tercera parte del blog que se enfoca en varios métodos populares de medición del tamaño del software y su utilidad para la estimación de proyectos de software.. En esta tercera parte se tratan los métodos de medición de tamaño no funcionales.. En el siguiente y último blog sobre este tema, en futuros blogs cubriré los métodos híbridos..
Se recomienda encarecidamente a los lectores interesados en este tema que lean primero el primera parte y segunda parte de este blog antes de leer esta tercera parte de la serie de blogs.
Para que un método de medición de tamaño de software en particular sea útil para la estimación de proyectos de software, las siguientes características deben aplicarse:
- El método de medición del tamaño se puede llevar a cabo de forma objetiva. (independiente de la persona que lo hace), repetible, comprobable y por lo tanto defendible forma;
- El tamaño en sí solo es útil cuando información histórica está disponible de proyectos medidos en ese método de medición de tamaño;
- Los métodos de medición del tamaño deben estar respaldados por modelos y/o herramientas paramétricas para tener en cuenta con precisión las características específicas del proyecto que influyen en la estimación, como por ejemplo QSM DELGADO, SEER para software, TruePlanning o COCOMO II.
Por supuesto, cualquier método de medición del tamaño del software que no cumpla con uno o más de estos criterios aún puede ser muy útil para una organización, siempre que elaboren un procedimiento para garantizar mediciones de tamaño repetibles, recopilar y analizar datos históricos y/o construir sus propios modelos de estimación basados en los datos recopilados. Sin embargo, para este blog, la atención se centra en la utilidad teórica del método de medición específico para fines de estimación de proyectos de software en el contexto de organizaciones que aún no cuentan con un proceso de estimación paramétrica. Para estas organizaciones, que estén dispuestos a implementar un método de medición de tamaño para estimar proyectos de software, este blog puede servir como guía para seleccionar un método específico.
Aunque todo lo escrito en este blog se basa en la experiencia personal y en la documentación disponible públicamente (referenciado), deseo recalcar que este blog solo refleja mis puntos de vista y creencias personales y por lo tanto no estoy afirmando que todo lo escrito en este blog sea una verdad absoluta. Mis creencias personales no son necesariamente las creencias de las organizaciones a las que estoy afiliado: Metros, Nesma y ISBSG.
Animo a todos a enviar comentarios y/o comentarios sobre este blog..
Métodos de medición de tamaño no funcional
Mientras que los métodos de medición del tamaño funcional solo miden el tamaño de los requisitos funcionales del usuario (lo que el software debe ofrecer al usuario), los métodos de medición de tamaño no funcional miden (a menudo parte de la) requisitos de usuario no funcionales, que pueden ser requisitos técnicos del usuario y/o requisitos de calidad del usuario (cómo debería funcionar el software). También la medida del código que se entrega se considera una medida de tamaño no funcional.
La medida de tamaño no funcional más utilizada son las líneas de código fuente. (slocs).
Líneas de código fuente (slocs)
Las líneas de código fuente atraen a muchas personas y organizaciones porque una vez que el sistema de software está listo, se puede contar automáticamente mediante contadores de código fuente. A menudo, las herramientas de desarrollo ya miden las líneas de código durante el proyecto.
Muchas organizaciones utilizan la medida de slocs como entrada para sus procesos de estimación de proyectos de software.. esto es notable, ya que el número de slocs solo se puede medir después de la finalización. Esto significa que para usar slocs en la estimación de software, los slocs tienen que ser estimados, no medido. Por lo general, un equipo de expertos calcula en conjunto la cantidad de líneas de código fuente para el nuevo proyecto y/o utiliza métodos de analogía con respecto a proyectos completados anteriormente para llegar a una estimación del tamaño del software que se entregará..
Aunque esto parece una buena idea, este método trae grandes riesgos a la estimación del esfuerzo. No hay norma ISO (o cualquier otro estándar) disponible para líneas de código fuente. Diferentes herramientas de conteo de códigos devuelven un (a veces completamente) resultado diferente después de contar el mismo código. A veces las líneas físicas se miden, pero también a menudo se cuentan las declaraciones de origen en su lugar. Dado que una declaración se puede escribir fácilmente en varias líneas, esto ya destaca un gran problema.
Adicionalmente, la cantidad de líneas de código fuente necesarias depende de factores como el entorno técnico, complejidad y capacidades del programador. Las líneas de código fuente tampoco representan realmente valor para los usuarios.. ¿Es mejor obtener más líneas de código o menos líneas de código?? Más líneas pueden significar más funcionalidad, pero si uno pagara a un proveedor basado en un precio por 1000 líneas de código fuente una cosa es segura... el cliente obtendría una gran cantidad de código! Los contadores de código no deben medir el código generado por las herramientas de desarrollo., pero en realidad es imposible que estas herramientas excluyan el código generado de la medición.
Por lo tanto, suele ser muy difícil utilizar los slocs de un proyecto de software completo como entrada para el siguiente proyecto de software.. Usar expertos para estimar el número total de líneas de código fuente para un nuevo proyecto y luego usar datos históricos basados en líneas de código fuente es extremadamente arriesgado.. Estimando de esta manera, ya existe un gran porcentaje de incertidumbre en el principal parámetro de entrada de la estimación.
Entonces, ¿Por qué muchas organizaciones estiman sus proyectos de esta manera?? Algunas publicaciones, por ejemplo ‘Orígenes de defectos de software y métodos de eliminación‘ por Capers Jones, afirman que estimar proyectos de esta manera es una forma de mala praxis profesional. A veces puede funcionar, pero el riesgo que implica es enorme y es probable que no se puedan evitar los proyectos fallidos con grandes sobrecostos. En realidad, esto es exactamente lo que a menudo se pasa por alto. Suele haber muchas cosas que salen mal en proyectos grandes, y al final casi siempre es posible 'culpar' a algunos problemas operativos que siempre aparecen durante un proyecto de software… algún problema técnico, o un propietario de producto que no se involucró lo suficiente, o el entorno OTAP no se implementó lo suficientemente rápido, o el cliente cambió mucho sus requisitos durante el proyecto… y así sucesivamente. Sin embargo, en la mayoría de los casos de fallas de software, al analizar la causa real, prueba que el proyecto comenzó con expectativas demasiado optimistas... el equipo es demasiado pequeño, la duración demasiado corta, los costos demasiado bajos. Estimaciones de expertos, y estimaciones que no se basan en estándares de la industria y datos de experiencia por lo general comienzan con expectativas optimistas. Organizaciones que entienden la relación entre una estimación realista y el resultado del proyecto, se enfocarán en implementar instrumentos que les permitan estimar el proyecto con la mayor precisión posible, tampoco recompensar las estimaciones demasiado optimistas entregadas por los proveedores, por ejemplo. sin embargo, las organizaciones tienen que alcanzar un cierto nivel de madurez para entender esto y este nivel de madurez aún está muy lejos para muchas organizaciones en la industria… incluso para aquellas que se consideran bastante maduras!
teóricamente, las líneas de código fuente no son útiles para la estimación de software en absoluto. Algunas personas reportan proyectos exitosos estimados de esta manera, pero desde un punto de vista teórico, esto podría ser el resultado de la casualidad o la suerte..
Las características para evaluar la utilidad de este método para la estimación de proyectos de software se enumeran en la siguiente tabla:
| Característica | Sí No | Observaciones |
| Objetivo, repetible, verificable y defendible | No | Slocs se pueden medir solo después de la finalización del proyecto. Para la estimación del proyecto, solo se pueden usar 'slocs adivinados'. |
| Datos históricos disponibles | si | ISBSG R13: 180 proyectos. sin embargo, no es posible verificar el tipo de SLOC medido. |
| Compatible con modelos/herramientas | si | QSM DELGADO, SEER para software, TruePlanning, COCOMO II. ISBSG |
puntos SNAP
SNAP es el acrónimo de "Proceso de evaluación no funcional de software".,” un método de medición del tamaño del software no funcional. El dimensionamiento de puntos SNAP está destinado a ser un complemento de un dimensionamiento de puntos de función, que mide el tamaño del software funcional. SNAP es un producto de la Grupo de usuarios de puntos de función internacional (IFPUG), y se dimensiona usando el Manual de prácticas de evaluación no funcional de software, ahora en versión 2.2.
SNAP está débilmente conectado a la ISO 9126 e ISO 25010 estándares para la calidad del software. Intenta dimensionar los requisitos no funcionales que se implementan en un proyecto de software.. Aunque esto parece una buena idea, el método SNAP parece perder su objetivo. No ofrece un instrumento de medición integral para todos los requisitos no funcionales y, además, una serie de requisitos no funcionales muy relevantes no se miden en absoluto.. Una serie de observaciones adicionales:
- La mayoría de la documentación que se utiliza en la industria no establece explícitamente la información necesaria sobre los requisitos no funcionales que SNAP intenta medir.. Adicionalmente, no está claro qué hacer cuando falta esta información. Contar algo de todos modos... o no contar nada?
- No todas las ISO 9126 o ISO 25010 se miden las categorías de requisitos no funcionales. Incluso cuando los puntos SNAP se pueden medir utilizando el método publicado, los requisitos no funcionales que la gente cree que son importantes generadores de costos (por ejemplo. rendimiento o seguridad, etcétera), son ignorados;
- No está claro cómo se determina la relación entre las diferentes categorías de SNAP y por qué esto sería válido. ¿Por qué la complejidad de la interfaz de usuario (Puntos SNAP = Nr de propiedades agregadas o configuradas … 2, 3 o 4 multiplicado por el número de elementos únicos de la interfaz de usuario) ser de igual... o más... o menos tamaño no funcional que el tamaño no funcional medido para procesos por lotes (4 veces, 6 tiempos o 10 veces el número de atributos de datos). Parece que no hay una conexión relevante entre las categorías y la forma en que se miden los puntos SNAP parece arbitraria;
- El profesor Doctor Abran señaló que el prueba estadística del método SNAP no pasa las pruebas habituales de validez metódica, ya que parece que los valores atípicos en el conjunto de datos utilizados para demostrar la correlación entre los puntos SNAP y el esfuerzo no parecen haberse eliminado;
- Algunos de los requisitos no funcionales que se miden son, de hecho, funcionales y también se miden en los métodos NESMA y/o IFPUG.. Esto es extraño para un método que solo pretende medir requisitos no funcionales..
Considerándolo todo, aunque IFPUG y muchos profesionales defienden el método SNAP como un método bueno y válido para usar en la estimación, desde un punto de vista práctico y teórico, todavía hay muchos problemas que abordar antes de que este método pueda ser útil cuando se trata de la estimación de proyectos.. Por el momento hay datos históricos muy limitados de proyectos medidos en SNAP disponibles. En 2013, el International Software Benchmarking Standards Group publicó un Formulario de recopilación de datos SNAP, pero hasta ahora no se han recibido presentaciones de proyectos con puntos SNAP.
Por ahora, como máximo, se puede usar para tratar de comprender las diferencias en el rendimiento o la productividad entre proyectos completados, pero aún no es adecuado para la estimación de proyectos..
Las características para evaluar la utilidad de este método para la estimación de proyectos de software se enumeran en la siguiente tabla:
| Característica | Sí No | Observaciones |
| Objetivo, repetible, verificable y defendible | No | El manual SNAP debe asegurar una medición objetiva, pero como no está seguro de qué hacer cuando falta la información necesaria, Es probable que los medidores hagan diferentes suposiciones que resulten en diferentes tamaños. |
| Datos históricos disponibles | No | ISBSG captura proyectos en puntos SNAP, pero aún no se han enviado datos. Posiblemente hay datos disponibles en el grupo IFPUG SNAP. |
| Compatible con modelos/herramientas | No |
Próximo blog
En el próximo blog sobre este tema., Daré mi opinión sobre la utilidad de los principales métodos híbridos de medición de tamaño para la estimación de proyectos de software..
Sobre el Autor
Harold van Heeringen es consultor sénior de evaluación comparativa en Metri. Aparte de su trabajo para Metri, él está involucrado en Nesma (miembro de la Junta), el Grupo de estándares internacionales de evaluación comparativa de software (ISBSG, presidente actual) y el Consorcio Internacional de Métricas de Software Común (CÓSMICO, Consejo Consultivo Internacional, en representación de los Países Bajos).