Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 2: Planificación de Proyectos de Software Buenos Aires, 27 de Marzo de 2008

2 Temas para hoy Repaso de la clase anterior: modelos de ciclo de vida Consideraciones generales sobre la administración de proyectos Identificación inicial de requerimientos y drivers del proyecto Introducción a las estimaciones en proyectos de software Planificación de tareas Diagramas GANTT y PERT Contenido de un plan de proyecto 2

3 Funciones del Gerenciamiento Gerenciamiento Planificar Staffing Controlar Organizar Liderar Qué es planificar? Predeterminar un curso de acción para cumplir objetivos 3

4 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 Algunos stakeholders clave Sponsor Líder usuario (Product Champion) Usuarios directos e indirectos 4

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

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

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

8 Estimaciones Cuándo se sabe exactamente qué tamaño tendrá, cuanto tardaremos y cuanto costará el software? 4x Precisión de la estimación 0.25x Fases del Ciclo de Vida Precisión de la Estimación del Costo del Software vs. Fase del Ciclo de Vida Software Estimating Technology: A Survey, de Richard D. Stutzke. El día en que termina el proyecto... (en el mejor caso) 8

9 Por qué fallan las estimaciones? Optimismo Poco conocimiento de la tecnología / el dominio Poca seriedad en la estimación No hay mediciones previas de proyectos Confusión entre progreso y esfuerzo Falta de seguimiento de proyectos Novedad Se agrega gente Falta de administración de requerimientos Cuidado con la Ley de Parkinson! ( 9

10 El Ciclo Dorado de las estimaciones Estimo Calibro Mido Analizo Registro Comparo 10

11 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. Tamaño Esfuerzo Cronograma Costo 11

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

13 Métodos de Estimación Basados en la experiencia de las personas Ojo experimentado Ojo con ajustes La técnica del ancho de banda de Delphi Un poco más sofisticados Puntos de Función y sus variantes (MARK II) Object Points Use Case Points Métodos caseros 13

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

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

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

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

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

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

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

21 Diagrama de red tipo PERT o CPM A D H J 1 1 day Mon 8/3/98 Mon 8/3/ days Tue 8/4/98 Fri 8/7/ days Wed 8/12/98 Wed 8/19/ days Thu 8/20/98 Mon 8/24/98 E 5 5 days B Wed 8/5/98 Tue 8/11/ days Mon 8/3/98 Tue 8/4/98 F 6 4 days Wed 8/5/98 Mon 8/10/98 C G I 3 3 days Mon 8/3/98 Wed 8/5/ days Thu 8/6/98 Thu 8/13/ days Fri 8/14/98 Mon 8/17/98 23

22 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, sin incluir la descripción detallada de actividades 24

23 Ejemplo de Gráfico GANTT 25

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

25 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! 27

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

27 El entregable Plan de Proyecto (estándar IEEE )