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 embargo, un gestor de proyecto no debería obsesionarse

con la estimación. Los enfoques modernos de

ingeniería del software (por ejemplo, modelos de procesos

evolutivos) toman un punto de vista iterativo del

desarrollo. En tales enfoques, es posible3 revisar la estimación

(a medida que se conoce más información), y

variarla cuando el cliente haga cambios de requisitos.

PLANIFICACIÓN DEL PROYECTO

El objetivo de la planificación del proyecto de software

es proporcionar un marco de trabajo que permita al

gestor hacer estimaciones razonables de recursos, coste

y planificación temporal. Estas estimaciones se hacen

dentro de un marco de tiempo limitado al comienzo de

un proyecto de software, y deberían actualizarse regularmente

a medida que progresa el proyecto. Además,

las estimaciones deberían definir los escenarios del

((mejor caso» y «peor caso» de forma que los resultados

del proyecto puedan limitarse.

El objetivo de la planificación se logra mediante un

proceso de descubrimiento de la información que lleve

a estimaciones razonables. En las secciones siguientes,

se estudian cada una de las actividades asociadas a la

planificación del proyecto de software.

PLANIFICACIÓN DEL PROYECTO

La primera actividad de la planificación del proyecto de

software es determinar el ámbito del software. Se deben

evaluar la función y el rendimiento que se asignaron al

software durante la ingeniería del sistema de computadora

(Capítulo lo), para establecer un ámbito de proyecto

que no sea ambiguo, ni incomprensible para

directivos y técnicos. Se debe delimitar la declaración

del ámbito del software.

El ámbito del software describe el control y los

datos a procesar, la función, el rendimiento, las restricciones,

las interfaces y la fiabilidad. Se evalúan las

funciones

...