Introducción a la Ingeniería de Software...requerido para desarrollar un sistema de forma precisa:...

Estimaciones

Bibliografía:•SW Estimation. Demystifying the Black Art. Steve McConnell.

2

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.

3

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.

4

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!

5

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

6

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

7

¿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.

El ProyectoEstimación = 20 meses/persona

Resultado = 20 meses/persona

Personal no pronto cuando

planificado

Nuevos requisitos

Personal reasignado para dar soporte a proyecto anterior

Personal menos experiente que lo

planificado

Nuevos requisitos

Funcionalidad inestable eliminada

Personal asignado a

presentaciónRequisitos eliminados

8

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%)

9

Influencias sobre la Estimación

• Tamaño• Tipo de SW• Factores del personal• Lenguaje de programación

10

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.

11

Tipo de SW

• Productividad varía según tipo de proyecto:

Tipo de SW 10.000 LOCs 100.000 LOCs 250.000 LOCsAviones 200 50 40Sistemas de Información 3.000 600 500Comando y control 500 100 80Sistemas embebidos 300 70 60Sistemas web 1.500 300 200Intranets 4.000 800 600Microcódigo 200 40 30Control de procesos 1.000 300 200Tiempo real 200 50 40Sistemas científicos 1.000 300 200Paquetes 1.000 200 200Drivers 600 100 90Telecomunicaciones 600 100 90

LOC / Mes persona (promedio)

12

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.

13

Lenguaje de Programación

LenguajeCantidad de sentencias

comparado con C

Assembler 2 a 1C 1 a 1Cobol 1 a 1,5Fortran 1 a 2C# 1 a 2,5C++ 1 a 2,5Java 1 a 2,5Visual Basic 1 a 4,5Perl 1 a 6Smalltalk 1 a 6SQL 1 a 10

• 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.

• Algunos lenguajes generan más

funcionalidad por LOC.

• Trabajar en lenguajes interpretados tiende a ser (hasta 2 veces) más productivo que en lenguajes compilados.

14

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" .

Métricas de Tamaño

Agenda:IntroducciónMétricas basadas en salidas:

•LOCsMétricas basadas en funcionalidad:

•Puntos de Función•Puntos de Característica•Puntos Objeto

16


• 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.

17


• 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

18

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?

19

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

20

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

Unidad de medida depende del lenguaje

¡Paradoja! ¿C más productivo que C++?

21

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.

22

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.

Agenda:Visión generalIFPUG Frontera de la aplicaciónTransaccionesDatos

Puntos de Función

24

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 (EI- External Input) Nro. Salidas Externas (EO- External Output) Nro. Consultas Exts. (EQ- External inQuiry)

Datos Nro.Archivos Int. Lógicos (ILF- InternalLogical File) Nro.Arch. Interfaz Externa (EIF-External Interface File)

25

Modelo para contar PF

EI

EQ

EO

Archivos Lógicos Internos (ILF)

Archivos de InterfazExternos (EIF)

Contiene datos derivados y/o

afecta comportamiento

14 “Características Generales de la

Aplicación

PF = PFSA x Factor de Ajuste

No mantenidos por la aplicación

Frontera de la aplicación

transaccionesdatos

26

Puntos de Función

Primera versión Segunda versión

B, M, A

Nro. Entradas x 4 (3,4,6) Nro. Salidas x 5 (4,5,7) Nro. Consultas x 4 (3,4,6)

Nro. Archivos x 10 (7,10,15) Nro. Interfaces externas x 7 (5,7,10)

27

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

28

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.

29

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

30

Frontera de la Aplicación (II)

Fronteras definidas a partir de la visión del

negocio

RR

.HH

.

Contabilidad

Ventas

Usuario 1

¿cómo impactaría en la cuenta total de PF considerar esta otra

frontera?No cumple con la aditividad: si uno componentes, la cuenta da menos.

31

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.

Transacciones

33


EI

EQ

EO






Aplicación




transaccionesdatos

34

Contar TransaccionesPasos:• 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

35

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.

36

Proceso ElementalDefinición:• Es la mínima unidad de actividad que tiene un significado para el

usuario debe ser autocontenido, no requiere de otra actividad para que

adquiera significado debe dejar al sistema en un estado consistente

Ejemplo:Si el usuario desea agregar un empleado, puede requerir incorporar:

nombre fecha de ingreso CI sueldo estado civil fecha de nacimiento

Este proceso elemental se completa al ingresar todos los

datos requeridos

37

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

38

Proceso en TransaccionesTipo de Proceso EI EO EQ

Acepta datos o inf. de control que entra SI p pPresenta información fuera de la frontera p SI SI

