Estimación de coste

Estimación de coste

-Al principio, el coste del software constituía un pequeño porcentaje del coste total de los sistemas basados en computadora.
-Hoy en día, el software es el elemento más caro de la mayoría de los sistemas informáticos.
-Se aplica las métricas para valorar la calidad de los productos de ingeniería o los sistemas que se construyen.
-Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas claramente definidas.
-Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.
-La estimación del coste y del esfuerzo del software nunca será una ciencia exacta.
-Son demasiadas las variables - humanas, técnicas, de entorno, políticas - que pueden afectar al coste final del software y al esfuerzo aplicado para desarrollarlo.
-No existe un modelo de estimación universal o una formula que pueda ser usada para todas las organizaciones.
-Hay muchas personas implicadas en los proyectos que necesitan de estimaciones.
-La utilidad de una estimación también dependerá de la etapa de desarrollo en la que nos encontremos.
-Generalmente, la estimación se hace superficialmente, sin apreciar el esfuerzo requerido para hacer un trabajo.
-Las estimaciones claras, completas y precisas son difíciles de formular, especialmente al inicio del proyecto.
-La rapidez con la que cambia la tecnología de la información y las metodologías de desarrollo de software son un problema para la estabilización del proceso de estimación.

Proyecto Cualquier esfuerzo planeado que tiene productos a ser generados, compromisos de entrega preestablecidos y limitaciones de recursos y presupuesto.
En general tiene las siguientes características:
•Fecha de inicio y fin
•Objetivos
•Uso de recursos restrictos a limites
•Una estructura jerárquica de actividades

Tamaño medida de que tan grande es el producto

Esfuerzo número de horas necesarias para completar una actividad.

Indicadores de Productividad

Tasa de entrega de proyecto = FP/h. Mide la tasa de entrega de proyectos.
FP es el valor de puntos de función no ajustados de un proyecto
h indica todo el esfuerzo aplicado al proyecto.

Tasa de soporte = h/FP período. Refleja el trabajo realizado sobre las aplicaciones sin crear nuevas funcionalidades (reparación de defectos, conversiones o mantenimiento preventivo).
h es el tiempo invertido en estas actividades durante un determinado período.
FP es el tamaño del proyecto en PFs. Esta métrica se calcula anualmente o trimestralmente.

Indicadores de Calidad

Tasa de Costo de Reparación = Costo / FP. Cuantifica el costo de reparar los defectos del software excluyendo los costos de prevención y detección de dichos errores. Se debe calcular mensualmente por un periodo no inferior a los primeros seis meses después de la implementación del proyecto.
costo es el tiempo total de reparación en horas multiplicado por la tasa de reparación por hora del personal.
FP son los PFs totales de la aplicación que está siendo reparada.

