You are on page 1of 237

Gestión de Proyectos

Bibliografía general: • SW Engineering Theory and Practice. Phleeger. • SW Engineering. Ian Sommerville.

Damaris Alvarado Franco

Agenda:
• • • • • • • • • • • Gestión de Proyectos Técnicas y Herramientas de Planificación Estimaciones de Tamaño, Esfuerzo, Costo y Duración Métricas de Tamaño Recursos Humanos y Organización Evaluación de Factibilidad Gestión de Riesgos Gestión de la Calidad Gestión de la Configuración Comunicaciones entre los involucrados Registro y Control de Avance

2

Gestión de Proyectos
Bibliografía específica: •A Guide to the Project Management Body of Knowledge (PMBok 2004 – Tercera Edición) del Project Management Institute (PMI)

Qué es un Proyecto
Operaciones y Proyectos
• Características Comunes:
 llevados a cabo por personas  sometidos a restricciones (recursos)  se planifican, ejecutan, controlan

• Diferencias:
 Operaciones: Continuos y Repetitivos  Proyectos: Temporales y Únicos

4

Proyecto
Un proyecto es un emprendimiento temporal para crear un producto o servicio único.
• Temporal:
 Tiene inicio y fin  Termina cuando:
• se alcanzan los objetivos • o es claro que no se van a alcanzar • o la necesidad ya no existe y el proyecto es cancelado.

 La oportunidad o ventana de mercado es temporal  El equipo rara vez sobrevive al proyecto. Pe. campaña política  El resultado permanece. Pe. monumento

5

Proyecto
• Singularidad - Producto o Servicio Único:
 Es diferente en alguna forma distintiva de todos los productos/servicios similares.  Alcance bien definido / Elaboración progresiva.

6

Proyecto
• Forma de organizar actividades que no pueden ser tratadas dentro de los límites operativos normales de la organización. • Resultado de:
     demanda de mercado. Pe. central térmica necesidad de la organización solicitud de un cliente avance tecnológico requisito legal. Pe. IRPF

7

Emprendimientos Relacionados
Programa
• Conjunto de proyectos manejados en forma coordinada para obtener beneficios que no se obtendrían de manejarlos individualmente. • A menudo incluyen elementos de Operación Continua • Ejemplos: Programa de obtención de fondos Publicación de un periódico

Subproyecto
• Parte de un proyecto • A menudo contratada a un proveedor • Pe. La instalación eléctrica en un proyecto de construcción.

8

Gestión de Proyectos
• Aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto, para satisfacer los requisitos (las necesidades y expectativas) de un proyecto. • Disciplina en sí misma • Incluye:
    Identificar requisitos Establecer objetivos claros y factibles Equilibrar demandas de Q, alcance, t y costos Considerar expectativas de stakeholders
9

Stakeholders
(accionistas o interesados)
• Personas u organizaciones que:
 están activamente involucrados en el proyecto  o sus intereses pueden ser afectados positiva o negativamente por la ejecución o el éxito del proyecto.

• Tiene diferentes intereses que pueden estar en conflicto. • Ejemplos:
 crisis económica mundial  papeleras
10

Alcance
• Alcance del producto (final):
 sus características  Se mide contra requerimientos.

• Alcance del proyecto:
 trabajos incluidos (y no)  Se mide contra el plan.

11

Alcance y Expectativas
Necesidades

Expectativas
Balancear

Calidad
Alcance

Restricciones Necesidades Expectativas Proceso
12

Relación con otras disciplinas
Administración General Comprende planificar, organizar, asignar personal, ejecutar y controlar las operaciones de una empresa de operación continua Áreas de Aplicación •Categorías de proyectos donde hay prácticas generalmente aceptadas que no aplican a todo tipo de proyectos. •Definidas por: Gestión de
 Elementos Técnicos (Pe. desarrollo de SW)  Elementos Administrativos (Pe. licitaciones públicas)  Ramas de la Industria (Pe. automotriz)

Proyectos

Administración Áreas de General Aplicación
13

Áreas de experiencia
• Fundamentos de Dirección de Proyectos • Conocimiento del área de aplicación • Comprensión del entorno del proyecto:
• cultural y social • internacional y político • físico

• Habilidades de dirección general • Habilidades interpersonales

14

Habilidades interpersonales
• • • • • • Comunicación efectiva Influencia en la organización Liderazgo Motivación Negociación y gestión de conflictos Resolución de problemas

15

Aspectos clave
• La naturaleza intangible del SW causa problemas de gestión. • Las principales actividades de los gestores se centran en:
 la planificación  la estimación  control y seguimiento

16

Planificación
Bibliografía específica: •PMI Practice Standard for WBSs.

¿Es importante planificar?

Técnicas y Herramientas de Planificación
Técnica WBS CPM PERT Gantt Perfil de uso de Recursos Evolución de gastos Valor Ganado

Herramienta Esquema numerado Word Project (y otros) “ “ “ Planilla Electrónica Project, Planilla Electrónica
18

– EDT (estructura de desglose de trabajo)
• Es una descomposición jerárquica, orientada al producto entregable, del trabajo para lograr los objetivos del proyecto y crear entregables requeridos. • La descomposición es la subdivisión de los productos entregables en componentes más pequeños y fáciles de manejar. • El proceso se repite mientras resulte necesario (y posible) hasta llegar al nivel de paquete de trabajo (=nivel más bajo, se puede estimar el costo y el cronograma de forma fiable). • Organiza y define el alcance TOTAL del proyecto (del producto y del proyecto).
19

WBS Work Breakdown Structure

WBS
Ejemplo: Casa
Casa Diseño Planos Memoria Descript. Terreno Delimitar Acondicionar Materiales Adquirir Construcción
Cimientos Muros Techos

Notas: 1. No se representan relaciones de precedencia ni posible concurrencia. 2. Es usual presentarlo (en lo posible) en el orden de ejecución, de izquierda a derecha

Sanitaria
Electricidad Terminaciones
20

WBS Work Breakdown Structure
– EDT (estructura de desglose de trabajo)
• Puede que no sea posible – planificación gradual. • • • • Sólo representa relaciones composición-descomposición No representa relaciones de precedencia Las ramas no tienen por qué ser simétricas Cada elemento debe tener una persona responsable de su realización

• Modelo de proceso implícito

21

WBS Contra-Ejemplo: Casa
Casa Dormitorios Principal Niños Huéspedes Living Comedor Cocina Baño

Notas: 1. En este caso hay una descomposición jerárquica del producto (no de las actividades), sin tener en cuenta los productos intermedios. 2. Considerado como WBS, ¿qué opina de la técnica constructiva implícita?
22

WBS
Descomposición
• Identificar productos entregables y trabajo relacionado:
 Analizar alcance y productos entregables de la gestión del proyecto y del producto.

• Estructurar el WBS – Opciones:
 entregables  subproyectos  fases del ciclo de vida

