Estimaciones

Bibliografa:
SW Estimation. Demystifying the Black Art. Steve McConnell.

Estimacin
Para poder planificar se debe estimar:
Esfuerzo
Costo
Duracin

Para proyectos pequeos, lo mejor es estimar esfuerzo,

dividir entre la productividad y obtener el tamao.

Estimacin
Estimacin:
Prediccin de cunto va a durar un proyecto o cunto
va a costar.

Meta:
Un objetivo de negocio deseado.

Compromiso:
Promesa de entregar la funcionalidad definida con un
nivel especfico de calidad en una determinada fecha.
3

Costo /= Precio
La relacin entre el costo real de desarrollo y el precio cobrado al
cliente se ve influenciada por mltiples factores:

econmicos
polticos
del negocio
de la propia organizacin
del proyecto especfico 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!

Estimar vs. planificar

Estimacin:
proceso analtico imparcial
objetivo: exactitud

Planificacin:
proceso parcial que procura una meta.
objetivo: un resultado particular

Estimacin =/ Plan

Plan
Consideraciones basadas en estimaciones
precisas:

Crear un WBS completo

Crear un cronograma detallado
Identificar el camino crtico
Priorizar la funcionalidad a entregar
Partir el proyecto en iteraciones

Buena prediccin?
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

Estimacin = 20
meses/persona

Nuevos
requisitos

Personal
asignado a
presentacin

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

Control
Controlo el proyecto para llegar al compromiso.
Ejemplo de la valija.
Tamao de la brecha:
preparacin extra cuidadosa
apretar cronograma, presupuesto o funcionalidades
cambiar metas

Imposible evaluar capacidad predictiva de la

estimacin, pero s su habilidad para permitir xito
del proyecto.
Propsito de la estimacin: evaluar si metas son
suficientemente realistas como para poder controlar
el proyecto para alcanzarlas. (20%)

Incertidumbre de la Estimacin
Cono de Incertidumbre
Cuantas ms decisiones tome, menor la
incertidumbre.

Incertidumbre de la Estimacin
Nube de Incertidumbre
Si el proyecto no converge:

proceso catico
requisitos inestables
tecnologa desconocida
negocio desconocido

Errores en la prctica de estimacin:

no incluir alcance del proyecto

10

Influencias sobre la Estimacin

Tamao
Tipo de SW
Factores del personal
Lenguaje de programacin

11

Tamao
Factor ms importante estimar tamao.
Consideraciones:
Economa de escala: Al producir en mayor cantidad
se reducen costos por unidad.
Deseconoma de escala: esfuerzo crece
exponencialmente con tamao:
por incremento en lneas de comunicacin.
en proyectos de diferente tamao no se puede multiplicar
por la misma productividad.

12

Tipo de SW
Productividad vara segn 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 Informacin
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
Microcdigo
200
40
30
Control de procesos
1.000
300
200
Tiempo real
200
50
40
Sistemas cientficos
1.000
300
200
Paquetes
1.000
200
200
Drivers
600
100
90
Telecomunicaciones
600
100
90

13

Factores del Personal

No puedo estimar con precisin si no s quin
va a trabajar en el proyecto.
Productividad personal vara por un factor de 10.
En una misma organizacin, productividad
similar.

14

Lenguaje de Programacin
La experiencia del equipo en el leng. y herramientas 40% de impacto en productividad gral.
Herramientas de soporte y ambiente de programacin
hasta 50% de impacto.
Cantidad de sentencias
comparado con C
Lenguaje
Algunos lenguajes generan ms 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) ms productivo que en lenguajes compilados.

15

Estimacin
No existe una forma sencilla de estimar el esfuerzo
requerido para desarrollar un sistema de forma precisa:
1. Las estimaciones iniciales parten de la definicin 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 tecnologa
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" .

16

Mtricas de Tamao
Agenda:
Introduccin
Mtricas basadas en salidas:
LOCs

Mtricas basadas en funcionalidad:

Puntos de Funcin
Puntos de Caracterstica
Puntos Objeto

Mtricas de Tamao
Tamao permite:
Estimar esfuerzo y duracin
Medir calidad (defectos / unidad de construccin)
Medir productividad (tamao / unidad de esfuerzo)

Ejemplos:
Casa: metros cuadrados de construccin
Carretera: kilmetros o kilmetros cuadrados
Software: ?
LOCs
Puntos de Funcin
etc.

18

Mtricas de Tamao

Features (caractersticas)
Historias de usuario
Puntos de historia
Requisitos
Casos de Uso
Puntos de Funcin
Pginas Web

Componentes GUI
(ventanas, cuadros de
dilogo, reportes, etc.)
Tablas de la BD
Definiciones de interfaces
Clases
Funciones / subrutinas
Lneas de cdigo

19

Lneas de Cdigo
Presentan varios problemas:
Variabilidad personal:
En tamao (mismo problema, distintas personas distintos LOCs)
En productividad

En qu lenguaje?
Lneas: fsicas? lgicas? En un lenguaje, qu es una lnea
lgica?
Con o sin lneas en blanco?
Con o sin comentarios?
Construidas (pe. scripts de BD, de test unitario, etc.) o libradas
al uso?
se cuenta cdigo open source o de bibliotecas de terceros?
se cuentan interfaces de clases y declaraciones de datos?

20

Lneas de Cdigo
Necesidad de definir criterios de medicin. Pe.
lenguaje
criterios para contar lneas en ese lenguaje (fsicas o lgicas)
con/sin comentarios
construidas o libradas al uso
discriminacin de lneas reusadas
Permite evaluar productividad en programacin:
Si la potencia del lenguaje aumenta, aumenta la productividad = producto
/ unidad de tiempo
Productividad estable en LOC, independiente del lenguaje. (depende
ms del tamao del proyecto y del tipo de sw)
OJO con medir productividad individual!:
Distintos estilos (sinttico o explayado)
Peligro de efecto Cauton

21

Lneas de Cdigo

Productividad en proyectos iguales, en lenguajes distintos

Proyecto A: 80.000 LOC C

Anlisis 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++

Anlisis 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 ms productivo que C++?

Unidad de medida depende del lenguaje

22

Lneas de Cdigo
Ventajas:
fcil de medir automticamente a partir del cdigo.
permite comparar proyectos y estimar proyectos
futuros basndose en datos de proyectos pasados.
la mayora de las herramientas de estimacin basan
sus estimaciones de esfuerzo y duracin en LOCs.

23

Lneas de Cdigo
Desventajas:
para medir se precisa que el cdigo est construido
sujeto a variaciones personales/grupales y estilos de
programacin.
deseconoma de escala
productividad vara segn tipo de sw.
no pueden usarse para estimar asignaciones de tareas,
porque productividad vara entre programadores.
requisitos, diseo y testing no producen LOCs
depende del lenguaje:
dificultad para medir productos implementados en ms de un
lenguaje.
difcil comparar proyectos en distintos lenguajes.

24

Puntos de Funcin
Agenda:
Visin general
IFPUG
Frontera de la aplicacin
Transacciones
Datos

Puntos de Funcin - Visin General

Albrecht (IBM-1979)
Objetivo: traducir en un Nmero el tamao de la
funcionalidad que brinda un producto de software
Desde el Punto de vista del usuario
Suma ponderada de caractersticas 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. Lgicos
Nro.Arch. Interfaz Externa

(ILF- InternalLogical File)

(EIF-External Interface File)

26

Modelo para contar PF

EI

No mantenidos
por la aplicacin

Archivos Lgicos
Internos (ILF)

14
Caractersticas
Generales de la
Aplicacin

EQ
EO
Contiene datos
derivados y/o
afecta
comportamiento

Archivos de Interfaz
Externos (EIF)

transacciones
PF =
PFSA

Frontera de la
aplicacin

datos
x

Factor de Ajuste
27

Puntos de Funcin
Primera versin

Segunda versin
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)

28

Puntos de Funcin
Normalizado por IFPUG
Ponderadores segn complejidad de c/caracterstica
(A,M,B)
Criterios definidos para asignar complejidad a c/u
Puntos de Funcin sin ajustar+ 14 criterios de ajuste
=(+-)35%
PFA=PFSA * (0,65+ 0,01* ( ponderadores))
Pond=0 a 5