Altera el comportamiento del sistema p* p* NOAl menos se actualiza un ILF p* p* NO

Fórmulas matemáticas y cálculos p p* NOCrea datos derivados p p* NO

Al menos un ILF o EIF referenciado p p SIRecupera datos o información de control p SI SI

Validaciones p p pSe convierten valores equivalentes p p p

Selección y filtro de datos p p pSe evalúan condiciones p p p

Reordena un conjunto de datos p p p

p=posiblep*=uno por lo menos debe estar presente

39

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

40

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

41

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

42

Complejidad de EI - Número de DET

Ejemplo 1 - agregar un empleado con los datos: nombre fecha de ingreso CI fecha de nacimiento

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)

4 DET

8 DET

43

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)

• * ( 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

6 DET

44

Complejidad de EQ/EO – Nro. de DET

• Ejemplo 1 – se listan los datos (nombre, dirección, teléfono)

• Ejemplo 2 – gráfica de tortas con la cantidad de empleados en determinado rango de edad, con descripción para cada rango

3 DET

2 DET:

valor y rótulo

45

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 imprimirloEsta 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 horaEjemplos:

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

46

Caracterización de la complejidad

Para EI 1 a 4 DET 5 a 15 DET 16 o más 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 20 o más DET

0 a 1 FTR Baja Baja Media

2 a 3 FTRs Baja Media Alta

4 o más FTRs Media Alta Alta

47

Contribución de Transacciones

\ ComplejidadTipo de Transacción

Baja Media Alta

External Input (EI) 3 4 6

External Output (EO) 4 5 7

External inQuiry (EQ) 3 4 6

48

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 3Listado Clientes EQ Baja 3

Cantidad Clientes EO Baja 4

Total de Contribución de Transacciones: 10

49

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

50

Consulta de EmpleadosSistema de RRHH

Empleado 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

51

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

52

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

53

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)

54

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?

55

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

57


EI

EQ

EO






Aplicación




transaccionesdatos

58

Contar DatosPasos:

• 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

59

Tipos de ArchivosInternal 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.

60

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

61

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

62

Caracterización de la complejidad

AltaAltaMedia6 o más RET

AltaMediaBaja2 a 5 RET

MediaBajaBaja1 RET

51 o más DET 20 a 50 DET1 a 19 DETPara ILF/EIF

1075Ext.Interface File(EIF)

15107Int. Logical File (ILF)

AltaMediaBaja \ Complejidad

Tipo de Archivo

Contribución de datos

63

Contribución de DatosEjemplo - 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

14Total de Contribución de Datos :

ILFILF

Tipo

7BajaTarea7BajaEmpleado

CuentaNivel ComplejidadArchivo

64

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

65

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.

66

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

67

Contribución de Datos – Ejemplo 1

Para la aplicación de RRHH el Usuario desea:

• Poder restringir el acceso a cada pantalla a ciertas personas

• Poder cambiar estas restricciones

• Emitir un listado con todos los agregados o cambios en las restricciones de acceso que incluya los datos:

• Id de usuario que hizo el cambio

• Los datos de seguridad (id_usuario, id_pantalla, tipo_acceso) anteriores y posteriores

• Fecha y hora del cambio

68


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

69


• 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

70


• 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 1 ILF, 1 RET, 6 DET - en Postal 1 ILF, 1 RET, 3 DET

71

Ejercicio de PF

Calcular la contribución de los datos y de las transacciones del ejercicio planteado.

72

Puntos de Característica

• PF diseñados originalmente para sistemas de información.• Variante para sistemas con complejidad algorítmica alta

(aplicaciones de tipo científico, de tiempo real y de sistemas): Puntos de característica

• Se considera el número de algoritmos que resuelven un problema complejo determinado.

• Se utiliza como multiplicador un único peso.

Cuenta Peso Nro. Entradas x 4 = Nro. Salidas x 5 = Nro. Consultas x 4 = Nro. Archivos x 10 = Nro. Interfaces externas x 7 = Nro. de algoritmos x 3 =

73

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.

Técnicas de Estimación

75

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.

76

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.

77

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

78

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.

79

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)

80

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

81

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

82

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.

83

Estimaciones basadas en Proxies - Técnicas

• Fuzzy Logic• Componentes Estándar• Puntos de historia• T-Shirt Sizing

84

Fuzzy Logic

• Clasificar características en MP, P, M, G, MG.• Datos históricos: LOCs promedio por

característica.• Calcular

• Se aplica la Ley de los Números Grandes.• Se puede aplicar también a estimación de

esfuerzo.

