Estimacion de Costos

Tema 2.
Estimacin de costes
4 4 4 4 4
Introduccin Productividad Tcnicas de estimacin Modelo algortmico de costes Duracin y personal del proyecto
Francisco Mora (DCCIA, Universidad de Alicante, 2002)
Introduccin
4 Qu es la estimacin de costes?
Consiste en predecir los recursos (monetarios, temporales, humanos, materiales, ...) necesarios para llevar a cabo el proceso de desarrollo del software.
4 Cuestiones fundamentales:
m Cunto esfuerzo es necesario para completar una
actividad? m Cunto tiempo se necesita para completar una actividad? m Cul es el coste total de una actividad?
Francisco Mora (DCCIA, Universidad de Alicante, 2002) Tema 2. 2
Componentes de coste
4 Costes hardware y software 4 Costes de viajes y aprendizaje 4 Costes de esfuerzo (factor dominante casi siempre)
m sueldo ingenieros del proyecto m gastos seguros y seguridad social
4 Otros costes:
m costes de alquiler, calefaccin y luz m costes de redes y comunicaciones m costes de recursos compartidos (p.e. librera,
personal del restaurante, etc.)

Factores de coste
Factor Market opportunity Description A development organisation may quote a low price because it wishes to move into a new segment of the software market. Accepting a low profit on one project may give the opportunity of more profit later. The experience gained may allow new products to be developed. If an organisation is unsure of its cost estimate, it may increase its price by some contingency over and above its normal profit. A customer may be willing to allow the developer to retain ownership of the source code and reuse it in other projects. The price charged may then be less than if the software source code is handed over to the customer. If the requirements are likely to change, an organisation may lower its price to win a contract. After the contract is awarded, high prices may be charged for changes to the requirements. Developers in financial difficulty may lower their price to gain a contract. It is better to make a small profit or break even than to go out of business.
Tema 2. 4
Cost estimate uncertainty
Contractual terms
Requirements volatility
Financial health
Productividad (I)
4 La productividad de un programador es una medida
de la "velocidad" a la que los ingenieros implicados en el desarrollo del software producen dicho software y su documentacin asociada
4 Es necesario estimar la productividad:
m para realizar las estimaciones necesarias en el
proyecto
m para evaluar si un proceso o mejoras en la
tecnologa son efectivas.
Tema 2.
Productividad (II)
Productividad = atributos del software esfuerzo total de desarrollo
4 Tipos de medidas:
m Relacionadas con el tamao (lneas de cdigo) m Relacionadas con la funcionalidad (puntos de
funcin, puntos de objeto)
Tema 2.
Lneas de cdigo
4 Qu es una lnea de cdigo?
m Es una medida propuesta inicialmente cuando los
programas se escriban en tarjetas, con una lnea por tarjeta m Actualmente los lenguajes permiten escribir varias sentencias en una lnea, o una misma sentencia en varias lneas
4 Se debe decidir qu programas deberan contarse
como parte del sistema 4 Asumen una relacin lineal entre el tamao y el volumen de documentacin
Comparaciones de productividad
4 Cuanto mayor sea la expresividad del lenguaje, ms
baja ser su productividad aparente.

4 Cunto ms lneas de cdigo emplee el
programador, mayor ser su productividad

Assembly code High-level language Assembly code High-level language Analysis Design Coding Testing Documentation 3 weeks 5 weeks 8 weeks 10 weeks 2 weeks 3 weeks 5 weeks 8 weeks 6 weeks 2 weeks Size Effort Productivity 5000 lines 28 weeks 714 lines/month 1500 lines 20 weeks 300 lines/month
Comparar la productividad utilizando lenguajes diferentes de programacin puede llevar a conclusiones errneas respecto a la productividad de los programadores
Puntos de funcin
4 Basados en una combinacin de caractersticas del
programa
m entradas y salidas externas m interacciones de usuario m interfaces externas m ficheros usados por el sistema
4 Se asocia un peso con cada uno de ellos 4 Los puntos de funcin se calculan multiplicando
cada factor por su peso y sumando todos ellos
Tema 2.
Clculo de los puntos de funcin(I)

