Estimación de Software: Esfuerzo, Costo y Métricas

Estimaciones
Bibliografía:
•SW Estimation. Demystifying the Black Art. Steve McConnell.
Estimación
• Para poder planificar se debe estimar:
 Esfuerzo
 Costo
 Duración
• Para proyectos pequeños, lo mejor es estimar esfuerzo,
dividir entre la productividad y obtener el tamaño.
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
• Muchas veces se presupuesta para ganar el cliente (Pricing to win).
• Pero si las estimaciones se ajustan al presupuesto, ¡error!
4
Estimar vs. planificar
• Estimación:
 proceso analítico imparcial
 objetivo: exactitud
• 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
pronto cuando
planificado
Requisitos
eliminados
Estimación = 20
meses/persona
Nuevos
requisitos
Personal
asignado a
presentación
Funcionalidad
inestable
eliminada
Resultado = 20
meses/persona
El Proyecto
Personal menos
experiente que lo
planificado
Personal reasignado
para dar soporte a
proyecto anterior
Nuevos
requisitos
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:
LOC / Mes persona (promedio)
Tipo de SW
10.000 LOCs 100.000 LOCs 250.000 LOCs
Aviones
200
50
40
Sistemas de Información
3.000
600
500
Comando y control
500
100
80
Sistemas embebidos
300
70
60
Sistemas web
1.500
300
200
Intranets
4.000
800
600
Microcódigo
200
40
30
Control de procesos
1.000
300
200
Tiempo real
200
50
40
Sistemas científicos
1.000
300
200
Paquetes
1.000
200
200
Drivers
600
100
90
Telecomunicaciones
600
100
90
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
comparado con C
Lenguaje
• Algunos lenguajes generan más Assembler
2a1
C
1a1
funcionalidad por LOC.
Cobol
1 a 1,5
Fortran
C#
C++
Java
Visual Basic
Perl
Smalltalk
SQL
1a2
1 a 2,5
1 a 2,5
1 a 2,5
1 a 4,5
1a6
1a6
1 a 10
• Trabajar en lenguajes interpretados tiende a ser (hasta 2
veces) más productivo que en lenguajes compilados.
13
Estimación
• No existe una forma sencilla de estimar el esfuerzo
requerido para desarrollar un sistema de forma precisa:
1. Las estimaciones iniciales parten de la definición imprecisa de
requisitos por parte del usuario.
2. El software a desarrollar a menudo se ejecutará sobre entornos
desconocidos por el equipo de desarrollo o bien utilizará tecnología
de punta.
3. Las personas que van a formar parte del proyecto (y sus
habilidades) pueden ser desconocidas.
• 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
•
•
•
•
•
•
•
Features (características)
Historias de usuario
Puntos de historia
Requisitos
Casos de Uso
Puntos de Función
Páginas Web
• Componentes GUI
(ventanas, cuadros de
diálogo, reportes, etc.)
• Tablas de la BD
• Definiciones de interfaces
• Clases
• Funciones / subrutinas
• 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
• Permite evaluar productividad en programación:
 Si la potencia del lenguaje aumenta, aumenta la productividad = producto /
unidad de tiempo
 Productividad estable en LOC, independiente del lenguaje. (depende más
del tamaño del proyecto y del tipo de sw)
 ¡OJO con medir productividad individual!:
• Distintos estilos (sintético o explayado)
• Peligro de efecto Cauton
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
¡Paradoja! ¿C más productivo que C++?
 Unidad de medida depende del lenguaje
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)
Objetivo: traducir en un Número el tamaño de la
funcionalidad que brinda un producto de software
• Desde el Punto de vista del usuario
• Suma ponderada de características del producto:
Transacciones
 Nro. Entradas Externas
 Nro. Salidas Externas
 Nro. Consultas Exts.
(EI- External Input)
(EO- External Output)
(EQ- External inQuiry)
Datos
 Nro.Archivos Int. Lógicos
 Nro.Arch. Interfaz Externa
(ILF- InternalLogical File)
(EIF-External Interface File)
24
Modelo para contar PF
EI
No mantenidos
por la aplicación
Archivos Lógicos
Internos (ILF)
14
“Características
Generales de la
Aplicación
EQ
EO
Contiene datos
derivados y/o
afecta
comportamiento
Archivos de Interfaz
Externos (EIF)
transacciones
PF =
PFSA
Frontera de la
aplicación
datos
x
Factor de Ajuste
25
Puntos de Función
Primera versión
Segunda versión
B, M, A
 Nro. Entradas
 Nro. Salidas
 Nro. Consultas
x
x
x
 Nro. Archivos
x
 Nro. Interfaces externas x
4
5
4
10
7
(3,4,6)
(4,5,7)
(3,4,6)
(7,10,15)
(5,7,10)
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.
Contabilidad
Ventas
No cumple con la aditividad: si uno
componentes, la cuenta da menos.
Fronteras
definidas a partir
de la visión del
negocio
¿cómo impactaría en
la cuenta total de PF
considerar esta otra
frontera?
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
EI
No mantenidos
por la aplicación
Archivos Lógicos
Internos (ILF)
14
“Características
Generales de la
Aplicación
EQ
EO
Contiene datos
derivados y/o
afecta
comportamiento
Archivos de Interfaz
Externos (EIF)
transacciones
PF =
PFSA
Frontera de la
aplicación
datos
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
Este proceso
 CI
elemental se completa
 sueldo
al ingresar todos los
 estado civil
 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