Midiendo tamao de productos en PF y en

LOCs se armaron tablas de conversin: CapersJones
29

Puntos de Funcin
Ventajas:
Se puede medir sin que exista el cdigo: a partir de documentacin
de requerimientos y/o diseo
Independiente del lenguaje

Desventajas:
aplicacin restringida a sistemas con uso intensivo de datos
persistentes y poco peso de algoritmos (Sist. de Informacin)
Medir PF requiere esfuerzo
Variabilidad en mediciones individuales - Medidores expertos
Criticado por factores de ajustes:

Demod (altamente dependientes del momento tecnolgico)

Caractersticas inciden distinto en el esfuerzo, tienen igual peso
FA elegidos son independiente entre s?
Si uso PF para estimar tamao y luego esfuerzo, corro el riesgo de
aplicar dos veces el mismo ajuste.
Combinacin de factores generalmente cerca de 1 son inocuos

30

Desarrollos ms recientes
IFPUG Manual versin 4.2 (2004)
MK II FFP (en Reino Unido)
1998 Estndar ISO 14143-1 Funct. Size Measurement

Mesma (en Holanda)

Criterio para ver si es un nico archivo lgico o varios:
Si elimino datos, el resto tambin se elimina?

31

Estandarizacin por IFPUG

Factores de ajuste:

comunicaciones de datos
procesamiento distribuido
consideraciones de performance
configuracin operacional altamente utilizada
entrada de datos on-line
eficiencia para el usuario final (dilogos interactivos)
actualizacin on-line y respaldo y recuperacin
procesamiento interno complejo
tasa de transacciones
reusabilidad
facilidad de instalacin
facilidad de operacin
uso en mltiples sitios
facilitar el cambio

32

Visin del Cliente-Usuario

No todo archivo fsico o tabla se traduce en un ILF o EIF
(archivos transitorios o de trabajo NO se cuentan)
Una transaccin que ocurre en mltiples entradas
fsicas (archivo de transacciones o pantallas, con
idntica lgica de procesamiento, se considera como
una sola transaccin)
Un mismo reporte fsico, pantalla o archivo de salida
pueden corresponder a ms de un EO/EQ
Reordenar o reacomodar los datos no se considera
como lgica de procesamiento nica
Una misma salida en distintos medios es una o varias
transacciones? No se han puesto de acuerdo.
33

Frontera de la Aplicacin (I)

Define lo que es externo a la aplicacin
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 lgicos mantenidos por la
aplicacin(ILF)
Asiste en la identificacin de los archivos lgicos
referenciados pero no mantenidos por la aplicacin (EIF)
Depende de la visin del negocio y externa del usuario
Es independiente de consideraciones tcnicas o de
implementacin
34

Frontera de la Aplicacin (II)

Usuario 1
Contabilidad
RR.HH.

Ventas

No cumple con la aditividad: si uno

componentes, la cuenta da menos.

Fronteras
definidas a partir
de la visin del
negocio
cmo impactara en
la cuenta total de PF
considerar esta otra
frontera?
35

Frontera de la Aplicacin (III)

Incide en la cuenta total de PF
al partir una aplicacin se incrementan los PF totales porque los ILF
se cuentan una vez como tales (por lo menos) y tambin se cuentan
como EIF

Se determina a partir de la visin de usuario basada en reas

funcionales separadas y NO en consideraciones tcnicas
una aplicacin Cliente/Servidor es una unidad; la frontera debe
englobar a ambos: Cliente y Servidor
una aplicacin 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.

36

Transacciones

Modelo para contar PF

EI

No mantenidos
por la aplicacin

Archivos Lgicos
Internos (ILF)

14
Caractersticas
Generales de la
Aplicacin

EQ
EO
Contiene datos
derivados y/o
afecta
comportamiento

Archivos de Interfaz
Externos (EIF)

transacciones
PF =
PFSA

Frontera de la
aplicacin

datos
x

Factor de Ajuste
38

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 funcin 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
transaccin; tiene que ser un ILF o EIF

39

Tipos de Transacciones
Definiciones:
EI (External Input) - Entrada Externa
Proceso elemental en el que datos cruzan la frontera de la
aplicacin de afuera hacia adentro. La intencin primordial es
mantener uno o ms 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
ms 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 informacin de control
cruzan la frontera de adentro hacia fuera. NO incluye datos
derivados y NO mantiene ningn ILF y NO altera el
comportamiento del sistema.

40

Proceso Elemental
Definicin:
Es la mnima 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
datos requeridos
fecha de nacimiento

41

Tipos de Transacciones - Resumen

Funcin

EI EO EQ

Altera el comportamiento del sistema

IP

NO

Mantiene uno o ms ILF

IP

NO

Presenta informacin al usuario

IP

IP

Presenta datos derivados al usuario

IP

NO

IP= Intencin Primordial

O= Opcional

42

Proceso en Transacciones
Tipo de Proceso
Acepta datos o inf. de control que entra
Presenta informacin fuera de la frontera
Altera el comportamiento del sistema
Al menos se actualiza un ILF
Frmulas matemticas y clculos
Crea datos derivados
Al menos un ILF o EIF referenciado
Recupera datos o informacin de control
Validaciones
Se convierten valores equivalentes
Seleccin y filtro de datos
Se evalan 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

43

Transacciones - Unicidad
Se cuenta si se cumple al menos una de:
Para EI:
lgica 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:

lgica 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

44

Complejidad de Tr - Nmero de FTR

Contar un FTR por cada ILF mantenido
Contar un FTR por cada ILF o EIF ledo durante el
proceso del EI
Contar slo un FTR por cada ILF que es ledo y mantenido
Ejemplo: Retiro de una cuenta bancaria
ILF en la aplicacin:
Cuenta
Movimientos
Cotizaciones dlar

El proceso de retiro lee la cuenta, verifica saldo , graba

movimiento y actualiza la cuenta.

2 FTR
45

Complejidad de Tr - Nmero de DET

Contar un DET por cada campo reconocible por el
usuario, no repetido, que entra o sale de la aplicacin
atravesando su frontera y es requerido para completar la
transaccin
No contar campos ledos o derivados por la aplicacin y
almacenados en un ILF si los campos no cruzaron la
frontera
Contar un DET por la posibilidad de que el sistema enve
un mensaje fuera de la frontera de la aplicacin 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
accin, mismo si hay mltiples mtodos para invocar el
mismo proceso lgico

46

Complejidad de EI - Nmero 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:

cdigo proveedor (E)

nombre proveedor (S)
fecha factura (E)
importe total (E)
* ( cdigo artculo

precio unitario

cantidad

importe) (E)

8 DET
47

Complejidad de EI - Nmero de DET

Ejemplo 3 ingreso de pedido de cliente
Usuario ingresa:

cdigo cliente (E)

nombre cliente (S)
fecha pedido (E)
importe total (E)

6 DET

* ( cdigo artculo

cantidad) (E)

Graba archivo de pedido con:

Cdigo cliente
Nombre cliente
Fecha pedido
*( cdigo artculo

precio unitario

cantidad)

Precio unitario se obtiene

del archivo de Artculos
NO cruza la frontera

48

Complejidad de EQ/EO Nro. de DET

Ejemplo 1 se listan los datos (nombre,
direccin, telfono)

3 DET

Ejemplo 2 grfica de tortas con la cantidad de

empleados en determinado rango de edad, con
descripcin para cada rango
2 DET:
valor y rtulo
49

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 aplicacin
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 ttulos (si son fijos) no se cuentan como DET
Variables generadas por el sistema relacionadas con el
paginado o fecha y hora
Ejemplos:

nros. de pgina
informacin de posicionamiento (filas 32 a 56 de 781)
Comandos para paginar (anterior, siguiente, barra de posicionamiento)
Fecha y hora

50

Caracterizacin de la complejidad
1 a 4 DET

5 a 15 DET

0 a 1 FTR

Baja

Baja

Media

2 FTRs

Baja

Media

Alta

3 o ms 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

