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

Transcripción

1 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. 2

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

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

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 5

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 6

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. Personal no pronto cuando planificado Estimación = 20 meses/persona Requisitos eliminados Personal asignado a presentación El Proyecto Funcionalidad inestable eliminada Resultado = 20 meses/persona Nuevos requisitos Personal menos experiente que lo planificado Personal reasignado para dar soporte a proyecto anterior Nuevos requisitos 7

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

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

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

11 Tipo de SW Productividad varía según tipo de proyecto: LOC / Mes persona (promedio) Tipo de SW LOCs LOCs LOCs Aviones Sistemas de Información Comando y control Sistemas embebidos Sistemas web Intranets Microcódigo Control de procesos Tiempo real Sistemas científicos Paquetes Drivers Telecomunicaciones

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

13 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. Algunos lenguajes generan más funcionalidad por LOC. Cantidad de sentencias comparado con C Lenguaje Assembler 2 a 1 C 1 a 1 Cobol 1 a 1,5 Fortran 1 a 2 C# 1 a 2,5 C++ 1 a 2,5 Java 1 a 2,5 Visual Basic 1 a 4,5 Perl 1 a 6 Smalltalk 1 a 6 SQL 1 a 10 Trabajar en lenguajes interpretados tiende a ser (hasta 2 veces) más productivo que en lenguajes compilados. 13

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

15 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

16 Métricas de Tamaño Tamaño permite: Estimar esfuerzo y duración Medir calidad (defectos / unidad de construcción) Medir productividad (tamaño / unidad de esfuerzo) Ejemplos: Casa: metros cuadrados de construcción Carretera: kilómetros o kilómetros cuadrados Software:? LOCs Puntos de Función etc. 16

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

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

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 19

20 Líneas de Código Productividad en proyectos iguales, en lenguajes distintos Proyecto A: 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: /8= Proyecto A : 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: /6= Paradoja! C más productivo que C++? Unidad de medida depende del lenguaje 20

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

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

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

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

25 Modelo para contar PF Frontera de la aplicación Contiene datos derivados y/o afecta comportamiento EI EQ EO Archivos Lógicos Internos (ILF) Archivos de Interfaz Externos (EIF) No mantenidos por la aplicación 14 Características Generales de la Aplicación datos transacciones PF = PFSA x Factor de Ajuste 25

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

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 27

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

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 29

30 Frontera de la Aplicación (II) RR.HH. Usuario 1 Ventas Contabilidad No cumple con la aditividad: si uno componentes, la cuenta da menos. Fronteras definidas a partir de la visión del negocio cómo impactaría en la cuenta total de PF considerar esta otra frontera? 30

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

32 Transacciones

33 Modelo para contar PF Frontera de la aplicación Contiene datos derivados y/o afecta comportamiento EI EQ EO Archivos Lógicos Internos (ILF) Archivos de Interfaz Externos (EIF) No mantenidos por la aplicación 14 Características Generales de la Aplicación datos transacciones PF = PFSA x Factor de Ajuste 33

34 Contar Transacciones Pasos: Identificar transacciones Asignar a cada una un tipo (EI, EO, EQ) Identificar la cantidad de DET y FTR Asignar a cada una un valor de complejidad (Alta, Media, Baja) en función de la cantidad de DET y FTR Definiciones: Data Element Type (DET): es un campo único (no repetitivo) reconocible por el usuario File Type Referenced (FTR): es un tipo de archivo al que se hace referencia en una transacción; tiene que ser un ILF o EIF 34

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

36 Proceso Elemental Definición: Es la mínima unidad de actividad que tiene un significado para el usuario debe ser autocontenido, no requiere de otra actividad para que adquiera significado debe dejar al sistema en un estado consistente Ejemplo: Si el usuario desea agregar un empleado, puede requerir incorporar: nombre fecha de ingreso CI sueldo estado civil fecha de nacimiento Este proceso elemental se completa al ingresar todos los datos requeridos 36

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 37

38 Proceso en Transacciones Tipo de Proceso EI EO EQ Acepta datos o inf. de control que entra SI p p Presenta información fuera de la frontera p SI SI Altera el comportamiento del sistema p* p* NO Al menos se actualiza un ILF p* p* NO Fórmulas matemáticas y cálculos p p* NO Crea datos derivados p p* NO Al menos un ILF o EIF referenciado p p SI Recupera datos o información de control p SI SI Validaciones p p p Se convierten valores equivalentes p p p Selección y filtro de datos p p p Se evalúan condiciones p p p Reordena un conjunto de datos p p p p=posible p*=uno por lo menos debe estar presente 38

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 39

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 40

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 41

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 8 DET cantidad importe) (E) 4 DET 42

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) 6 DET Precio unitario se obtiene del archivo de Artículos NO cruza la frontera 43