IP= Intención Primordial
O= Opcional
37
Proceso en Transacciones
Tipo de Proceso
Acepta datos o inf. de control que entra
Presenta información fuera de la frontera
Altera el comportamiento del sistema
Al menos se actualiza un ILF
Fórmulas matemáticas y cálculos
Crea datos derivados
Al menos un ILF o EIF referenciado
Recupera datos o información de control
Validaciones
Se convierten valores equivalentes
Selección y filtro de datos
Se evalúan condiciones
Reordena un conjunto de datos
p=posible
p*=uno por lo menos debe estar presente
EI EO EQ
SI
p
p*
p*
p
p
p
p
p
p
p
p
p
p
SI
p*
p*
p*
p*
p
SI
p
p
p
p
p
p
SI
NO
NO
NO
NO
SI
SI
p
p
p
p
p
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
• Contar un FTR por cada ILF mantenido
• Contar un FTR por cada ILF o EIF leído durante el proceso
del EI
• Contar sólo un FTR por cada ILF que es leído y mantenido
Ejemplo: Retiro de una cuenta bancaria
ILF en la aplicación:
 Cuenta
 Movimientos
 Cotizaciones dólar
El proceso de retiro lee la cuenta, verifica saldo , graba
movimiento y actualiza la cuenta.
2 FTR
40
Complejidad de Tr - Número de DET
• Contar un DET por cada campo reconocible por el
usuario, no repetido, que entra o sale de la aplicación
atravesando su frontera y es requerido para completar la
transacción
• No contar campos leídos o derivados por la aplicación y
almacenados en un ILF si los campos no cruzaron la
frontera
• Contar un DET por la posibilidad de que el sistema envíe
un mensaje fuera de la frontera de la aplicación para
indicar un error , confirmar que el proceso está completo
o verificar si el proceso debiera continuar
• Contar un DET por la posibilidad de especificar una
acción, mismo si hay múltiples métodos para invocar el
mismo proceso lógico
41
Complejidad de EI - Número de DET
Ejemplo 1 - agregar un empleado con los datos:




nombre
fecha de ingreso
CI
fecha de nacimiento
4 DET
Ejemplo 2 - ingreso de datos de factura de proveedor:




código proveedor (E)
nombre proveedor (S)
fecha factura (E)
importe total (E)
• * ( código artículo
•
precio unitario
•
cantidad
•
importe) (E)
8 DET
42
Complejidad de EI - Número de DET
• Ejemplo 3 – ingreso de pedido de cliente
• Usuario ingresa:




código cliente (E)
nombre cliente (S)
fecha pedido (E)
importe total (E)
6 DET
• * ( código artículo
•
cantidad) (E)
• Graba archivo de pedido con:
 Código cliente
 Nombre cliente
 Fecha pedido
• *( código artículo
•
precio unitario
•
cantidad)
Precio unitario se obtiene
del archivo de Artículos –
NO cruza la frontera
43
Complejidad de EQ/EO – Nro. de DET
• Ejemplo 1 – se listan los datos (nombre,
dirección, teléfono)
3 DET
• Ejemplo 2 – gráfica de tortas con la cantidad de
empleados en determinado rango de edad, con
descripción para cada rango
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
0 a 1 FTR
Baja
Baja
Media
2 FTRs
Baja
Media
Alta
3 o más FTRs
Media
Alta
Alta
Para EO/EQ
1 a 5 DET
6 a 19 DET
0 a 1 FTR
Baja
Baja
Media
2 a 3 FTRs
Baja
Media
Alta
Media
Alta
Alta
4 o más FTRs
16 o más DET
20 o más DET
46
Contribución de Transacciones
\ Complejidad
Tipo de Transacción
Baja
Media
Alta
3
4
6
External Output (EO)
4
5
7
External inQuiry (EQ)
3
4
6
External Input
(EI)
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
EO
Baja
4
Cantidad Clientes
Total de Contribución de Transacciones:
10
48
Menúes de aplicación
• Empleado:
 Nuevo
 Modificar
 Listar
Al elegir “Nuevo” aparece un formulario vacío
para ingresar datos.
NO se considera proceso elemental
porque no satisface una necesidad del usuario
49
Consulta de Empleados
Empleado
Sistema de RRHH
Tareas Asignaciones Informes
Ayuda
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)
EI, 1 FTR (Empleado), 4 DET (nombre, CI, cargo, F1)
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
Si ya está prevista la consulta del empleado
¿se debe contar dos veces?
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?
EQ , 1 FTR, 5 DET, Baja
55
Datos
Modelo para contar PF
EI
No mantenidos
por la aplicación
Archivos Lógicos
Internos (ILF)
14
“Características
Generales de la
Aplicación
EQ
EO
Contiene datos
derivados y/o
afecta
comportamiento
PF =
Archivos de Interfaz
Externos (EIF)
transacciones
PFSA
Frontera de la
aplicación
datos
x
Factor de Ajuste
57
Contar Datos
Pasos:
• Identificar Archivos
• Asignar a cada uno un tipo (ILF, EIF)
• Identificar la cantidad de RET y DET
• Asignar a cada uno un valor de complejidad (Alta, Media, Baja) en
función de la cantidad de RET y DET
Definiciones cortas:
• Data Element Type (DET):
 es un campo único (no repetido) reconocible por el usuario (ya
lo habíamos visto al contar funciones)
• Record Element Type (RET):
 es un subconjunto de campos de un archivo, reconocible como