Anlisis del dominio de inf. y desarrollo de contadores
Establecer contadores para el dominio de entrada e interfaces del sistema
Establecer pesos y evaluar la complejidad
Asignar niveles de complejidad o pesos para cada contador
Evaluacin de factores globales
Considerar factores externos, Fi como reutilizacin, concurrencia, SO, ... Puntos de funcin = (contador peso) C donde: C = (0.65 + 0.01 N) (Multiplicador de N=
complejidad) Fi (Grado de influencia)
Tema 2. 10
Calcular los puntos de funcin
Clculo de los puntos de funcin(II)

Parmetro de medida N entradas usuario N salidas usuario N peticiones usuario N ficheros N interfaces externas Total contadores Multiplicador de complejidad Puntos de funcin
Contador
Factor de peso Simp. Med. Compl. 3 4 3 3 7 4 5 4 4 10 6 7 6 6 15 = = = = =
Ventajas de los puntos de funcin

4 Son independientes del lenguaje de
programacin
4 Pueden calcularse a partir de la especificacin 4 Usa informacin del dominio del problema 4 Resulta ms fcil a la hora de reusar
componentes
4 Se encamina a aproximaciones orientadas a
objetos
Puntos de funcin y estimacin

4 Los puntos de funcin (FP) pueden usarse para
estimar el nmero de lneas de cdigo (LOC) dependiendo del nmero medio de LCDs por PF para un lenguaje dado (AVC)
m LOC = AVC * nmero de puntos de funcin m AVC es un factor dependiente del lenguaje que vara
desde 200-300 para lenguaje ensamblador hasta 240 para un lenguaje 4GL
4 Los puntos de funcin son muy subjetivos.
Dependen del estimador.

Puntos de objeto
4 Los puntos de objeto son una medida alternativa
relacionada con la funcionalidad cuando se utilizan lenguajes 4GLs o similares para el desarrollo 4 Los puntos de objeto NO son clases de objetos 4 El nmero de puntos de objeto en un programa es una estimacin ponderada de:
m El nmero de pantallas que son visualizadas por
separado m El nmero de informes que se producen por el sistema m El nmero de mdulos 3GL que deben desarrollarse para complementar el cdigo 4GL
Estimacin de puntos de objeto

4 Son mas fciles de estimar a partir de una
especificacin que los puntos de funcin, ya que solamente consideran pantallas, informes y mdulos 3GL
4 Por lo tanto pueden estimarse en fases tempranas
del proceso de desarrollo. En estas etapas resulta muy difcil estimar el nmero de lneas de cdigo de un sistema
Tema 2.
15
Factores que afectan la product.

4 Experiencia en el dominio de la aplicacin 4 Calidad del proceso 4 Tamao del proyecto 4 Tecnologa de soporte 4 Entorno de trabajo
Tema 2.
16
Calidad y productividad
4 Todas las mtricas basadas en volumen/unidad de
tiempo son engaosas debido a que no tienen en cuenta la calidad

4 La productividad puede incrementarse
generalmente a costa de la calidad

4 No est claro cmo la productividad y las mtricas
de calidad estn relacionadas

4 Las mtricas de productividad deberan usarse
nicamente como gua

Tcnicas de estimacin (I)

4 No existe una forma simple de obtener estimaciones
exactas del esfuerzo requerido para desarrollar un sistema software

m Las estimaciones iniciales se basan en informacin
incompleta en la definicin de requerim. del usuario

m El software puede tener que ejecutarse sobre ordenadores
no usuales o usar nuevas tecnologas

m Puede desconocerse a la gente que interviene en el proy.
Tema 2.
18
Tcnicas de estimacin (II)

4 Modelado algortmico de costes 4 Juicio experto 4 Estimacin por analoga 4 Ley de Parkinson 4 Pricing to win
Tema 2.
19
Modelado algortmico de costes

4 Es una aproximacin que utiliza frmulas obtenidas
a partir de informacin histrica. Suele basarse en el tamao del software