Tamaño característica LOCs promedio por característica Cant. características LOCs estimadasMuy pequeño 127 22 2794Pequeño 253 15 3795Mediano 500 10 5000Grande 1014 30 30420Muy grande 1998 27 53946Total 104 95955

85

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.

• Para usar en etapas tempranas.

Comp. estándar LOCs por componente MínMás probable Máx Nro. estimado LOCs estimadas

Pág. web dinámicas 487 11 25 50 26,8 13052Pág. web estáticas 58 20 35 40 33,3 1931Tablas BD 2437 12 15 20 15,3 37286Reportes 288 8 12 20 12,7 3658Reglas de negocio 8327 1 1 8327TOTAL 64.254

86

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

87

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

88

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

89

Estimación por Analogía• Matriz de costos de Wolverton (TRW-1974)

Dificultad

Tipo OE OM OD NE NM ND

Control 21 27 30 33 40 49

I/O 17 24 27 28 35 43

Pre/post proces. 16 23 26 28 34 42

Algoritmo 15 20 22 25 30 35

Manejo de Datos 24 31 35 37 46 57

Tiempo crítico 75 75 75 75 75 75

Se estima el tamaño de cada módulo en LOCs

O=Old; N=New

E=Easy; M=Medium; D=Difficult

90

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

91

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

92

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.

93

COCOMO II3 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 exponentex: 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)

94

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

95

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 plataformaRelativos a los req. de HW y SW del sistema TIME -> Carga de Procesadores STOR -> Restricciones de Memoria PVOL -> Volatilidad de la Plataforma

96

COCOMO II –Multiplicadores de Esfuerzo (Post-Arq.)

• Atributos del personalRelativos 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 proyectoRelativos a las características intrínsecas de cada proyecto específico TOOL -> Herramientas SITE -> Dispersión/Comunicaciones SCED -> Compresión/Estiramiento de Plazo

97

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

98

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.

Gestión de los Recursos Humanos

100

Gestión de RR.HH.

• ¿Def.?• Gestión pobre de RRHH – causa de fracaso del

proyecto.• Factores críticos:

Consistencia Respeto Inclusión Honestidad

101

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.

102

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

103

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

104

Estilos de TrabajoINTUITIVO

RACIONAL

INTR

OV

ER

TID

OEX

TR

OV

ER

TID

O

INTUITIVOINTROVERTIDO:Pregunta al restoReconoce sentimientos

INTUITIVOEXTROVERTIDO:Informa al restoReconoce sentimientos

RACIONALINTROVERTIDO:Pregunta al restoDecide lógicamente

RACIONALEXTROVERTIDO:Informa al restoDecide lógicamente

¾ de técnicos son introvertidos (vs. 1/3 de la población)

105

MotivaciónMaslow ’54

Necesidades fisiológicas

Necesidades de seguridad

Necesidades sociales

Necesidades de estima

Necesidad de realización

106

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.

107

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

108

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.

109

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.

110

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

111

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)

112

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

113

Trabajo en grupoDistribución del tiempo

Actividades no productivas20%

Trabajo individual30% Interacción con

otras personas50%

114

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

115

ComunicacionesDos personas 1 línea de comunicación

Tres personas

Cuatro personas

Cinco personas

3 líneas de comunicación



:n personas

:n(n-1)/2 líneas de comunicación

116

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.

117

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

118

“Chief Programmer Team”

Chief programmer

Assistant chief programmer

Test teamAdministrationLibrarianSeniorprogrammers

Juniorprogrammers

119

• 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.

Resto de componentes del equipo de desarrollo

Jefe de proyecto

“Chief Programmer Team”

120

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.

121

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.

122

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.

Enlaces de comunicación

Jefes de grupo

Jefe de proyecto

Resto de componentes del equipo de desarrollo

123

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

124

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

125

Ciclo de Vida de un Equipo

• Integración• Tormenta• Aceptación• Etapa productiva• Desintegración

126

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

127

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

128

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

129

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

130

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

Evaluación de Factibilidad

132

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?

133

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?

134

Estudio de Factibilidad (III)

• Análisis Costo/Beneficio

• Informe de Factibilidad: Documento donde se recomienda si seguir con el sistema, proponiendo cambiar el alcance, presupuesto, agenda, etc.

Técnicos Clientes

135

Eval. de Factibilidad - Cuándo

• Frecuentemente el Estudio de Factibilidad es previo a un proyecto (ante-proyecto, pre-factibilidad)

• Puede ser la etapa inicial• A lo largo del proyecto, en puntos de control

preestablecidos, se vuelve a formular la pregunta:

¿Vale la pena seguir?

136