tal por el usuario
58
Tipos de Archivos
Internal Logical File (ILF)
• Es un grupo de datos o de información de control,
lógicamente relacionado, identificable por el usuario y
mantenido dentro de la frontera de la aplicación.
External Interface File (EIF)
• Es un grupo de datos o de información de control,
lógicamente relacionado, identificable por el usuario,
referenciado por la aplicación, pero mantenido fuera de la
frontera de la aplicación.
Nota: Un EIF para una aplicación tiene que ser un ILF para
alguna otra.
59
Record Element Type (RET)
• 2 tipos de subgrupos:
 Opcionales - al crear una instancia de los datos, puede
no estar presente ninguno
 Obligatorios - el usuario debe ingresar los datos de al
menos un subgrupo obligatorio
Ejemplo: Aplicación de RRHH. Empleado tiene datos generales
y además puede ser mensual o jornalero. Adicionalmente,
puede tener personas a su cargo (núcleo familiar).
RET:
 Mensual (incluyendo generales) - obligatorio
 Jornalero (incluyendo generales) - obligatorio
 Núcleo Familiar - opcional
Nota: Los subgrupos no necesariamente son disjuntos
60
Data Element Type (DET)
• Contar un DET por cada campo no repetitivo, reconocible
por el usuario, que se recupera o mantiene desde ILF o
EIF a través de un proceso elemental
Ejemplos:
 Número de cuenta que se almacena en varios campos
cuenta como 1 (un) DET
 Imagen previa y posterior de un archivo con 10
campos, para auditoría, cuenta como 2 DET (uno por la
previa y otro por la posterior)
 El registro de fecha y hora de alta/modificación en un