4 La mayora de modelos tienen una componente
exponencial (los costes no crecen normalmente de forma lineal con el tamao del proyecto)
m Esfuerzo = A TamaoB M
Tema 2.
20
Exactitud de la estimacin
4 El tamao de un sistema software puede conocerse
con exactitud solamente cuando est terminado

4 Algunos factores que influyen en el tamao final
son:
m Uso de COTs y componentes m Lenguaje de programacin utilizado m Distribucin del sistema
4 La estimacin del tamao se realiza de forma ms
exacta a medida que el desarrollo del sistema progresa

Estimar la incertidumbre
4x
2x
Feasibility Requirements
Design
Code
Delivery
0.5x
0.25x
Tema 2.
22
Juicio experto
4 Uno o ms expertos, tanto en desarrollo de software
como en el dominio de la aplicacin usan su experiencia para predecir los costes de software. Se realizan iteraciones hasta que se alcanza un consenso 4 Ventajas: Mtodo de estimacin relativamente barato. Puede ser bastante exacto si los expertos tienen experiencia directa en sistemas similares 4 Desventajas: Muy impreciso si no se dispone de los expertos adecuados!
Tema 2.
23
Estimacin por analoga

4 El coste de un proyecto se calcula por comparacin
con proyectos similares en el mismo dominio de aplicacin

4 Ventajas: Bastante preciso si se disponen de datos
de proyectos previos
4 Inconvenientes: Imposible de realizar sin no se han
abordado proyectos comparables. Necesita un mantenimiento sistemtico de una base de datos
Tema 2.
24
Ley de Parkinson
4 Los costes del proyecto estn en funcin de los
recursos disponibles, utilizando todo el tiempo permitido.

4 Ventajas: No realiza presupuestos "abultados" 4 Inconvenientes: El sistema normalmente no termina
Tema 2.
25
Pricing to win
4 El coste del proyecto est en funcin de lo que el
cliente est dispuesto a pagar

4 Ventajas: La empresa desarrolladora consigue el
contrato
4 Inconvenientes: La probabilidad de que el cliente
obtenga el sistema que quiere es pequea. Los costes no reflejan realmente el trabajo requerido
Tema 2.
26
Estimacin ascend. y descend.

4 Cualquiera de estas aproximaciones puede
utilizarse de forma ascendente o descendente 4 Descendente

m Comienza a nivel de sistema y evala la totalidad de
funcionalidades y cmo stas se subdividen en susbsistemas

4 Ascendente
Comiemza a nivel de componentes y estima el esfuerzo requerido para cada componente. Dichos esfuerzos se aaden a la estimacin final
Tema 2.
27
Estimacin descendente
4 Se puede usar sin conocer la arquitectura ni los
componentes que formarn parte del sistema

4 Tiene en cuenta costes tales como integracin,
gestin de configuraciones y documentacin

4 Puede infra-estimar costes relacionados con la
resolucin de problemas tcnicos de bajo nivel difciles de resolver
Tema 2.
28
Estimacin ascendente
4 Se puede usar cuando la arquitectura del sistema
es conocida y los componentes han sido identificados

4 Proporciona estimaciones bastante exactas si el
sistema se ha diseado con detalle

4 Puede infra-estimar costes a nivel de sistema, tales
como integracin y documentacin
Tema 2.
29
Comparando mtodos
4 Cada mtodo tiene sus ventajas e inconvenientes 4 La estimacin debera basarse en varios mtodos 4 Si el resultado de aplicar varios de ellos difiere
mucho, es que no se dispone de suficiente informacin

4 Muchas veces el mtodo Pricing to win es el nico
aplicable
Tema 2.
30
Modelo COCOMO
4 COnstructive COst MOdel
4 Es un modelo emprico basado en la experiencia
con proyectos (grandes)

4 Es un mtodo bien documentado, cuya primera
versin se public en 1981

4 La ltima versin, COCOMO 2, tiene en cuenta
diferentes aproximaciones de desarrollo, reutilizacin, etc.