44 Complejidad de EQ/EO Nro. de DET Ejemplo 1 se listan los datos (nombre, dirección, teléfono) 3 DET Ejemplo 2 gráfica de tortas con la cantidad de empleados en determinado rango de edad, con descripción para cada rango 2 DET: valor y rótulo 44

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 imprimirlo Esta marca NO se cuenta como DET Literales Ejemplo: Los títulos (si son fijos) no se cuentan como DET Variables generadas por el sistema relacionadas con el paginado o fecha y hora Ejemplos: nros. de página información de posicionamiento (filas 32 a 56 de 781) Comandos para paginar (anterior, siguiente, barra de posicionamiento) Fecha y hora 45

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 46

47 Contribución de Transacciones \ Complejidad Tipo de Transacción Baja Media Alta External Input (EI) External Output (EO) External inquiry (EQ)

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 3 Listado Clientes EQ Baja 3 Cantidad Clientes EO Baja 4 Total de Contribución de Transacciones: 10 48

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 49

50 Consulta de Empleados Sistema de RRHH Empleado Tareas Asignaciones Informes Ayuda Lista de Empleados Apellido Nombre CI Sueldo Pérez Juan Martínez Pedro Fernández María Giménez Ana Detalle Núcleo Familiar Cancelar 50

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 51

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 52

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

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

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 55

56 Datos

57 Modelo para contar PF Contiene datos derivados y/o afecta comportamiento EI EQ EO Archivos Lógicos Internos (ILF) Archivos de Interfaz Externos (EIF) transacciones datos Frontera de la aplicación No mantenidos por la aplicación 14 Características Generales de la Aplicación PF = PFSA x Factor de Ajuste 57

58 Contar Datos Pasos: Identificar Archivos Asignar a cada uno un tipo (ILF, EIF) Identificar la cantidad de RET y DET Asignar a cada uno un valor de complejidad (Alta, Media, Baja) en función de la cantidad de RET y DET Definiciones cortas: Data Element Type (DET): es un campo único (no repetido) reconocible por el usuario (ya lo habíamos visto al contar funciones) Record Element Type (RET): es un subconjunto de campos de un archivo, reconocible como tal por el usuario 58

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

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 60

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 61

62 Caracterización de la complejidad Para ILF/EIF 1 a 19 DET 20 a 50 DET 51 o más DET 1 RET Baja Baja Media 2 a 5 RET Baja Media Alta 6 o más RET Media Alta Alta Contribución de datos \ Complejidad Baja Media Alta Tipo de Archivo Int. Logical File (ILF) Ext.Interface File(EIF)

63 Ejemplo - Contribución de Datos Aplicación mantiene los archivos: Tarea ( #tarea, nom_tarea, escala) Descripción_Tarea ( #tarea, #línea, l_descrip) Empleado ( CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea) ILF identificados: Tarea, Empleado Tarea: 2 RET - Tarea, Descripción_Tarea 5 DET - #tarea, nom_tarea, escala, #línea, l_descrip Empleado: 1 RET 5 DET - CI, nom_empleado, fecha_nac, fecha_ingreso, #tarea Archivo Tipo Nivel Complejidad Cuenta Empleado Tarea ILF ILF Baja Baja Total de Contribución de Datos :

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 64

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

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 66

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 67

68 Contribución de Datos Ejemplo 1 Archivos: Seguridad_Pantalla (id_usuario, id_pantalla, tipo_acceso) Seguridad_Auditoría (fecha_hora_cambio, id_usuario_cambio, id_usuario_ant, id_pantalla_ant, tipo acceso_ant, id_usuario_post, id_pantalla_post, tipo_acceso_post) 1 ILF, 2 RET, 7 DET: (Seguridad_Pantalla 3 DET Seguridad_Auditoría 4 DET (fecha_hora_cambio, id_usuario_cambio, imagen_ant, imagen_post)) 68

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

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

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

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

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

74 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% Prom= , 385, 364. Tomar medio 365? Cuenta de tickets = 407 Contar cuando sea posible, calcular cuando no se puede contar (contar otra cosa y calcular a partir de datos calibrados), usar juicio solo como último recurso. 75

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

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 77

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

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

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 80

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 81

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

83 Estimaciones basadas en Proxies - Técnicas Fuzzy Logic Componentes Estándar Puntos de historia T-Shirt Sizing 83

84 Fuzzy Logic Clasificar características en MP, P, M, G, MG. Datos históricos: LOCs promedio por característica. Calcular Tamaño característica LOCs promedio por característica Cant. características LOCs estimadas Muy pequeño Pequeño Mediano Grande Muy grande Total Se aplica la Ley de los Números Grandes. Se puede aplicar también a estimación de esfuerzo. 84

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. Comp. estándar LOCs por componente Mín Más probable Máx Nro. estimado LOCs estimadas Pág. web dinámicas , Pág. web estáticas , Tablas BD , Reportes , Reglas de negocio TOTAL Para usar en etapas tempranas. 85

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 86

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 87

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 88

89 Estimación por Analogía Matriz de costos de Wolverton (TRW-1974) O=Old; N=New Dificultad E=Easy; M=Medium; D=Difficult Tipo OE OM OD NE NM ND Control I/O Pre/post proces Algoritmo Manejo de Datos Tiempo crítico Se estima el tamaño de cada módulo en LOCs 89

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 90

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*S c ) m (X) donde a, b y c son constantes (dependen de la org) S es el tamaño estimado del producto Tamaño es factor más influyente c gral. está entre 1 y 1.5. Refleja que el esfuerzo no crece linealmente con el tamaño, sino que es mayor por manejo de la complejidad. (Productividad decrece) m es un multiplicador de ajuste que depende del vector X de factores de ajuste 91