Estudio de Factibilidad – EjemploProyecto “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

137

Evaluación Financiera de Proyectos

Tasa de dto. 3,15% ANUALInversión Inicial $ 50.000

PROYECTO 1Semestres Ingresos Egresos Flujo Caja Reintegro

0 (50.000) (50.000) 1 20.000 6.000 14.000 (36.000) 2 22.000 7.500 14.500 (21.500) 3 25.000 6.000 19.000 (2.500) 4 25.000 6.000 19.000 16.500 5 25.000 6.000 19.000

Tasa Dto. Semestral 1,56%Actualización de FF $ 81.417,89VAN $ 31.417,89TIR 19,60%Actualización Ingresos $ 111.515,30Actualización Egresos $ 30.097,41Indice Rentabilidad 370,51%

TIR Anualizada 43,04%


0 (50.000) (50.000) 1 15.000 3.000 12.000 (38.000) 2 16.000 3.200 12.800 (25.200) 3 18.000 3.500 14.500 (10.700) 4 18.000 3.800 14.200 3.500 5 18.000 4.000 14.000




0 (50.000) (50.000) 1 17.000 2.700 14.300 (35.700) 2 17.000 2.700 14.300 (21.400) 3 17.000 2.700 14.300 (7.100) 4 17.000 2.700 14.300 7.200 5 17.000 2.700 14.300



Perfil del VAN

$ 0

$ 5.000

$ 10.000

$ 15.000

$ 20.000

$ 25.000

$ 30.000

$ 35.000

0,00% 5,00% 10,00% 15,00% 20,00% 25,00%

Tasa

VA

N

Proyecto 1

Proyecto 2

Proyecto 3

Gestión de Riesgos

139

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.

140

Proceso de Gestión de Riesgos

1. Planificación de la Gestión de Riesgos2. 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.

141

Proceso de Gestión de Riesgos

Identificación AnálisisSeguimiento

y ControlPlanificación

de la Respuesta

Lista de riesgos

Lista de riesgos

priorizados

Planes de reducción y contingencia

Evaluación de los riesgo

Planificación de la Gestión de Riesgos

Plan de Gestión de

riesgos

Registro de Riesgos

142

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).

143

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)

144

Categorías de Riesgos (PMBoK)

Requisitos Subcontratistas y proveedores

RegulatorioTecnología

MercadoComplejidad e interfaces

ClienteRendimiento y fiabilidad

CalidadCondiciones climáticas

Dependencias del proyecto

Recursos

Financiación

Priorización

Planificación

Estimación

Control

Comunicación

Técnico Externode la

organizaciónDirección de

proyectos

145

Clasificación de Riesgos (Sommerville)

Riesgos: del proyecto del producto del negocio

Problemas de:

•presupuesto•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: •el costo y •la duración del proyecto.

•la calidad del sw resultante.

•al equipo de desarrollo y a •la realización del proyecto en sí.

146

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 yproducto

El número o el impacto de los cambios en los requisitos es mayor al esperado.

Retrasos en la especificación Proyecto yproducto

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 noperformantes

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.

147

Tipos más comunes de riesgos (Sommerville)

Tipo de riesgo Ejemplos

Técnicos(tecnologías utilizadas (sw y hw))

BD no puede procesar la # de transacciones/seg esperada.Componentes de SW a reusar defectuosos.Tecnologías desconocidas.

De personal (equipo de desarrollo)

No se consigue personal con las habilidades requeridas.Personal clave no está disponible.No se puede proveer la capacitación necesaria.

Organizacionales(del ambiente organizacional de desarrollo y del cliente)

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.

148

“Top 10 Risk Items” (Boehm) 1989

1. Limitaciones de Personal2. Calendario y Presupuesto3. Funciones equivocadas4. Interfaz de usuario no

adecuada5. “Gold plating” (preciosismo)6. Cambios en Requisitos7. Suministros externos8. Tareas externas9. Desempeño de Tiempo Real10. Forzar ciencia de

computación

19951. 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

149

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

150

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

151

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ónS: Decisión tomada (V/F)

E: Prob. de escenarios, Recompensa si ocurreS: Valor monet. esp.(EMV)

Beneficios - costos

¿Construir o mejorar?

Mejorar planta existente

Construir nueva planta

Poca demanda

Fuerte demanda

Poca demanda

Fuerte demanda

-$120

-$50

F

V

65%

35%

65%

35%

$200

$90

$120

$60

$80M

-$30M

$70M

$10M

EMV del Nodo de Posibilidad = $ 42,5 M

EMV del Nodo de Posibilidad = $ 49,0 M

EMV de la decisión = $ 49 M