• Descomponer en componentes detallados, que representan productos, servicios o resultados verificables. • Asignar códigos de identificación a componentes • Verificar que el grado de descomposición es necesario y suficiente.
23

WBS
Ejercicio (Ex. feb 2007)
Una empresa distribuidora mayorista desea implantar el paquete de software XYZ para soportar la gestión de inventarios de mercadería, pedidos a proveedores y entregas a clientes. Esta empresa cuenta actualmente con un sistema que funciona con tecnología obsoleta que soporta parcialmente estas funciones. Sus oficinas y depósito están ubicados en un mismo edificio. La empresa no cuenta con equipos informáticos con capacidad disponible como para implantar el paquete.El paquete XYZ tiene previsto un conjunto grande de parámetros para adaptarlo a las necesidades específicas de cada organización. Sin embargo, existe cierto riesgo de que resulte necesario incorporar modificaciones al software. Construya un WBS para el proyecto, considerando que el resultado esperado es contar con el paquete XYZ implantado y funcionando en la empresa, de forma de satisfacer sus necesidades.
24

WBS
• Modelo simplificador:
 Actividades no aparecen en el tiempo  No hay relaciones de precedencia

• Ventaja:
 Permite revisar que no olvide nada  Permite gestionar el alcance del proyecto: actividades que no están no son responsabilidad del proyecto

25

Actividad e Hito
• Actividad es una parte de un proyecto que se lleva a cabo durante un período de tiempo. • Un Hito es un punto en el tiempo que marca el inicio o el fin de una actividad. • Describir cada actividad
 precedentes  duración  producto

26

Grafo de Actividades (CPM)
Critical Path Method • Modelo que introduce tiempo y precedencias. • Permite calcular la duración total del proyecto. • Se consideran:
 las hojas del WBS (actividades)  las relaciones de precedencia entre ellas  no se admiten circuitos de precedencia

27

Grafo de actividades
• Hoy en día lo usual es representar:
 actividades por bloques (compatible con Diag. Gantt)  las relaciones de precedencia por flechas (intuitivo)  Hay un nodo Inicio y otro Fin (no se precisan elementos ficticios)

• Modelo simplificador:
 duraciones fijas  No permite indicar comienzo de una actividad en un punto de la ejecución de otra. Solución: • Dividir actividades • Pe. Con Project poner que no comience hasta que actividad precedente esté cumplida en un 90%
28

Grafo de Actividades
i.Electricidad

b.Memoria Descript.
a.Planos d.Adquirir (Materiales)

j.Sanitaria h.Techos g.Muros k.Terminaciones

inicio

fin

c.Delimitar (Terreno)

e.Cimientos
f.Acondicionar (Terreno)
29