COCOMO 81
Project complexity Simple Moderate Formula PM = 2.4 (KDSI)1.05 M PM = 3.0 (KDSI)1.12 M PM = 3.6 (KDSI)1.20 M Description Well-understood applications deve loped by small teams. More complex projects where team members may have lim ited experience of related systems. Complex projects where the software is part of a strongly couple d complex of hardware, software, regulations and operational procedures.
Embedded
Tema 2.
32
Niveles COCOMO 2
4 COCOMO 2 es un modelo de tres niveles que
permite estimaciones cada vez ms detalladas y que pueden realizarse a la vez que progresa el desarrollo del proyecto 4 Nivel inicial de prototipado
m Estimaciones realizadas con puntos de objeto y una
frmula simple para el clculo del esfuerzo

4 Nivel inicial de diseo
m Estimaciones realizadas con puntos de funcin
convertidas en lneas de cdigo

4 Nivel post-arquitectura
m Estimaciones basadas en lneas de cdigo fuente
Nivel inicial prototipado

4 Soporta proyectos con prototipado y proyectos que
hacen uso intensivo de la reutilizacin 4 Basado en estimaciones estndar de la productividad del desarrollador en puntos-objeto/mes 4 Tiene en cuenta el uso de herramientas CASE 4 La frmula es:
m PM = ( NOP (1 - %reuse/100 ) ) / PROD m PM es el esfuerzo en personas-mes, NOP es el nmero
de puntos de objeto, y PROD es la productividad
Tema 2.
34
Productiv. de puntos de objeto

4 La productividad (PROD) depende de:
m m
La experiencia y capacidad del desarrollador Las capacidades de la herramienta CASE utilizada
Deve lopers expe rience and capabilit y ICASE maturity and capabilit y PROD (NOP/month)
Very low
Low
Nominal
High
Very high
Very low 4
Low 7
Nominal 13
High 25
Very high 50
Tema 2.
35
Nivel inicial de diseo

4 Las estimaciones pueden hacerse despus de que
los requerimientos hayan sido establecidos 4 Basado en las frmulas estndar para mtodos algortmicos
m PM = A TamaoB M + PMm en donde m M = PERS RCPX RUSE PDIF PREX FCIL
SCED m PMm = (ASLOC (AT/100)) / ATPROD

m A = 2.5 segn la calibracin inicial, Tamao se da en
KLOC, B vara desde 1.1 hasta 1.24 dependiendo de la novedad del proyecto, la flexibilidad del desarrollo, la gestin de riesgos, y la madurez del proceso
Multiplicadores (M)
4 Los multiplicadores reflejan la capacidad de los
desarrolladores, requerim. no funcionales, la familiaridad con la plataforma de desarrollo, etc.

m RCPX - fiabilidad de producto y complejidad m RUSE - reutilizacin requerida m PDIF - dificultad de la plataforma m PREX - experiencia del personal m PERS - capacidad del personal m SCED - agenda requerida m FCIL - facilidades de soporte de grupo
4 PM refleja la cantidad de cdigo generada
automticamente
Nivel post-arquitectura
4 Usa la misma frmula que la estimacin inicial de diseo
m PM = A TamaoB M + PMm
4 Se ajusta la estimacin de tamao para que tenga en
cuenta
m La volatilidad de los requerimientos m Grado de posible reutilizacin m ESLOC = ASLOC (AA + SU +0.4DM + 0.3CM +0.3IM)/100
6 ESLOC es el nmero de lneas de cdigo nuevo. ASLOC es el nmero de lneas de cdigo reusable que debe modificarse, DM es el porcentaje de diseo modificado, CM es el porcentaje de cdigo que se modifica, IM es el porcentaje del esfuerzo original de
integracin del software reusado. 6 SU es un factor basado en la interpretacin del coste del software, AA es un factor que refleja los costes de evaluacin iniciales para decidir si el software puede reutilizarse.
El trmino exponente (B)