Para EI

4 o ms FTRs

16 o ms DET

20 o ms DET

51

Contribucin de Transacciones
\ Complejidad
Tipo de Transaccin

Baja

Media

Alta

External Output (EO)

External inQuiry (EQ)

External Input

(EI)

52

Contribucin de Transacciones
Ejemplo -

Aplicacin integrada por:

Alta cliente (#cliente, nombre, direccin)

Listado de clientes (#cliente, nombre, direccin)

Consulta de la cantidad de clientes existentes
un nico ILF (Clientes)
Transaccin

Tipo

Nivel Complejidad

Cuenta

Alta Cliente

EI

Baja

Listado Clientes

EQ

Baja

EO

Baja

Cantidad Clientes

Total de Contribucin de Transacciones:

10
53

Menes de aplicacin
Empleado:
Nuevo
Modificar
Listar
Al elegir Nuevo aparece un formulario vaco
para ingresar datos.

NO se considera proceso elemental

porque no satisface una necesidad del usuario
54

Consulta de Empleados
Sistema de RRHH
Empleado Tareas Asignaciones Informes Ayuda
Lista de Empleados
Apellido

Nombre

CI

Sueldo

Prez

Juan

1.234.567-8

10.000

Martnez

Pedro

2.345.678-9

20.000

Fernndez

Mara

3.456.789-0

30.000

Gimnez

Ana

4.567.890-1

40.000

Detalle

Ncleo Familiar

Cancelar
55

Consulta de Empleados
Archivo Empleados: (CI, apellido, nombre, sueldo)
EQ
1 FTR
DET:

Nombre y Apellido (nombre)

CI
Sueldo
Acciones (Detalle, Ncleo Familiar, Cancelar)

Complejidad: Baja
Contribucin: 3 PF
56

GUI
Radio buttons 1 DET el grupo
Check boxes 1 DET cada opcin
Command buttons La posibilidad de
especificar una accin cuenta como un DET
Combo box 1 DET (adems es una EQ)
Desplegar imagen 1 DET
Barra de desplazamiento no cuenta

57

Ayuda sensible al contexto

El usuario pidi que alta de empleado (nombre, CI, cargo)
en la aplicacin RRHH tuviera ayuda sensible al contexto.
La informacin de ayuda es mantenida por la aplicacin
ASC en el archivo Ayuda, y es referenciada por las
aplicaciones RRHH, Contabilidad, Activo Fijo y Stock.
Al apretar F1 despliega la descripcin del campo bajo el
cursor.

Cmo se cuenta?

EQ, 1 FTR (Ayuda), 3 DET (#pantalla, #campo, texto)

EI, 1 FTR (Empleado), 4 DET (nombre, CI, cargo, F1)
58

Consulta Implcita
La modificacin de datos del empleado es
incmoda si no parte de los datos que existen.
El usuario no pidi una consulta de los datos, sin
embargo la espera.
Cmo considerarla?

EQ

Si ya est prevista la consulta del empleado

se debe contar dos veces?
59

Archivo para otra Aplicacin

Al fin del da, la informacin de los cheques
impresos por la aplicacin de RRHH se enva a la
aplicacin Contable usando un archivo de texto
Archivos involucrados:
Cheque (#cheque, importe, banco, cuenta, orden)
Cheque_txt (lnea)
Es un proceso elemental?
En caso afirmativo, de qu tipo y complejidad?
EQ , 1 FTR, 5 DET, Baja

60

Datos

Modelo para contar PF

EI

No mantenidos
por la aplicacin

Archivos Lgicos
Internos (ILF)

14
Caractersticas
Generales de la
Aplicacin

EQ
EO
Contiene datos
derivados y/o
afecta
comportamiento

PF =

Archivos de Interfaz
Externos (EIF)

transacciones
PFSA

Frontera de la
aplicacin

datos
x

Factor de Ajuste
62

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
funcin 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
habamos visto al contar funciones)

Record Element Type (RET):

es un subconjunto de campos de un archivo, reconocible como tal
por el usuario

63

Tipos de Archivos
Internal Logical File (ILF)
Es un grupo de datos o de informacin de control,
lgicamente relacionado, identificable por el usuario y
mantenido dentro de la frontera de la aplicacin.
External Interface File (EIF)
Es un grupo de datos o de informacin de control,
lgicamente relacionado, identificable por el usuario,
referenciado por la aplicacin, pero mantenido fuera de la
frontera de la aplicacin.
Nota: Un EIF para una aplicacin tiene que ser un ILF para
alguna otra.
64

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: Aplicacin de RRHH. Empleado tiene datos generales
y adems puede ser mensual o jornalero. Adicionalmente,
puede tener personas a su cargo (ncleo familiar).
RET:
Mensual (incluyendo generales) - obligatorio
Jornalero (incluyendo generales) - obligatorio
Ncleo Familiar - opcional

Nota: Los subgrupos no necesariamente son disjuntos

65

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 travs de un proceso elemental

Ejemplos:
Nmero de cuenta que se almacena en varios campos
cuenta como 1 (un) DET
Imagen previa y posterior de un archivo con 10 campos,
para auditora, cuenta como 2 DET (uno por la previa y
otro por la posterior)
El registro de fecha y hora de alta/modificacin en un
archivo, cuenta como un DET si fue requerido por el
usuario

66

Caracterizacin de la complejidad
Para ILF/EIF

1 a 19 DET

20 a 50 DET

51 o ms DET

1 RET

Baja

Baja

Media

2 a 5 RET

Baja

Media

Alta

Media

Alta

Alta

6 o ms RET

Contribucin de datos
\ Complejidad
Tipo de Archivo

Baja

Media

Alta

Int. Logical File (ILF)

10

15

Ext.Interface File(EIF)

10
67

Contribucin de Datos
Ejemplo -

Aplicacin mantiene los archivos:

Tarea ( #tarea, nom_tarea, escala)

Descripcin_Tarea ( #tarea, #lnea, l_descrip)
Empleado ( CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea)

ILF identificados: Tarea, Empleado

Tarea: 2 RET - Tarea, Descripcin_Tarea
5 DET - #tarea, nom_tarea, escala, #lnea, l_descrip
Empleado: 1 RET
5 DET - CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea
Archivo

Tipo

Nivel Complejidad

Cuenta

Empleado

ILF

Baja

Tarea

ILF

Baja

Total de Contribucin de Datos :

14

68

Usuario
Definicin:
Un usuario es cualquier persona que especifica
Requerimientos Funcionales de Usuario y/o cualquier
persona o cosa que se comunica o interacta con el
software
Ejemplos:
Para la aplicacin de RRHH incluye al personal del
departamento de RRHH que interactan con la
aplicacin y a la aplicacin contable que interacta para
recibir la informacin de los asientos contables
correspondientes a la liquidacin de sueldos
69

Contribucin de Datos Gua (I)

Los datos son un grupo lgico que soporta

requerimientos del usuario?

Una aplicacin puede usar un mismo ILF o EIF en mltiples

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 fsico, tabla o clase de objetos

corresponde a un archivo lgico desde el punto de vista del
usuario

No asumir que todo archivo fsico debe ser contado o incluido

como parte de un ILF o EIF. Pe. Archivos temporales o de trabajo.

70

Contribucin de Datos Gua (II)

Dnde se mantienen los datos, dentro o fuera

de la aplicacin?

Archivos lgicos mantenidos por ms de una

aplicacin se consideran como ILF al contar cada
una

Recordar que en el caso anterior, en cada aplicacin

slo se consideran los DET que usa y estos se
determinan desde el punto de vista de cada
aplicacin

71

Contribucin de Datos Ejemplo 1

Para la aplicacin 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

72

Contribucin de Datos Ejemplo 1

Archivos:
Seguridad_Pantalla (id_usuario, id_pantalla, tipo_acceso)
Seguridad_Auditora (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_Auditora 4 DET (fecha_hora_cambio,
id_usuario_cambio, imagen_ant, imagen_post))
73

Contribucin de Datos Ejemplo 2

La aplicacin de Seguridad permite asignar a las
personas, permisos de acceso a las instalaciones y
recursos informticos.
En la aplicacin de RRHH se mantienen los sig. datos del
archivo Empleado: (#empleado, CI, nombre, fecha_nac)
En la aplicacin de Seguridad el encargado de seguridad
puede modificar el campo nivel de seguridad y ver
adems los datos: #empleado, CI, nombre.
Cmo 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
74

Contribucin de Datos Ejemplo 3

La aplicacin de RRHH:
mantiene los sig. datos del empleado: (id, nombre,
direccin postal (calle, nro, piso, apto, ciudad, CP),
sueldo, cargo).
al ingresarlo, calcula y graba la fecha de retiro.
imprime etiquetas para envo postal.

La aplicacin Postal:
mantiene los cdigos de edificio y
genera un listado con cant. de empleados en cada piso
de cada edificio, para evaluar el proceso ms efectivo
para distribuir el correo.

Empleado: - en RRHH
- en Postal

1 ILF, 1 RET, 6 DET

1 ILF, 1 RET, 3 DET

75

Ejercicio de PF
Calcular la contribucin de los datos y de las
transacciones del ejercicio planteado.

76

Puntos de Caracterstica
PF diseados originalmente para sistemas de informacin.
Variante para sistemas con complejidad algortmica alta
(aplicaciones de tipo cientfico, de tiempo real y de
sistemas): Puntos de caracterstica
Se considera el nmero 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

77

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

aplicacin: El nro. de mdulos 3GL para
complementar el cdigo 4GL

10 PO por cada mdulo 3GL

Los PO son una alternativa a los PF cuando se utilizan 4GL.

Son ms fciles de estimar a partir de una especificacin que los PF,
ya que slo consideran pantallas, informes y mdulos 3GL. Por lo
tanto pueden estimarse en fases tempranas del proceso de
desarrollo. En estas etapas resulta muy difcil estimar el nro. de
LOCs de un sistema.

78

Tcnicas de Estimacin

Contar, Calcular, Juzgar

Ejemplo: Banquete
Costoso contar comensales uno por uno
Estimaciones:

Experto: 335
Carlos: 11 * 7. Plan: 5 personas por mesa = 385
Luca: Lmite: 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.

80

Contar
Tamao es factor ms importante. Buscar mtrica
significativa del tamao, dependiendo del ambiente.
Buscar lo que se pueda contar lo ms temprano posible:
desarrollo temprano: caractersticas, CU, historias...
medio: reqs detallados, PF, solicitudes de cambio, pginas web,
reportes, pantallas, tablas...
desarrollo tardo: cdigo, defectos reportados, clases, tareas...

Contar algo que produzca un promedio estadsticamente

vlido (por lo menos 20 tems).
Mismas asunciones que datos histricos: misma
mtrica, tamao de equipo, experiencia de
programadores, tecnologa de desarrollo, etc.
Contar lo que requiera menor esfuerzo.
81

Calcular
Recoger datos histricos para poder calcular
una estimacin a partir de una cuenta.
Ejemplos:
cuento cant. defectos abiertos / pginas web
calculo a partir de:
tiempo promedio que llev corregir defectos
tiempo promedio para disear, implementar y testear
pginas web

Puedo calibrar con 3 tipos de datos:

de la industria (desarrollos del mismo tipo de sw)
histricos de la organizacin
del proyecto
82

Datos de la Industria
Productividad entre distintas organizaciones
vara 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 histricos son igual o mejores que juicio
de expertos.

83

Datos Histricos

En proyectos medianos o gdes. las caractersticas organizacionales

influyen ms que las capacidades personales en el resultado del proy.:
Se puede despedir empleados?
Personal con dedicacin exclusiva o interrupciones de soporte?
Se puede contratar personal o se lo saca de otros proyectos?
La organizacin apoya prcticas efectivas de diseo, implementacin,
aseguramiento de la Q y verificacin?
La organizacin opera bajo regulaciones?
Alta rotacin de personal en el empresa?

Datos histricos incluyen estos factores.

Factores de ajuste de Cocomo son subjetivos; datos histricos, no.
Se usa asuncin simplificadora: las cosas van a ir ms o menos igual que
en proyectos anteriores (no mejor, como querra).
Datos a recoger:

Tamao (LOCs)
Esfuerzo (meses-persona)
Duracin (meses calendario)
Defectos (clasificados por severidad)

84

Tcnicas de Estimacin

Estimaciones basadas en Proxies.

Juicio de Expertos
Estimacin por Analoga
Mtodos Algortmicos
Mtodos basados en Aprendizaje
Automatizado

85

Enfoques de Estimacin
Estimacin global (visin de las diferentes reas)
Desv.: pasar por alto dificultades tcnicas asociadas a
componentes.

Descomposicin y estimacin de c/componente (WBS):

Desv: pasar por alto esfuerzo de integracin.
pesimista, ms probable, optimista
distribucin Beta: E =(p+4m+o)/6
como en Pert; se pueden considerar v.a. independientes? En
tamao, 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

86

Estimaciones basadas en Proxies

Identificar un proxy:

correlacionado con lo que queremos contar

ms fcil de contar o estimar
o disponible ms tempranamente.
Pe. casos de prueba. Proxy = reqs.

Contar o estimar los tems del proxy

Usar datos histricos para calcular.
Sirven para crear estimaciones globales
(proyecto, iteracin), pero no para una tarea o
caracterstica.
87

Estimaciones basadas en Proxies Tcnicas

Fuzzy Logic
Componentes Estndar
Puntos de historia
T-Shirt Sizing

88

Fuzzy Logic
Clasificar caractersticas en MP, P, M, G, MG.
Datos histricos: LOCs promedio por
caracterstica.
Calcular
Tamao caracterstica
Muy pequeo
Pequeo
Mediano
Grande
Muy grande
Total

LOCs promedio por caracterstica

127
253
500
1014
1998

Cant. caractersticas
22
15
10
30
27
104

LOCs estimadas
2794
3795
5000
30420
53946
95955

Se aplica la Ley de los Nmeros Grandes.

Se puede aplicar tambin a estimacin de
esfuerzo.
89

Componentes Estndar
Si desarrollamos muchos programas que son similares
en arquitectura.
Pasos:
Identificar componentes estndar (pginas web, archivos,
tablas, reglas de negocio, grficos, pantallas, reportes, etc.)
Calcular LOCs promedio por componente en datos
histricos.
Estimar la cant. de componentes estndar.
Ms
Comp. estndar
LOCs por componente Mn probable
Mx Nro. estimado LOCs estimadas
Pg. web dinmicas
487 11
25 50
26,8
13052
Pg. web estticas
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.

90

Juicio de Expertos
La estimacin se realiza valindose de la
experiencia y de la opinin de expertos como
nica gua.
Aplicable a Tamao, Esfuerzo, Costo, Duracin
Estimaciones iniciales en gral. subestimamos
Humphrey multiplicar x 2

91

Juicio de Expertos
Tcnica Delphi (formal)
Consulta a varios expertos
C/experto estima por separado
Valor medio se distribuye y se pide ajuste de estimacin
Variantes con discusin previa o justificaciones
distribuidas
Normalmente los resultados convergen rpidamente

92

Estimacin por Analoga

Un proyecto similar en tamao, complejidad y tipo
de funciones a otro, probablemente dure y cueste
aproximadamente lo mismo.

Analoga 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
93

Estimacin por Analoga

Matriz de costos de Wolverton (TRW-1974)

O=Old; N=New

Tipo
Control
I/O
Pre/post proces.
Algoritmo
Manejo de Datos
Tiempo crtico

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 tamao de cada mdulo en LOCs

94

Estimacin por Analoga

Matriz de costos
Idea: cruzar tipo de programas con niveles de
dificultad
Tabla en base de datos histricos
Con estabilidad tecnolgica y caractersticas
similares de personal buena estimacin
En Uruguay, mejor por esfuerzo, por inflacin.

Modelo subjetivo:
Difcil determinar similitudes. Pe. Maratn
Difcil determinar cmo diferencias afectan costo

95

Mtodos Algortmicos
Modelos que reflejan relacin entre esfuerzo factores que lo
influencian (experiencia, tamao, tipo de aplicacin).
Elaborados a partir de una gran muestra de proyectos de
diverso tamao y complejidad, tomados de diversas
organizaciones.
Sirve como base, cuando no se dispone de base histrica
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 tamao estimado del producto Tamao es factor ms
influyente
c gral. est entre 1 y 1.5. Refleja que el esfuerzo no crece linealmente
con el tamao, 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

96

Mtodos Algortmicos
Ejemplo: Walston-Felix (1977): E=5.25 S0.91
Inters histrico.
Exponente menor que 1 E crece, pero crece menos
la productividad crece con el tamao.

Ejemplo: COCOMO (Constructive Cost Model) Boehm

81.
Problema: modelos dependientes del tamao.
Trasladan estimacin del esfuerzo a estimacin del
tamao. Pero estimaciones son requeridas
tempranamente, y tamao depende de decisiones de
diseo.

97

COCOMO II
3 modelos con distinto nivel de complejidad
composicin de aplicaciones (tamao en Object Points)
diseo temprano (tamao en PF)
post-arquitectura (tamao 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, duracin (y cantidad promedio de gente)
de desarrollo, SIN contar Requerimientos
Esfuerzo en Meses-Persona (152 horas-Persona)

98

COCOMO II - Ajustes de Escala

PREC -> Precedentes
FLEX -> Flexibilidad del Desarrollo
Requerimientos pre-establecidos
Interfaces externas
RESL -> Arquitectura/Resolucin de Riesgos
TEAM -> Cohesin del equipo
PMAT -> Madurez del Proceso de SW

99

COCOMO II

Multiplicadores de Esfuerzo (Post-Arq.)

4 categoras:
Atributos del producto
Relativos a las caractersticas del sw a desarrollar
RELY
-> Confiabilidad requerida
DATA
-> Tamao BD
CPLX
-> Complejidad
RUSE
-> Reuso de productos en proyecto y otros
DOCU -> Documentacin 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

100

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 caractersticas intrnsecas de cada proyecto especfico
TOOL
-> Herramientas
SITE
-> Dispersin/Comunicaciones
SCED -> Compresin/Estiramiento de Plazo

101

Aprendizaje Automtico
Aprender de proyectos pasados
Predecir el costo (esfuerzo, duracin)
Tcnicas de Data Mining:
Construir un modelo (Redes Neuronales, Modelos
Estadsticos) consistente con datos histricos
usar el modelo para generar una prediccin
(estimacin) del futuro

102

Estimacin 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 ms personas trabajan en un proyecto,
mayor el esfuerzo total por prdidas debidas a
la comunicacin.
La incorporacin de personal en ltimas fases
incrementa el esfuerzo y ocasiona retrasos en
la fecha de finalizacin del proyecto.
103

Gestin de los Recursos

Humanos

Gestin de RR.HH.
Def.?
Gestin pobre de RRHH causa de fracaso del
proyecto.
Factores crticos:

Consistencia
Respeto
Inclusin
Honestidad

105

Recursos Humanos y Organizacin

Para determinar el calendario del proyecto y
estimar el esfuerzo y costo asociados, debemos
saber:
cunta gente va a estar trabajando en el proyecto,
qu tareas van a desarrollar y
qu habilidades y experiencia deben tener.

Quin hace qu y cmo se va a organizar el

personal.

106

Conformacin del Equipo de

Desarrollo
El trabajo en grupo se impone en el desarrollo de
SW:
por el tamao del proyecto y
porque el problema a resolver abarca muchos aspectos
distintos en los que se requieren distintos expertos.

Cmo seleccionar el personal del

equipo de desarrollo?
Fuentes:
CVs
Entrevistas
Referencias

107

Caractersticas del Personal

Capacidad para desempear una tarea
Inters en el trabajo
Experiencia con aplicaciones similares, herramientas,
lenguajes, tcnicas y ambiente de desarrollo
Capacitacin - estudios
Capacidad para comunicarse con otros y compartir la
responsabilidad
Capacidad de supervisin
Capacidad para resolver problemas
Adaptabilidad Capacidad de aprender, aceptar y
asimilar cambios.
Capacidad para resistir cierta cantidad de tensin.
Personalidad

108

INTUITIVO
INTUITIVO
INTUITIVO
INTROVERTIDO:
EXTROVERTIDO:
Pregunta al resto
Informa al resto
Reconoce
Reconoce sentimientos
sentimientos

RACIONAL
INTROVERTIDO:
Pregunta al resto
Decide
lgicamente

RACIONAL
EXTROVERTIDO:
Informa al resto
Decide lgicamente

EXTROVERTIDO

INTROVERTIDO

Estilos de Trabajo

RACIONAL
de tcnicos son introvertidos (vs. 1/3 de la poblacin)

109

Motivacin
Maslow 54
Necesidad
de realizacin
Necesidades
de estima
Necesidades sociales
Necesidades de seguridad
Necesidades fisiolgicas
110

Motivacin
En orgs. de desarrollo de SW, satisfacer:
Necesidades sociales:
tiempo y lugares de encuentro, interaccin entre los miembros

Necesidades de estima:
reconocimiento pblico de sus logros
pago acorde a habilidades y experiencia

Necesidades de realizacin:
hacerlos responsables por su trabajo
asignarles tareas demandantes pero no imposibles
proveer programa de capacitacin

Ser miembro de un grupo cohesivo es altamente motivador Motivar al grupo como tal.

111

Trabajo en Grupo
Composicin del grupo:
Balance de habilidades, experiencia y
personalidades

Cohesin:
Equipo y no personas trabajando juntas

Comunicaciones:
Comunicacin efectiva

Organizacin:
Todos satisfechos con su rol y valorados

112

Composicin del Grupo

Se pueden catalogar tres personalidades tipo genricas:
Orientadas a la tarea. La motivacin es el trabajo en s.
Orientadas a la relacin. La motivacin es el trabajo en equipo y la
relacin y presencia de otros compaeros de tarea.
Orientadas a s mismas. - La motivacin es xito personal.

De los grupos constituidos nicamente por un tipo de las

personalidades anteriores, slo funciona bien el de los orientados a la
relacin.
Los grupos de las personalidades orientadas a la tarea y orientadas a
s mismas no funcionan:
sentimientos negativos a trabajar en equipo
exceso de lderes.

Lo ms exitoso es constituir equipos donde:

exista un equilibrio en las personalidades de los integrantes

el lder est orientado a la tarea.

113

Composicin 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 aceptacin 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.
114

Actividades del jefe de proyecto

Organizacin del modo de trabajo.

Asignar el personal
Asignar/ajustar los roles y responsabilidades
Definir/comunicar los objetivos
Estimacin del trabajo que puede realizar el personal
Planificacin de las tareas a realizar por cada miembro
del equipo.
Control de las actividades del personal
Motivar
Facilitar la comunicacin entre los integrantes
Resolucin de problemas haciendo uso del personal
disponible
Brindar retroalimentacin respecto a los logros
115

Cohesin 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 estndar de calidad
trabajo conjunto entre integrantes
todos conocen el trabajo de todos. Hay continuidad si
uno se va
responsabilidad del sw compartida (egoless
programming)
116

Cohesin del Grupo

Para fomentar la cohesin:
eventos sociales con las familias
sentido de identidad del grupo, nombre y territorio
actividades de construccin de grupo: pe. deportes

Problemas:
Resistencia irracional al cambio de lder
Pensamiento grupal Habilidades erosionadas por
lealtad

117

Trabajo en grupo

Distribucin del tiempo

118

Comunicaciones
Dentro del equipo de desarrollo las comunicaciones son
necesarias e inevitables para que el grupo trabaje con
eficiencia.
Pero tambin son improductivas ya que mientras dura la
comunicacin el individuo no est realizando su funcin.
Por tanto, intentar minimizar y acortar las reuniones de
comunicacin.
Qu factores afectan a la comunicacin en grupo?
Tamao del grupo
Estructura del grupo
Composicin del grupo - Personalidades implicadas y su
categora profesional
Ambiente fsico de trabajo

119

Comunicaciones
Dos personas

1 lnea de comunicaci

Tres personas

3 lneas de comunicaci

Cuatro personas

6 lneas de comunicaci

Cinco personas

10 lneas de comunicaci
:
n(n-1)/2 lneas d
comunicacin

:
n personas

120

Comunicaciones
Cuanto mayor es el grupo mayor es el nmero de
enlaces de comunicacin 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 comunicacin y el mnimo de
comunicaciones entre grupos.

Los grupos ideales son de entre 2 y 8 personas.

Disminuyen los problemas de comunicacin.
Otros beneficios:
Los miembros del grupo conocen el trabajo de los dems, 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.

121

Organizacin del Equipo de Proyecto

Los miembros del equipo se organizan para
generar productos de calidad de manera
eficiente.
La eleccin de una estructura apropiada
depende de:
la formacin y estilos de trabajo de los miembros del
equipo
la cantidad de integrantes del equipo
los estilos de direccin de los clientes y
desarrolladores
122

Chief Programmer Team

Chief
programmer
Assistant chief
programmer

Senior
programmers

Librarian

Administration

Test team

Junior
programmers
123

Chief Programmer Team

A cada una de las personas del equipo de desarrollo, se
le asignan una serie de tareas de forma individual, y
slo 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

124

Enfoque Egoless (sin ego) Equipo

Democrtico 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 asignacin y coordinacin de
tareas entre los distintos equipos es responsabilidad
del jefe de proyecto.

125

Equipo Democrtico
Todos los miembros del equipo participan en las decisiones
(democrtico).
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 aqul.
El software es producto de un equipo ms que de personas
individuales. No hay identificacin personal con el software.
Para eso, las crticas se hacen al producto o resultado, no a
las personas.

126

Equipos Jerrquicos

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
desempear.
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 comunicacin

Resto de componentes del equipo de desarrollo

127

Comparacin de Estructuras
Organizativas
Muy Estructuradas
Certidumbre
Repeticin
Proyectos Grandes

Poco Estructuradas

Incertidumbre
Nuevas Tcnicas o Tecnologa
Proyectos Pequeos
Creatividad

128

Ambiente Fsico de Trabajo

El tamao 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. Personalizacin: Posibilidad de adaptar al gusto
propio el ambiente de trabajo personal.
4. reas comunes para intercambiar y discutir

129

Ciclo de Vida de un Equipo

Integracin
Tormenta
Aceptacin
Etapa productiva
Desintegracin

130

Reuniones (Problemas)

El propsito es poco claro.

Los participantes no estn preparados.
Gente clave est ausente o llega tarde.
La conversacin se aleja del propsito.
Los participantes discuten, dominan la
conversacin, o no participan.
Las decisiones tomadas en la reunin luego
nunca se hacen efectivas.
A una reunin de 8 personas durante 2 horas
significa un esfuerzo de 16 horas/persona
131

Reuniones (Soluciones)
Definir objetivo, agenda y duracin
Los participantes deben conocerlos con
antelacin suficiente
Definir quines deben (y no deben) participar
Asignar el rol de coordinador o moderador para
ceirse a la agenda
Asignar el rol de secretario, responsable por el
acta, la que se debe distribuir a los participantes

132

Manejo de Conflictos
Qu opinar de un proyecto en el que no
aparece ningn 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

133

Estilos de Manejo de Conflictos

Estilo

Nivel de Eficacia

Evitarlo

No lo resuelve (reaparece)

Suavizarlo

Solucin corto plazo, No lo

resuelve

Solucin de compromiso

Solucin, pero todos pierden

algo

Forzar la resolucin

Solucin, pero daa las

relaciones entre las partes

Enfrentarlo/buscar
solucin al problema

Se logra la mejor solucin

134

Conflictos - Criterios Generales

No responder a posibles agresiones
Or y comunicarse efectivamente
Promover la apertura, expresin 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 innovacin
Elegir la estrategia para enfrentarlo teniendo en cuenta
la importancia, urgencia y consecuencias posibles
Conviene encontrar soluciones del tipo ganar-ganar
135

Evaluacin de Factibilidad

Estudio de Factibilidad (I)

Estudio corto para resolver si es posible y
conveniente construir el sistema con la
tecnologa existente, las restricciones de costo y
tiempo, etc.
Responder a la pregunta: Vale la Pena?

137

Estudio de Factibilidad (II)

Estudio y evaluacin de alternativas
Factibilidad (para alguna o varias alternativas)
Tcnica:
Es posible?Puede ser implementado con la tecnologa
existente, dentro de las restricciones de costo y tiempo?
Qu se precisa para lograrlo?) => Recursos, Plazo

Econmica (cunto cuesta? flujos financieros?)

Operativa (Habr algo que haga que el sistema no
funcione?).
Ej.: cultura de la organizacin
Puede ser integrado con otros sistemas existentes?

Jurdica
Institucional:
Contribuye el sistema a los objetivos globales de la organizacin?

138

Estudio de Factibilidad (III)

Anlisis Costo/Beneficio
Tcnicos

Clientes

Informe de Factibilidad: Documento donde se

recomienda si seguir con el sistema,
proponiendo cambiar el alcance, presupuesto,
agenda, etc.

139

Eval. de Factibilidad - Cundo

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?

140

Estudio de Factibilidad Ejemplo

Proyecto ComidaClick
Introduccin
Factibilidad de la solucin
Factibilidad tcnica
Factibilidad econmica

Impacto del proyecto

Impacto en el mbito social

Impacto econmico
Impacto ecolgico
Impacto cultural

Pertinencia del proyecto

Conclusiones
141

Evaluacin Financiera de Proyectos

Tasa de dto.
Inversin Inicial
PROYECTO 1
Semestres
0
1
2
3
4
5
Tasa Dto. Semestral
Actualizacin de FF
VAN
TIR
Actualizacin Ingresos
Actualizacin Egresos
Indice Rentabilidad

3,15%
$ 50.000

Ingresos
20.000
22.000
25.000
25.000
25.000

ANUAL

Egresos
6.000
7.500
6.000
6.000
6.000

Flujo Caja
(50.000)
14.000
14.500
19.000
19.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
Actualizacin de FF
VAN
TIR
Actualizacin Ingresos
Actualizacin 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
Actualizacin de FF
VAN
TIR
Actualizacin Ingresos
Actualizacin 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

142

Gestin de Riesgos

Definicin de Riesgo
Un riesgo es un evento o condicin inciertos,
que, si se produce, tiene un efecto positivo o
negativo sobre al menos un objetivo del proyecto.
Objetivo de la Gestin de Riesgos:
aumentar la probabilidad y el impacto de los
eventos positivos, y disminuir los de los adversos.
Gestin proactiva y consistente durante todo el
proyecto.

144

Proceso de Gestin de Riesgos

1. Planificacin de la Gestin de Riesgos
2. Identificacin de riesgos

Identificar los posibles riesgos del proyecto, del producto y del

negocio.

3. Anlisis cualitativo [y cuantitativo]de Riesgos:

Determinar la probabilidad de ocurrencia y las consecuencias de

cada riesgo.

4. Planificacin 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.

5. Seguimiento y Control de los Riesgos

Controla la ocurrencia de riesgos y ejecuta los planes de

mitigacin y contingencia, y evala su efectividad, a lo largo del
proyecto.

145

Proceso de Gestin de Riesgos

Planificacin de la
Gestin de Riesgos

Identificacin

Anlisis

Planificacin
de la Respuesta

Seguimiento
y Control

Plan de
Gestin de
riesgos

Lista de
riesgos

Lista de
riesgos
priorizados

Planes de
reduccin y
contingencia

Evaluacin
de los
riesgo

Registro de Riesgos

146

Planificacin
de la Gestin de Riesgos
Proceso de decidir cmo abordar y llevar a cabo
las actividades de gestin de riesgos.
En fase temprana.
Salida: Plan de Gestin de Riesgos (parte del
Plan de Gestin del Proyecto):

Metodologa
Roles y responsabilidades
Preparacin del presupuesto
Periodicidad
Categoras de riesgos
Definiciones de niveles probabilidad e impacto
(relativas, numricas).

147

Identificacin de Riesgos
Determina qu riesgos pueden afectar al proyecto y documenta
sus caractersticas.
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
Genricos: comunes a todo proyecto de software.
Especficos: vulnerabilidades especficas de un proyecto dado.

Salida: Registro de Riesgos:

Lista de riesgos identificados
Causas (= condiciones o eventos que daran lugar al riesgo)

148

Categoras de Riesgos (PMBoK)

Tcnico

Externo

Requisitos
Tecnologa
Complejidad
e interfaces
Rendimiento
y fiabilidad
Calidad

de la
organizacin

Direccin de
proyectos

Subcontratistas
y proveedores

Dependencias
del proyecto

Regulatorio

Recursos

Planificacin

Mercado

Financiacin

Control

Cliente

Priorizacin

Estimacin

Comunicacin

Condiciones
climticas

149

Clasificacin de Riesgos (Sommerville)

Riesgos:

del proyecto

del producto

del negocio

Problemas presupuesto
de:
agenda
personal
recursos
del cliente y
sus requisitos
tamao
complejidad del
proyecto

diseo
interfaz
incertidumbre
tcnica
obsolescencia o
de utilizacin de
tecnologa de punta

cambio en la
direccin
cambios de
estrategia de
negocio
cambios en el
mercado
prdidas en la
empresa

Afectan:

la calidad del sw
resultante.

al equipo de
desarrollo y a
la realizacin del
proyecto en s.

el costo y
la duracin del
proyecto.

150

Riesgo

Tipo

Descripcin

Abandono del personal del

proyecto

Proyecto

Personal experimentado deja el proyecto antes de

su finalizacin.

Cambios de gerencia

Proyecto

Cambios en la gerencia, con diferentes

prioridades.

HW no disponible

Proyecto

HW para el desarrollo, el testing o la implantacin

no est disponible en la fecha acordada.

Cambio en los requisitos

Proyecto y
producto

El nmero o el impacto de los cambios en los

requisitos es mayor al esperado.

Retrasos en la especificacin

Proyecto y
producto

La especificacin de las interfaces no estn

disponibles en la fecha acordada.

Tamao subestimado

Proyecto y
prod.

El tamao 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 tecnologa

Negocio

La tecnologa sobre la cual iba a construirse el

proyecto es sustituda 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.

151

Tipos ms comunes de riesgos

Tipo de riesgo

Tcnicos
(tecnologas utilizadas (sw y hw))

De personal
(equipo de desarrollo)

Organizacionales
(del ambiente organizacional de
desarrollo y del cliente)

(Sommerville)

Ejemplos

BD no puede procesar la # de transacciones/seg esperada.

Componentes de SW a reusar defectuosos.
Tecnologas desconocidas.
No se consigue personal con las habilidades requeridas.
Personal clave no est disponible.
No se puede proveer la capacitacin necesaria.
Nueva gerencia.
Probs. financieros reducen presupuesto.

De herramientas

El cdigo generado es ineficiente.

Incompatibilidad entre herramientas.

De requerimientos

Cambios en reqs requieren trabajo de rediseo importante.

Los clientes no logran entender impacto de cambios
solicitados.

De estimacin

Tiempo de desarrollo, tasa de reparacin de defectos y/o

tamao subestimados.

152

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, desempeo, calidad
7. Cambios en Requisitos
8. Software Heredado
9. Tareas externas
10. Forzar ciencia de computacin

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. Desempeo de Tiempo Real
10. Forzar ciencia de
computacin

153

Anlisis Cualitativo de Riesgos

Evaluar los riesgos identificados:
Impacto o prdida asociada si ocurre
Probabilidad de ocurrencia
Calificarlos y priorizarlos segn Severidad o Exposicin:
(Severidad= impacto * probabilidad)
Registrar:
detalles explicativos
asunciones
agruparlos por categora o fase del proyecto o causas comunes,
para analizar
indicadores de prioridad:
urgencia tiempo para dar respuesta
sntomas y seales de advertencia
calificacin del riesgo

154

Anlisis Cuantitativo de Riesgos

Opcional
Tcnicas:

Anlisis de sensibilidad
Anlisis del valor monetario esperado
Anlisis mediante rbol de decisiones
Modelado y simulacin

155

Diagrama de rbol de Decisiones

Definicin de
decisin

Nodo de decisin

Nodo de posibilidad

Valor del camino

Decisin a tomar

E: Costo de cada opcin

S: Decisin 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 decisin = $
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

156

Planificacin de la Respuesta Estrategias

Evitar / Explotar
Transferir / Compartir
Mitigar / Mejorar:
(= reducir / aumentar probabilidad o impacto)

Aceptar:
decisin de no cambiar plan de gestin 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

157

Planificacin 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
ms de una persona en puestos clave.
Prdida de informacin Mitigacin: 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.

158

Mitigacin del Riesgo

Quizs no sea rentable o posible desarrollar
respuestas proactivas. Se justifica dependiendo
de:
Nivel de Reduccin= (severidad antes de reduccinseveridad despus de reduccin) / (costo de reduccin)
Si nivel de reduccin<1 no valdr la pena

159

Seguimiento y Control de Riesgos

Monitorear riesgos peridicamente:

Detectar riesgos nuevos o que cambien
Seguimiento de riesgos identificados
Seguimiento de condiciones que disparan
planes de contingencia
Revisar ejecucin de las respuestas a los
riesgos y su efectividad.

160

Actividades en Gestin de Riesgos

Segn Rook, 1993

Lista de Comprobacin
Descomposicin
Anlisis de Supuestos
Anlisis de Procs. de
Decisin de Sistemas
Dinmica
Modelos de Desempeo
Modelos de Costo
Anlisis de Redes
Anlisis de Decisiones
Factores de Riesgo en Calid

Identificar Riesgos
Evaluar Riesgos Analizar Riesgos
Priorizar Riesgos
No se pueden
atender todos

Gestin de Riesgos

Impacto y/o
Probabilidad

Severidad de Riesgos
Reduccin Compuesta

Reducir
Incertidumbre
Reducir Riesgos

Control de Riesgos

Obtener Informacin
Evitar un Riesgo
Transferirlo
Evaluar Nivel de Reducci
Desarrollar el Proceso

Planear Solucin de Riesgos

Qu hacer si ocurre

Peridicamente, o en Resolver Riesgos

hitos del proyecto

Planear elemento de Rie

Plan integrado
Reducir Riesgo
Una vez
Monitoreo e Informes
ocurrido
Reevaluar Riesgos
161

Riesgos y el Plan del Proyecto

Actividades de Reduccin de Riesgos ->WBS
Considerarlas en plazo, esfuerzo, costo
Prever un colchn en el plazo
8% de duracin para proyectos normales (no
planificar con el enfoque si todo sale bien)
ms si el riesgo de pasarse de la fecha estipulada
para el proyecto lo justifica

162

Gestin de la Calidad

Gestin de la Calidad
Planear la calidad:
identificar estndares de calidad relevantes al proyecto y cmo
satisfacerlas

Asegurar la calidad:
asegurar que los estndares se cumplieron
detectar de desviaciones durante el proceso de produccin
para aumentar la confianza en la obtencin de los objetivos de
calidad

Controlar la calidad:
control de productos obtenidos

Gestin de la Q debe reportar a alta gerencia

directamente, por encima del jefe de proyecto, para
que obj. de Q no estn comprometidos por recortes de
presupuesto o calendario.
164

Gestin de la Calidad
Gestin de la
Calidad
Planear la
Calidad

Asegurar la
Calidad

Responsabilidades
Estndares
Procedimientos
Puntos de Control

Revisiones

Verificar

Auditoras

Validar

Mtricas de Q
Checklists

Controlar la
Calidad

WBS
165

Plan de Calidad
Plan de Calidad:
Descripcin del producto, mercado y calidad esperada.
Planes del producto: fechas de liberacin de versiones,
responsables del producto, planes de distribucin del producto.
Desc. de procesos para el desarrollo y la gestin del producto.
Los atributos de calidad ms 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.
Gestin de riesgos claves que pueden afectar la calidad del
producto.

166

Gestin de la Calidad
Relacin entre calidad del proceso y calidad del
producto:
es claro en procesos de manufactura, porque el
proceso se puede estandarizar y monitorear
fcilmente.
el SW no es manufacturado sino diseado difcil
predecir cmo cambios en proceso afecta Q del
producto. Pero experiencia muestra relacin.

167

Gestin de la Configuracin

Gestin de la Configuracin
Gestin de los componentes de un producto:
Registro y control de los cambios de un producto y
de sus componentes
Coordinacin fuente-ejecutable

Gestin de los entregables de un proyecto:

Registro y control de sus cambios
Asegurar su disponibilidad (respaldos)
Generacin y Control de la Lnea Base o de
Referencia

WBS
169

Gestin de las Comunicaciones

Gestin de las Comunicaciones

Procesos involucrados:
Planificacin de las comunicaciones
Distribucin de la informacin
Reportes de situacin, avance y
predicciones
Cierre administrativo

171

Comunicacin entre los Involucrados

Patrocinador, Cliente, Usuario, Desarrolladores,
Otros Interesados-Involucrados
Procedimientos de comunicacin
peridicos, 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
172

Plan de Gestin del Proyecto

Plan de Gestin del Proyecto

Documento para comunicar :

organizacin
estimaciones de costo y duracin
calendario de actividades e hitos del proyecto
la gestin y el anlisis de riesgos

al cliente y al equipo de trabajo

174

Plan de Gestin del Proyecto Puntos (1)

Alcance
Descripcin tcnica del sistema propuesto
Estndares, procedimientos y tcnicas y
herramientas propuestas
Calendario
Organizacin del equipo de proyecto
Plan de Gestin de RRHH
Plan de Capacitacin
175

Plan de Gestin del Proyecto Puntos (2)

Plan de Aseguramiento de la Calidad

Plan de Gestin de la Configuracin
Plan de Verificacin y Validacin
Plan de Gestin de Riesgos
Procedimientos para la Gestin de Cambios
Plan de Comunicaciones a los Interesados
Plan de Mantenimiento

176

Registro y Control de Avance

Bibliografa especfica:
Practice Standard for Earned Value Management (PMI
2005)

Registro y Control de Avance

Saber dnde est un proyecto y hacia dnde
est yendo, comparando con lo planificado.
Objetivos:

medir
analizar
predecir
informar el desempeo en costos y cronograma

178

Medicin del Desempeo del Proyecto

Dimensiones:
Granularidad del desglose de actividades
nivel de detalle del WBS
Frecuencia de la medicin
Intervalo en que el desempeo del proyecto es medido

Dependen de:
importancia (significance) impacto del fracaso o xito.
Factores que la afectan:

financieros
polticos
ambientales
incertidumbre probabilidad de fracaso o xito.
Factores que contribuyen:

tamao
complejidad
duracin

179

Registro y Medicin del Avance

Actividades cumplidas (entregables obtenidos)
Cuidado con los significados, ej. programa terminado =
terminada la codificacin?
revisado por un par?
pas la prueba unitaria?
pronto para entrar en explotacin?

Actividades empezadas
Cmo considerar actividades a medias?
180

Tcnicas de Medicin
Seleccin de la tcnica en base a:
Tangiblidad del producto
Duracin del esfuerzo

181

Tcnicas de medicin
Productos Tangibles (I)

Tcnicas de frmula fija:

Tareas no empezadas en 0

Tareas comenzadas: Se asigna un % fijo al fin del primer perodo de

medicin (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

182

Tcnicas de medicin
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 ms largas, con entregables
intermedios tangibles.

Porcentaje de completitud:
Es la tcnica ms subjetiva, si no hay indicadores
objetivos (pe. # unidades del producto completas)
En cada perodo de medicin, el responsable de la tarea
estima el % de trabajo completado.
Riesgo del Sndrome del 90%

183

Tcnicas de medicin
Productos Intangibles

Esfuerzo repartido
si la tarea B tiene una relacin directa de soporte con
otra A. Pe. (QA, inspecciones)
El VG para cada perodo de medicin 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 perodo de medicin y se
acredita al finalizar el mismo.

184

Registro y Control de Avance

Tcnicas

Gantt
Diagrama de Evolucin de Gastos
Enfoque del Valor Ganado

185

Registro y Control de Avance Tcnicas - Gantt

Actividad
A
B
C
D

A y B estn atrasadas, C adelantada, y el proyecto?

Est costando ms o menos de lo previsto?
186

Analizar Avance en Gantt

Enfoque posible: analizar Camino Crtico
No siempre da informacin:
incertidumbre cules van a estar en CC por duracin
muchas actividades sin relacin de precedencia y
recursos limitados.

187

Registro y Control de Avance Tcnicas -

Diagrama de Evolucin de Gastos

$

Diagrama de

Planificado

Evolucin

Real

de Gastos
Acumulados

Se lleva gastado ms de lo previsto a la fecha, pero

cul fue el avance logrado? se va a gastar ms o menos de

lo previsto?
188

Registro y Control de Avance Tcnicas

Enfoque del Valor Ganado

Modelo implcito en diagrama de Gantt nos dificulta determinar si el
proyecto est o no atrasado.
Diagrama de evolucin 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 llevndolas 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, das de atraso, desviacin de
costos.

189

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

t1

t0

Fin Planificado
(FP)

Fin de acuerdo
a tendencia (FT)

190

Enfoque del Valor Ganado

Medidas de Desempeo Respecto al Tiempo
Preguntas de Gestin del Proyecto Medidas de desempeo (MVG)
Cmo vamos respecto al tiempo?

Anlisis y Prediccin de Cronograma

-Estamos adelantados o atrasados?

-Varianza del Cronograma

(SV = VG -VP)

-Cunto?

- Varianza del Tiempo (TV = TP TR)

Cun eficientemente estamos

usando el tiempo?

- ndice de Desempeo del Cronograma

(SPI = VG / VP)

Cundo 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

191

Enfoque del Valor Ganado

Medidas de Desempeo Respecto al Costo
Cmo vamos respecto al costo?

Anlisis y Prediccin de Costos

Estamos por encima o por debajo del -Varianza del Costo

presupuesto? Cunto?
(VC = VG - CR)
- Cun eficientemente estamos
usando los recursos?

-ndice de Desempeo del Costo

(CPI = VG / CR)

Cunto 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

192

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 podran
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.
193

Enfoque del Valor Ganado

Guas prcticas

1. Establecer la lnea base para medir el

desempeo (valor planificado) (LBD)

Descomponer el alcance (WBS)

Asignar responsabilidades de gestin
Desarrollar un cronograma y el VP para cada tarea
Seleccionar las tcnicas de medida para todas las
tareas
Mantener la integridad de la lnea base para medir
el desempeo. Solo se podra cambiar ante:

cambios en el alcance
desempeo pasado pobre y la LBD ya no sirve para medir

194

Tcnicas
1.50/50
2. Hitos con peso
3. 25/75
4. 0/100
5. Hitos con peso
6. 50/50

195

Enfoque del Valor Ganado

Guas prcticas

2. Medir y analizar el desempeo contra la LBD

Registrar el uso de los recursos

Medir el avance
Acreditar el valor ganado de acuerdo a las tcnicas
elegidas
Analizar y predecir desempeo de costos y
cronograma
Informar problemas de desempeo y/o tomar acciones
pertinentes

196

Fecha de hoy: 30 de abril

197

Ejercicio
Calcular SV, TV, SPI, FT
Calcular VC, CPI, CFT

198

Ejemplo Valor Ganado

18

Relevamiento
10

Diseo
80% - 100%
20

Desarrollo
70% - 80%
40

Verificacin, Instalacin y Capacitacin

0% - 15%

Valor planificado = 18 + 10 + 16 + 6 = $50

Valor Ganado = 18 + 8 + 14 + 0 = $40
Costo Actual = $45

199

Ejemplo Valor Ganado (2)

100
90
80

Recursos

70
60

VP
VG
CA

50
40
30
20
10
0
1

Tiempo

200

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/dlar gastado hasta el momento.

201