Grafo de Actividades –
Conceptos Básicos
• Comienzo Temprano (lo antes que puede comenzar respetando las precedencias y las duraciones) • Fin Temprano (la fecha de fin si la actividad comienza lo antes posible y dura lo previsto) • Comienzo Tardío (lo más tarde que puede comenzar la actividad sin afectar la duración del proyecto) • Fin Tardío (lo más tarde que puede terminar la actividad sin afectar la duración del proyecto) • Holgura Total (cuanto se puede atrasar el comienzo de una actividad sin afectar la fecha de fin del proyecto • Camino Crítico: integrado por actividades que si se atrasan, atrasan el proyecto (Holgura Total=0)
30

Grafo de Actividades con Duraciones
i (1)

b (4)
j (2)

0 inicio
a (3) c (5) d (5) g (5) Colores: k (10) f (8) e (7)
31

h (7)

fin

•Temprano •Tardío

Grafo de Actividades con Duraciones
35 3
b (4)

36 45 37
j (2)

i (1)

7 11

44 35 43

7 0 inicio 0 3
a (3)

45

45

0 3 3 8
d (5)

7
11 8 16

12
c (5)

28 35
h (7)

fin

16

28 35 23 28
g (5)

3
Colores:
•Temprano •Tardío

35 35

45 45
32

8 8

23 28
16 23
e (7)

k (10)

f (8)

16

16 23

¿Cuál es el Camino Crítico?

Camino Crítico
• ¿Interés de determinar el Camino Crítico? • Atrasos se deben generalmente a:
 No se terminaron precedentes  No están los recursos. Pe. huelga

33

PERT
Program Evaluation & Review Technique
• • • Como CPM pero la duraciones variables aleatorias de distribución β y se trabaja con el valor esperado. Para la duración de cada actividad hace tres estimaciones: “a” (optimista), “m” (más probable) y “b”(pesimista) Le atribuye distribución Beta (no siempre simétrica) y aproxima:
   el valor esperado por E=(a+4m+b)/6,  por (b-a)/6 y 2 = [(b-a)/6] 2

Supone:
   que las duraciones son variables aleatorias independientes que el camino crítico tiene duración mayor a cualquier otro nro. de actividades en el camino crítico suficientemente gde. como para aplicar el Teorema del Límite (la suma tiene distribución normal) por lo que: E proyecto=  E activ.camino crítico

2camino crítico= 2activ.camino crítico
34

PERT
Principales limitaciones
• El número de actividades que forman el camino crítico debe ser bastante elevado.

• Las distintas variables aleatorias deben seguir la misma distribución de probabilidad
• Las variables aleatorias deben ser independientes, pero ¿duraciones son v.a. independientes?
En SW no. Si el diseño llevó el doble de lo previsto, es razonable que la implementación también lleve el doble.

• ¿Y los otros caminos?
No se tiene en cuenta que, debido a la aleatoriedad, otras actividades que no forman parte del camino crítico podrían tener una duración mayor que la esperada y pasar a formar parte del camino crítico.

PERT muy usado en la construcción, no tanto en SW.
35

Diagrama de Gantt
HOY ACTIVIDAD
ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC

WBS 1.0 PLANEAR SISTEMA
1.1 Revisar especificación
Especificación aprobada Presupuesto aprobado Calendario aprobado Plan aprobado

1.2 Revisar presupuesto
1.3 Revisar calendario 1.4 Desarrollar plan

WBS 2.0 DISEÑAR SISTEMA
2.1 Diseño de alto nivel 2.2 Prototipar 2.3 Interfaz de usuario 2.4 Diseño detallado
Completada Duración Flotante Crítica Deslizamiento

Diseño aprobado

Diseño aprobado
Inicio Tarea Fin Ttarea

36

Perfil de Uso de Recursos
• Un diagrama de Gantt tiene asociado (de forma explícita o no) una utilización de recursos (personas, maquinaria, etc.) para cumplir las actividades • El Perfil de Uso permite evaluar si el plan del diagrama es factible (no hay sobre-utilización) y si hay sobre-costos derivados de períodos de ocio • El plan final resulta de revisar y ajustar Gantt y Recursos Sub-utilización

Sobreutilización
Recurso Ocioso

Capacidad del Recurso

Nivel de uso

t
37

Ajuste del plan - Técnicas
1. Nivelado y ajuste en la utilización de los recursos disponibles. 2. Si duración excesiva  acortar duración total del proyecto:
• • Camino crítico – para identificar qué ajustar. Técnicas:
• • Compresión de actividades– agregando recursos Paralelizar – riesgo (plazo, costo, calidad)

38

Ajuste del Plan – Acortar Duración
 Acortar la duración incrementa el esfuerzo:
• Más recursos – costo:
– overhead de mayor coordinación y gestión – más líneas de comunicación – malosentendidos, errores, corrección

Paralelizar - en gral.:
– costo por retrabajo

La “Zona Imposible”: 8 personas en 10 meses - ¿80 personas en un mes? ¿1.600 personas en 1 día? No se puede comprimir más del 25%. Extender el cronograma reduce el esfuerzo solo si se reduce el equipo, sino ley de Parkinson. 39

Niveles e Instancias de Planificación
• Instancias:
 ¿Cuándo se lleva a cabo la planificación?  ¿Qué nivel de detalle se puede obtener antes de detallar los requerimientos?  ¿Tengo que esperar a tener requerimientos detallados para planificar?

• Niveles:
 Macro, en donde se detallan fases  Micro, con detalle de actividades y componentes
40

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

Estimación
• Para poder planificar se debe estimar:
 Esfuerzo  Costo  Duración
• Para proyectos pequeños, lo mejor es estimar esfuerzo, dividir entre la productividad y obtener el tamaño.

42

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.

43

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
oportunidad de mercado incertidumbre en las estimaciones condiciones contractuales volatilidad de los requisitos del sistema dificultades financieras

tales como:

• Muchas veces se presupuesta para ganar el cliente (Pricing to win). • Pero si las estimaciones se ajustan al presupuesto, ¡error!
44

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

45

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

46

¿Buena predicción?
• Proyectos afectados por:  eventos externos imprevistos.  cambio de asumpciones.
El proyecto entregado no es el mismo que fue estimado.

 control:
• Principio de Incertidumbre de Heisenberg: el observar algo lo cambia.
Personal no pronto cuando planificado Requisitos eliminados Personal asignado a presentación Funcionalidad inestable eliminada Resultado = 20 meses/persona

Estimación = 20 meses/persona

El Proyecto
Personal reasignado para dar soporte a proyecto anterior

Nuevos requisitos

Personal menos experiente que lo planificado

Nuevos requisitos

47

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

48

Incertidumbre de la Estimación – Cono de Incertidumbre
• Cuantas más decisiones tome, menor la incertidumbre.

49

Incertidumbre de la Estimación – Nube de Incertidumbre
• Si el proyecto no converge:
    proceso caótico requisitos inestables tecnología desconocida negocio desconocido

• Errores en la práctica de estimación:
 no incluir alcance del proyecto
50

Influencias sobre la Estimación
• • • • Tamaño Tipo de SW Factores del personal Lenguaje de programación

51

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.

52

Tipo de SW
• Productividad varía según tipo de proyecto:
LOC / Mes persona (promedio) Tipo de SW 10.000 LOCs 100.000 LOCs 250.000 LOCs Aviones 200 50 40 Sistemas de Información 3.000 600 500 Comando y control 500 100 80 Sistemas embebidos 300 70 60 Sistemas web 1.500 300 200 Intranets 4.000 800 600 Microcódigo 200 40 30 Control de procesos 1.000 300 200 Tiempo real 200 50 40 Sistemas científicos 1.000 300 200 Paquetes 1.000 200 200 Drivers 600 100 90 Telecomunicaciones 600 100 90
53

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.

54

Lenguaje de Programación
• La experiencia del equipo en el leng. y herramientas 40% de impacto en productividad gral. • Herramientas de soporte y ambiente de programación – hasta 50% de impacto. Cantidad de sentencias comparado con C • Algunos lenguajes generan más Lenguaje Assembler 2a1 C 1a1 funcionalidad por LOC. Cobol 1 a 1,5
Fortran C# C++ Java Visual Basic Perl Smalltalk SQL 1a2 1 a 2,5 1 a 2,5 1 a 2,5 1 a 4,5 1a6 1a6 1 a 10

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

55

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

56

Métricas de Tamaño
Agenda:
Introducción Métricas basadas en salidas:
•LOCs

Métricas basadas en funcionalidad:
•Puntos de Función •Puntos de Característica •Puntos Objeto

Métricas de Tamaño
• Tamaño permite:
 Estimar esfuerzo y duración  Medir calidad (defectos / unidad de construcción)  Medir productividad (tamaño / unidad de esfuerzo)

• Ejemplos:
 Casa: metros cuadrados de construcción  Carretera: kilómetros o kilómetros cuadrados  Software: ¿?
• LOCs • Puntos de Función • etc.

58

Métricas de Tamaño
• • • • • • • Features (características) Historias de usuario Puntos de historia Requisitos Casos de Uso Puntos de Función Páginas Web
• Componentes GUI (ventanas, cuadros de diálogo, reportes, etc.) • Tablas de la BD • Definiciones de interfaces • Clases • Funciones / subrutinas • Líneas de código

59

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?

60

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
61

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

• Proyecto A‟: 42.000 LOC C++

¡Paradoja! ¿C más productivo que C++?
 Unidad de medida depende del lenguaje
62

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.

63

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.

64

Puntos de Función
Agenda:
Visión general IFPUG Frontera de la aplicación Transacciones Datos

Puntos de Función - Visión General
• Albrecht (IBM-1979) Objetivo: traducir en un Número el tamaño de la funcionalidad que brinda un producto de software • Desde el Punto de vista del usuario • Suma ponderada de características del producto:
Transacciones
 Nro. Entradas Externas  Nro. Salidas Externas  Nro. Consultas Exts. (EI- External Input) (EO- External Output) (EQ- External inQuiry) (ILF- InternalLogical File) (EIF-External Interface File)

Datos
 Nro.Archivos Int. Lógicos  Nro.Arch. Interfaz Externa

66

Modelo para contar PF
EI Archivos Lógicos Internos (ILF)

Frontera de la aplicación No mantenidos por la aplicación

EQ EO
Contiene datos derivados y/o afecta comportamiento

Archivos de Interfaz Externos (EIF)

14 “Características Generales de la Aplicación

transacciones PF = PFSA

datos x Factor de Ajuste
67

Puntos de Función
Primera versión Segunda versión B, M, A

 Nro. Entradas  Nro. Salidas  Nro. Consultas

x x x

4 5 4 10 7

(3,4,6) (4,5,7) (3,4,6) (7,10,15) (5,7,10)

 Nro. Archivos x  Nro. Interfaces externas x

68

Puntos de Función
• Normalizado por IFPUG
 Ponderadores según complejidad de c/característica (A,M,B)  Criterios definidos para asignar complejidad a c/u  Puntos de Función sin ajustar+ 14 criterios de ajuste =(+-)35%  PFA=PFSA * (0,65+ 0,01*Σ ( ponderadores)) Pond=0 a 5

• Midiendo tamaño de productos en PF y en LOCs se armaron tablas de conversión: CapersJones
69

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
70

Desarrollos más recientes
• IFPUG – Manual versión 4.2 (2004) • MK II – FFP (en Reino Unido)
1998 – Estándar ISO 14143-1 – Funct. Size Measurement

• Mesma (en Holanda)
Criterio para ver si es un único archivo lógico o varios: Si elimino datos, ¿el resto también se elimina?

71

Estandarización por IFPUG
Factores de ajuste:
              comunicaciones de datos procesamiento distribuido consideraciones de performance configuración operacional altamente utilizada entrada de datos on-line eficiencia para el usuario final (diálogos interactivos) actualización on-line y respaldo y recuperación procesamiento interno complejo tasa de transacciones reusabilidad facilidad de instalación facilidad de operación uso en múltiples sitios facilitar el cambio
72

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

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
74

Frontera de la Aplicación (II)
Usuario 1
Contabilidad

RR.HH.

Ventas

Fronteras definidas a partir de la visión del negocio ¿cómo impactaría en la cuenta total de PF considerar esta otra frontera?
75

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

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.

76

Transacciones

Modelo para contar PF
EI Archivos Lógicos Internos (ILF)

Frontera de la aplicación No mantenidos por la aplicación

EQ EO
Contiene datos derivados y/o afecta comportamiento

Archivos de Interfaz Externos (EIF)

14 “Características Generales de la Aplicación

transacciones PF = PFSA

datos x Factor de Ajuste
78

Contar Transacciones
Pasos: • Identificar transacciones • Asignar a cada una un tipo (EI, EO, EQ) • Identificar la cantidad de DET y FTR • Asignar a cada una un valor de complejidad (Alta, Media, Baja) en función de la cantidad de DET y FTR Definiciones: • Data Element Type (DET):
 es un campo único (no repetitivo) reconocible por el usuario

• File Type Referenced (FTR):
 es un tipo de archivo al que se hace referencia en una transacción; tiene que ser un ILF o EIF
79

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

Proceso Elemental
Definición: • Es la mínima unidad de actividad que tiene un significado para el Usuario
 debe ser autocontenido, no requiere de otra actividad para que adquiera significado  debe dejar al sistema en un estado consistente

Ejemplo:
Si el usuario desea agregar un empleado, puede requerir incorporar:  nombre  fecha de ingreso Este proceso  CI elemental se completa  sueldo al ingresar todos los  estado civil  fecha de nacimiento datos requeridos

81

Tipos de Transacciones - Resumen
Función
Altera el comportamiento del sistema Mantiene uno o más ILF Presenta información al usuario Presenta datos derivados al usuario

EI EO EQ
IP IP O O O O IP IP NO NO IP NO

IP= Intención Primordial

O= Opcional

82

Proceso en Transacciones
Tipo de Proceso
Acepta datos o inf. de control que entra Presenta información fuera de la frontera Altera el comportamiento del sistema Al menos se actualiza un ILF Fórmulas matemáticas y cálculos Crea datos derivados Al menos un ILF o EIF referenciado Recupera datos o información de control Validaciones Se convierten valores equivalentes Selección y filtro de datos Se evalúan condiciones Reordena un conjunto de datos

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

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

83

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

84

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
85

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
86

Complejidad de EI - Número de DET
Ejemplo 1 - agregar un empleado con los datos:
    nombre fecha de ingreso CI fecha de nacimiento

4 DET

Ejemplo 2 - ingreso de datos de factura de proveedor:
    código proveedor (E) nombre proveedor (S) fecha factura (E) importe total (E)
• * ( código artículo • precio unitario • cantidad • importe) (E)

8 DET
87

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)