4 Depende de 5 factores de escala. La suma de
dichos factores se divide por 100 y se aade a 1.01 4 Ejemplo

m Antecedentes - proyecto nuevo - 4 m Flexibilidad desarrollo - no implicacin cliente - Muy
alto - 1 m Arquitectura/resolucin riesgos - No anlisis de riesgos - Muy bajo - 5 m Cohesin del grupo - nuevo grupo - nominal - 3 m Madurez proceso - algn control - nominal - 3
4 El factor de escala es 1.17
Factores de escala de exponente

Scale factor Precedentedness Explanation Reflects the previous experience of the organisation with this type of project. Very low means no previous experience, Extra high means that the organisation is completely familiar with this application domain. Reflects the degree of flexibility in the development process. Very low means a prescribed process is used; Extra high means that the client only sets general goals. Reflects the extent of risk analysis carried out. Very low means littl e analysis, Extra high means a complete a thorough risk analysis. Reflects how well the development team know each other and work together. Very low means very difficult interactions, Extra high means an integrated and effective team with no communication problems. Reflects the process maturity of the organisation. The computation of this value depends on the CMM Maturity Questionnaire but an estimate can be achieved by subtracting the CMM process maturity level from 5.
(B)
Development flexibility Architecture/risk resolution Team cohesion
Process maturity
Tema 2.
40
Multiplicadores (M)
4 Atributos del producto 4 Atributos del ordenador
4 Atributos del personal 4 Atributos del proyecto
Tema 2.
41
Conductores de coste del proy.

Product attributes RELY Required system reliability CPLX Complexity of system modules DOCU Extent of documentation required Computer attributes TIME Execution time constraints PVOL Volatilit y of development platform Personnel attributes ACAP Capability of project analysts PCON Personnel continuity PEXP Programmer experience in project domain Project attributes TOOL Use of software tools DATA RUSE Size of database used Required percentage of reusable components
STOR
Memory constraints
PCAP AEXP LTEX
Programmer capabilit y Analyst experience in project domain Language and tool experience
SITE
Extent of multi-site working and quality of site communications Tema 2.
Development schedule compression Francisco Mora (DCCIA, Universidad de Alicante, 2002)
SCED
42
Efectos de los conduct. de coste

Exponent value System size (including factors for reuse and requirements volatility) Initial COCOMO estimate without cost drivers Reliability Complexity Memory constraint Tool use Schedule Adjusted C OCOMO estimate Reliability Complexity Memory constraint Tool use Schedule Adjusted C OCOMO estimate 1.17 128, 000 DSI 730 person-months Very high, multiplier = 1.39 Very high, multiplier = 1.3 High, multiplier = 1.21 Low, multiplier = 1.12 Accelerated, multiplier = 1.29 2306 person-months Very low, multiplier = 0.75 Very low, multiplier = 0.75 None, multiplier = 1 Very high, multiplier = 0.72 Normal, multiplier = 1 295 person-months
Tema 2. 43
(M)
Planificacin del proyecto

4 Los modelos algortmicos de costes proporcionan una
base para la planificacin del proyecto en tanto que permiten comparar estrategias alternativas 4 Ejemplo: desarrollo de un sistema espacial empotrado
m Debe ser fiable m Debe tener un peso mnimo (nmero de chips) m Multiplicadores de fiabilidad y restricciones del
ordenador > 1
4 Componentes de coste
m Hardware destino m Plataforma de desarrollo m Esfuerzo requerido
Opciones de gestin
EJEMPLO
A. Use existing hardware, development system and development team
B. Processor and memory upgrade Hardware cost increase Experience decrease
C. Memory upgrade only Hardware cost increase
D. More experienced staff
E. New de velopment system Hardware cost increase Experience decr ease
F. Staff with hardware experience
Tema 2.
45
Gestin de opciones de coste

