El tamaño del software es el principal impulsor para la estimación de costos del proyecto

Con mucho, la mayoría de los modelos de estimación de costos para el desarrollo de software, Los proyectos de mejora o mantenimiento utilizan el tamaño del software como parámetro de entrada principal.. El tamaño del software es ampliamente reconocido como un factor de costo importante para el esfuerzo y el costo necesarios para los proyectos de software.. Sin embargo, a diferencia de muchos objetos físicos, no existen estándares de medición universales para medir el tamaño del software. Mientras que un pintor que necesita estimar el costo de pintar una pared normalmente mediría el tamaño de esta pared en pies cuadrados o metros cuadrados como entrada para su estimación., la medición del tamaño del software es difícil debido al hecho de que no tiene una forma física real. sin embargo, hay una serie de métodos disponibles en la industria que se pueden utilizar para medir el tamaño del software. Sin embargo, para los estimadores de costos que no son expertos en dimensionamiento de software, puede ser difícil comprender las ventajas y desventajas de los métodos disponibles y, por lo tanto, puede resultarles difícil seleccionar el mejor método para su propósito. en este blog, se proporciona una descripción general de los métodos más utilizados para el dimensionamiento de software disponibles en la industria. También se dan las ventajas y desventajas de estos métodos, así como recomendaciones sobre qué métodos usar para qué tipos de proyectos de software.. En la siguiente tabla se muestran los métodos de medición del tamaño del software que se tratan en este blog.

Medida del tamaño del software	Alcance de medición	Tamaño
SLOCK	Objeto de software físico	Tamaño técnico en SLOC
IFPUG	Requisitos de usuario funcional	Tamaño funcional en FP
nesma	Requisitos de usuario funcional	Tamaño funcional en FP
CÓSMICO	Requisitos de usuario funcional	Tamaño funcional en CFP
SIESTA	Parte de los requisitos de usuario no funcionales	Tamaño no funcional en puntos SNAP
Puntos de casos de uso	casos de uso, caracteristicas tecnicas del proyecto, caracteristicas ambientales del proyecto	'Combinación de esfuerzo/tamaño' en los puntos de caso de uso
Puntos de función rápida	Requisitos funcionales del usuario y tamaño de la configuración	FFP de Gartner
puntos de la historia	Elementos pendientes, funcional y no funcional	'Combinación de esfuerzo/complejidad' en los puntos de la historia

Estimación de costos de proyectos de software

En la estimación de costos de proyectos de software, el enfoque suele estar en estimar las horas de esfuerzo de las personas en el equipo. La razón de esto es que las horas de esfuerzo generalmente impulsan los costos totales del proyecto.. Por supuesto, hay otros costos involucrados., por ejemplo. licencias, lugares de trabajo, infraestructura, etc., pero estos costos no dependen del tamaño del software y también se pueden calcular de una manera más sencilla.

A (simplificado) modelo de estimación se muestra en la siguiente figura.

El tamaño del software a desarrollar es el principal parámetro de entrada para la estimación del proyecto.. Es crucial para la precisión de la estimación que el tamaño se mida con precisión.. Seleccionar una tasa de productividad realista también es un paso muy importante. Esto debe hacerse con base en datos históricos o con la ayuda de herramientas paramétricas profesionales que se basen en datos relevantes de la industria.. Por lo general, se prefiere usar los datos de la empresa, ya que esto muestra las capacidades reales de la organización que pueden ser (mucho) mejor o (mucho) peor que el promedio de la industria. Las características específicas del proyecto también pueden ser importantes para considerar, por ejemplo. horario de presion, tamaño del equipo, restricciones de calidad, etc.. Por lo tanto, Las herramientas paramétricas suelen ser muy útiles en este paso de la estimación de un proyecto..

Multiplicando el tamaño por la productividad, las horas de esfuerzo bruto se calculan. Por lo general, algunos ajustes son necesarios en función de un análisis de riesgo.. Si uno necesita ser 99% seguro de que no habrá un sobrecosto de los costos, por ejemplo, las horas de esfuerzo probablemente se ajustarán para crear una contingencia.

Clasificación de los métodos de medición del tamaño del software

Existe una distinción importante entre los métodos de medición del tamaño funcional y otros (métodos de medición de tamaño no funcionales o métodos híbridos). Los métodos de medición del tamaño funcional miden la funcionalidad. ('¿Qué hace el software?') que el software ofrece a sus usuarios y cuantifica esto de alguna manera. Cuanta más funcionalidad puede usar el usuario, este mayor el tamaño del software. Una de las principales ventajas de este tipo de métodos es que el tamaño es independiente de la tecnología utilizada. (por ejemplo. Java, .Red, Oráculo) y método de implementación utilizado (CUNAS, desarrollo de cascada, desarrollo ágil, etc.).