6 DET

• 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

88

Complejidad de EQ/EO – Nro. de DET
• Ejemplo 1 – se listan los datos (nombre,
dirección, teléfono)
3 DET

• Ejemplo 2 – gráfica de tortas con la cantidad de
empleados en determinado rango de edad, con descripción para cada rango
2 DET:
valor y rótulo
89

Complejidad de Tr – Nro. de DET
NO CONTAR: • Campos recuperados o derivados por el sistema y almacenados en un ILF por el proceso elemental, si no cruzaron la frontera de la aplicación Ejemplo: Al imprimir cheques, el registro en el archivo se marca para
no volver a imprimirlo Esta marca NO se cuenta como DET

• Literales Ejemplo: Los títulos (si son fijos) no se cuentan como DET • Variables generadas por el sistema relacionadas con el paginado o fecha y hora Ejemplos:
    nros. de página información de posicionamiento (filas 32 a 56 de 781) Comandos para paginar (anterior, siguiente, barra de posicionamiento) Fecha y hora

90

Caracterización de la complejidad
Para EI
0 a 1 FTR 2 FTRs 3 o más FTRs
1 a 4 DET 5 a 15 DET 16 o más DET

Baja Baja Media

Baja Media Alta

Media Alta Alta

Para EO/EQ
0 a 1 FTR 2 a 3 FTRs 4 o más FTRs

1 a 5 DET

6 a 19 DET

20 o más DET

Baja Baja Media

Baja Media Alta

Media Alta Alta

91

Contribución de Transacciones
\ Complejidad Tipo de Transacción
External Input (EI)

Baja

Media

Alta

3 4 3

4 5 4

6 7 6

External Output (EO) External inQuiry (EQ)

92

Contribución de Transacciones
Ejemplo -