archivo, cuenta como un DET si fue requerido por el
usuario
61
Caracterización de la complejidad
Para ILF/EIF
1 a 19 DET
20 a 50 DET
51 o más DET
1 RET
Baja
Baja
Media
2 a 5 RET
Baja
Media
Alta
Media
Alta
Alta
6 o más RET
Contribución de datos
\ Complejidad
Tipo de Archivo
Baja
Media
Alta
Int. Logical File (ILF)
7
10
15
Ext.Interface File(EIF)
5
7
10
62
Contribución de Datos
Ejemplo -
•
•
•
Aplicación mantiene los archivos:
Tarea ( #tarea, nom_tarea, escala)
Descripción_Tarea ( #tarea, #línea, l_descrip)
Empleado ( CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea)
ILF identificados: Tarea, Empleado
Tarea: 2 RET - Tarea, Descripción_Tarea
5 DET - #tarea, nom_tarea, escala, #línea, l_descrip
Empleado: 1 RET
5 DET - CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea
Archivo
Tipo
Nivel Complejidad
Cuenta
Empleado
ILF
ILF
Baja
Baja
7
7
14
Tarea
Total de Contribución de Datos :
63
Usuario
Definición:
• Un usuario es cualquier persona que especifica
Requerimientos Funcionales de Usuario y/o cualquier
persona o cosa que se comunica o interactúa con el
software
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
•
Fecha y hora del cambio
Los datos de seguridad (id_usuario, id_pantalla,
tipo_acceso) anteriores y posteriores
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)
1 ILF, 2 RET, 7 DET:
(Seguridad_Pantalla – 3 DET
Seguridad_Auditoría – 4 DET (fecha_hora_cambio,
id_usuario_cambio, imagen_ant, imagen_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?
Empleado
- en RRHH:
1 ILF, 1 RET, 4 DET
- en Seguridad: 1 ILF, 1 RET, 4 DET
69
Contribución de Datos – Ejemplo 3
• La aplicación de RRHH:
 mantiene los sig. datos del empleado: (id, nombre,
dirección postal (calle, nro, piso, apto, ciudad, CP),
sueldo, cargo).
 al ingresarlo, calcula y graba la fecha de retiro.
 imprime etiquetas para envío postal.
• La aplicación Postal:
 mantiene los códigos de edificio y
 genera un listado con cant. de empleados en cada
piso de cada edificio, para evaluar el proceso más
efectivo para distribuir el correo.
Empleado: - en RRHH
- en Postal
1 ILF, 1 RET, 6 DET
1 ILF, 1 RET, 3 DET
70
Ejercicio de PF
Calcular la contribución de los datos y de las
transacciones del ejercicio planteado.
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
Nro. Salidas
x
Nro. Consultas
x
Nro. Archivos
x
Nro. Interfaces externas
Nro. de algoritmos x
4
5
4
10
x
3
=
=
=
=
7
=
=
72
Puntos Objeto
• Son una medida indirecta de software que se calcula teniendo en cuenta el total de:
Sencillas
Moderadamente
complejas
Complejas
pantallas o interfaces de usuario
1 PO
2 PO
3 PO
informes
2 PO
5 PO
8 PO
componentes necesarios construir para la
aplicación: El nro. de módulos 3GL para
complementar el código 4GL
•
•
10 PO por cada módulo 3GL
Los PO son una alternativa a los PF cuando se utilizan 4GL.
Son más fáciles de estimar a partir de una especificación que los
PF, ya que sólo consideran pantallas, informes y módulos 3GL. Por
lo tanto pueden estimarse en fases tempranas del proceso de
desarrollo. En estas etapas resulta muy difícil estimar el nro. de
LOCs de un sistema.
73
Técnicas de Estimación
Contar, Calcular, Juzgar
• Ejemplo: Banquete
 Costoso contar comensales uno por uno
 Estimaciones:
•
•
•
•
•
Experto: 335
Carlos: 11 * 7. Plan: 5 personas por mesa = 385
Lucía: Límite: 485. Lleno al 70-80%. 340-388. Prom=364
335, 385, 364. ¿Tomar medio 365?
Cuenta de tickets = 407
•Contar cuando sea posible,
•calcular cuando no se puede contar (contar otra cosa y
calcular a partir de datos calibrados),
•usar juicio solo como último recurso.
75
Contar
• Tamaño es factor más importante. Buscar métrica
significativa del tamaño, dependiendo del ambiente.
• Buscar lo que se pueda contar lo más temprano posible:
 desarrollo temprano: características, CU, historias...
 medio: reqs detallados, PF, solicitudes de cambio, páginas web,
reportes, pantallas, tablas...
 desarrollo tardío: código, defectos reportados, clases, tareas...
• Contar algo que produzca un promedio estadísticamente
válido (por lo menos 20 ítems).
• Mismas asunciones que datos históricos: misma
métrica, tamaño de equipo, experiencia de
programadores, tecnología de desarrollo, etc.
• Contar lo que requiera menor esfuerzo.
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
•
•
•
•
•
Estimaciones basadas en Proxies.
Juicio de Expertos
Estimación por Analogía
Métodos Algorítmicos
Métodos basados en Aprendizaje
Automatizado
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.
• Sirven para crear estimaciones globales
(proyecto, iteración), pero no para una tarea o
característica.
82
Estimaciones basadas en Proxies Técnicas
•
•
•
•
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
Muy pequeño
Pequeño
Mediano
Grande
Muy grande
Total
LOCs promedio por característica
127
253
500
1014
1998
Cant. características
22
15
10
30
27
104
LOCs estimadas
2794
3795
5000
30420
53946
95955
• Se aplica la Ley de los Números Grandes.
• Se puede aplicar también a estimación de
esfuerzo.
84
Componentes Estándar
• Si desarrollamos muchos programas que son similares
en arquitectura.
• Pasos:
 Identificar componentes estándar (páginas web, archivos,
tablas, reglas de negocio, gráficos, pantallas, reportes,
etc.)
 Calcular LOCs promedio por componente en datos
históricos.
 Estimar la cant. de componentes estándar.
Más
Comp. estándar
LOCs por componente Mín probable
Máx Nro. estimado LOCs estimadas
Pág. web dinámicas
487 11
25 50
26,8
13052
Pág. web estáticas
58 20
35 40
33,3
1931
Tablas BD
2437 12
15 20
15,3
37286
Reportes
288
8
12 20
12,7
3658
Reglas de negocio
8327
1
1
8327
TOTAL
64.254
• Para usar en etapas tempranas.
85
Juicio de Expertos
• La estimación se realiza valiéndose de la
experiencia y de la opinión de expertos como
única guía.
• Aplicable a Tamaño, Esfuerzo, Costo, Duración
• Estimaciones iniciales en gral. subestimamos
 Humphrey multiplicar x 2
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.
• Analogía con antecedentes:
 Los datos deben ser precisos.
 Debe existir consistencia entre las medidas
utilizadas (p.e. LOC referidas a un mismo
lenguaje).
 Las aplicaciones que se contemplan deben ser
similares a la que se pretende estimar.
• Construir historia propia
88
Estimación por Analogía
•
Matriz de costos de Wolverton (TRW-1974)
O=Old; N=New
Tipo
Control
I/O
Pre/post proces.
Algoritmo
Manejo de Datos
Tiempo crítico
Dificultad
OE OM OD
21 27 30
17 24 27
16 23 26
15 20 22
24 31 35
75 75 75
E=Easy; M=Medium; D=Difficult
NE NM ND
33 40 49
28 35 43
28 34 42
25 30 35
37 46 57
75 75 75
Se estima el tamaño de cada módulo en LOCs
89
Estimación por Analogía
• Matriz de costos
 Idea: cruzar tipo de programas con niveles de
dificultad
 Tabla en base de datos históricos
 Con estabilidad tecnológica y características
similares de personal  buena estimación
 En Uruguay, mejor por esfuerzo, por inflación.
• 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
• Ejemplo: Walston-Felix (1977): E=5.25 S0.91
 Interés histórico.
 Exponente menor que 1  E crece, pero crece menos
la productividad crece con el tamaño.
• Ejemplo: COCOMO (Constructive Cost Model) – Boehm
‘81.
Problema: modelos dependientes del tamaño.
Trasladan estimación del esfuerzo a estimación del
tamaño. Pero estimaciones son requeridas
tempranamente, y tamaño depende de decisiones de
diseño.
92
COCOMO II
3 modelos con distinto nivel de complejidad
 composición de aplicaciones (tamaño en Object Points)
 diseño temprano (tamaño en PF)
 post-arquitectura (tamaño en LOCs)
E= b Sc(y) m(X)
y: Elementos de escala para ajustar el exponente
x: Multiplicadores de esfuerzo
• Herramientas que soportan los 2 últimos modelos
• Calibrada con base de datos de proyectos
• Estima esfuerzo, duración (y cantidad promedio de gente)
de desarrollo, SIN contar Requerimientos
• Esfuerzo en Meses-Persona (152 horas-Persona)
93
COCOMO II - Ajustes de Escala
 PREC -> Precedentes
 FLEX -> Flexibilidad del Desarrollo
» Requerimientos pre-establecidos
» Interfaces externas
 RESL -> Arquitectura/Resolución de Riesgos
 TEAM -> Cohesión del equipo
 PMAT -> Madurez del Proceso de SW
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
• Atributos del proyecto
Relativos a las características intrínsecas de cada proyecto específico
 TOOL
-> Herramientas
 SITE
-> Dispersión/Comunicaciones
 SCED -> Compresión/Estiramiento de Plazo
96
Aprendizaje Automático
• Aprender de proyectos pasados
• Predecir el costo (esfuerzo, duración)
• Técnicas de Data Mining:
 Construir un modelo (Redes Neuronales, Modelos
Estadísticos) consistente con datos históricos
 usar el modelo para generar una predicción
(estimación) del futuro
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.
• Quién hace qué y cómo se va a organizar el
personal.
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
INTUITIVO
INTUITIVO
INTUITIVO
INTROVERTIDO:
EXTROVERTIDO:
Pregunta al resto
Informa al resto
Reconoce sentimientos Reconoce sentimientos
RACIONAL
INTROVERTIDO:
Pregunta al resto
Decide lógicamente
RACIONAL
EXTROVERTIDO:
Informa al resto
Decide lógicamente
EXTROVERTIDO
INTROVERTIDO
Estilos de Trabajo
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.
• De los grupos constituidos únicamente por un tipo de las
personalidades anteriores, sólo funciona bien el de los orientados a
la relación.
• Los grupos de las personalidades orientadas a la tarea y orientadas
a sí mismas no funcionan:
 sentimientos negativos a trabajar en equipo
 exceso de líderes.
• Lo más exitoso es constituir equipos donde:


exista un equilibrio en las personalidades de los integrantes
el líder esté orientado a la tarea.
108
Composición del Grupo
– El jefe de proyecto
• Es el responsable de coordinar las distintas tareas y
grupos de personas que constituyen el equipo de
desarrollo.
• 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.
¿Qué factores afectan a la comunicación en grupo?
 Tamaño del grupo
 Estructura del grupo
 Composición del grupo - Personalidades implicadas y su
categoría profesional
 Ambiente físico de trabajo
114
Comunicaciones
Dos personas
1 línea de comunicación
Tres personas
3 líneas de comunicación
Cuatro personas
6 líneas de comunicación
Cinco personas
10 líneas de comunicación
:
n(n-1)/2 líneas de
comunicación
:
n personas
115
Comunicaciones
• Cuanto mayor es el grupo mayor es el número de
enlaces de comunicación entre sus miembros. Para
disminuirlas:
• Estructurar las comunicaciones de manera que todas pasen por
un coordinador central dentro de cada grupo de trabajo.
• Establecer grupos de comunicación y el mínimo de
comunicaciones entre grupos.
• Los grupos ideales son de entre 2 y 8 personas.
Disminuyen los problemas de comunicación.
Otros beneficios:
• Los miembros del grupo conocen el trabajo de los demás, con lo
que se puede mantener la continuidad si alguno de ellos
abandona el grupo.
• El trabajo desarrollado se considera responsabilidad grupal, no
individual.
• Mayor consenso hacia como abordar las tareas.
116
Organización del Equipo de Proyecto
• Los miembros del equipo se organizan para
generar productos de calidad de manera
eficiente.
• La elección de una estructura apropiada
depende de:
 la formación y estilos de trabajo de los miembros del
equipo
 la cantidad de integrantes del equipo
 los estilos de dirección de los clientes y
desarrolladores
117
“Chief Programmer Team”
Chief
programmer
Assistant chief
programmer
Senior
programmers
Librarian
Administration
Test team
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
Resto de componentes del equipo de desarrollo
119
Enfoque Egoless (sin ego) – Equipo
Democrático – Estructura Plana
• Se establecen distintos equipos de personas, y se
asignan una serie de tareas a cada equipo.
• La responsabilidad de organizar, coordinar y distribuir
las tareas dentro del equipo es compartida por todos
sus miembros, y la asignación y coordinación de
tareas entre los distintos equipos es responsabilidad
del jefe de proyecto.
120
Equipo Democrático
• Todos los miembros del equipo participan en las
decisiones (democrático).
• Todos los miembros cooperan conjuntamente para
desarrollar cada una de las tareas. Todos igualmente
responsables.
• En cada equipo se elige un portavoz, que informa del
estado de las tareas asignadas, al jefe de proyecto y que
comunica a los miembros del equipo de las decisiones y
comentarios realizados por aquél.
• El software es producto de un equipo más que de personas
individuales. No hay identificación personal con el software.
Para eso, las críticas se hacen al producto o resultado, no
a las personas.
121
Equipos Jerárquicos
•
•
•
•
•
El equipo de trabajo se divide en varios grupos.
Existe un jefe de grupo que es el que coordina y asigna áreas a sus
miembros.
El jefe de grupo depende a su vez del jefe de proyecto, ante el cual deberá
rendir cuentas y el cual le va a designar las tareas que su grupo debe
desempeñar.
La responsabilidad de asignar y coordinar las tareas de cada equipo de
desarrollo, corresponde únicamente a sus jefes de grupo.
El jefe de proyecto sigue teniendo como responsabilidad la asignar las
tareas y coordinar los distintos equipos.
Jefe de proyecto
Jefes de grupo
Enlaces de comunicación
Resto de componentes del equipo de desarrollo
122
Comparación de Estructuras
Organizativas
• Muy Estructuradas
 Certidumbre
 Repetición
 Proyectos Grandes
• 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
Solución de compromiso
Solución, pero todos pierden
algo
Forzar la resolución
Solución, pero daña las
relaciones entre las partes
Enfrentarlo/buscar
solución al problema
Se logra la mejor solución
129
Conflictos - Criterios Generales
• No responder a posibles agresiones
• Oír y comunicarse efectivamente
• Promover la apertura, expresión emocional y las nuevas
ideas
• Expresar sentimientos como tales y no como hechos
• Minimizar conflictos potenciales que entorpecen el
proyecto
• Estimular conflictos cuando ello aumenta la creatividad
y la innovación
• Elegir la estrategia para enfrentarlo teniendo en cuenta
la importancia, urgencia y consecuencias posibles
• Conviene encontrar soluciones del tipo ganar-ganar
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.
Responder a la pregunta: ¿Vale la Pena?
132
Estudio de Factibilidad (II)
• Estudio y evaluación de alternativas
• Factibilidad (para alguna o varias alternativas)
 Técnica:
• ¿Es posible?¿Puede ser implementado con la tecnología
existente, dentro de las restricciones de costo y tiempo?
• ¿Qué se precisa para lograrlo?) => Recursos, Plazo
 Económica (¿cuánto cuesta? ¿flujos financieros?)
 Operativa (¿Habrá algo que haga que el sistema no
funcione?).
• Ej.: cultura de la organización
• ¿Puede ser integrado con otros sistemas existentes?
 Jurídica
 Institucional:
• ¿Contribuye el sistema a los objetivos globales de la organización?
133
Estudio de Factibilidad (III)
• Análisis Costo/Beneficio
Técnicos
Clientes
• Informe de Factibilidad: Documento donde se
recomienda si seguir con el sistema,
proponiendo cambiar el alcance, presupuesto,
agenda, etc.
134
Eval. de Factibilidad - Cuándo
• Frecuentemente el Estudio de Factibilidad es
previo a un proyecto (ante-proyecto, prefactibilidad)
• 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.
Inversión Inicial
PROYECTO 1
Semestres
0
1
2
3
4
5
Tasa Dto. Semestral
Actualización de FF
VAN
TIR
Actualización Ingresos
Actualización Egresos
Indice Rentabilidad
3,15%
$ 50.000
Ingresos
20.000
22.000
25.000
25.000
25.000
ANUAL
Egresos Flujo Caja
(50.000)
6.000
14.000
7.500
14.500
6.000
19.000
6.000
19.000
6.000
19.000
Reintegro
(50.000)
(36.000)
(21.500)
(2.500)
16.500
1,56%
$ 81.417,89
$ 31.417,89
19,60%
$ 111.515,30
$ 30.097,41
370,51%
PROYECTO 2
Semestres
0
1
2
3
4
5
Tasa Dto. Semestral
Actualización de FF
VAN
TIR
Actualización Ingresos
Actualización Egresos
Indice Rentabilidad
TIR Anualizada
Ingresos
15.000
16.000
18.000
18.000
18.000
Egresos
3.000
3.200
3.500
3.800
4.000
Flujo Caja
(50.000)
12.000
12.800
14.500
14.200
14.000
Reintegro
(50.000)
(38.000)
(25.200)
(10.700)
3.500
PROYECTO 3
Semestres
0
1
2
3
4
5
Tasa Dto. Semestral
Actualización de FF
VAN
TIR
Actualización Ingresos
Actualización Egresos
Indice Rentabilidad
1,56%
$ 64.366,84
$ 14.366,84
10,59%
$ 81.036,90
$ 16.670,05
486,12%
22,29%
TIR Anualizada
Ingresos
17.000
17.000
17.000
17.000
17.000
Egresos Flujo Caja
(50.000)
2.700
14.300
2.700
14.300
2.700
14.300
2.700
14.300
2.700
14.300
Reintegro
(50.000)
(35.700)
(21.400)
(7.100)
7.200
1,56%
$ 68.266,34
$ 18.266,34
13,24%
$ 81.155,79
$ 12.889,45
629,63%
28,24%
Perfil del VAN
$ 35.000
43,04%
$ 30.000
$ 25.000
VAN
TIR Anualizada
Proyecto 1
$ 20.000
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.
• Objetivo de la Gestión de Riesgos:
aumentar la probabilidad y el impacto de los
eventos positivos, y disminuir los de los adversos.
• Gestión proactiva y consistente durante todo el
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
Planificación de la
Gestión de Riesgos
Identificación
Análisis
Planificación
de la Respuesta
Seguimiento
y Control
Plan de
Gestión de
riesgos
Lista de
riesgos
Lista de
riesgos
priorizados
Planes de
reducción y
contingencia
Evaluación
de los
riesgo
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.
• Salida: Registro de Riesgos:
 Lista de riesgos identificados
 Causas (= condiciones o eventos que darían lugar al riesgo)
143
Categorías de Riesgos (PMBoK)
Técnico
Externo
Requisitos
Tecnología
Complejidad
e interfaces
Rendimiento
y fiabilidad
Calidad
de la
organización
Dirección de
proyectos
Subcontratistas
y proveedores
Dependencias
del proyecto
Regulatorio
Recursos
Planificación
Mercado
Financiación
Control
Cliente
Priorización
Estimación
Comunicación
Condiciones
climáticas
144
Clasificación de Riesgos (Sommerville)
Riesgos:
del proyecto
del producto
del negocio
Problemas •presupuesto
de:
•agenda
•personal
•recursos
•del cliente y
sus requisitos
•tamaño
•complejidad del
proyecto
•diseño
•interfaz
•incertidumbre
técnica
•obsolescencia o
de utilización de
tecnología de punta
•cambio en la
dirección
•cambios de
estrategia de
negocio
•cambios en el
mercado
•pérdidas en la
empresa
Afectan:
•la calidad del sw
resultante.
•al equipo de
desarrollo y a
•la realización del
proyecto en sí.
•el costo y
•la duración del
proyecto.
145
Riesgo
Tipo
Descripción
Abandono del personal del
proyecto
Proyecto
Personal experimentado deja el proyecto antes de
su finalización.
Cambios de gerencia
Proyecto
Cambios en la gerencia, con diferentes
prioridades.
HW no disponible
Proyecto
HW para el desarrollo, el testing o la implantación
no está disponible en la fecha acordada.
Cambio en los requisitos
Proyecto y
producto
El número o el impacto de los cambios en los
requisitos es mayor al esperado.
Retrasos en la especificación
Proyecto y
producto
La especificación de las interfaces no están
disponibles en la fecha acordada.
Tamaño subestimado
Proyecto y
prod.
El tamaño del proyecto se ha subestimado.
Herramientas CASE no
performantes
Producto
Las herramientas CASE para el desarrollo no son
todo lo eficientes que se esperaba.
Cambios de tecnología
Negocio
La tecnología sobre la cual iba a construirse el
proyecto es sustituída por una nueva.
Producto de la competencia
Negocio
Un producto de la competencia aparece en el
mercado antes de que el sistema se termine de
construir.
146
Tipos más comunes de riesgos
(Sommerville)
Tipo de riesgo
Técnicos
(tecnologías utilizadas (sw y hw))
De personal
(equipo de desarrollo)
Organizacionales
(del ambiente organizacional de
desarrollo y del cliente)
Ejemplos
BD no puede procesar la # de transacciones/seg esperada.
Componentes de SW a reusar defectuosos.
Tecnologías desconocidas.
No se consigue personal con las habilidades requeridas.
Personal clave no está disponible.
No se puede proveer la capacitación necesaria.
Nueva gerencia.
Probs. financieros reducen presupuesto.
De herramientas
El código generado es ineficiente.
Incompatibilidad entre herramientas.
De requerimientos
Cambios en reqs requieren trabajo de rediseño importante.
Los clientes no logran entender impacto de cambios
solicitados.
De estimación
Tiempo de desarrollo, tasa de reparación de defectos y/o
tamaño subestimados.
147
“Top 10 Risk Items” (Boehm)
1989
1995
1. Limitaciones de Personal
1. Limitaciones de Personal
2. Calendario, Presupuesto, Procesos
3. COTS, componentes externos
4. Requerimientos inadecuados
5. Interfaz de usuario inadecuada
6. Arquitectura, desempeño, calidad
7. Cambios en Requisitos
8. Software Heredado
9. Tareas externas
10. Forzar ciencia de computación
2. Calendario y Presupuesto
3. Funciones equivocadas
4. Interfaz de usuario no
adecuada
5. “Gold plating” (preciosismo)
6. Cambios en Requisitos
7. Suministros externos
8. Tareas externas
9. Desempeño de Tiempo Real
10. Forzar ciencia de
computación
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
decisión
Nodo de decisión
Nodo de posibilidad
Valor del camino
Decisión a tomar
E: Costo de cada opción
S: Decisión tomada (V/F)
E: Prob. de escenarios,
Recompensa si ocurre
S: Valor monet. esp.(EMV)
Beneficios - costos
Construir
nueva planta
¿Construir
o mejorar?
Fuerte demanda
F
-$120
EMV del Nodo de
Posibilidad = $ 42,5 M
Poca demanda
EMV de la decisión = $
49 M
Fuerte demanda
Mejorar planta
existente
V
-$50
65%
$80M
$200
35%
-$30M
$90
65%
$70M
$120
EMV del Nodo de
Posibilidad = $ 49,0 M
Poca demanda
35%
$60
$10M
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).
• Respuesta para Contingencias:
 Plan de Contingencia:
• solo se ejecutará bajo condiciones predefinidas / eventos
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
• Quizás no sea rentable o posible desarrollar
respuestas proactivas. Se justifica dependiendo
de:
 Nivel de Reducción= (severidad antes de reducciónseveridad después de reducción) / (costo de reducción)
 Si nivel de reducción<1 no valdrá la pena
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
Descomposición
Análisis de Supuestos
Análisis de Procs. de
Decisión de Sistemas
Dinámica
Modelos de Desempeño
Modelos de Costo
Análisis de Redes
Análisis de Decisiones
Factores de Riesgo en Calidad
Identificar Riesgos
Evaluar Riesgos
Analizar Riesgos
Priorizar Riesgos
Gestión de Riesgos
No se pueden
atender todos
Impacto y/o
Probabilidad
Severidad de Riesgos
Reducción Compuesta
Reducir
Incertidumbre
Reducir Riesgos
Control de Riesgos
Planear Solución de Riesgos
Qué hacer si ocurre
Periódicamente, o en
hitos del proyecto
Resolver Riesgos
Obtener Información
Evitar un Riesgo
Transferirlo
Evaluar Nivel de Reducción
Desarrollar el Proceso
Planear elemento de Riesgo
Plan integrado
Reducir Riesgo
Una vez
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
Gestión de la Q debe reportar a alta gerencia
directamente, por encima del jefe de proyecto, para
que obj. de Q no estén comprometidos por recortes de
presupuesto o calendario.
159
Gestión de la Calidad
Gestión de la
Calidad
Planear la
Calidad
• Responsabilidades
• Estándares
• Procedimientos
• Puntos de Control
• Métricas de Q
• Checklists
Asegurar la
Calidad
Controlar la
Calidad
• Revisiones
• Verificar
• Auditorías
• Validar
WBS
160
Plan de Calidad
• Plan de Calidad:
 Descripción del producto, mercado y calidad esperada.
 Planes del producto: fechas de liberación de versiones,
responsables del producto, planes de distribución del
producto.
 Desc. de procesos para el desarrollo y la gestión del producto.
 Los atributos de calidad más importantes del producto:
Pe. Seguridad (safety), Seguridad (security), Confiabilidad, Robustez,
Comprensibilidad, Verificabilidad, Modularidad, Complejidad,
Eficiencia, Portabilidad, Reusabilidad, Usabilidad, Facilidad de
Aprendizaje
 Procedimientos para evaluar si un atributo de calidad está
presente en el producto.
 Gestión de riesgos claves que pueden afectar la calidad del
producto.
161
Gestión de la Calidad
• Relación entre calidad del proceso y calidad del
producto:
 es claro en procesos de manufactura, porque el
proceso se puede estandarizar y monitorear
fácilmente.
 el SW no es manufacturado sino diseñado – difícil
predecir cómo cambios en proceso afecta Q del
producto. Pero experiencia muestra relación.
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:
 Planificación de las comunicaciones
 Distribución de la información
 Reportes de situación, avance y
predicciones
 Cierre administrativo
166
Comunicación entre los Involucrados
• Patrocinador, Cliente, Usuario, Desarrolladores,
Otros Interesados-Involucrados
• Procedimientos de comunicación
 periódicos, hitos
 formales, no formales
 revisiones conjuntas (con Cliente, Usuarios, etc.)
• Manejo de Expectativas de los interesados
• Decisiones por personas autorizadas y con
conocimiento de causa
WBS
167
Plan de Gestión del Proyecto
Plan de Gestión del Proyecto
• Documento para comunicar :




organización
estimaciones de costo y duración
calendario de actividades e hitos del proyecto
la gestión y el análisis de riesgos
al cliente y al equipo de trabajo
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)
•
•
•
•
•
•
•
Plan de Aseguramiento de la Calidad
Plan de Gestión de la Configuración
Plan de Verificación y Validación
Plan de Gestión de Riesgos
Procedimientos para la Gestión de Cambios
Plan de Comunicaciones a los Interesados
Plan de Mantenimiento
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
• Diagrama de Evolución de Gastos
• Enfoque del Valor Ganado
180
Registro y Control de Avance Técnicas - Gantt
Actividad
A
B
C
D
A y B están atrasadas, C adelantada, ¿y el proyecto?
¿Está costando más o menos de lo previsto?
181
Analizar Avance en Gantt
• Enfoque posible: analizar Camino Crítico
• No siempre da información:
 incertidumbre cuáles van a estar en CC por duración
 muchas actividades sin relación de precedencia y