92 Métodos Algorítmicos Ejemplo: Walston-Felix (1977): E=5.25 S 0.91 Interés histórico. Exponente menor que 1 E crece, pero crece menos la productividad crece con el tamaño. Ejemplo: COCOMO (Constructive Cost Model) Boehm 81. Problema: modelos dependientes del tamaño. Trasladan estimación del esfuerzo a estimación del tamaño. Pero estimaciones son requeridas tempranamente, y tamaño depende de decisiones de diseño. 92

93 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 S c(y) m(x) y: Elementos de escala para ajustar el exponente x: Multiplicadores de esfuerzo Herramientas que soportan los 2 últimos modelos Calibrada con base de datos de proyectos Estima esfuerzo, duración (y cantidad promedio de gente) de desarrollo, SIN contar Requerimientos Esfuerzo en Meses-Persona (152 horas-persona) 93

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 94

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

96 COCOMO II Multiplicadores de Esfuerzo (Post-Arq.) Atributos del personal Relativos a la experiencia y capacidades del equipo de desarrollo ACAP -> Capacidad de Analistas AEXP -> Experiencia de Analistas en dominio del proy. PCAP -> Capacidad de Programadores PEXP -> Experiencia de Programadores en el dominio del proy. LTEX -> Experiencia en Lenguaje y Herramientas PCON -> Continuidad del personal Atributos del proyecto Relativos a las características intrínsecas de cada proyecto específico TOOL -> Herramientas SITE -> Dispersión/Comunicaciones SCED -> Compresión/Estiramiento de Plazo 96

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 97

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

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

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

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 102

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 103

104 EXTROVERTIDO INTROVERTIDO Estilos de Trabajo INTUITIVO INTROVERTIDO: Pregunta al resto Reconoce sentimientos RACIONAL INTROVERTIDO: Pregunta al resto Decide lógicamente INTUITIVO INTUITIVO EXTROVERTIDO: Informa al resto Reconoce sentimientos RACIONAL EXTROVERTIDO: Informa al resto Decide lógicamente RACIONAL ¾ de técnicos son introvertidos (vs. 1/3 de la población) 104

105 Motivación Maslow 54 Necesidad de realización Necesidades de estima Necesidades sociales Necesidades de seguridad Necesidades fisiológicas 105

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

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 107

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

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

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 110

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

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 112

113 Trabajo en grupo Distribución del tiempo Trabajo individual 30% Interacción con otras personas 50% Actividades no productivas 20% 113

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 114

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

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

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 117

118 Chief Programmer Team Chief programmer Assistant chief programmer Senior programmers Librarian Administration Test team Junior programmers 118

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

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

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

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. Jefe de proyecto Jefes de grupo Enlaces de comunicación Resto de componentes del equipo de desarrollo 122

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 123

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 124

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

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 126

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 127

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 128

129 Estilos de Manejo de Conflictos Evitarlo Suavizarlo Estilo Nivel de Eficacia No lo resuelve (reaparece) Solución corto plazo, No lo resuelve Solución de compromiso Forzar la resolución Enfrentarlo/buscar solución al problema Solución, pero todos pierden algo Solución, pero daña las relaciones entre las partes Se logra la mejor solución 129

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 130