compendio de ingeniería del...
TRANSCRIPT
2.3 ESTIMACION DE PROYECTOS
Ingeniería de SoftwareINF - 163
Resumen preparado por Miguel Cotaña1
25/08/2011
Larry Putnam, ha apuntado que la
gestión del desarrollo de software
considera la estimación como una
actividad que permite obtener,
principalmente, respuestas a las
siguientes preguntas:
¿Cuánto Costará?
¿Cuánto tiempo llevará hacerlo?2
La gestión de un proyecto es una tarea
vital para el éxito del mismo. Dentro de
la gestión, la planificación juega un
importante rol, debido a que es en esta
etapa donde se debe hacer las
asignaciones de los recursos
disponibles, para lo que es necesario
estimar costos y plazos para el
proyecto a realizar.
3
La planificación del proyecto software
tiene que estimar 3 cosas antes de que
comience el proyecto: cuanto durará,
cuanto esfuerzo requerirá y cuanta
gente estará implicada.
Uno de los parámetros críticos de la
estimación es determinar su exactitud.
Además el planificador debe predecir
los recursos de Hw y Sw que va a
requerir y el riesgo implicado.4
No sólo es necesario
aportarle una solución sino que
ésta solución debe implantarse en un tiempo y con unos costes
acordados.
5
COSTE
TIEMPO
REQUISITOS
OBJETIVO
La estimación requiere: experiencia,buena información histórica, coraje deconfiar en las métricas, para obtenerbuenos resultados, debido a que cadaproyecto es diferente, cada empresa esdiferente y el contexto de los sistemasque desarrollamos cambianconstantemente, no existe un métodoque se adapte completamente acualquier proyecto, así la estimacióndebe ajustarse localmente.
6
7
Estimar
Horas
hombre
Estimar
El
costo
Determinar
Plazos de
entrega
Determinar
Personal
involucrado
Estimación enfoque tradicional
Existe cuatro factores que influyensignificativamente en las estimaciones:
La complejidad del proyecto;
El tamaño del proyecto;
El grado de incertidumbreestructural;
Disponibilidad de informaciónhistórica.
8
Técnicas de descomposición: Tamaño del Sw.
9
¿Cómo se define tamaño del software?
Es un resultado cuantificable delproyecto. Se pueden asumir dosenfoques:
Directo: se mide mediante líneasde código (LDC);
Indirecto, se mide mediante puntosde función (PF).
10
Puntos de
Función sin
ajustar
Puntos de
Función
ajustados
Líneas
De código
Del software
Ratio
Líneas de
Código PF
Estimación: método Punto Función
11
Putman y Myers sugieren:
Tamaño de lógica difusa;
Tamaño de punto de función;
Tamaño de componentes estándar;
Tamaño del cambio.
Estos resultados se fusionanestadísticamente para crear unaestimación basada en tres puntos odel valor esperado, se desarrolla:valores optimistas (bajos), valoresprobables y valores pesimistas (altos)
12
Estimación basada en el problema:
Los datos de LDC y PF son distintastécnicas de estimación, pero que tienenvarias características en común, y seutilizan en dos formas para estimar elproyecto de software:
Como variable para estimar eltamaño del software;
Como métrica de línea baserecolectada de proyectoshistóricos.
13
Estimación con casos de uso:Desarrollar un enfoque de estimación decasos de uso es un problema debido a:
Están descritos con diferentes grados deabstracción (dependen del usuario);
Los casos de uso no explican lacomplejidad de las funciones y de lascaracterísticas del software;
Los casos de uso no explican elcomportamiento de las diferentes funcionesy características.
14
Para evitar estos problemas Smithsugiere el uso de los casos de uso en laestimación pero dentro de un contextode “jerarquía estructural”, ésta sedescribe con no más de 10 casos de usoy 30 escenarios distintos para cada casode uso.
Como en toda estimación utilizamosdatos históricos según la ecuación:
15
LDC estimada = N x LDCprom + [(Sa/Sh - 1) + (Pa/Ph – 1)] x LDCajuste
Donde:
N = número real de casos de uso
LDCprom = promedio histórico de LDC
LDCajuste = diferencia entre este proyecto y los
proyectos promedio
Sa = escenarios reales de casos de uso
Sh = escenarios promedio de casos de uso
Pa = páginas reales por caso de uso
Ph = páginas promedio por caso de uso
Modelos empíricos de estimación
16
No hay ningún modelo específico paratodo proyecto de software, como vimosen las secciones anteriores utilizamosdatos históricos, pero éstos estánlimitados a una muestra pequeña deproyectos anteriores, además que cadaescenario y grupo de trabajo esdiferente, da lugar a que cada modelose debe adecuar localmente.
17
Estimar
Horas
hombre
Estimar
Tiempo
total
Determinar
Personal
involucrado
Estimar
El
costo
Determinar
Lineas de
codigo
Establecer
Plazo de
entrega
Estimación: método COCOMO
Estimación del Costo
18
La estimación de costos es una de las
más difíciles y erráticas tareas de la
ingeniería de software; es difícil hacer
estimaciones exactas durante la fase de
planeación de un desarrollo debido a la
gran cantidad de factores desconocidos
en ese momento.
Reconociendo este problema, algunas
organizaciones utilizan una serie de
estimadores de costos.
19
Los factores principales queinfluyen en el costo delsoftware son: Capacidad del
programador; Complejidad del
producto; Tamaño del programa; Tiempo disponible; Confiabilidad requerida; Nivel tecnológico.
20
Capacidad del programador: Por
numero de líneas que puede generar al
mes. En proyectos muy grandes, las
diferencias individuales tienden a
compensarse, pero en proyectos de cinco
programadores o menos la diferencia
puede ser muy importante.
21
COMPLEJIDAD DEL PRODUCTO
Programas de Aplicación
Programas de Apoyo
Programas de Sistema
Procesamiento de datos
Compiladores Sistemas de Bases de Datos
Programas científicos Ligadores Sistemas Operativos
Sistema de Inventarios
Sistemas de Tiempo Real
22
Esfuerzo total en meses delprogramador (PM):
KDSI (número de millares de instrucciones decódigo fuente entregadas con el producto)
Prog. aplicación: PM= 2.4 * (KDSI)** 1.05
Prog. apoyo : PM= 3.0 * (KDSI)** 1.12
Prog. sistema: PM= 3.6 * (KDSI)** 1.20
23
Tiempo de desarrollo para unprograma (TDEV) en meses:
Ya habiendo calculado PM
Prog. aplicación: TDEV= 2.5 * (PM)** 0.38
Prog. apoyo : TDEV= 2.5 * (PM)** 0.35
Prog. sistema: TDEV= 2.5 * (PM)** 0.32
24
Nivel promedio de contratación(personas por proyecto):
Dado el número total de meses programador deun proyecto y el tiempo nominal de desarrollorequeridos
Prog. Aplic.: 176.6 PM / 17.85 MO = 9.9 programadores
Prog. apoyo: 294 PM / 18.3 MO = 16 programadores
Prog. Sist.: 489.6 PM / 18.1 MO = 27 programadores
25
Tiempo disponible:
Es el esfuerzo total del proyecto que se
relaciona con el calendario del trabajo asignado
para la terminación del proyecto. Donde para
Boehm es muy importante las siguientes
variables.
Esfuerzo Relativo ( E/ E Nominal)
Calendario Relativo T Deseado/ T Nominal
Para Putman, el esfuerzo de un proyecto es
inversamente proporcional al tiempo de
desarrollo elevado a la cuarta que se ve
reflejado en una curva.
E = K/ /Td**4).
26
Confiabilidad requerida:
La confiabilidad de un producto puede
definirse como la probabilidad de que un
Programa desempeñe una función requerida
bajo ciertas condiciones especificadas y durante
cierto Tiempo.
La confiabilidad puede expresarse en términos
de los siguiente puntos:
Exactitud;
Firmeza;
Cobertura;
Consistencia del código fuente.
27
Las características de la confiabilidad pueden
instrumentarse en un producto de
programación, pero existe un costo asociado
con los siguiente puntos:
Nivel de análisis;
Diseño;
Instrumentación;
Esfuerzo de verificación;
Validación.
28
Factores multiplicadores de esfuerzopara ajustes por confiabilidad.
CATEGORIA CONSECUENCIA DE LA FALLA FACTOR
Muy baja Alguna molestia menor 0,75
Baja Pérdidas fáciles de recuperar 0,88
Nominal Dificultad relativa a la recuperación
1,00
Alta Gran pérdida financiera 1,15
Muy alta Riesgo de una vida 1,40E
29
Nivel tecnológico:
El nivel de tecnología empleado en un
proyecto de programación se refleja en el
lenguaje utilizado, las practicas y las
herramientas de programación utilizadas.
Sabemos que el número de líneas de código
fuente escrita por día es independiente del
lenguaje de programación y que las
proposiciones escritas en un lenguaje de alto
nivel como JAVA o el VISUAL BASIC suelen
generar varias instrucciones a nivel de
Maquina .
Técnicas de estimación de costos
30
En la mayor parte de las organizaciones,
la estimación de costos se basa en las
experiencia pasadas.
La estimación de costos puede llevarse a
cabo en forma jerárquica de abajo hacia
arriba o de arriba hacia abajo.
31
La estimación hacia abajo se enfoca
primero a los costos del nivel del
sistema, así como a los costos de
manejo de la configuración, del
control de calidad, de la integración
del sistema , del entrenamiento y de
las publicaciones de la
documentación.
32
Estimación hacia arriba, primero se
estima el costo del desarrollo de
cada modulo; tales costos se
integran para obtener un costo
total. Esta técnica tiene la ventaja
de enfocarse directamente a los
costos del sistema.
Algunos enfoques consideran:
Juicio experto;
Estimación de costo por la
técnica Delfi;
Estructuras de división de
trabajo;
Modelos de costo por algoritmos
o módulos.
33
Razones de difícil estimación
No existe un modelo universal;
Hay muchas personas implicadas en
los proyectos que precisan de
estimaciones;
La utilidad de una estimación
dependerá de la etapa de desarrollo
en la que nos encontremos;
La estimación, a menudo se realiza
superficialmente;
34
35
Las estimaciones claras, completas y
precisas son difíciles de formular;
Las características del Sw y de su
desarrollo hacen difícil la estimación;
Existe tendencia aparente hacia la
subestimación;
Existen malas interpretaciones;
El estimador tiende a reducir en
algún grado, para hacer más
aceptable la oferta.
36
QUÉproducto
CON QUÉsignificado
QUIÉNPersonal
CÓMOProyecto
PARA QUIÉNusuario
Tamaño sw RestriccionesOrdenador
Calidad personal
Req. durac. Proyecto
participación
Calidadrequerida
Tiempo ejec. Resp. Mem.
Experiencia Dilatación comprensi.
estabilidad
Compleji-dad del Sw
Herramientas Organiza-ción
experiencia
Nivel de utilización
Técnicas Prototipado conocimientos
Documen-tación
Programación Modeladoágil
Equipos
Tipo aplicación
Equipo de programación
Matriz de organizació
procedimiento
Requisitos de un buen estimador
No tiene ningún interés, directo ni
indirecto en los resultados del proceso
de estimación:
Formación y experiencia profesional;
Juicio independiente;
Basarse en metodos que pueda ser
explicado, cuestionado, discutido y
auditado por otros expertos;
Usa herramientas de estimación;
Documentar la estimación.37
Salidas del proceso de estimación
¿cuánta gente se necesita?;
¿De qué perfiles?;
¿Cuáles son los riesgos?;
¿Cómo afectan las restricciones
impuestas a las estimaciones?;
¿Cuánto esfuerzo se necesita para
realizar cada fase del ciclo de vida?;
¿Cómo impacta este proceso en el
resto de proyectos de la empresa?;
38
39
¿Cuál será el esfuerzo para
mantener este proyecto?;
¿Cuál será el tamaño del sistema
(lineas de código)?;
¿Cuántos defectos tendrá el
producto?;
¿Cuánta documentación será
generada?;
¿Cuál será el esfuerzo para generar
dicha documentación?.
Riesgos en la Estimación
Subestimación del tamaño;
El tiempo requerido para desarrollar
el producto está subestimado;
La tasa de reparación de defectos
está subestimada;
Información imprecisa acerca delproyecto a estimar; Caos en el procesos de desarrollo delproducto; Imprecisión del mismo proceso deestimación.
40