• Alta cliente (#cliente, nombre, dirección)

Aplicación integrada por:

• Listado de clientes (#cliente, nombre, dirección) • Consulta de la cantidad de clientes existentes • un único ILF (Clientes)
Transacción
Alta Cliente Listado Clientes Cantidad Clientes
Tipo Nivel Complejidad

Cuenta

EI EQ EO

Baja Baja Baja

3 3 4 10
93

Total de Contribución de Transacciones:

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
94

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

Pérez
Martínez Fernández

Juan
Pedro María

1.234.567-8
2.345.678-9 3.456.789-0

10.000
20.000 30.000

Giménez
Detalle

Ana

4.567.890-1 Núcleo Familiar

40.000 Cancelar
95

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
96

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

97

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

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?
99

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

100

Datos

Modelo para contar PF
EI Archivos Lógicos Internos (ILF)

Frontera de la aplicación No mantenidos por la aplicación

EQ EO
Contiene datos derivados y/o afecta comportamiento

Archivos de Interfaz Externos (EIF)

14 “Características Generales de la Aplicación

transacciones PFSA

datos x Factor de Ajuste
102

PF =

Contar Datos
Pasos: • Identificar Archivos • Asignar a cada uno un tipo (ILF, EIF) • Identificar la cantidad de RET y DET • Asignar a cada uno un valor de complejidad (Alta, Media, Baja) en función de la cantidad de RET y DET

Definiciones cortas: • Data Element Type (DET):
 es un campo único (no repetido) reconocible por el usuario (ya lo habíamos visto al contar funciones)

• Record Element Type (RET):
 es un subconjunto de campos de un archivo, reconocible como tal por el usuario
103

Tipos de Archivos
Internal Logical File (ILF) • Es un grupo de datos o de información de control, lógicamente relacionado, identificable por el usuario y mantenido dentro de la frontera de la aplicación.

External Interface File (EIF) • Es un grupo de datos o de información de control, lógicamente relacionado, identificable por el usuario, referenciado por la aplicación, pero mantenido fuera de la frontera de la aplicación. Nota: Un EIF para una aplicación tiene que ser un ILF para alguna otra.
104

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
105

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
106

Caracterización de la complejidad
Para ILF/EIF
1 RET 2 a 5 RET 6 o más RET
1 a 19 DET 20 a 50 DET 51 o más DET

Baja Baja Media

Baja Media Alta

Media Alta Alta

Contribución de datos
\ Complejidad Tipo de Archivo Int. Logical File (ILF) Ext.Interface File(EIF) Baja Media Alta

7 5

10 7

15 10
107

Contribución de Datos
Ejemplo -

• • •

Aplicación mantiene los archivos:

Tarea ( #tarea, nom_tarea, escala) Descripción_Tarea ( #tarea, #línea, l_descrip) Empleado ( CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea)

ILF identificados: Tarea, Empleado Tarea: 2 RET - Tarea, Descripción_Tarea 5 DET - #tarea, nom_tarea, escala, #línea, l_descrip Empleado: 1 RET 5 DET - CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea Archivo Empleado Tarea
Tipo Nivel Complejidad

Cuenta

ILF ILF

Baja Baja

Total de Contribución de Datos :

7 7 14

108

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

109

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


• •

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

111

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
112

Contribución de Datos – Ejemplo 1
Archivos:
• Seguridad_Pantalla (id_usuario, id_pantalla, tipo_acceso) • Seguridad_Auditoría (fecha_hora_cambio, id_usuario_cambio,
id_usuario_ant, id_pantalla_ant, tipo acceso_ant,

id_usuario_post, id_pantalla_post, tipo_acceso_post)

1 ILF, 2 RET, 7 DET: (Seguridad_Pantalla – 3 DET Seguridad_Auditoría – 4 DET (fecha_hora_cambio, id_usuario_cambio, imagen_ant, imagen_post))
113

Contribución de Datos – Ejemplo 2
• La aplicación de Seguridad permite asignar a las personas, permisos de acceso a las instalaciones y recursos informáticos. • En la aplicación de RRHH se mantienen los sig. datos del archivo Empleado: (#empleado, CI, nombre, fecha_nac) • En la aplicación de Seguridad el encargado de seguridad puede modificar el campo “nivel de seguridad” y ver además los datos: #empleado, CI, nombre. ¿Cómo contar el archivo Empleado en RRHH y en Seguridad? Empleado - en RRHH: 1 ILF, 1 RET, 4 DET - en Seguridad: 1 ILF, 1 RET, 4 DET
114

Contribución de Datos – Ejemplo 3
• La aplicación de RRHH:
 mantiene los sig. datos del empleado: (id, nombre, dirección postal (calle, nro, piso, apto, ciudad, CP), sueldo, cargo).  al ingresarlo, calcula y graba la fecha de retiro.  imprime etiquetas para envío postal.

• La aplicación Postal:
 mantiene los códigos de edificio y  genera un listado con cant. de empleados en cada piso de cada edificio, para evaluar el proceso más efectivo para distribuir el correo. Empleado: - en RRHH - en Postal 1 ILF, 1 RET, 6 DET 1 ILF, 1 RET, 3 DET
115

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

116

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 Nro. Salidas Nro. Consultas Nro. Archivos Nro. Interfaces externas Nro. de algoritmos

x x x x x x

4 5 4 10 7 3

= = = = = =
117

Puntos Objeto
• Son una medida indirecta de software que se calcula teniendo en cuenta el total de:
Sencillas
pantallas o interfaces de usuario 1 PO

Moderadamente complejas
2 PO

Complejas
3 PO

informes componentes necesarios construir para la aplicación: El nro. de módulos 3GL para complementar el código 4GL

2 PO

5 PO 10 PO por cada módulo 3GL

8 PO

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

Técnicas de Estimación

Contar, Calcular, Juzgar
• Ejemplo: Banquete
 Costoso contar comensales uno por uno  Estimaciones:
• • • • • Experto: 335 Carlos: 11 * 7. Plan: 5 personas por mesa = 385 Lucía: Límite: 485. Lleno al 70-80%. 340-388. Prom=364 335, 385, 364. ¿Tomar medio 365? Cuenta de tickets = 407

•Contar cuando sea posible,
•calcular cuando no se puede contar (contar otra cosa y calcular a partir de datos calibrados), •usar juicio solo como último recurso.
120

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

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
122

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.

123

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)

124

Técnicas de Estimación
• • • • Juicio de Expertos Estimación por Analogía Métodos Algorítmicos Métodos basados en Aprendizaje Automatizado

125

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

126

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

127

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

128

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
129

Estimación por Analogía
• Matriz de costos de Wolverton (TRW-1974) O=Old; N=New 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

Tipo Control I/O Pre/post proces. Algoritmo Manejo de Datos Tiempo crítico

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

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
131

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

132

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

COCOMO II
3 modelos con distinto nivel de complejidad  composición de aplicaciones (tamaño en Object Points)  diseño temprano (tamaño en PF)  post-arquitectura (tamaño en LOCs) E= b Sc(y) m(X) y: Elementos de escala para ajustar el exponente x: Multiplicadores de esfuerzo • Herramientas que soportan los 2 últimos modelos • Calibrada con base de datos de proyectos • Estima esfuerzo, duración (y cantidad promedio de gente) de desarrollo, SIN contar Requerimientos • Esfuerzo en Meses-Persona (152 horas-Persona)
134

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

135

COCOMO II –
Multiplicadores de Esfuerzo (Post-Arq.)
4 categorías: • Atributos del producto
Relativos a las características del sw a desarrollar  RELY -> Confiabilidad requerida  DATA -> Tamaño BD  CPLX -> Complejidad  RUSE -> Reuso de productos en proyecto y otros  DOCU -> Documentación requerida

• Atributos de la plataforma
Relativos a los req. de HW y SW del sistema  TIME -> Carga de Procesadores  STOR -> Restricciones de Memoria  PVOL -> Volatilidad de la Plataforma
136

COCOMO II –
Multiplicadores de Esfuerzo (Post-Arq.)
• Atributos del personal
Relativos a la experiencia y capacidades del equipo de desarrollo  ACAP -> Capacidad de Analistas  AEXP -> Experiencia de Analistas en dominio del proy.  PCAP -> Capacidad de Programadores  PEXP -> Experiencia de Programadores en el dominio del proy.  LTEX -> Experiencia en Lenguaje y Herramientas  PCON -> Continuidad del personal

• Atributos del proyecto
Relativos a las características intrínsecas de cada proyecto específico  TOOL -> Herramientas  SITE -> Dispersión/Comunicaciones  SCED -> Compresión/Estiramiento de Plazo
137

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

138

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

Gestión de los Recursos Humanos

Gestión de RR.HH.
• ¿Def.? • Gestión pobre de RRHH – causa de fracaso del proyecto. • Factores críticos:
    Consistencia Respeto Inclusión Honestidad

141

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.

142

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

143

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
144

Estilos de Trabajo
INTROVERTIDO
INTUITIVO INTUITIVO INTUITIVO INTROVERTIDO: EXTROVERTIDO: Pregunta al resto Informa al resto Reconoce sentimientos Reconoce sentimientos RACIONAL EXTROVERTIDO: Informa al resto Decide lógicamente

EXTROVERTIDO

RACIONAL INTROVERTIDO: Pregunta al resto Decide lógicamente

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

Motivación
Maslow ‟54
Necesidad de realización Necesidades de estima Necesidades sociales

Necesidades de seguridad
Necesidades fisiológicas
146

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.

147

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

148

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.

149

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

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
151

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

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

153

Trabajo en grupo

Distribución del tiempo

Trabajo individual 30%

Interacción con otras personas 50%

Actividades no productivas 20%

154

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
155

Comunicaciones
Dos personas Tres personas 1 línea de comunicación

3 líneas de comunicación

Cuatro personas

6 líneas de comunicación

Cinco personas : n personas

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

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

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
158

“Chief Programmer Team”
Chief programmer
Assistant chief programmer

Senior programmers

Librarian

Administration

Test team

Junior programmers
159

“Chief Programmer Team”
• A cada una de las personas del equipo de desarrollo, se le asignan una serie de tareas de forma individual, y sólo responden de su trabajo ante el jefe de proyecto. Existe muy poco trabajo combinado. • La responsabilidad de coordinar todas las tareas es únicamente del jefe de proyecto.
Jefe de proyecto

Resto de componentes del equipo de desarrollo
160

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

161

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. • La organización, coordinación y distribución de tareas dentro del equipo se realiza conjuntamente por todos sus miembros. • 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. • Las críticas se hacen al producto o resultado, no a las personas.
162

Equipos Jerárquicos
• • • • El equipo de trabajo se divide en varios grupos. Existe un jefe de grupo que es el que coordina y asigna áreas a sus miembros. El jefe de grupo depende a su vez del jefe de proyecto, ante el cual deberá rendir cuentas y el cual le va a designar las tareas que su grupo debe desempeñar. La responsabilidad de asignar y coordinar las tareas de cada equipo de desarrollo, corresponde únicamente a sus jefes de grupo. El jefe de proyecto sigue teniendo como responsabilidad la asignar las tareas y coordinar los distintos equipos.
Jefe de proyecto

Jefes de grupo
Enlaces de comunicación

Resto de componentes del equipo de desarrollo
163

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

164

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
165

Ciclo de Vida de un Equipo
• • • • • Integración Tormenta Aceptación Etapa productiva Desintegración

166

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
167

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

168

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

169

Estilos de Manejo de Conflictos
Estilo

Nivel de Eficacia No lo resuelve (reaparece) Solución corto plazo, No lo resuelve Solución, pero todos pierden algo Solución, pero daña las relaciones entre las partes Se logra la mejor solución
170

Evitarlo Suavizarlo Solución de compromiso Forzar la resolución Enfrentarlo/buscar solución al problema

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
171

Evaluación de Factibilidad

Estudio de Factibilidad (I)
• Estudio corto para resolver si es posible y conveniente construir el sistema con la tecnología existente, las restricciones de costo y tiempo, etc. Responder a la pregunta: ¿Vale la Pena?

173

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?
174

Estudio de Factibilidad (III)
• Análisis Costo/Beneficio
Técnicos Clientes

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

175

Eval. de Factibilidad - Cuándo
• Frecuentemente el Estudio de Factibilidad es previo a un proyecto (ante-proyecto, prefactibilidad) • Puede ser la etapa inicial • A lo largo del proyecto, en puntos de control preestablecidos, se vuelve a formular la pregunta: ¿Vale la pena seguir?

176

Estudio de Factibilidad – Ejemplo Proyecto “ComidaClick”
• Introducción • Factibilidad de la solución
 Factibilidad técnica  Factibilidad económica

• Impacto del proyecto
    Impacto en el ámbito social Impacto económico Impacto ecológico Impacto cultural

• Pertinencia del proyecto • Conclusiones
177

Evaluación Financiera de Proyectos
Tasa de dto. Inversión Inicial PROYECTO 1 Semestres 0 1 2 3 4 5 Tasa Dto. Semestral Actualización de FF VAN TIR Actualización Ingresos Actualización Egresos Indice Rentabilidad TIR Anualizada 3,15% $ 50.000 ANUAL
PROYECTO 3 Semestres 0 1 2 3 4 5 Tasa Dto. Semestral Actualización de FF VAN TIR Actualización Ingresos Actualización Egresos Indice Rentabilidad TIR Anualizada

Ingresos 20.000 22.000 25.000 25.000 25.000 1,56% $ 81.417,89 $ 31.417,89 19,60% $ 111.515,30 $ 30.097,41 370,51%

Egresos Flujo Caja (50.000) 6.000 14.000 7.500 14.500 6.000 19.000 6.000 19.000 6.000 19.000

Reintegro (50.000) (36.000) (21.500) (2.500) 16.500

PROYECTO 2 Semestres 0 1 2 3 4 5 Tasa Dto. Semestral Actualización de FF VAN TIR Actualización Ingresos Actualización Egresos Indice Rentabilidad TIR Anualizada

Ingresos 15.000 16.000 18.000 18.000 18.000 1,56% $ 64.366,84 $ 14.366,84 10,59% $ 81.036,90 $ 16.670,05 486,12% 22,29%

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

Ingresos 17.000 17.000 17.000 17.000 17.000 1,56% $ 68.266,34 $ 18.266,34 13,24% $ 81.155,79 $ 12.889,45 629,63% 28,24%

Egresos 2.700 2.700 2.700 2.700 2.700

Flujo Caja (50.000) 14.300 14.300 14.300 14.300 14.300

Reintegro (50.000) (35.700) (21.400) (7.100) 7.200

Perfil del VAN
$ 35.000

43,04%

$ 30.000 $ 25.000

VAN

$ 20.000 $ 15.000 $ 10.000 $ 5.000 $0 0,00% 5,00% 10,00% Tasa 15,00% 20,00% 25,00%

Proyecto 1 Proyecto 2 Proyecto 3

178

Gestión de Riesgos

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

180

Proceso de Gestión de Riesgos
1. Planificación de la Gestión de Riesgos 2. Identificación de riesgos
 Identificar los posibles riesgos del proyecto, del producto y del negocio. Determinar la probabilidad de ocurrencia y las consecuencias de cada riesgo. Trazar planes para reducir las amenazas (evitar la ocurrencia de un riesgo o minimizar su impacto) y mejorar las oportunidades. Controla la ocurrencia de riesgos y ejecuta los planes de mitigación y contingencia, y evalúa su efectividad, a lo largo del proyecto.
181

3. Análisis cualitativo [y cuantitativo]de Riesgos:

4. Planificación de la Respuesta a los Riesgos

5. Seguimiento y Control de los Riesgos

Proceso de Gestión de Riesgos

Planificación de la Gestión de Riesgos

Identificación

Análisis

Planificación de la Respuesta

Seguimiento y Control

Plan de Gestión de riesgos

Lista de riesgos

Lista de riesgos priorizados

Planes de reducción y contingencia

Evaluación de los riesgo

Registro de Riesgos

182

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

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

Categorías de Riesgos (PMBoK)
Técnico Externo
de la organización Dirección de proyectos Estimación Planificación Control Comunicación

Requisitos Tecnología Complejidad e interfaces Rendimiento y fiabilidad Calidad

Subcontratistas y proveedores

Dependencias del proyecto

Regulatorio Mercado Cliente Condiciones climáticas

Recursos Financiación Priorización

185

Clasificación de Riesgos (Sommerville)
Riesgos: del proyecto del producto •diseño •interfaz •incertidumbre técnica •obsolescencia o de utilización de tecnología de punta del negocio •cambio en la dirección •cambios de estrategia de negocio •cambios en el mercado •pérdidas en la empresa •al equipo de desarrollo y a •la realización del proyecto en sí.
186

Problemas •presupuesto de: •agenda •personal •recursos •del cliente y sus requisitos •tamaño •complejidad del proyecto Afectan: •el costo y •la duración del proyecto.

•la calidad del sw resultante.

Riesgo
Abandono del personal del proyecto Cambios de gerencia

Tipo
Proyecto

Descripción
Personal experimentado deja el proyecto antes de su finalización. Cambios en la gerencia, con diferentes prioridades. HW para el desarrollo, el testing o la implantación no está disponible en la fecha acordada. El número o el impacto de los cambios en los requisitos es mayor al esperado.

Proyecto Proyecto Proyecto y producto

HW no disponible
Cambio en los requisitos

Retrasos en la especificación
Tamaño subestimado
Herramientas CASE no performantes

Proyecto y producto
Proyecto y prod. Producto

La especificación de las interfaces no están disponibles en la fecha acordada.
El tamaño del proyecto se ha subestimado. Las herramientas CASE para el desarrollo no son todo lo eficientes que se esperaba. La tecnología sobre la cual iba a construirse el proyecto es sustituída por una nueva. Un producto de la competencia aparece en el mercado antes de que el sistema se termine de construir.

Cambios de tecnología Producto de la competencia

Negocio Negocio

187

Tipos más comunes de riesgos
(Sommerville)
Tipo de riesgo Ejemplos
BD no puede procesar la # de transacciones/seg esperada. Componentes de SW a reusar defectuosos. Tecnologías desconocidas. No se consigue personal con las habilidades requeridas. Personal clave no está disponible. No se puede proveer la capacitación necesaria. Nueva gerencia. Probs. financieros reducen presupuesto.

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

De personal
(equipo de desarrollo)

Organizacionales
(del ambiente organizacional de desarrollo y del cliente)

De herramientas
De requerimientos De estimación

El código generado es ineficiente. Incompatibilidad entre herramientas.
Cambios en reqs requieren trabajo de rediseño importante. Los clientes no logran entender impacto de cambios solicitados. Tiempo de desarrollo, tasa de reparación de defectos y/o tamaño subestimados. 188

“Top 10 Risk Items” (Boehm)
1989
1. Limitaciones de Personal
2. Calendario y Presupuesto 3. Funciones equivocadas 4. Interfaz de usuario no adecuada 5. “Gold plating” (preciosismo) 6. Cambios en Requisitos 7. Suministros externos 8. Tareas externas 9. Desempeño de Tiempo Real 10. Forzar ciencia de computación

1995
1. Limitaciones de Personal 2. Calendario, Presupuesto, Procesos 3. COTS, componentes externos 4. Requerimientos inadecuados 5. Interfaz de usuario inadecuada 6. Arquitectura, desempeño, calidad 7. Cambios en Requisitos 8. Software Heredado 9. Tareas externas 10. Forzar ciencia de computación

189

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
190

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

191

Diagrama de Árbol de Decisiones
Definición de decisión Decisión a tomar Nodo de decisión E: Costo de cada opción S: Decisión tomada (V/F) Nodo de posibilidad E: Prob. de escenarios, Recompensa si ocurre S: Valor monet. esp.(EMV) Valor del camino Beneficios - costos

Fuerte demanda Construir nueva planta ¿Construir o mejorar?
F -$120 EMV del Nodo de Posibilidad = $ 42,5 M

65% $200

$80M

Poca demanda
EMV de la decisión = $ 49 M

35% $90 65% $120

-$30M

Fuerte demanda Mejorar planta existente
V -$50 EMV del Nodo de Posibilidad = $ 49,0 M

$70M

Poca demanda

35% $60

$10M

192

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
193

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

Mitigación del Riesgo
• Quizás no sea rentable o posible desarrollar respuestas proactivas. Se justifica dependiendo de:
 Nivel de Reducción= (severidad antes de reducciónseveridad después de reducción) / (costo de reducción)  Si nivel de reducción<1 no valdrá la pena

195

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.

196

Actividades en Gestión de Riesgos
Según Rook, 1993
Identificar Riesgos
Evaluar Riesgos Analizar Riesgos Priorizar Riesgos No se pueden atender todos Gestión de Riesgos Impacto y/o Reducir
Lista de Comprobación Descomposición Análisis de Supuestos Análisis de Procs. de Decisión Dinámica de Sistemas Modelos de Desempeño Modelos de Costo Análisis de Redes Análisis de Decisiones Factores de Riesgo en Calidad Severidad de Riesgos Reducción Compuesta Obtener Información Evitar un Riesgo Transferirlo Evaluar Nivel de Reducción Desarrollar el Proceso

Probabilidad Incertidumbre Reducir Riesgos Control de Riesgos Planear Solución de Riesgos Qué hacer si ocurre Periódicamente, o en hitos del proyecto Resolver Riesgos

Planear elemento de Riesgo Plan integrado Reducir Riesgo Una vez Monitoreo e Informes ocurrido 197 Reevaluar Riesgos

Riesgos y el Plan del Proyecto
• Actividades de Reducción de Riesgos ->WBS • Considerarlas en plazo, esfuerzo, costo • Prever un colchón en el plazo
 8% de duración para proyectos normales (no planificar con el enfoque “si todo sale bien”)  más si el riesgo de pasarse de la fecha estipulada para el proyecto lo justifica

198

Gestión de la Calidad

Gestión de la Calidad
• Planear la calidad:
 identificar estándares de calidad relevantes al proyecto y cómo satisfacerlas

• Asegurar la calidad:
 asegurar que los estándares se cumplieron  detectar de desviaciones durante el proceso de producción  para aumentar la confianza en la obtención de los objetivos de calidad

• Controlar la calidad:
 control de productos obtenidos

Gestión de la Q debe reportar a alta gerencia directamente, por encima del jefe de proyecto, para que obj. de Q no estén comprometidos por recortes de presupuesto o calendario.
200

Gestión de la Calidad
Gestión de la Calidad Planear la Calidad • Responsabilidades • Estándares • Procedimientos • Puntos de Control • Métricas de Q • Checklists Asegurar la Calidad • Revisiones • Auditorías Controlar la Calidad • Verificar • Validar

WBS
201

Plan de Calidad
• Plan de Calidad:
 Descripción del producto, mercado y calidad esperada.  Planes del producto: fechas de liberación de versiones, responsables del producto, planes de distribución del producto.  Desc. de procesos para el desarrollo y la gestión del producto.  Los atributos de calidad más importantes del producto: Pe. Seguridad (safety), Seguridad (security), Confiabilidad, Robustez, Comprensibilidad, Verificabilidad, Modularidad, Complejidad, Eficiencia, Portabilidad, Reusabilidad, Usabilidad, Facilidad de Aprendizaje  Procedimientos para evaluar si un atributo de calidad está presente en el producto.  Gestión de riesgos claves que pueden afectar la calidad del producto.
202

Gestión de la Calidad
• Relación entre calidad del proceso y calidad del producto:
 es claro en procesos de manufactura, porque el proceso se puede estandarizar y monitorear fácilmente.  el SW no es manufacturado sino diseñado – difícil predecir cómo cambios en proceso afecta Q del producto. Pero experiencia muestra relación.

203

Gestión de la Configuración

Gestión de la Configuración
• Gestión de los componentes de un producto:
 Registro y control de los cambios de un producto y de sus componentes  Coordinación fuente-ejecutable

• Gestión de los entregables de un proyecto:
 Registro y control de sus cambios  Asegurar su disponibilidad (respaldos)  Generación y Control de la Línea Base o de Referencia

WBS
205

Gestión de las Comunicaciones

Gestión de las Comunicaciones
Procesos involucrados:
 Planificación de las comunicaciones  Distribución de la información  Reportes de situación, avance y predicciones  Cierre administrativo

207

Comunicación entre los Involucrados
• Patrocinador, Cliente, Usuario, Desarrolladores, Otros Interesados-Involucrados • Procedimientos de comunicación
 periódicos, hitos  formales, no formales  revisiones conjuntas (con Cliente, Usuarios, etc.)

• Manejo de Expectativas de los interesados • Decisiones por personas autorizadas y con conocimiento de causa

WBS
208

Plan de Gestión del Proyecto

Plan de Gestión del Proyecto
• Documento para comunicar :
    organización estimaciones de costo y duración calendario de actividades e hitos del proyecto la gestión y el análisis de riesgos

al cliente y al equipo de trabajo

210

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
211

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

212

Registro y Control de Avance
Bibliografía específica: •Practice Standard for Earned Value Management (PMI – 2005)

Registro y Control de Avance
• Saber dónde está un proyecto y hacia dónde está yendo, comparando con lo planificado. • Objetivos:
    medir analizar predecir informar el desempeño en costos y cronograma

214

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

215

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?

216

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

217

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
218

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

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

Registro y Control de Avance

Técnicas
• Gantt
• Diagrama de Evolución de Gastos

• Enfoque del Valor Ganado

221

Registro y Control de Avance Técnicas - Gantt
Actividad A B C D

A y B están atrasadas, C adelantada, ¿y el proyecto? ¿Está costando más o menos de lo previsto?
222

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.

223

Registro y Control de Avance – Técnicas -

Diagrama de Evolución de Gastos
$

Diagrama de
Evolución de Gastos Planificado Real

Acumulados
t

Se lleva gastado más de lo previsto a la fecha, pero
¿cuál fue el avance logrado? ¿se va a gastar más o menos de lo previsto?
224

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

Enfoque de Valor Ganado
$
Costo Final de acuerdo a tendencia(CT)

Planificado

Costo Planificado Final (CPF)

Valor Ganado (Valor presupuestado del avance logrado) Costo Real en t0
Valor Ganado en t0 es el previsto para t1

0

t1

t0

Fin Planificado (FP)

Fin de acuerdo a tendencia (FT)

t

226

Enfoque del Valor Ganado
Medidas de Desempeño Respecto al Tiempo
Preguntas de Gestión del Proyecto Medidas de desempeño (MVG)
¿Cómo vamos respecto al tiempo? -¿Estamos adelantados o atrasados? -¿Cuánto? ¿Cuán eficientemente estamos usando el tiempo? ¿Cuándo vamos a terminar? Análisis y Predicción de Cronograma -Varianza del Cronograma (SV = VG -VP) - Varianza del Tiempo (TV = TP – TR) - Índice de Desempeño del Cronograma (SPI = VG / VP) -Fin de acuerdo a la tendencia (FT = FP / SPI)

Valor Ganado: VG | Valor Planificado: VP | Tiempo Planificado: TP | Tiempo Real: TR | Final Planificado: FP
227

Enfoque del Valor Ganado
Medidas de Desempeño Respecto al Costo
¿Cómo vamos respecto al costo? Análisis y Predicción de Costos

¿Estamos por encima o por debajo del -Varianza del Costo presupuesto? ¿Cuánto? (VC = VG - CR) - ¿Cuán eficientemente estamos usando los recursos? ¿Cuánto va a costar el proyecto? -Índice de Desempeño del Costo (CPI = VG / CR) -Costo de Acuerdo a Tendencia (CFT= CFP / CPI)

Costo Real: CR | Valor Ganado: VG | Valor Planificado: VP | Costo Final Planificado: CFP
228

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

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

230

Técnicas 1.50/50 2. Hitos con peso 3. 25/75 4. 0/100 5. Hitos con peso 6. 50/50
231

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

232

Fecha de hoy: 30 de abril

233

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

234

Ejemplo Valor Ganado
18

Relevamiento
10

Diseño
80% - 100% 20

Desarrollo
70% - 80% 40

Verificación, Instalación y Capacitación
0% - 15%

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

235

Ejemplo Valor Ganado (2)
100 90 80 70 60 50 40 30 20 10 0 1 2 Tiempo 3

Recursos

VP VG CA

236

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.

237