El dimensionamiento o estimación del tamaño del software es una actividad de ingeniería de software que se utiliza para determinar o estimar el tamaño de una aplicación o componente de software con el fin de poder implementar otras actividades de gestión de proyectos de software (como la estimación o el seguimiento). El tamaño es una característica inherente de un software, al igual que el peso es una característica inherente de un material tangible.
El dimensionamiento del software es diferente de la estimación del esfuerzo de producción . El dimensionamiento estima el tamaño probable de un software, mientras que la estimación del esfuerzo predice el esfuerzo necesario para crearlo. La relación entre el tamaño del software y el esfuerzo necesario para producirlo se denomina productividad .
Por ejemplo, si un ingeniero de software ha creado una pequeña aplicación de calculadora basada en la web, podemos decir que el esfuerzo del proyecto fue de 280 horas-hombre. Sin embargo, esto no proporciona ninguna información sobre el tamaño del producto de software en sí. Por el contrario, podemos decir que el tamaño de la aplicación es de 5.000 líneas de código (LOC) o 30 puntos de función (FP) sin identificar el esfuerzo del proyecto necesario para producirlo.
Históricamente, la metodología de dimensionamiento de software más común ha sido contar las líneas de código escritas en la fuente de la aplicación. Otro enfoque es hacer una Medición de Tamaño Funcional, para expresar el tamaño de la funcionalidad como un número realizando un análisis de puntos de función . El método de dimensionamiento original es el IFPUG . El método de dimensionamiento funcional (FSM) IFPUG FPA se ha utilizado con éxito, a pesar de ser menos preciso en la estimación de algoritmos complejos y ser relativamente más difícil de usar que la estimación de líneas de código. Han surgido adaptaciones de la metodología original de Medición de Tamaño Funcional, y estos estándares son: Puntos de Función COSMIC , Puntos de Función Mk II , Puntos de Función Nesma y Puntos de Función FiSMA. Otras variantes de estos estándares incluyen Puntos de Función Orientados a Objetos (OOFP) y variantes más nuevas como Puntos de Función Micro Ponderados , que factorizan la complejidad algorítmica y del flujo de control .
El mejor método de dimensionamiento funcional depende de varios factores, incluido el dominio funcional de las aplicaciones, la madurez del proceso de la organización en desarrollo y el grado de uso del método FSM. [1] [2] Hay muchos usos y beneficios de los puntos de función [3] más allá de medir la productividad del proyecto y estimar los proyectos planificados, estos incluyen monitorear el progreso del proyecto y evaluar la cobertura de requisitos de los paquetes comerciales listos para usar (COTS) .
Otros métodos de dimensionamiento de software incluyen el dimensionamiento de software basado en casos de uso , que se basa en contar la cantidad y las características de los casos de uso que se encuentran en una pieza de software, y la medición de tamaño funcional COSMIC , que aborda el dimensionamiento de software que tiene una cantidad muy limitada de datos almacenados, como los sistemas de "control de procesos" y "tiempo real".
Tanto el método IFPUG como los métodos COSMIC son normas ISO/IEC.
El método IFPUG para dimensionar los aspectos no funcionales de un software o componente se denomina SNAP, por lo tanto, el tamaño no funcional se mide mediante puntos SNAP . El modelo SNAP consta de cuatro categorías y catorce subcategorías para medir los requisitos no funcionales. Los requisitos no funcionales se asignan a las subcategorías pertinentes. Cada subcategoría se dimensiona y el tamaño de un requisito es la suma de los tamaños de sus subcategorías. El proceso de dimensionamiento SNAP es muy similar al proceso de dimensionamiento de puntos de función. Dentro del límite de la aplicación, los requisitos no funcionales se asocian con categorías pertinentes y sus subcategorías. Utilizando un conjunto estandarizado de criterios básicos, cada una de las subcategorías se dimensiona según su tipo y complejidad; el tamaño de dicho requisito es la suma de los tamaños de sus subcategorías. Estos tamaños se suman para dar la medida del tamaño no funcional de la aplicación de software.
Varias normas de calidad de software exigen el uso de un método de dimensionamiento válido como parte del ciclo de vida de ingeniería de software estándar de la organización . Por ejemplo, Capability Maturity Model Integration ( CMMI ) plantea dicho requisito. Una organización no puede ser evaluada (certificada) como CMMI nivel 2 o nivel 3 a menos que se utilice adecuadamente el dimensionamiento de software.