EJEMPLO
Option RELY STOR TIME TOOL S A B C D E F 1.39 1.39 1.39 1.39 1.39 1.39 1.06 1 1 1.06 1 1 1.11 1 1.11 1.11 1 1 0.86 1.12 0.86 0.86 0.72 1.12 LTEX Total effort Software cost Hardwa re cost 1 63 949393 100000 1.22 88 1313550 120000 1 60 895653 105000 0.84 51 769008 100000 1.22 56 844425 220000 0.84 57 851180 120000 Total cost 1049393 1402025 1000653 897490 1044159 1002706
Tema 2.
46
Seleccin de opciones
4 Opcin D (usa ms personal con experiencia)
parece la mejor alternativa

m Sin embargo tiene un alto riesgo asociado ya que
personal con experiencia puede ser difcil de encontrar

4 Opcin C (actualizacin memoria) tiene un menor
ahorro de costes, pero un riesgo muy bajo En conjunto, el modelo revela la importancia del personal con experiencia en el desarrollo del software
Tema 2.
47
Duracin y personal del proyecto

4 Adems de la estimacin del esfuerzo, se debe
estimar el tiempo requerido para terminar el proyecto, as como el personal necesario

4 La duracin del proyecto puede estimarse mediante
la frmula de COCOMO 2
m TDEV = 3 (PM)(0.33+0.2*(B-1.01)) m PM es el esfuerzo.
La duracin es independiente del nmero de gente que trabaje en el proyecto (depende del esfuerzo total invertido en el proyecto)
Puntos clave
4 Es necesario estimar costes: (esfuerzo, tiempo de 4 4
4 4
desarrollo y nmero de recursos) La productividad es un factor a tener en cuenta a la hora de realizar estimaciones Existen varias tcnicas de estimacin de costes. La estimacin algortmica de costes es difcil al necesitar una estimacin previa de atributos del producto terminado Los modelos de estimacin algortmicos suponen una opcin de anlisis cuantitativo El tiempo necesario para completar un proyecto no es proporcional al nmero de personas que trabajan en el mismo

Estimacion de Costos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estimacion de Costos

Cargado por

Copyright:

Formatos disponibles

Tema 2.

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

personal del restaurante, etc.)

Cost estimate uncertainty

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

tecnologa son efectivas.

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

funcin, puntos de objeto)

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

baja ser su productividad aparente.

programador, mayor ser su productividad

cada factor por su peso y sumando todos ellos

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Clculo de los puntos de funcin(I)

Establecer contadores para el dominio de entrada e interfaces del sistema

Establecer pesos y evaluar la complejidad

Asignar niveles de complejidad o pesos para cada contador

Evaluacin de factores globales

Calcular los puntos de funcin

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Clculo de los puntos de funcin(II)

Factor de peso Simp. Med. Compl. 3 4 3 3 7 4 5 4 4 10 6 7 6 6 15 = = = = =

Ventajas de los puntos de funcin

Puntos de funcin y estimacin

Dependen del estimador.

Estimacin de puntos de objeto

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Factores que afectan la product.

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

tiempo son engaosas debido a que no tienen en cuenta la calidad

generalmente a costa de la calidad

de calidad estn relacionadas

nicamente como gua

Tcnicas de estimacin (I)

exactas del esfuerzo requerido para desarrollar un sistema software

incompleta en la definicin de requerim. del usuario

no usuales o usar nuevas tecnologas

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Tcnicas de estimacin (II)

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Modelado algortmico de costes

a partir de informacin histrica. Suele basarse en el tamao del software

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

con exactitud solamente cuando est terminado

4 La estimacin del tamao se realiza de forma ms

exacta a medida que el desarrollo del sistema progresa

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Estimacin por analoga

con proyectos similares en el mismo dominio de aplicacin

abordado proyectos comparables. Necesita un mantenimiento sistemtico de una base de datos

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

recursos disponibles, utilizando todo el tiempo permitido.

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

cliente est dispuesto a pagar

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

Estimacin ascend. y descend.

utilizarse de forma ascendente o descendente 4 Descendente

funcionalidades y cmo stas se subdividen en susbsistemas

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

componentes que formarn parte del sistema

gestin de configuraciones y documentacin

resolucin de problemas tcnicos de bajo nivel difciles de resolver