OBSERVACIONES SOBRE LA ESTIMACIÓN

OBSERVACIONES SOBRE LA ESTIMACIÓN

A un destacado ejecutivo se le preguntó una vez por la

característica más importante que debe tener un gestor

de proyectos. Respondió: una persona con la habilidad

de saber qué es lo que va a ir mal antes de que ocurra...

» . Debemos añadir: y con el coraje para hacer

estimaciones cuando el futuro no está claro...».

La estimación de recursos, costes y planificación temporal

de un esfuerzo en el desarrollo de software requiere

experiencia, acceder a una buena información

histórica y el coraje de confiar en predicciones (medidas)

cuantitativas cuando todo lo que existe son datos

cualitativos. La estimación conlleva un riesgo inherente'

y es este riesgo el que lleva a la incertidumbre.

La complejidad del proyecto tiene un gran efecto en la

incertidumbre, que es inherente en la planificación. Sin

embargo, la complejidad es una medida relativa que se ve

afectada por la familiaridad con esfuerzos anteriores. Se

podría considerar una aplicación sofisticada de comercio

electrónico como «excesivamente compleja» para un desarrollador

que haya realizado su primera aplicación. Sin

embargo para un equipo de software que desarrolle su

enésimo sitio web de comercio electrónico podría considerarse

«sumamente fácil» (una de tantas). Se han propuesto

una serie de medidas cuantitativas de la complejidad

del software (por ejemplo, [ZU597]). Tales medidas se

aplican en el nivel de diseño y de codificación, y por consiguiente

son difíciles de utilizar durante la planificación

del software (antes de que exista un diseño o un código).

Sin embargo, al comienzo del proceso de planificación se

pueden establecer otras valoraciones de complejidad más

subjetivas (por ejemplo, los factores de ajuste de la complejidad

del punto de función descritos en el Capítulo 4).

El tamaño del proyecto es otro factor importante que

puede afectar a la precisión y a la eficiencia de las estimaciones.

A medida que el tamaño aumenta, crece rápidamente*

la interdependencia entre varios elementos del

software. El problema de la descomposición, un enfoque

importante hacia la estimación, se hace más difícil

porque los elementos descompuestos pueden ser todavía

excesivamente grandes. Parafraseando la ley de

Murphy: <<lo que puede ir mal irá mal», y si hay más

cosas que puedan fallar, más cosas fallarán.

El tamaño se incrementa con frecuencia debido al cambio del ámbito))

que ocurre cuando el cliente modifica los requisitos. El incremento del

tamaño del proyecto puede tener un impacto geométrico en el coste y

en la planificación del proyecto [MAH96].

la complejidad del proyecto, el tamaño del proyecto y el

grado de incertidumbre estructural afectan a la fiabilidad

de la estimación.

El grado de incertidumbre estructural tiene también

efecto en el riesgo de la estimación. En este contexto,

la estructura se refiere al grado en el que los requisitos

se han definido, la facilidad con la que pueden subdividirse

funciones, y la naturaleza jerárquica de la información

que debe procesarse.

La disponibilidad de información histórica tiene una

fuerte influencia en el riesgo de la estimación. Al mirar

atrás, podemos emular lo que se ha trabajado y mejorar

las áreas en donde surgieron problemas. Cuando se dispone

de las métricas completas de software de proyectos

anteriores (Capítulo 4), se pueden hacer estimaciones con

mayor seguridad; establecer planificaciones para evitar

dificultades anteriores, y así reducir el riesgo global.

El riesgo se mide por el grado de incertidumbre en las

estimaciones cuantitativas establecidas por recursos, coste

y planificación temporal. Si no se entiende bien el ámbito

del proyecto o los requisitos del proyecto están sujetos

a cambios, la incertidumbre y el riesgo son peligrosamente

altos. El planificador del software debería solicitar definiciones

completas de rendimiento y de interfaz (dentro

de una especificación del sistema). El planificador y, lo que

es más importante, el cliente, deben tener presente que

cualquier cambio en los requisitos del software significa

inestabilidad en el coste y en la planificación temporal.

Sin

...