Estimaciones - Universidad de Buenos Aires
Anuncio
Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 3b: Planificación y Estimación de Proyectos de Software Buenos Aires, 28 de Agosto de 2008 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Sobre el Gerenciamiento - Funciones Gerenciamiento “Staffing” Planificar Organizar Controlar Liderar ¿Qué es planificar? Predeterminar un curso de acción para cumplir objetivos 2 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Puntos clave: identificación de “Stakeholders” Debo identificar claramente: Para quién desarrollaré el producto Quién pagará el producto Quién usará el producto Quién es un factor de decisión esencial para el éxito del producto Quién tiene el know-how Quién y cómo se aceptará el producto Algunos “stakeholders” clave Sponsor Líder usuario (Product Champion) Usuarios directos e indirectos 3 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Determinación de Factores Críticos Distintos objetivos compiten “Puede ser bueno, lo puedo entregar rápido, puede ser barato. Elija dos” En general, podemos hablar de cinco dimensiones de la calidad en un proyecto de software: Funcionalidad Calidad Recursos Costo Plazo Cada una puede ser driver, restricción, grado de libertad 4 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Representación con diagramas de flexibilidad Sistema de información interno Aplicación comercial competitiva “Quality Driven” Fuente: Karl Wiegers, Creating a Software Engineering Culture. Dorset House, 1996. 5 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Identificación Preliminar de Requerimientos Además de los factores críticos, necesitamos un entendimiento inicial del alcance y los requerimientos (si queremos tener un plan) Esto incluye tanto los requerimientos funcionales como atributos de calidad (“ilities”) Son el input para muchas tareas de planificación Inicialmente se usan para la estimación 6 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Estimaciones - ¿Qué hay que estimar? Tamaño: ¿Qué tan grande es lo que tenemos que hacer? Esfuerzo: ¿Cuántas horas / persona son necesarias para construirlo? Costo: ¿Cuánto gastaremos en hacerlo? Esta es la secuencia natural de estimación, aunque en muchos casos se comienza por el esfuerzo. Esfuerzo Cronograma Tamaño Costo 7 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Cómo se suele estimar? Para tamaño se suelen usar líneas de código u otras mediciones del tipo “puntos” (de función, de caso de uso) Luego se ajustan por distintos factores Para esfuerzo se multiplica la estimación de tamaño por un “factor de productividad” E (Hs persona) = T (MT) * P (Hs Persona/MT) El costo está principalmente compuesto por horas. El resto de los costos es relativamente fácil de estimar Vamos a ver más detalles en la clase sobre métodos de estimación 8 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Problemas recurrentes en las estimaciones Somos generalmente optimistas. No recordamos todas las experiencias pasadas. Omitimos tareas importantes que luego no hacemos por falta de tiempo comprometiendo la calidad, o las hacemos comprometiendo el cronograma En vez de estimaciones, tenemos objetivos (“esto tiene que estar listo para Junio”) 9 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¡Porque no se puede! Existen pocos datos para poder estimar. No vale la pena, es imposible o inutil estimar En software siempre puedo estimar con un cierto nivel de incertidumbre... a partir de la experiencia anterior (mi experiencia, casos similares, métricas de mi empresa, otras empresas…) y usar eso como base para trabajar. 10 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Incertidumbre de la Estimación (waterfall) 4x 2x x etapas Entrega 1/2 x 1/4 x Codificación Diseño Requerimientos Factibilidad Fuente: Software Estimating Technology: A survey. Richard Stutzke. 11 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 El ciclo dorado de la estimación Estimo Mido Calibro Analizo Registro Comparo 12 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Por qué estimamos mal? Algo estamos haciendo mal... La toma de requerimientos es pobre No sabemos cómo estimar La estimación la hace marketing, o ventas, o … No conocemos la tecnología, el dominio, o ninguna de las dos cosas No reconocemos las diferencias de escala Y también confudimos Esfuerzo y tiempo (en la planificación) Tiempo, esfuerzo y progreso (en la ejecución) 13 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Qué cosas afectan el tamaño del software? Cantidad y complejidad de las funcionalidades Cantidad y complejidad de los datos Factores Adicionales: Atributos de calidad Novedad Tecnologías a utilizar Restricciones Etc... 14 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Una clasificación de métodos Empíricos: Opinión de experto u “Ojo de buen cubero”. Opiniones basadas en experiencias personales. Opiniones basadas en comparación con proyectos anteriores de similares características (analogía). Descomposición. (1) Descomponer, (2) Estimar cada parte, (3) Sumar, ajustar y contar el costo de las uniones. Métodos Algorítmicos. Usar un algoritmo que toma datos del sistema (e.g. funcionalidades, pantallas, inputs...) y factores de ajuste por complejidad y devuelve un número. Combinaciones de los anteriores. 15 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Método de Clark Dividir al sistema en módulos Estimar para cada módulo tres valores Optimista (O): el menor tamaño / esfuerzo imaginable Pesimista (P): el mayor tamaño / esfuerzo imaginable Valor “medio” (M) Calcular el estimado... Estimado = ( O + 4 M + P) / 6 16 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi Desarrollado por Rand Corporation, a fines de los ’40 Aprovecha la experiencia de los expertos y elimina el sesgo producido por el optimismo de algunos de los expertos 17 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Participantes: - Moderador - Gerente del Proyecto Actividades - Definir el alcance de la especificación a estimar - Juntar la información disponible para la estimación - Se seleccionan de 2 a 4 estimadores adicionales al moderador para participar del proceso 18 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Participantes: - Moderador - Gerente del Proyecto - Estimadores Actividades - Se expone la técnica a los estimadores que no la conocen. - Se exhibe la información disponible sobre el problema: especificación, restricciones, condiciones de contexto, etc. - Se definen los objetivos de la estimación. - Se revisan los requerimientos y se evalúa si los estimadores son idóneos para el dominio de problema a estimar. 19 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Participantes: - Estimadores Actividades - Cada estimador construye una lista de las tareas / módulos. - Se asocia la estimación a cada una de ellas. 20 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Participantes: - Moderador - Estimadores Actividades - Se recolectan las estimaciones individuales y se colocan sobre un gráfico. No se debe indicar quién hizo cada estimación (!). 21 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados 22 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados 23 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Actividades - Continúo en este proceso hasta que: - El desvío es aceptable. - Se acabó el tiempo de la reunión (aprox. 2 hrs.) - No hay cambios entre iteraciones. - Los estimadores en este momento se sienten seguros de la estimación más allá de las diferencias... 24 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Participantes: - Gerente del Proyecto - Moderador Actividades - Se crea una lista maestra de tareas asociando a cada una cada una de las estimaciones. 25 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Wideband Delphi (versión “full”) Planificación Reunión de Lanzamiento Preparación Individual Reunión de Estimación Ensamblado de Tareas Revisión de Resultados Participantes: - Gerente del Proyecto - Moderador - Estimadores Actividades - Se revisa la lista de tareas y se llega a un acuerdo acerca de su composición. 26 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Los Puntos de Función Método creado por Allan Albrecht en 1977 (IBM) Es un método de estimación algorítmico para el tamaño Muy usado (en alguna de sus variantes). Grupo de usuarios IFPUG activo “Puntos de función” = el tamaño es un puntaje dependiente de las funcionalidades y algunas características generales del proyecto y el sistema Hay “números mágicos” que permiten llevar los puntos de función a líneas de código o esfuerzo 27 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Método Identificar (“contar”) los componentes del Sistema Calcular el valor funcional sin ajustar Ajustarlo según ciertas características de la aplicación Aplicar un factor de productividad para calcular el esfuerzo 28 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Las componentes del sistema a contar Dos preguntas molestas ¿Qué está dentro del sistema? ¿Qué está fuera del sistema? Factores a “contar” Entradas Externas Salidas Externas Consultas Externas Archivos Lógicos Internos Archivos de Interfaz Externos 29 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Complejidad para Entradas Externas “Archivos” referenciados Items de Datos <5 5-15 16+ <2 Simple Simple Mediano 2-3 Simple Mediano Complejo 4+ Mediano Complejo Complejo 30 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Complejidad para Salidas y Consultas Externas “Archivos” referenciados Items de Datos <6 6-19 20+ <2 Simple Simple Mediano 2-3 Simple Mediano Complejo 4+ Mediano Complejo Complejo 31 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Complejidad para Archivos Internos y Archivos de Interfaz Archivos referenciados Items de Datos <20 20-50 51+ 1 Simple Simple Mediano 2-5 Simple Mediano Complejo 6+ Mediano Complejo Complejo 32 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Tabla de Cálculo del Valor Funcional (Sin ajustar) Componente Entrada Externa Salida Externa Consultas Externas Archivos Lógicos Internos Archivos de Interfaces Ext Simple __ x 3=__ __ x 4=__ __ x 7=__ __ x 5=__ __ x 3=__ Complejidad Mediana Compleja Tot. __ x 4=__ __ x 6=__ __ x 5=__ __ x 7=__ __ x 10=__ __ x 15=__ __ x 7=__ __ x 10=__ __ x 4=__ __ x 6=__ Total PF Brutos: 33 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Factores de Complejidad 1. 2. 3. 4. 5. 6. 7. ¿La información y el control, usan comunicaciones? ¿El procesamiento distribuido es una característica de la aplicación? ¿La aplicación tiene objetivos de performance? ¿La aplicación va a correr sobre un entorno muy usado? ¿La frecuencia de transacciones es alta e influye sobre el diseño y la implementación? ¿Hay entrada de datos on line? ¿Es importante la eficiencia en las entradas on line? 34 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Factores de Complejidad (2) 8. 9. 10. 11. 12. 13. 14. ¿Los archivos internos se actualizan on line? ¿El procesamiento complejo es una característica de la aplicación? ¿La aplicación será construida pensando en la reusabilidad de sus componentes? ¿Es un requerimiento que la conversión de datos y la instalación sean simples? ¿La facilidad de operación es un requerimiento de la aplicación? ¿La aplicación será instalada en múltiples sitios? ¿La aplicación será desarrollada para facilitar sus cambios? 35 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Cálculo de puntos de función ajustados Se asigna a los factores de complejidad un peso, entre 0 y5 0 = no está presente 5 = tiene un alto impacto en el proyecto Se calculan los puntos de función ajustados: PFA = Puntos de función sin ajustar * [0.65 + 0.01 * suma de nivel de influencia] Máxima influencia: 1.35 (0.65+0.7) Mínima influencia: 0.65 36 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Esfuerzo (que ya sabemos que no es tiempo) No existe una forma única de asociar PF a horas hombre. Regla Genérica: 1PF = 8 HH Usar el “language level” de Capers Jones 4-8 10 to 20 Function Points per staff month 9 - 15 16 to 23 Function Points per staff month 16 - 23 15 to 30 Function Points per staff month 24 - 55 30 to 50 Function Points per staff month Above 55 40 to 100 Function Points 1st Generation Default. LL: 1.00 LOC: 320 2nd Generation Default. LL: 3.00 LOC: 107 3rd Generation Default. LL: 4.00 LOC: 80 4th Generation Default. LL: 16.00 LOC: 20 Java. LL: 6, LOC: 53 1PF = 9 HH Staff Month = 136 horas por mes 37 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 ¿Para qué puede usarse? Para estimar un proyecto, en cualquier momento del desarrollo (inclusive muy temprano) Para medir productividad Para monitorear “outsourcing” Para medir los cambios Para normalizar otras medidas defecto, precio ... 38 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 A favor Basado en una visión externa “Sencillo” de aplicar Puede ser entendido por usuarios no técnicos Independiente del ambiente de desarrollo Puede hacerse una estimación temprana Hay registros históricos de su uso 39 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 En contra – Ejemplo de MARK II La clasificación en 3 categorías es muy simplificada Las estimaciones son bajas si los algoritmos son complejos La selección de pesos es empírica Propuesta: Symons, MARK II: PF = 0.44 * Cantidad de elementos de datos de input + 1.67 * Cantidad de referencias a entidades + 0.38 * cantidad de elementos de datos de salidas Fuente: Charles Symons, Software Sizing and Estimating: MKII FPA. Wiley & Sons, 1991 40 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Ejemplo Mark II Tipo de Transacción Agregar Cliente Datos Entidades Input Referenciadas 53 Cliente Consultar Stock 2 Procesar Cabecera pedido Procesar item de orden 20 Cancelar orden 2 Reporte de Stock por tienda y producto Total 1 6 84 Total 1 Producto, local, Stock 3 Cliente, orden Despacho 3 Orden, despacho, stock item, producto, local 6 Cliente, orden, item, producto 4 Local, producto, stock 3 20 Datos Output 3 10 40 14 15 21 103 41 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Use Case Points Basada en especificaciones con casos de uso Unadjusted Actor Weight (UAW) = Actores * Peso Unadjusted Use Case Weight (UUCW) = Casos de Uso * Peso Unadjusted Use Case Points (UUCP) = UAW + UUCW Use Case Points (UCP) = UUCP*TCF*ECF TCF-Technical Complexity Factor ECF-Environmental Complexity Factor Estimación total (horas persona) = UCP * Factor de Productividad (Horas Persona por Punto de Caso de Uso) Factor de productividad típico: 20 Fuente: http://www.geocities.com/shiv_koirala/fp/usecasepoints.html 42 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Peso de los Casos de Uso Tipo de Caso de Uso Descripción Peso Simple Una interfaz de usuario simple que toca una única entidad de base de datos. Su escenario exitoso tiene 3 pasos o menos; su implementación implica menos de 5 clases 5 Promedio Más diseño de interfaz y toca 2 o más 10 entidades de base de datos. Su implementación implica 5 a 10 clases Complejo Interfaz de usuario compleja. Toca 3 o más entidades de base de datos. Tiene más de 7 pasos. Su implementación involucra más de 10 clases. 15 43 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Peso de los actores Tipo de Actor Descripción Peso Simple El actor representa otro sistema con una API definida 1 Promedio El actor representa otro sistema interactuando por un protocolo 2 Complejo El actor es una persona interactuando por una interfaz 3 44 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Factores técnicos Factor Descripción Peso T1 Distributed System 2 T2 Response time 1 T3 End user efficiency (online) 1 T4 Complex internal processing 1 T5 Code must be re-usable 1 T6 Easy to install 0,5 T7 Easy to use 0,5 T8 Portable 2 T9 Easy to change 1 T10 Concurrent 1 T11 Include special security features 1 T12 Provide direct access for third parties 1 T13 Special user training facilities are required 1 A cada ítem se le asigna un valor de entre 0 a 5 y se multiplica por el peso Technical Complexity Factors: TCF=0.6+ (0.01*TFactor) 45 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Factores Ambientales Factor Descripción Peso E1 Familiar with Rational Unified Process 1,5 E2 Application experience 0,5 E3 Object-oriented experience 1 E4 Lead analyst capability 0,5 E5 Motivation 1 E6 Stable requirements 2 E7 Part-time workers Difficult programming language -1 E8 -1 A cada ítem se le asigna un valor de entre 0 a 5 y se multiplica por el peso Environmental Complexity Factors: ECF= 1.4+ (-0.03 * EFactor) 46 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Métodos algorítmicos “caseros” Se pueden hacer variaciones sobre métodos existentes O nuevos métodos Con características similares Especializados para el dominio o la tecnología en particular Ejemplo: factores técnicos y ambientales “customizados” a una organización en particular 47 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Lo importante Hay varios métodos posibles, sencillos o complejos. No adoptar un método porque sí. Recopilar información sobre proyectos anteriores. Usar y adaptar los métodos a la organización. Seguir el Ciclo Dorado. Los métodos iterativos facilitan la traducción a duración de proyectos (“curva de staffing plana”) 48 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Work Breakdown Structures (WBS) En muchos casos, el primer paso del armado de un cronograma Segrega el proyecto o el producto en pedazos o partes más pequeñas y manejables, hasta el nivel en que será ejecutado el control. Método: Definir el propósito del WBS Identificar el nodo raíz (nombre del proyecto/producto) Dividir cada componente en subcomponentes (hasta 7 +/- 2 elementos) Continuar la división hasta que se cumpla con el objetivo (ej: poder estimar o asignar tareas) Desarrollar un diccionario 49 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Tipos de WBS – De Proceso WBS de proceso La raíz identifica el nombre del proyecto El segundo nivel identifica elementos mayores Planificación, organización, análisis de requerimientos, diseño, iteraciones, etc Partición de un proceso en subprocesos hasta obtener tareas individuales (1 o 2 personas) a desarrollar en poco tiempo (1 a 2 semanas) 50 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Tipos de WBS – De Producto WBS de producto Altamente relacionado con la arquitectura del producto. Identifica componentes e interfaces del producto Identifica hardware, software y datos La raíz identifica el nombre del producto Los otros elementos son ítems discretos e identificables de hardware, software y datos 51 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Tipos de WBS - Híbrida WBS híbrida Combina elementos de los dos tipos anteriores La raíz es un proceso, alternando elementos de proceso y producto La idea es que los procesos producen productos y los subproductos requieren procesos para su desarrollo Utilizado por managers que quieren priorizar la estimación y control precisos de cada elemento de producto 52 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 La determinación de dependencias Para poder optimizar la alocación de recursos y la paralelización de tareas es imprescindible conocer con precisión todas las dependencias entre tareas La fecha de comienzo de tareas debe ser dinámicamente establecida en función de sus dependencias Las dependencias pueden ser no sólo de “fin a comienzo” y no sólo entre tareas globales (todas las combinaciones entre fin y comienzo de la tarea predecesora y sucesora son posibles) Se identifican tareas del tipo “hitos” (duración 0), con entregables asociados 54 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 La determinación de dependencias (cont.) Se deben considerar e incluir puntos de revisión y ajuste (que suelen generar ciclos de tareas) p.ej.: la ejecución del testing implica ajustes en la codificación. Es esencial considerar no sólo dependencias entre tareas internas al proyecto sino también dependencias con otros proyectos. Para ello, considerar: no sólo proyectos técnicos sino también de negocios no sólo proyectos “propios” sino también proyectos existentes en la organización con impacto en el propio. Al final se agregan dependencias por contención de recursos 55 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Identificación del Camino Crítico El camino crítico es la secuencia de tareas cuyo atraso provoca atrasos en el fin del proyecto Las herramientas las calculan automáticamente Las tareas no críticas tienen un margen (“slack”) más allá del cual se convierten en críticas Por lógica: El mayor esfuerzo en la estimación debe ser puesto sobre las tareas críticas Un análisis del plan para comprimir cronogramas debe comenzar por las tareas críticas Hay 4 tipos de precedencias El “lag” es una duración que afecta la dependencia Ejemplo, la tarea B puede empezar 3 días después de que termine la tarea A A (F,C Lag 3d) B 56 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Diagrama de red tipo PERT o CPM A D H J 1 1 day 4 4 days 8 Mon 8/3/98 Mon 8/3/98 Tue 8/4/98 Fri 8/7/98 Wed 8/12/98 Wed 8/19/98 6 days 10 3 days Thu 8/20/98 Mon 8/24/98 E 5 5 days Wed 8/5/98 Tue 8/11/98 B 2 2 days Mon 8/3/98 Tue 8/4/98 F C 6 4 days Wed 8/5/98 Mon 8/10/98 G I 3 3 days 7 6 days 9 2 days Mon 8/3/98 Wed 8/5/98 Thu 8/6/98 Thu 8/13/98 Fri 8/14/98 Mon 8/17/98 57 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Cronograma o Gráfico de Gantt Gráficos de barras desarrollados por Henry Gantt a principios del siglo XX. Técnica hoy ampliamente usada Muestra tareas con responsables, fechas, secuencia de ejecución y costos directos Sirve fundamentalmente como referencia para la ejecución y control del proyecto. Para presentaciones se suelen usar sólo diagramas de hitos o de componentes de alto nivel, sin incluir la descripción detallada de actividades 58 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Ejemplo de Gráfico GANTT 59 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Otros conceptos Línea de base: versión estable del plan que se usará como base para el seguimiento Programación por valor acumulado: definición de pesos a los entregables de los hitos, para medir avance (no esfuerzo) 60 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 El plan de gestión del proyecto Documento consistente y coherente para guiar la ejecución y el control del proyecto, creado por el Gerente del proyecto sobre la base de la documentación que aportan los miembros del equipo y otros interesados en el proyecto Se usa comúnmente el estándar de la IEEE. Hay otros estándares (por ejemplo RUP) Un cronograma no es un plan! 61 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 Organización de grupos de programación Grupo del programador jefe de Mills Grupo del programador “cirujano” de Brooks Grupo jerárquico Grupo estilo MSF de Microsoft, sin jerarquía, con separación clara de roles Grupos tipo Scrum – Auto-organizados, sin roles 62 © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008 El entregable “Plan de Proyecto” (estándar IEEE 1058-1998) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Overview (Clause 1 of the SPMP) 1. Project summary (Subclause 1.1 of the SPMP) 2. Evolution of the SPMP (Subclause 1.2 of the SPMP) References (Clause 2 of the SPMP) Definitions (Clause 3 of the SPMP) Project organization (Clause 4 of the SPMP) 1. External interfaces (Subclause 4.1 of the SPMP) 2. Internal structure (Subclause 4.2 of the SPMP) 3. Roles and responsibilities (Subclause 4.3 of the SPMP) Managerial process plans (Clause 5 of the SPMP) 1. Project start-up plan (Subclause 5.1 of the SPMP) 2. Work plan (Subclause 5.2 of the SPMP) 3. Control plan (Subclause 5.3 of the SPMP) 4. Risk management plan (Subclause 5.4 of the SPMP) 5. Project closeout plan (Subclause 5.5 of the SPMP) Technical process plans (Clause 6 of the SPMP) 1. Process model (Subclause 6.1 of the SPMP) 2. Methods, tools, and techniques (Subclause 6.2 of the SPMP) 3. Infrastructure plan (Subclause 6.3 of the SPMP) 4. Product acceptance plan (Subclause 6.4 of the SPMP) Supporting process plans (Clause 7 of the SPMP) 1. Configuration management plan (Subclause 7.1 of the SPMP) 2. Verification and validation plan (Subclause 7.2 of the SPMP) 3. Documentation plan (Subclause 7.3 of the SPMP) 4. Quality assurance plan (Subclause 7.4 of the SPMP) 5. Reviews and audits plan (Subclause 7.5 of the SPMP) 6. Problem resolution plan (Subclause 7.6 of the SPMP) 7. Subcontractor management plans (Subclause 7.7 of the SPMP) 8. Process improvement plan (Subclause 7.8 of the SPMP) Additional plans (Clause 8 ofthe SPMP) Plan annexes Plan index © Cátedra de Ingeniería de Software II – FCEN – UBA, 2008
