Beruflich Dokumente
Kultur Dokumente
Bibliografía:
•SW Estimation. Demystifying the Black Art. Steve McConnell.
Estimación
• Para poder planificar se debe estimar:
Esfuerzo
Costo
Duración
2
Estimación
• Estimación:
Predicción de cuánto va a durar un proyecto o cuánto
va a costar.
• Meta:
Un objetivo de negocio deseado.
• Compromiso:
Promesa de entregar la funcionalidad definida con un
nivel específico de calidad en una determinada fecha.
3
Costo /= Precio
• La relación entre el costo real de desarrollo y el precio cobrado al
cliente se ve influenciada por múltiples factores:
económicos
políticos
del negocio
de la propia organización
del proyecto específico a desarrollar
tales como:
oportunidad de mercado
incertidumbre en las estimaciones
condiciones contractuales
volatilidad de los requisitos del sistema
dificultades financieras
• Planificación:
proceso parcial que procura una meta.
objetivo: un resultado particular
Estimación =/ Plan
5
Plan
Consideraciones basadas en estimaciones
precisas:
Crear un WBS completo
Crear un cronograma detallado
Identificar el camino crítico
Priorizar la funcionalidad a entregar
Partir el proyecto en iteraciones
6
¿Buena predicción?
• Proyectos afectados por:
eventos externos imprevistos.
cambio de asumpciones.
El proyecto entregado no es el mismo que fue estimado.
control:
• Principio de Incertidumbre de Heisenberg: el observar algo lo
cambia.
Personal no Personal Funcionalidad
pronto cuando Requisitos asignado a inestable
planificado eliminados presentación eliminada
Resultado = 20
Estimación = 20 meses/persona
meses/persona El Proyecto
Personal reasignado
Nuevos
Personal menos para dar soporte a Nuevos
requisitos
experiente que lo proyecto anterior requisitos
planificado
7
Control
• Controlo el proyecto para llegar al compromiso.
• Ejemplo de la valija.
• Tamaño de la brecha:
preparación extra cuidadosa
apretar cronograma, presupuesto o funcionalidades
cambiar metas
• Imposible evaluar capacidad predictiva de la
estimación, pero sí su habilidad para permitir éxito
del proyecto.
• Propósito de la estimación: evaluar si metas son
suficientemente realistas como para poder controlar
el proyecto para alcanzarlas. (20%)
8
Influencias sobre la Estimación
• Tamaño
• Tipo de SW
• Factores del personal
• Lenguaje de programación
9
Tamaño
• Factor más importante – estimar tamaño.
• Consideraciones:
Economía de escala: Al producir en mayor cantidad
se reducen costos por unidad.
Deseconomía de escala: esfuerzo crece
exponencialmente con tamaño:
• por incremento en líneas de comunicación.
• en proyectos de diferente tamaño no se puede multiplicar
por la misma productividad.
10
Tipo de SW
• Productividad varía según tipo de proyecto:
11
Factores del Personal
• No puedo estimar con precisión si no sé quién
va a trabajar en el proyecto.
• Productividad personal varía por un factor de
10.
• En una misma organización, productividad
similar.
12
Lenguaje de Programación
• La experiencia del equipo en el leng. y herramientas -
40% de impacto en productividad gral.
• Herramientas de soporte y ambiente de programación –
hasta 50% de impacto. Cantidad de sentencias
Lenguaje comparado con C
• Algunos lenguajes generan más Assembler 2a1
C 1a1
funcionalidad por LOC. Cobol 1 a 1,5
Fortran 1a2
C# 1 a 2,5
C++ 1 a 2,5
Java 1 a 2,5
Visual Basic 1 a 4,5
Perl 1a6
Smalltalk 1a6
SQL 1 a 10
• Ley de Parkinson:
“El trabajo se expande hasta llenar el tiempo disponible para que se
termine" .
14
Métricas de Tamaño
Agenda:
Introducción
Métricas basadas en salidas:
•LOCs
Métricas basadas en funcionalidad:
•Puntos de Función
•Puntos de Característica
•Puntos Objeto
Métricas de Tamaño
• Tamaño permite:
Estimar esfuerzo y duración
Medir calidad (defectos / unidad de construcción)
Medir productividad (tamaño / unidad de esfuerzo)
• Ejemplos:
Casa: metros cuadrados de construcción
Carretera: kilómetros o kilómetros cuadrados
Software: ¿?
• LOCs
• Puntos de Función
• etc.
16
Métricas de Tamaño
• Componentes GUI
• Features (características) (ventanas, cuadros de
• Historias de usuario diálogo, reportes, etc.)
• Puntos de historia • Tablas de la BD
• Requisitos • Definiciones de interfaces
• Casos de Uso • Clases
• Puntos de Función • Funciones / subrutinas
• Páginas Web • Líneas de código
17
Líneas de Código
• Presentan varios problemas:
Variabilidad personal:
• En tamaño (mismo problema, distintas personas distintos LOCs)
• En productividad
¿En qué lenguaje?
Líneas: ¿físicas? ¿lógicas? En un lenguaje, ¿qué es una línea
lógica?
¿Con o sin líneas en blanco?
¿Con o sin comentarios?
¿Construidas (pe. scripts de BD, de test unitario, etc.) o libradas
al uso?
¿se cuenta código open source o de bibliotecas de terceros?
¿se cuentan interfaces de clases y declaraciones de datos?
18
Líneas de Código
• Necesidad de definir criterios de medición. Pe.
lenguaje
criterios para contar líneas en ese lenguaje (físicas o lógicas)
con/sin comentarios
construidas o libradas al uso
discriminación de líneas reusadas
19
Líneas de Código
• Productividad en proyectos iguales, en lenguajes distintos
• Proyecto A: 80.000 LOC C
Análisis Reqs./Dis. Sist.: 2 meses-persona
Dis.Det./Cod./PU/P.Int.: 4 meses-persona
Prueba Sistema: 2 meses-persona
Esfuerzo: 8 meses-pers. Productividad: 80.000/8= 10.000
• Proyecto A’: 42.000 LOC C++
Análisis Reqs/.Dis. Sist.: 2 meses-persona
Dis.Det./Cod./PU/P.Int.: 2 meses-persona
Prueba Sistema: 2 meses-persona
Esfuerzo: 6 meses-pers. Productividad: 42.000/6= 7.000
20
Líneas de Código
• Ventajas:
fácil de medir automáticamente a partir del código.
permite comparar proyectos y estimar proyectos
futuros basándose en datos de proyectos pasados.
la mayoría de las herramientas de estimación basan
sus estimaciones de esfuerzo y duración en LOCs.
21
Líneas de Código
• Desventajas:
para medir se precisa que el código esté construido
sujeto a variaciones personales/grupales y estilos de
programación.
deseconomía de escala
productividad varía según tipo de sw.
no pueden usarse para estimar asignaciones de tareas,
porque productividad varía entre programadores.
requisitos, diseño y testing no producen LOCs
depende del lenguaje:
• dificultad para medir productos implementados en más de un
lenguaje.
• difícil comparar proyectos en distintos lenguajes.
22
Puntos de Función
Agenda:
Visión general
IFPUG
Frontera de la aplicación
Transacciones
Datos
Puntos de Función - Visión General
• Albrecht (IBM-1979)
24
Modelo para contar PF Frontera de la
aplicación
No mantenidos
por la aplicación
EI Archivos Lógicos
Internos (ILF)
14
EQ “Características
Generales de la
Archivos de Interfaz
Aplicación
EO Externos (EIF)
Contiene datos
derivados y/o
afecta datos
comportamientotransacciones
PF = PFSA x Factor de Ajuste
25
Puntos de Función
Primera versión Segunda versión
B, M, A
Nro. Entradas x 4 (3,4,6)
Nro. Salidas x 5 (4,5,7)
Nro. Consultas x 4 (3,4,6)
26
Puntos de Función
• Ventajas:
Se puede medir sin que exista el código: a partir de documentación
de requerimientos y/o diseño
Independiente del lenguaje
• Desventajas:
aplicación restringida a sistemas con uso intensivo de datos
persistentes y poco peso de algoritmos (Sist. de Información)
Medir PF requiere esfuerzo
Variabilidad en mediciones individuales - Medidores expertos
Criticado por factores de ajustes:
• Demodé (altamente dependientes del momento tecnológico)
• Características inciden distinto en el esfuerzo, tienen igual peso
• ¿FA elegidos son independiente entre sí?
• Si uso PF para estimar tamaño y luego esfuerzo, corro el riesgo de
aplicar dos veces el mismo ajuste.
• Combinación de factores generalmente cerca de 1 son inocuos
27
Visión del Cliente-Usuario
• No todo archivo físico o tabla se traduce en un ILF o EIF
(archivos transitorios o de trabajo NO se cuentan)
• Una transacción que ocurre en múltiples entradas
físicas (archivo de transacciones o pantallas, con
idéntica lógica de procesamiento, se considera como
una sola transacción)
• Un mismo reporte físico, pantalla o archivo de salida
pueden corresponder a más de un EO/EQ
• Reordenar o reacomodar los datos no se considera
como lógica de procesamiento única
• Una misma salida en distintos medios ¿es una o varias
transacciones? No se han puesto de acuerdo.
28
Frontera de la Aplicación (I)
• Define lo que es “externo” a la aplicación
• Interfaz entre lo “interno” y el “mundo exterior”
• Se puede concebir como una “membrana” que atraviesan
los datos procesados por las transacciones (EI, EO, EQ)
• Encierra los archivos lógicos mantenidos por la
aplicación(ILF)
• Asiste en la identificación de los archivos lógicos
referenciados pero no mantenidos por la aplicación (EIF)
• Depende de la visión del negocio y externa del usuario
• Es independiente de consideraciones técnicas o de
implementación
29
Frontera de la Aplicación (II)
Usuario 1
RR.HH.
Fronteras
definidas a partir
de la visión del
Contabilidad negocio
Ventas
¿cómo impactaría en
la cuenta total de PF
considerar esta otra
No cumple con la aditividad: si uno
frontera?
componentes, la cuenta da menos.
30
Frontera de la Aplicación (III)
• Incide en la cuenta total de PF
al partir una aplicación se incrementan los PF totales porque los ILF se
cuentan una vez como tales (por lo menos) y también se cuentan como
EIF
• Se determina a partir de la visión de usuario basada en áreas
funcionales separadas y NO en consideraciones técnicas
una aplicación Cliente/Servidor es una unidad; la frontera debe
englobar a ambos: Cliente y Servidor
una aplicación que se extiende para que funcione en Internet no se
puede (por eso solo) considerar como dos aplicaciones a los efectos de
los PF
• Desconfiar de la frontera si:
no se identifican EIF
hay demasiados EIF o un mismo archivo es ILF en varias aplicaciones.
31
Transacciones
Modelo para contar PF Frontera de la
aplicación
No mantenidos
por la aplicación
EI Archivos Lógicos
Internos (ILF)
14
EQ “Características
Generales de la
Archivos de Interfaz
Aplicación
EO Externos (EIF)
Contiene datos
derivados y/o
afecta datos
comportamientotransacciones
PF = PFSA x Factor de Ajuste
33
Contar Transacciones
Pasos:
• Identificar transacciones
• Asignar a cada una un tipo (EI, EO, EQ)
• Identificar la cantidad de DET y FTR
• Asignar a cada una un valor de complejidad (Alta,
Media, Baja) en función de la cantidad de DET y FTR
Definiciones:
• Data Element Type (DET):
es un campo único (no repetitivo) reconocible por el usuario
• File Type Referenced (FTR):
es un tipo de archivo al que se hace referencia en una
transacción; tiene que ser un ILF o EIF
34
Tipos de Transacciones
Definiciones:
• EI (External Input) - Entrada Externa
Proceso elemental en el que datos cruzan la frontera de la
aplicación de afuera hacia adentro. La intención primordial es
mantener uno o más ILF y/o alterar el comportamiento del sistema.
• EO (External Output) - Salida Externa
Proceso elemental en el que datos derivados a partir de uno o más
ILF o EOF cruzan la frontera de adentro hacia fuera. Un EO puede
actualizar un ILF o alterar el comportamiento del sistema.
• EQ (External Query) - Consulta Externa
Proceso elemental en el que datos o información de control cruzan
la frontera de adentro hacia fuera. NO incluye datos derivados y
NO mantiene ningún ILF y NO altera el comportamiento del
sistema.
35
Proceso Elemental
Definición:
• Es la mínima unidad de actividad que tiene un significado para el
usuario
debe ser autocontenido, no requiere de otra actividad para que
adquiera significado
debe dejar al sistema en un estado consistente
Ejemplo:
Si el usuario desea agregar un empleado, puede requerir incorporar:
nombre
fecha de ingreso
CI
Este proceso
sueldo elemental se completa
estado civil al ingresar todos los
fecha de nacimiento datos requeridos
36
Tipos de Transacciones - Resumen
Función EI EO EQ
Altera el comportamiento del sistema IP O NO
Mantiene uno o más ILF IP O NO
Presenta información al usuario O IP IP
Presenta datos derivados al usuario O IP NO
37
Proceso en Transacciones
Tipo de Proceso EI EO EQ
Acepta datos o inf. de control que entra SI p p
Presenta información fuera de la frontera p SI SI
Altera el comportamiento del sistema p* p* NO
Al menos se actualiza un ILF p* p* NO
Fórmulas matemáticas y cálculos p p* NO
Crea datos derivados p p* NO
Al menos un ILF o EIF referenciado p p SI
Recupera datos o información de control p SI SI
Validaciones p p p
Se convierten valores equivalentes p p p
Selección y filtro de datos p p p
Se evalúan condiciones p p p
Reordena un conjunto de datos p p p
p=posible
p*=uno por lo menos debe estar presente
38
Transacciones - Unicidad
Se cuenta si se cumple al menos una de:
• Para EI:
lógica distinta de otras EI
el conjunto de DET distinto del de otras EI
conjunto de ILF o EIF distinto del de otras EI
• Para EO, EQ:
lógica distinta de otras EO o EQ
el conjunto de DET distinto del de otras EO o EQ
conjunto de ILF o EIF distinto del de otras EO o EQ
39
Complejidad de Tr - Número de FTR
2 FTR
40
Complejidad de Tr - Número de DET
42
Complejidad de EI - Número de DET
43
Complejidad de EQ/EO – Nro. de DET
2 DET:
valor y rótulo
44
Complejidad de Tr – Nro. de DET
NO CONTAR:
• Campos recuperados o derivados por el sistema y
almacenados en un ILF por el proceso elemental, si no
cruzaron la frontera de la aplicación
Ejemplo: Al imprimir cheques, el registro en el archivo se marca para no
volver a imprimirlo
Esta marca NO se cuenta como DET
• Literales
Ejemplo: Los títulos (si son fijos) no se cuentan como DET
• Variables generadas por el sistema relacionadas con el
paginado o fecha y hora
Ejemplos:
nros. de página
información de posicionamiento (filas 32 a 56 de 781)
Comandos para paginar (anterior, siguiente, barra de posicionamiento)
Fecha y hora
45
Caracterización de la complejidad
Para EI 1 a 4 DET 5 a 15 DET 16 o más DET
46
Contribución de Transacciones
47
Contribución de Transacciones
Ejemplo - Aplicación integrada por:
• Alta cliente (#cliente, nombre, dirección)
• Listado de clientes (#cliente, nombre, dirección)
• Consulta de la cantidad de clientes existentes
• un único ILF (Clientes)
Transacción Tipo Nivel Complejidad Cuenta
Alta Cliente EI Baja 3
Listado Clientes EQ Baja 3
Cantidad Clientes EO Baja 4
Total de Contribución de Transacciones: 10
48
Menúes de aplicación
• Empleado:
Nuevo
Modificar
Listar
Lista de Empleados
Apellido Nombre CI Sueldo
Pérez Juan 1.234.567-8 10.000
Martínez Pedro 2.345.678-9 20.000
Fernández María 3.456.789-0 30.000
Giménez Ana 4.567.890-1 40.000
Detalle Núcleo Familiar Cancelar
50
Consulta de Empleados
Archivo Empleados: (CI, apellido, nombre, sueldo)
• EQ
• 1 FTR
• DET:
Nombre y Apellido (nombre)
CI
Sueldo
Acciones (Detalle, Núcleo Familiar, Cancelar)
• Complejidad: Baja
• Contribución: 3 PF
51
GUI
• Radio buttons – 1 DET el grupo
• Check boxes – 1 DET cada opción
• Command buttons – La posibilidad de
especificar una acción cuenta como un DET
• Combo box – 1 DET (además es una EQ)
• Desplegar imagen – 1 DET
• Barra de desplazamiento – no cuenta
52
Ayuda sensible al contexto
• El usuario pidió que alta de empleado (nombre, CI, cargo)
en la aplicación RRHH tuviera ayuda sensible al contexto.
• La información de ayuda es mantenida por la aplicación
ASC en el archivo Ayuda, y es referenciada por las
aplicaciones RRHH, Contabilidad, Activo Fijo y Stock.
• Al apretar F1 despliega la descripción del campo bajo el
cursor.
¿Cómo se cuenta?
EQ, 1 FTR (Ayuda), 3 DET (#pantalla, #campo, texto)
53
Consulta Implícita
La modificación de datos del empleado es
incómoda si no parte de los datos que existen.
El usuario no pidió una consulta de los datos, sin
embargo la espera.
¿Cómo considerarla? EQ
54
Archivo para otra Aplicación
Al fin del día, la información de los cheques
impresos por la aplicación de RRHH se envía a la
aplicación Contable usando un archivo de texto
Archivos involucrados:
Cheque (#cheque, importe, banco, cuenta, orden)
Cheque_txt (línea)
¿Es un proceso elemental?
En caso afirmativo, ¿de qué tipo y complejidad?
55
Datos
Modelo para contar PF Frontera de la
aplicación
No mantenidos
por la aplicación
EI Archivos Lógicos
Internos (ILF)
14
EQ “Características
Generales de la
Archivos de Interfaz
Aplicación
EO Externos (EIF)
Contiene datos
derivados y/o
afecta datos
comportamiento transacciones
61
Caracterización de la complejidad
Para ILF/EIF 1 a 19 DET 20 a 50 DET 51 o más DET
Contribución de datos
\ Complejidad Baja Media Alta
Tipo de Archivo
Ejemplos:
• Para la aplicación de RRHH incluye al personal del
departamento de RRHH que interactúan con la
aplicación y a la aplicación contable que interactúa para
recibir la información de los asientos contables
correspondientes a la liquidación de sueldos
64
Contribución de Datos – Guía (I)
• ¿Los datos son un grupo lógico que soporta
requerimientos del usuario?
• Una aplicación puede usar un mismo ILF o EIF en múltiples
procesos, pero el archivo se cuenta una sola vez
• Un mismo archivo no se puede contar a la vez como ILF y EIF; si
cumple ambos criterios, contarlo como ILF
• Si un grupo de datos no fue contado como ILF ni EIF, contar sus
DET para el ILF o EIF que incluye al grupo
• No asumir que un archivo físico, tabla o clase de objetos
corresponde a un archivo lógico desde el punto de vista del
usuario
• No asumir que todo archivo físico debe ser contado o incluido
como parte de un ILF o EIF. Pe. Archivos temporales o de
trabajo.
65
Contribución de Datos – Guía (II)
• ¿Dónde se mantienen los datos, dentro o fuera
de la aplicación?
• Archivos lógicos mantenidos por más de una
aplicación se consideran como ILF al contar cada
una
• Recordar que en el caso anterior, en cada aplicación
sólo se consideran los DET que usa y estos se
determinan desde el punto de vista de cada
aplicación
66
Contribución de Datos – Ejemplo 1
Para la aplicación de RRHH el Usuario desea:
• Poder restringir el acceso a cada pantalla a
ciertas personas
• Poder cambiar estas restricciones
• Emitir un listado con todos los agregados o
cambios en las restricciones de acceso que
incluya los datos:
• Id de usuario que hizo el cambio
• Los datos de seguridad (id_usuario, id_pantalla,
tipo_acceso) anteriores y posteriores
• Fecha y hora del cambio
67
Contribución de Datos – Ejemplo 1
Archivos:
• Seguridad_Pantalla (id_usuario, id_pantalla, tipo_acceso)
• Seguridad_Auditoría (fecha_hora_cambio, id_usuario_cambio,
id_usuario_ant, id_pantalla_ant, tipo acceso_ant,
id_usuario_post, id_pantalla_post, tipo_acceso_post)
68
Contribución de Datos – Ejemplo 2
• La aplicación de Seguridad permite asignar a las
personas, permisos de acceso a las instalaciones y
recursos informáticos.
• En la aplicación de RRHH se mantienen los sig. datos
del archivo Empleado: (#empleado, CI, nombre,
fecha_nac)
• En la aplicación de Seguridad el encargado de
seguridad puede modificar el campo “nivel de
seguridad” y ver además los datos: #empleado, CI,
nombre.
¿Cómo contar el archivo Empleado en RRHH y en
Seguridad?
71
Puntos de Característica
• PF diseñados originalmente para sistemas de información.
• Variante para sistemas con complejidad algorítmica alta
(aplicaciones de tipo científico, de tiempo real y de
sistemas): Puntos de característica
• Se considera el número de algoritmos que resuelven un
problema complejo determinado.
• Se utiliza como multiplicador un único peso.
Cuenta Peso
Nro. Entradas x 4 =
Nro. Salidas x 5 =
Nro. Consultas x 4 =
Nro. Archivos x 10 =
Nro. Interfaces externas x 7 =
Nro. de algoritmos x 3 =
72
Puntos Objeto
• Son una medida indirecta de software que se calcula teniendo en cuenta el total de:
informes 2 PO 5 PO 8 PO
76
Calcular
• Recoger datos históricos para poder calcular
una estimación a partir de una cuenta.
• Ejemplos:
cuento cant. defectos abiertos / páginas web
calculo a partir de:
• tiempo promedio que llevó corregir defectos
• tiempo promedio para diseñar, implementar y testear
páginas web
• Puedo calibrar con 3 tipos de datos:
de la industria (desarrollos del mismo tipo de sw)
históricos de la organización
del proyecto
77
Datos de la Industria
• Productividad entre distintas organizaciones
varía por un factor de 10. (Pe. entre 25 y 250
meses-persona). ¿Uso promedio?
• Juicio de expertos son mejores que modelos de
la industria.
• Datos históricos son igual o mejores que juicio
de expertos.
78
Datos Históricos
• En proyectos medianos o gdes. las características organizacionales
influyen más que las capacidades personales en el resultado del proy.:
¿Se puede despedir empleados?
¿Personal con dedicación exclusiva o interrupciones de soporte?
¿Se puede contratar personal o se lo saca de otros proyectos?
¿La organización apoya prácticas efectivas de diseño, implementación,
aseguramiento de la Q y verificación?
¿La organización opera bajo regulaciones?
¿Alta rotación de personal en el empresa?
Datos históricos incluyen estos factores.
• Factores de ajuste de Cocomo son subjetivos; datos históricos, no.
• Se usa asunción simplificadora: las cosas van a ir más o menos igual
que en proyectos anteriores (no mejor, como querría).
• Datos a recoger:
Tamaño (LOCs)
Esfuerzo (meses-persona)
Duración (meses calendario)
Defectos (clasificados por severidad) 79
Técnicas de Estimación
80
Enfoques de Estimación
• Estimación global (visión de las diferentes áreas)
Desv.: pasar por alto dificultades técnicas asociadas a
componentes.
• Descomposición y estimación de c/componente (WBS):
Desv: pasar por alto esfuerzo de integración.
• pesimista, más probable, optimista
• distribución Beta: E =(p+4m+o)/6
• como en Pert; ¿se pueden considerar v.a. independientes? En
tamaño, sí, a menos del sesgo del estimador:
σ 2 = Σ σ 2 comp
σ = √ Σ σ 2 comp < √ (Σ σ comp) 2 = Σ σ comp
puedo tener σ de comp. gdes., pero σ total chica porque
los errores se compensan
81
Estimaciones basadas en Proxies
• Identificar un proxy:
correlacionado con lo que queremos contar
más fácil de contar o estimar
o disponible más tempranamente.
Pe. casos de prueba. Proxy = reqs.
• Contar o estimar los ítems del proxy
• Usar datos históricos para calcular.
• Fuzzy Logic
• Componentes Estándar
• Puntos de historia
• T-Shirt Sizing
83
Fuzzy Logic
• Clasificar características en MP, P, M, G, MG.
• Datos históricos: LOCs promedio por
característica.
• Calcular
Tamaño característica LOCs promedio por característica Cant. características LOCs estimadas
Muy pequeño 127 22 2794
Pequeño 253 15 3795
Mediano 500 10 5000
Grande 1014 30 30420
Muy grande 1998 27 53946
Total 104 95955
86
Juicio de Expertos
• Técnica Delphi (formal)
Consulta a varios expertos
C/experto estima por separado
Valor medio se distribuye y se pide ajuste de estimación
Variantes con discusión previa o justificaciones
distribuidas
Normalmente los resultados convergen rápidamente
87
Estimación por Analogía
• Un proyecto similar en tamaño, complejidad y tipo
de funciones a otro, probablemente dure y cueste
aproximadamente lo mismo.
• Modelo subjetivo:
Difícil determinar similitudes. Pe. Maratón
Difícil determinar cómo diferencias afectan costo
90
Métodos Algorítmicos
• Modelos que reflejan relación entre esfuerzo factores que lo
influencian (experiencia, tamaño, tipo de aplicación).
• Elaborados a partir de una gran muestra de proyectos de
diverso tamaño y complejidad, tomados de diversas
organizaciones.
• Sirve como base, cuando no se dispone de base histórica
propia.
En gral. de la forma: E=(a+b*Sc) m (X)
donde a, b y c son constantes (dependen de la org)
S es el tamaño estimado del producto – Tamaño es factor más
influyente
c gral. está entre 1 y 1.5. Refleja que el esfuerzo no crece
linealmente con el tamaño, sino que es mayor por manejo de la
complejidad. (Productividad decrece)
m es un multiplicador de ajuste que depende del vector X de
factores de ajuste
91
Métodos Algorítmicos
E= b Sc(y) m(X)
y: Elementos de escala para ajustar el exponente
x: Multiplicadores de esfuerzo
94
COCOMO II –
Multiplicadores de Esfuerzo (Post-Arq.)
4 categorías:
• Atributos del producto
Relativos a las características del sw a desarrollar
RELY -> Confiabilidad requerida
DATA -> Tamaño BD
CPLX -> Complejidad
RUSE -> Reuso de productos en proyecto y otros
DOCU -> Documentación requerida
• Atributos de la plataforma
Relativos a los req. de HW y SW del sistema
TIME -> Carga de Procesadores
STOR -> Restricciones de Memoria
PVOL -> Volatilidad de la Plataforma
95
COCOMO II –
Multiplicadores de Esfuerzo (Post-Arq.)
• Atributos del personal
Relativos a la experiencia y capacidades del equipo de desarrollo
ACAP -> Capacidad de Analistas
AEXP -> Experiencia de Analistas en dominio del proy.
PCAP -> Capacidad de Programadores
PEXP -> Experiencia de Programadores en el dominio del proy.
LTEX -> Experiencia en Lenguaje y Herramientas
PCON -> Continuidad del personal
97
Estimación – Personal requerido
• El personal requerido no puede calcularse
dividiendo el esfuerzo entre el tiempo de
desarrollo deseado.
• El nro. de personas que trabajan en el proyecto
depende de la fase de desarrollo.
• Cuantas más personas trabajan en un proyecto,
mayor el esfuerzo total por pérdidas debidas a
la comunicación.
• La incorporación de personal en últimas fases
incrementa el esfuerzo y ocasiona retrasos en
la fecha de finalización del proyecto.
98
Gestión de los Recursos
Humanos
Gestión de RR.HH.
• ¿Def.?
• Gestión pobre de RRHH – causa de fracaso del
proyecto.
• Factores críticos:
Consistencia
Respeto
Inclusión
Honestidad
100
Recursos Humanos y Organización
• Para determinar el calendario del proyecto y
estimar el esfuerzo y costo asociados, debemos
saber:
cuánta gente va a estar trabajando en el proyecto,
qué tareas van a desarrollar y
qué habilidades y experiencia deben tener.
101
Conformación del Equipo de
Desarrollo
• El trabajo en grupo se impone en el desarrollo de
SW:
por el tamaño del proyecto y
porque el problema a resolver abarca muchos aspectos
distintos en los que se requieren distintos expertos.
¿Cómo seleccionar el personal del
equipo de desarrollo?
• Fuentes:
CVs
Entrevistas
Referencias
102
Características del Personal
• Capacidad para desempeñar una tarea
• Interés en el trabajo
• Experiencia con aplicaciones similares, herramientas,
lenguajes, técnicas y ambiente de desarrollo
• Capacitación - estudios
• Capacidad para comunicarse con otros y compartir la
responsabilidad
• Capacidad de supervisión
• Capacidad para resolver problemas
• Adaptabilidad – Capacidad de aprender, aceptar y
asimilar cambios.
• Capacidad para resistir cierta cantidad de tensión.
• Personalidad
103
Estilos de Trabajo
INTUITIVO
INTUITIVO INTUITIVO
INTROVERTIDO: EXTROVERTIDO:
INTROVERTIDO
EXTROVERTIDO
Pregunta al resto Informa al resto
Reconoce sentimientos Reconoce sentimientos
RACIONAL RACIONAL
INTROVERTIDO: EXTROVERTIDO:
Pregunta al resto Informa al resto
Decide lógicamente Decide lógicamente
RACIONAL
¾ de técnicos son introvertidos (vs. 1/3 de la población)
104
Motivación
Maslow ’54
Necesidad
de realización
Necesidades
de estima
Necesidades sociales
Necesidades de seguridad
Necesidades fisiológicas
105
Motivación
En orgs. de desarrollo de SW, satisfacer:
• Necesidades sociales:
tiempo y lugares de encuentro, interacción entre los miembros
• Necesidades de estima:
reconocimiento público de sus logros
pago acorde a habilidades y experiencia
• Necesidades de realización:
hacerlos responsables por su trabajo
asignarles tareas demandantes pero no imposibles
proveer programa de capacitación
• Ser miembro de un grupo cohesivo es altamente motivador -
Motivar al grupo como tal.
106
Trabajo en Grupo
• Composición del grupo:
Balance de habilidades, experiencia y
personalidades
• Cohesión:
Equipo y no personas trabajando juntas
• Comunicaciones:
Comunicación efectiva
• Organización:
Todos satisfechos con su rol y valorados
107
Composición del Grupo
• Se pueden catalogar tres personalidades tipo genéricas:
Orientadas a la tarea. – La motivación es el trabajo en sí.
Orientadas a la relación. – La motivación es el trabajo en equipo y la
relación y presencia de otros compañeros de tarea.
Orientadas a sí mismas. - La motivación es éxito personal.
• Tiene que:
• Demostrar lealtad al grupo.
• Demostrar coherencia al tomar decisiones
• Exigir la aceptación universal de las decisiones una vez
tomadas
• Proteger al grupo como entidad frente al exterior.
• Debe comprender los factores humanos para evitar
demandas poco realistas sobre el personal.
109
Actividades del jefe de proyecto
• Organización del modo de trabajo.
• Asignar el personal
• Asignar/ajustar los roles y responsabilidades
• Definir/comunicar los objetivos
• Estimación del trabajo que puede realizar el personal
• Planificación de las tareas a realizar por cada miembro
del equipo.
• Control de las actividades del personal
• Motivar
• Facilitar la comunicación entre los integrantes
• Resolución de problemas haciendo uso del personal
disponible
• Brindar retroalimentación respecto a los logros
110
Cohesión del Grupo
• En un grupo cohesivo, los integrantes:
piensan en el grupo antes que en sí mismos
son leales al grupo
se identifican con los objetivos del grupo y con los
otros integrantes
tienden a proteger al grupo
• Ventajas:
se puede establecer un estándar de calidad
trabajo conjunto entre integrantes
todos conocen el trabajo de todos. Hay continuidad si
uno se va
responsabilidad del sw compartida (egoless
programming)
111
Cohesión del Grupo
• Para fomentar la cohesión:
eventos sociales con las familias
sentido de identidad del grupo, nombre y territorio
actividades de construcción de grupo: pe. deportes
• Problemas:
Resistencia irracional al cambio de líder
Pensamiento grupal – Habilidades erosionadas por
lealtad
112
Trabajo en grupo
Distribución del tiempo
Trabajo
individual
30%
Interacción con
otras personas
50%
Actividades no
productivas
20%
113
Comunicaciones
• Dentro del equipo de desarrollo las comunicaciones son
necesarias e inevitables para que el grupo trabaje con
eficiencia.
• Pero también son improductivas ya que mientras dura la
comunicación el individuo no está realizando su función.
• Por tanto, intentar minimizar y acortar las reuniones de
comunicación.
114
Comunicaciones
Dos personas 1 línea de comunicación
117
“Chief Programmer Team”
Chief
programmer
Assistant chief
programmer
Junior
programmers
118
“Chief Programmer Team”
• A cada una de las personas del equipo de desarrollo, se
le asignan una serie de tareas de forma individual, y
sólo responden de su trabajo ante el jefe de proyecto.
Existe muy poco trabajo combinado.
• La responsabilidad de coordinar todas las tareas es
únicamente del jefe de proyecto.
Jefe de proyecto
120
Equipo Democrático
• Todos los miembros del equipo participan en las
decisiones (democrático).
Jefes de grupo
Enlaces de comunicación
• Poco Estructuradas
Incertidumbre
Nuevas Técnicas o Tecnología
Proyectos Pequeños
Creatividad
123
Ambiente Físico de Trabajo
• El tamaño del puesto de trabajo, la luminosidad,
el ruido y el grado de intimidad afectan al
rendimiento.
• Lugar de trabajo que permita:
1. Intimidad: Para poder concentrarse y trabajar sin
interrupciones.
2. Conciencia exterior: A ser posible disponer de luz
natural y vista al exterior.
3. Personalización: Posibilidad de adaptar al gusto
propio el ambiente de trabajo personal.
4. Áreas comunes para intercambiar y discutir
124
Ciclo de Vida de un Equipo
• Integración
• Tormenta
• Aceptación
• Etapa productiva
• Desintegración
125
Reuniones (Problemas)
• El propósito es poco claro.
• Los participantes no están preparados.
• Gente clave está ausente o llega tarde.
• La conversación se aleja del propósito.
• Los participantes discuten, dominan la
conversación, o no participan.
• Las decisiones tomadas en la reunión luego
nunca se hacen efectivas.
A una reunión de 8 personas durante 2 horas
significa un esfuerzo de 16 horas/persona
126
Reuniones (Soluciones)
• Definir objetivo, agenda y duración
• Los participantes deben conocerlos con
antelación suficiente
• Definir quiénes deben (y no deben) participar
• Asignar el rol de coordinador o moderador para
ceñirse a la agenda
• Asignar el rol de secretario, responsable por el
acta, la que se debe distribuir a los participantes
127
Manejo de Conflictos
• ¿Qué opinar de un proyecto en el que no
aparece ningún conflicto?
• Conflicto: no siempre es malo
Puede ser estimulante
Promueven la creatividad
• A veces hay que “crearlos” (abogado del diablo)
para evaluar riesgos
• El manejo de conflictos es clave para el éxito de
un proyecto
128
Estilos de Manejo de Conflictos
Estilo Nivel de Eficacia
Evitarlo No lo resuelve (reaparece)
Suavizarlo Solución corto plazo, No lo
resuelve
130
Evaluación de Factibilidad
Estudio de Factibilidad (I)
• Estudio corto para resolver si es posible y
conveniente construir el sistema con la
tecnología existente, las restricciones de costo y
tiempo, etc.
132
Estudio de Factibilidad (II)
• Estudio y evaluación de alternativas
Técnicos Clientes
134
Eval. de Factibilidad - Cuándo
• Frecuentemente el Estudio de Factibilidad es
previo a un proyecto (ante-proyecto, pre-
factibilidad)
• Puede ser la etapa inicial
• A lo largo del proyecto, en puntos de control
preestablecidos, se vuelve a formular la
pregunta:
¿Vale la pena seguir?
135
Estudio de Factibilidad – Ejemplo
Proyecto “ComidaClick”
• Introducción
• Factibilidad de la solución
Factibilidad técnica
Factibilidad económica
• Impacto del proyecto
Impacto en el ámbito social
Impacto económico
Impacto ecológico
Impacto cultural
• Pertinencia del proyecto
• Conclusiones
136
Evaluación Financiera de Proyectos
Tasa de dto. 3,15% ANUAL
Inversión Inicial $ 50.000
PROYECTO 2 PROYECTO 3
PROYECTO 1 Semestres Ingresos Egresos Flujo Caja Reintegro Semestres Ingresos Egresos Flujo Caja Reintegro
0 (50.000) (50.000)
Semestres Ingresos Egresos Flujo Caja Reintegro 0
1 15.000 3.000
(50.000)
12.000
(50.000)
(38.000) 1 17.000 2.700 14.300 (35.700)
0 (50.000) (50.000) 2 16.000 3.200 12.800 (25.200) 2
3
17.000
17.000
2.700
2.700
14.300
14.300
(21.400)
(7.100)
3 18.000 3.500 14.500 (10.700)
1 20.000 6.000 14.000 (36.000) 4 18.000 3.800 14.200 3.500 4 17.000 2.700 14.300 7.200
5 18.000 4.000 14.000 5 17.000 2.700 14.300
2 22.000 7.500 14.500 (21.500)
3 25.000 6.000 19.000 (2.500) Tasa Dto. Semestral
Actualización de FF
1,56%
$ 64.366,84
Tasa Dto. Semestral
Actualización de FF
1,56%
$ 68.266,34
4 25.000 6.000 19.000 16.500 VAN $ 14.366,84 VAN $ 18.266,34
TIR 10,59% TIR 13,24%
5 25.000 6.000 19.000 Actualización Ingresos $ 81.036,90 Actualización Ingresos $ 81.155,79
Actualización Egresos $ 16.670,05 Actualización Egresos $ 12.889,45
Indice Rentabilidad 486,12% Indice Rentabilidad 629,63%
Tasa Dto. Semestral 1,56% TIR Anualizada 22,29% TIR Anualizada 28,24%
Actualización de FF $ 81.417,89
VAN $ 31.417,89
TIR 19,60%
Actualización Ingresos $ 111.515,30 Perfil del VAN
Actualización Egresos $ 30.097,41
Indice Rentabilidad 370,51%
$ 35.000
TIR Anualizada 43,04%
$ 30.000
$ 25.000
Proyecto 1
$ 20.000
VAN
Proyecto 2
$ 15.000 Proyecto 3
$ 10.000
$ 5.000
$0
0,00% 5,00% 10,00% 15,00% 20,00% 25,00%
Tasa
137
Gestión de Riesgos
Definición de Riesgo
• Un riesgo es un evento o condición inciertos,
que, si se produce, tiene un efecto positivo o
negativo sobre al menos un objetivo del proyecto.
139
Proceso de Gestión de Riesgos
1. Planificación de la Gestión de Riesgos
2. Identificación de riesgos
Identificar los posibles riesgos del proyecto, del producto y del
negocio.
1. Análisis cualitativo [y cuantitativo]de Riesgos:
Determinar la probabilidad de ocurrencia y las consecuencias de
cada riesgo.
1. Planificación de la Respuesta a los Riesgos
Trazar planes para reducir las amenazas (evitar la ocurrencia
de un riesgo o minimizar su impacto) y mejorar las
oportunidades.
1. Seguimiento y Control de los Riesgos
Controla la ocurrencia de riesgos y ejecuta los planes de
mitigación y contingencia, y evalúa su efectividad, a lo largo del
proyecto.
140
Proceso de Gestión de Riesgos
Registro de Riesgos
141
Planificación
de la Gestión de Riesgos
• Proceso de decidir cómo abordar y llevar a cabo
las actividades de gestión de riesgos.
• En fase temprana.
• Salida: Plan de Gestión de Riesgos (parte
del Plan de Gestión del Proyecto):
Metodología
Roles y responsabilidades
Preparación del presupuesto
Periodicidad
Categorías de riesgos
Definiciones de niveles probabilidad e impacto
(relativas, numéricas).
142
Identificación de Riesgos
• Determina qué riesgos pueden afectar al proyecto y documenta
sus características.
• Participa todo el personal (sentido de pertenencia y
responsabilidad)
• Proceso iterativo.
• Identificar:
Factores internos (lo que puedo controlar o influenciar).
Factores externos (fuera de mi alcance). Pe. Quiebra la tablita
Genéricos: comunes a todo proyecto de software.
Específicos: vulnerabilidades específicas de un proyecto dado.
Tecnología
Regulatorio Recursos Planificación
Complejidad
e interfaces Mercado Financiación Control
144
Clasificación de Riesgos (Sommerville)
Riesgos: del proyecto del producto del negocio
Problemas •presupuesto •diseño •cambio en la
de: •agenda •interfaz dirección
•personal •incertidumbre •cambios de
•recursos técnica estrategia de
•obsolescencia o negocio
•del cliente y
de utilización de •cambios en el
sus requisitos
tecnología de punta mercado
•tamaño
•pérdidas en la
•complejidad del empresa
proyecto
148
Análisis Cualitativo de Riesgos
• Evaluar los riesgos identificados:
Impacto o pérdida asociada si ocurre
Probabilidad de ocurrencia
• Calificarlos y priorizarlos según Severidad o Exposición:
(Severidad= impacto * probabilidad)
• Registrar:
detalles explicativos
asunciones
agruparlos por categoría o fase del proyecto o causas
comunes, para analizar
indicadores de prioridad:
• urgencia – tiempo para dar respuesta
• síntomas y señales de advertencia
• calificación del riesgo
149
Análisis Cuantitativo de Riesgos
• Opcional
• Técnicas:
Análisis de sensibilidad
Análisis del valor monetario esperado
Análisis mediante árbol de decisiones
Modelado y simulación
150
Diagrama de Árbol de Decisiones
Definición de Nodo de decisión Nodo de posibilidad Valor del camino
decisión
Decisión a tomar E: Costo de cada opción E: Prob. de escenarios, Beneficios - costos
S: Decisión tomada (V/F) Recompensa si ocurre
S: Valor monet. esp.(EMV)
65%
Fuerte demanda $80M
$200
Construir F
EMV del Nodo de
nueva planta -$120 Posibilidad = $ 42,5 M
35%
Poca demanda -$30M
¿Construir $90
EMV de la decisión = $
o mejorar? 49 M
65%
Fuerte demanda $70M
$120
V
Mejorar planta EMV del Nodo de
Posibilidad = $ 49,0 M
existente -$50
35%
Poca demanda $10M
$60
151
Planificación de la Respuesta -
Estrategias
• Evitar / Explotar
• Transferir / Compartir
• Mitigar / Mejorar:
(= reducir / aumentar probabilidad o impacto)
• Aceptar:
decisión de no cambiar plan de gestión del proyecto o no se
pudo identificar estrategia de respuesta adecuada.
• Pasivamente:
– Aceptar consecuencias
– Si pasa veo qué hago
• Activamente – Establecer reserva para contingencias (t, $,
RRHH).
152
Planificación de la Respuesta -
Ejemplos
• Evitar:
Componentes defectuosos - Reemplazar componentes
potencialmente defectuosos con componentes
comprados de fiabilidad conocida.
• Mitigar:
Personal enfermo – Reorganizar el equipo para que
haya más de una persona en puestos clave.
Pérdida de información – Mitigación: Backup
• Plan de contingencia:
Problemas financieros – Preparar un informe para la
gerencia marcando contribuciones del proyecto al
negocio.
Si se va Fulano de la empresa, Sultano se hace cargo.
153
Mitigación del Riesgo
154
Seguimiento y Control de Riesgos
• Monitorear riesgos periódicamente:
• Detectar riesgos nuevos o que cambien
• Seguimiento de riesgos identificados
• Seguimiento de condiciones que disparan
planes de contingencia
• Revisar ejecución de las respuestas a los
riesgos y su efectividad.
155
Actividades en Gestión de Riesgos
Según Rook, 1993 Lista de Comprobación
Identificar Riesgos Descomposición
Análisis de Supuestos
Evaluar Riesgos Analizar Riesgos Análisis de Procs. de
Decisión de Sistemas
Dinámica
Priorizar Riesgos Modelos de Desempeño
Modelos de Costo
Análisis de Redes
No se pueden Análisis de Decisiones
atender todos Factores de Riesgo en Calidad
Gestión de Riesgos
Severidad de Riesgos
Reducción Compuesta
Impacto y/o
Reducir Obtener Información
Probabilidad
Incertidumbre Evitar un Riesgo
Reducir Riesgos Transferirlo
Evaluar Nivel de Reducción
Control de Riesgos Desarrollar el Proceso
Planear Solución de Riesgos
Planear elemento de Riesgo
Qué hacer si ocurre Plan integrado
Periódicamente, o en Resolver Riesgos Reducir Riesgo Una vez
hitos del proyecto Monitoreo e Informes
ocurrido
156
Reevaluar Riesgos
Riesgos y el Plan del Proyecto
• Actividades de Reducción de Riesgos ->WBS
• Considerarlas en plazo, esfuerzo, costo
• Prever un colchón en el plazo
8% de duración para proyectos normales (no
planificar con el enfoque “si todo sale bien”)
más si el riesgo de pasarse de la fecha estipulada
para el proyecto lo justifica
157
Gestión de la Calidad
Gestión de la Calidad
• Planear la calidad:
identificar estándares de calidad relevantes al proyecto y cómo
satisfacerlas
• Asegurar la calidad:
asegurar que los estándares se cumplieron
detectar de desviaciones durante el proceso de producción
para aumentar la confianza en la obtención de los objetivos de
calidad
• Controlar la calidad:
control de productos obtenidos
159
Gestión de la Calidad
Gestión de la
Calidad
162
Gestión de la Configuración
Gestión de la Configuración
• Gestión de los componentes de un producto:
Registro y control de los cambios de un producto y
de sus componentes
Coordinación fuente-ejecutable
• Gestión de los entregables de un proyecto:
Registro y control de sus cambios
Asegurar su disponibilidad (respaldos)
Generación y Control de la Línea Base o de
Referencia
WBS
164
Gestión de las Comunicaciones
Gestión de las Comunicaciones
Procesos involucrados:
166
Comunicación entre los Involucrados
169
Plan de Gestión del Proyecto – Puntos (1)
• Alcance
• Descripción técnica del sistema propuesto
• Estándares, procedimientos y técnicas y
herramientas propuestas
• Calendario
• Organización del equipo de proyecto
• Plan de Gestión de RRHH
• Plan de Capacitación
170
Plan de Gestión del Proyecto – Puntos (2)
171
Registro y Control de Avance
Bibliografía específica:
•Practice Standard for Earned Value Management (PMI – 2005)
Registro y Control de Avance
• Saber dónde está un proyecto y hacia dónde
está yendo, comparando con lo planificado.
• Objetivos:
medir
analizar
predecir
informar el desempeño en costos y cronograma
173
Medición del Desempeño del Proyecto
• Dimensiones:
Granularidad del desglose de actividades
– nivel de detalle del WBS
Frecuencia de la medición
– Intervalo en que el desempeño del proyecto es medido
• Dependen de:
importancia (significance) – impacto del fracaso o éxito.
Factores que la afectan:
– financieros
– políticos
– ambientales
incertidumbre – probabilidad de fracaso o éxito.
Factores que contribuyen:
– tamaño
– complejidad
– duración
174
Registro y Medición del Avance
• Actividades cumplidas (entregables obtenidos)
Cuidado con los significados, ej. “programa terminado” =
¿terminada la codificación?
¿revisado por un par?
¿pasó la prueba unitaria?
¿pronto para entrar en explotación?
• Actividades empezadas
• ¿Cómo considerar actividades a medias?
175
Técnicas de Medición
• Selección de la técnica en base a:
Tangiblidad del producto
Duración del esfuerzo
176
Técnicas de medición –
Productos Tangibles (I)
• Técnicas de fórmula fija:
Tareas no empezadas en 0
Tareas comenzadas: Se asigna un % fijo al fin del primer período de
medición (independientemente del avance real) y el resto al
completar la tarea:
• 50/50
– con muchas actividades se compensa
– con pocas actividades, hay problema
• 25/75 o
• 0/100 - Enfoque pesimista: actividad no terminada = avance 0:
– avance medido no sesgado por estimaciones de avance de
tareas intermedias.
– avance en tareas gdes. no se refleja granularidad del plan
Apropiadas para tareas cortas
177
Técnicas de medición –
Productos Tangibles (II)
• Hitos con peso:
Se divide la tarea en segmentos, marcando hitos
comprobables
Se asigna un valor a cada hito alcanzado
Apropiada para tareas más largas, con entregables
intermedios tangibles.
• Porcentaje de completitud:
Es la técnica más subjetiva, si no hay indicadores
objetivos (pe. # unidades del producto completas)
En cada período de medición, el responsable de la
tarea estima el % de trabajo completado.
Riesgo del Síndrome del 90%
178
Técnicas de medición –
Productos Intangibles
• Esfuerzo repartido
si la tarea B tiene una relación directa de soporte con
otra A. Pe. (QA, inspecciones)
El VG para cada período de medición es
directamente proporcional al de la tarea A.
• Nivel de esfuerzo
tareas que no producen resultados tangibles que
puedan ser medidos objetivamente. Pe. adm. del
proyecto
se asigna un valor a cada período de medición y se
acredita al finalizar el mismo.
179
Registro y Control de Avance
Técnicas
• Gantt
180
Registro y Control de Avance -
Técnicas - Gantt
Actividad
A
B
C
D
182
Registro y Control de Avance – Técnicas -
Diagrama de Evolución de Gastos
$
Diagrama de
Planificado
Evolución
Real
de Gastos
Acumulados
t
Se lleva gastado más de lo previsto a la fecha, pero
¿cuál fue el avance logrado? ¿se va a gastar más o menos de
lo previsto?
183
Registro y Control de Avance – Técnicas
Enfoque del “Valor Ganado”
• Modelo implícito en diagrama de Gantt nos dificulta determinar si el
proyecto está o no atrasado.
184
Enfoque de Valor Ganado
Costo Final de
acuerdo
$ a tendencia(CT)
Planificado Costo Planificado
Final (CPF)
Valor Ganado (Valor
presupuestado del
avance logrado)
Costo Real en t0
Valor Ganado en t0
es el previsto para t1
0 t1 t0 t
Fin Planificado Fin de acuerdo
(FP) a tendencia (FT)
185
Enfoque del Valor Ganado
Medidas de Desempeño Respecto al Tiempo
Preguntas de Gestión del Proyecto Medidas de desempeño (MVG)
¿Cómo vamos respecto al tiempo? Análisis y Predicción de Cronograma
-¿Estamos adelantados o atrasados? -Varianza del Cronograma
(SV = VG -VP)
-¿Cuánto? - Varianza del Tiempo (TV = TP – TR)
¿Cuán eficientemente estamos - Índice de Desempeño del Cronograma
usando el tiempo? (SPI = VG / VP)
186
Enfoque del Valor Ganado
Medidas de Desempeño Respecto al Costo
187
Enfoque del Valor Ganado
• Permite detectar desviaciones en costo y plazo
y tendencias en etapas tempranas del proyecto
(15-20%)
• Adecuado para proyectos grandes (CC puede
aparecer por cualquier lado) o limitados por
recursos (muchas actividades que podrían
desarrollarse en paralelo)
• VG puede no mostrar varianza en el
cronograma pero igual el proyecto está
atrasado, cuando tareas futuras son terminadas
antes que tareas en el CC.
188
Enfoque del Valor Ganado –
Guías prácticas
1. Establecer la línea base para medir el
desempeño (valor planificado) (LBD)
Descomponer el alcance (WBS)
Asignar responsabilidades de gestión
Desarrollar un cronograma y el VP para cada tarea
Seleccionar las técnicas de medida para todas las
tareas
Mantener la integridad de la línea base para medir
el desempeño. Solo se podría cambiar ante:
• cambios en el alcance
• desempeño pasado pobre y la LBD ya no sirve para medir
189
Técnicas
1.50/50
2. Hitos con peso
3. 25/75
4. 0/100
5. Hitos con peso
6. 50/50
190
Enfoque del Valor Ganado –
Guías prácticas
2. Medir y analizar el desempeño contra la LBD
Registrar el uso de los recursos
Medir el avance
Acreditar el valor ganado de acuerdo a las técnicas
elegidas
Analizar y predecir desempeño de costos y
cronograma
Informar problemas de desempeño y/o tomar acciones
pertinentes
191
Fecha de hoy: 30 de abril
192
Ejercicio
193
Ejemplo Valor Ganado
18
Relevamiento
10
Diseño
80% - 100%
20
Desarrollo
70% - 80%
40
Verificación, Instalación y Capacitación
0% - 15%
194
Ejemplo Valor Ganado (2)
100
90
80
70
60
Recursos
VP
50 VG
40 CA
30
20
10
0
1 2 3
Tiempo
195
Ejemplo Valor Ganado (3)
• Schedule Variance = 40 - 50 = -$10
• Schedule Performance Index = 40 / 50 = 0.8
• El Cost Variance es la diferencia entre el valor
ganado y el costo actual. En este ejemplo,
corresponde a $5 con signo negativo.
• El Cost Performance Index (CPI) is 40/45 = 0.89.
O sea que el proyecto tiene un costo de la
eficiencia que indica que provee $0.89 por cada
peso/dólar gastado hasta el momento.
196