Los métodos de medición de tamaño no funcionales miden los artefactos técnicos del software., generalmente el código de software que se construye. También existen métodos híbridos que miden aspectos funcionales, aspectos técnicos y, a veces, también aspectos ambientales del proyecto de software para llegar a un tamaño, por ejemplo. Puntos de casos de uso. sin embargo, la mayoría de los métodos miden el tamaño funcional o el tamaño técnico del software.

Métodos de medición del tamaño funcional: ventajas y desventajas

En general, Las principales ventajas de todas las normas ISO/IEC para la medición del tamaño funcional son:

• La medición del tamaño se realiza de forma objetiva.. Dos medidores certificados deben tener el mismo tamaño al medir los mismos requisitos funcionales del usuario;
• La medida del tamaño es repetible y verificable.. Si el especialista en medición hizo alguna suposición, estos deben documentarse como parte de la medición del tamaño.;
• La medida del tamaño es defendible.. Esto es muy importante ya que el tamaño funcional se usa a menudo en contratos de precio unitario entre proveedores y clientes.. Los contratos de precio por punto de función solo son posibles cuando el tamaño funcional se puede determinar sin disputa;
• Algunos de los métodos ofrecen métodos derivados que permiten a los estimadores de costos medir con bastante precisión el tamaño funcional bastante temprano en el ciclo de vida del proyecto.. por ejemplo el Método indicativo Nesma se puede utilizar después de la fase de análisis de requisitos y ofrece una forma rápida de obtener una indicación del tamaño funcional (+50% / -30% precisión).
• El tamaño funcional puede reconocerse como "valor" para los usuarios y clientes del sistema de software. Más funcionalidad significa más valor y, por lo tanto, mayores costos. Esto, por ejemplo, en comparación con el tamaño técnico, como las líneas de código fuente. (slocs) donde no está claro si más slocs significan más valor para el usuario y/o el negocio.
• Debido a la estandarización, la ventaja más importante es que es posible almacenar los datos de proyectos terminados para usarlos en estimaciones para nuevos proyectos. Así como el pintor que tiene datos de su productividad en horas por pie cuadrado para tipos de paredes específicos, las organizaciones pueden obtener información sobre su productividad en términos de horas por punto de función. Esto permite la evaluación comparativa, por ejemplo, contra la base de datos abierta de la industria del International Software Benchmarking Standards Group (ISBSG).

Algunas de las desventajas de usar métodos de medición de tamaño funcional para dimensionar y estimar software son:

• La medición del tamaño funcional requiere personas con experiencia para llevar a cabo esta actividad.. Como es una actividad tan importante, realmente se recomienda que solo los medidores certificados realicen el dimensionamiento e incluso luego tengan un proceso de revisión adecuado.. Hay algunas iniciativas para medir automáticamente el tamaño funcional del software, pero hasta ahora no son muy precisas.;
• La medición del tamaño funcional lleva algo de tiempo y cuesta esfuerzo. Por lo general, esto es menos que 1% del presupuesto del proyecto y, con mucho, la mayoría de los proyectos se pueden medir dentro de 1 semana de duración. Por lo general, los beneficios de hacer una medición de tamaño funcional superan el costo muchas veces, ya que permite a los interesados ​​elaborar planes más realistas y evitar sobrecostos y posibles humillaciones;
• Los métodos de medición del tamaño funcional miden los requisitos funcionales del usuario que se especifican en la documentación funcional.. Hay algunos requisitos a esta documentación para que los medidores puedan medirla.. sin embargo, si no se cumplen estos requisitos, el proyecto probablemente esté condenado de todos modos, ya que los programadores no podrán codificar y los probadores no podrán probar usando estos documentos. Una medida de tamaño funcional es, de hecho, una poderosa prueba estática de los requisitos, en muchos casos se detectan graves defectos y omisiones, permitiendo un ajuste temprano de las especificaciones y, por lo tanto, evitando los costos de detección y corrección posteriores de los defectos.

El tamaño funcional de los proyectos de software se puede utilizar en las herramientas y modelos de estimación paramétrica más utilizados., por ejemplo. QSM DELGADO, Galorath vidente, Sistemas de precios Trueplanning y COCOMO II.

Próximo blog

En el próximo blog sobre este tema., Daré mi opinión sobre las ventajas y desventajas cuando se trata de la estimación de costos de proyectos de software de los métodos enumerados en la tabla..

 

 

Sobre el Autor

Harold van Heeringen es consultor sénior de métricas de software / ingeniero senior de costos de software para Sogeti Nederland B.V. Aparte de su trabajo para el departamento de Tallaje, Estimación & Control de Sogeti, é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).

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