152

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

153

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.

154

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ón-

severidad después de reducción) / (costo de reducción) Si nivel de reducción<1 no valdrá la pena

155

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.

156

Actividades en Gestión de Riesgos

Gestión de Riesgos

Evaluar Riesgos

Control de Riesgos

Identificar Riesgos

Analizar Riesgos

Priorizar Riesgos

Reducir Riesgos

Planear Solución de Riesgos

Lista de ComprobaciónDescomposiciónAnálisis de SupuestosAnálisis de Procs. de DecisiónDinámica de Sistemas

Modelos de DesempeñoModelos de CostoAnálisis de RedesAnálisis de DecisionesFactores de Riesgo en Calidad

Severidad de RiesgosReducción Compuesta

Obtener InformaciónEvitar un RiesgoTransferirloEvaluar Nivel de ReducciónDesarrollar el Proceso

Planear elemento de RiesgoPlan integrado

Reducir RiesgoMonitoreo e InformesReevaluar Riesgos

Resolver Riesgos

No se pueden atender todos

Una vez ocurrido

Impacto y/o Probabilidad Reducir

Incertidumbre

Qué hacer si ocurre

Periódicamente, o en hitos del proyecto

Según Rook, 1993

157

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

Gestión de la Calidad

159

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.

160



Planear la Calidad

Asegurar la Calidad

Controlar la Calidad

• Responsabilidades • Estándares

• Procedimientos

• Puntos de Control

• Métricas de Q• Checklists

• Revisiones

• Auditorías

• Verificar

• Validar

WBS

161

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:

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.

Pe. Seguridad (safety), Seguridad (security), Confiabilidad, Robustez, Comprensibilidad, Verificabilidad, Modularidad, Complejidad, Eficiencia, Portabilidad, Reusabilidad, Usabilidad, Facilidad de Aprendizaje

162


• 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.

Gestión de la Configuración

164

Gestión de la Configuración

WBS

• 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

Gestión de las Comunicaciones

166

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

167

Comunicación entre los Involucrados

WBS

• 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

Plan de Gestión del Proyecto

169

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

170

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

171

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

Registro y Control de Avance

Bibliografía específica:•Practice Standard for Earned Value Management (PMI – 2005)

173

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

174

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

175

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?

176

Técnicas de Medición

• Selección de la técnica en base a: Tangiblidad del producto Duración del esfuerzo

177

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

178

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%

179

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.

180

Registro y Control de AvanceTécnicas

• Gantt

• Diagrama de Evolución de Gastos

• Enfoque del Valor Ganado

181

Registro y Control de Avance -Técnicas - Gantt

Actividad

A y B están atrasadas, C adelantada, ¿y el proyecto?

¿Está costando más o menos de lo previsto?

A

B

C

D

182

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.

183

Registro y Control de Avance – Técnicas - Diagrama de Evolución de Gastos

$

t

Diagrama de

Evolución

de Gastos

Acumulados

Real

Planificado

Se lleva gastado más de lo previsto a la fecha, pero

¿cuál fue el avance logrado? ¿se va a gastar más o menos de lo previsto?

184

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.

185

Enfoque de Valor Ganado

$

t

Valor Ganado (Valor presupuestado del avance logrado)

Planificado

Fin Planificado(FP)

Costo Planificado Final (CPF)

t0 Fin de acuerdo a tendencia (FT)

Costo Real en t0

Costo Final de acuerdo

a tendencia(CT)

t1

Valor Ganado en t0

es el previsto para t10

186

Enfoque del Valor GanadoMedidas 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

187

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 presupuesto? ¿Cuánto?

-Varianza del Costo (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

188

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.

189

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

190

Técnicas1.50/502. Hitos con peso3. 25/754. 0/1005. Hitos con peso6. 50/50

191

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

192

Fecha de hoy: 30 de abril

193

Ejercicio

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

194

Ejemplo Valor Ganado

• Valor planificado = 18 + 10 + 16 + 6 = $50• Valor Ganado = 18 + 8 + 14 + 0 = $40• Costo Actual = $45

Relevamiento

Diseño

Desarrollo

Verificación, Instalación y Capacitación40

0% - 15%

18

10

70% - 80%

2080% - 100%

195

Ejemplo Valor Ganado (2)

0

10

20

30

40

50

60

70

80

90

100

1 2 3

Tiempo

Recursos VP

VGCA

196

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.

Introducción a la Ingeniería de Software...requerido para desarrollar un sistema de forma precisa:...

Documents

Transcript of Introducción a la Ingeniería de Software...requerido para desarrollar un sistema de forma precisa:...