Tasa de Estabilidad = 1 - (#cambios / FP). Proporciona un indicador de que tan bien una mejora o una aplicación cumplió las expectativas del usuario.
#cambios son los cambios solicitados durante el primer trimestre (90 días) después de la implementación.
FP es el tamaño de la aplicación en PFs.

Tasa de Defectos = #defectos / FP. Relaciona el numero de defectos con el tamaño en PFs de una aplicación.
#defectos es el total de incidencias en las que la aplicación no cumplió las especificaciones.
FP son los PFs de la aplicación mantenida. Se debe calcular mensualmente solo durante los primeros seis meses después de la implementación del proyecto.

Destreza en Testeo = #defectos/FP. Es la tasa de defectos durante la fase de pruebas. Una tasa alta indica o bien poca calidad o unos procedimientos de pruebas muy efectivos. Se debe comparar con la tasa de defectos observada en la aplicación después de la implementación. Se calcula para cada ciclo de pruebas. 

Fiabilidad = 1 - (#fallos/FP). Considera el número de fallos de la aplicación desde que se puso en marcha. Múltiples fallos causados por el mismo defecto se cuentan repetidamente. FP es el total de PFs de la aplicación que está siendo medida. Se debe calcular mensual o trimestralmente.

Proceso de estimación

Métodos de estimación 

Para realizar estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles:

•Dejar la estimación para más adelante
•Basar las estimaciones en proyectos similares ya terminados.
•Utilizar «técnicas de descomposición»
•Utilizar uno o más modelos empíricos
•Basados en la experiencia.
•Basado exclusivamente en los recursos.
•Método basado exclusivamente en el mercado.
•Basado en los componentes del producto o en el proceso de desarrollo.
•Métodos algorítmicos

Métodos basados exclusivamente en la experiencia:
•Juicio experto
     •Puro
     •Delphi
•Analogía
•Distribución de la utilización de recursos en el ciclo de vida

Juicio experto: Puro
•Un experto estudia las especificaciones y haces su estimación.
•Se basa fundamentalmente en los conocimientos del experto.
•Si desaparece el experto, la empresa deja de estimar

Juicio experto: Wideband Delphi
•Un grupo de personas son informadas y tratan de adivinar lo que costara el desarrollo tanto en esfuerzo, como su duración.
•Las estimaciones en grupo suelen ser mejores que las individuales.

Método de trabajo del Wideband Delphi
•Se dan las especificaciones a un grupo de expertos.
•Se les reúne para que discutan tanto el producto como la estimación.
•Remiten sus estimaciones individuales al coordinador.
•Cada estimador recibe información sobre su estimación, y las ajenas pero de forma anónima.
•Se reúnen de nuevo para discutir las estimaciones.
•Cada uno revisa su propia estimación y la envía al coordinador.
•Se repite el proceso hasta que la estimación converge de forma razonable.

Analogía 

•Consiste en comparar las especificaciones de un proyecto, con las de otros proyectos.

Analogía, pueden variar los siguientes factores:
•Tamaño: ¿mayor o menor?
•Complejidad: ¿Más complejo de lo usual?
•Usuarios: Si hay más usuarios habrán más complicaciones.
•Otros factores:
          •Sistema Operativo, entornos (la primera vez más).
          •Hardware, ¿Es la primera vez que se va a utilizar?
          •Personal del proyecto, ¿nuevos en la organización?

Distribución de la utilización de recursos en el ciclo de vida
•Usualmente las organizaciones tienen una estructura de costes similar entre proyectos.
•Si en un proyecto ya hemos realizado algunas fases, es de esperar que los costes se distribuyan de manera proporciona.

Método basado exclusivamente en los recursos: Parkinson
•En la estimación consiste en ver de cuanto personal y durante cuanto tiempo se dispone de el, haciendo esa estimación.
•En la realización:

“El trabajo se expande hasta consumir todos los recursos disponibles” (Ley de Parkinson)

Método basado exclusivamente en el mercado: precio para vender
•Lo importante es conseguir el contrato.
•El precio se fija en función de lo que creemos que esta dispuesto a pagar el cliente.
•Si se usa en conjunción con otros métodos puede ser aceptable, para ajustar la oferta.
•Peligro si es el único método utilizado.

Basado en los componentes del producto o proceso de desarrollo:
•Bottom-up
•Se descompone el proyecto en las unidades lo menores posibles.
•Se estima cada unidad y se calcula el coste total.
•Top-Down
•Se ve todo el proyecto, se descompone en grandes bloques o fases.
•Se estima el coste de cada componente.

Métodos algorítmicos
•Se basan en la utilización de fórmulas que aplicadas sobre modelos top-down o bottom-up producen una estimación de coste del proyecto

Putnam

•Relaciona cantidad de personas-mes y la duración del proyecto.
•Y=2Kate-at²
Y = Personas-mes en cada punto
K = Esfuerzo total del proyecto,
(Área bajo la curva)
a = Cte. asociada a la aceleración
de entrada de personas en el
proyecto,
t = instante del tiempo.

MODELO COCOMO 

Creado por Barry Boehm en 1981. Su nombre significa COnstructive COst MOdel (Modelo constructivo de costo) y se puede dividir en tres modelos.

COCOMO básico: Calcula el esfuerzo y el costo del desarrollo en función del tamaño del programa estimado en LDC.

COCOMO intermedio: Calcula el esfuerzo del desarrollo en función del tamaño del programa y un conjunto de conductores de costo que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

COCOMO detallado: Incorpora las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costo en cada fase (análisis, desarrollo, etc.) del proceso.

Estimación de proyectos por método COCOMO

Los modelos COCOMO están definidos para tres tipos de proyectos de software:

•Orgánicos.
    •Proyectos pequeños y sencillos.
    •Equipos pequeños con experiencia en la aplicación.
    •Requisitos poco rígidos.
•Semiacoplados.
    •Proyectos de tamaño y complejidad intermedia.
    •Equipos con variado niveles de experiencia.
    •Requisitos poco o medio rígidos.
•Empotrados.
   •Proyectos que deben ser desarrollados con un conjunto de requisitos (hardware y software) muy restringidos.

COCOMO Básico

Métrica de los Puntos de Función
•Es una métrica que se puede aplicar en las primeras fases de desarrollo.
•Se basa en características fundamentalmente “Externas” de la aplicación a desarrollar.
•Mide dos tipos de características:
•Los elementos de función (entradas, salidas, ficheros, etc.)
•Los factores de Complejidad.

Estimación del Esfuerzo Requerido
•Partimos de los datos históricos de la Organización
•Esfuerzo = PFA * Promedio ( Lenguaje)