recursos limitados.
182
Registro y Control de Avance – Técnicas -
Diagrama de Evolución de Gastos
$
Diagrama de
Planificado
Evolución
Real
de Gastos
Acumulados
Se lleva gastado más de lo previsto a la fecha, pero
t
¿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.
• Diagrama de evolución de gastos permite ver gastado respecto a lo
planificado gastar en el tiempo, pero sin relacionarlo con los logros
planificados.
• El enfoque del “valor ganado” corresponde a un modelo en el que se
unifican todas las actividades planificadas llevándolas a $ por su costo
planificado.
 Tenemos un plan de gastos que coincide con el plan de logros (lo
que ganamos).
 A posteriori es posible controlar si se logró el avance previsto y si
costó lo previsto.
 Se pueden obtener: % de avance, días de atraso, desviación de
costos.
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
Fin Planificado
(FP)
t
Fin de acuerdo
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
usando el tiempo?
- Índice de Desempeño del Cronograma
(SPI = VG / VP)
¿Cuándo vamos a terminar?
-Fin de acuerdo a la tendencia
(FT = FP / SPI)
Valor Ganado: VG | Valor Planificado: VP |
Tiempo Planificado: TP | Tiempo Real: TR | Final Planificado: FP
186
Enfoque del Valor Ganado
Medidas de Desempeño Respecto al Costo
¿Cómo vamos respecto al costo?
Análisis y Predicción de Costos
¿Estamos por encima o por debajo del -Varianza del Costo
presupuesto? ¿Cuánto?
(VC = VG - CR)
- ¿Cuán eficientemente estamos
usando los recursos?
-Índice de Desempeño del Costo
(CPI = VG / CR)
¿Cuánto va a costar el proyecto?
-Costo de Acuerdo a Tendencia
(CFT= CFP / CPI)
Costo Real: CR | Valor Ganado: VG | Valor Planificado: VP |
Costo Final Planificado: CFP
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
• Calcular SV, TV, SPI, FT
• Calcular VC, CPI, CFT
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%
• Valor planificado = 18 + 10 + 16 + 6 = $50
• Valor Ganado = 18 + 8 + 14 + 0 = $40
• Costo Actual = $45
194
Ejemplo Valor Ganado (2)
100
90
80
Recursos
70
60
VP
VG
CA
50
40
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