INTRODUCCIÓN A LA PLANEACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE.

Presentación del tema: "INTRODUCCIÓN A LA PLANEACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE."— Transcripción de la presentación:

1 INTRODUCCIÓN A LA PLANEACIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE

2 DEFINICIÓN DEL ÁMBITO DEL SOFTWARE Definición del ámbito Es la definición del ámbito del software a través de la creación de un enunciado de ámbito del proyecto En la definición del ámbito se consideran los entregables, los supuestos, y restricciones documentadas al inicio del proyecto

3 HERRAMIENTAS Y TÉCNICAS PARA LA DEFINICIÓN DE ÁMBITO DEL SOFTWARE Análisis del producto El proceso de proyectar el producto final a partir de los objetivos del proyecto Identificación de alternativas El proceso de crear diferentes planes para alcanzar las metas del proyecto Juicio experto Expertos en distintas áreas contribuyen con sus conocimientos en la definición del ámbito Análisis de los participantes Ayudan a organizar y priorizar las necesidades y objetivos de los participantes

4 ANÁLISIS DEL PRODUCTO Es una evaluación del producto final del proyecto y qué tomará para crearlo Técnicas Análisis de funciones Analiza todas las cosas que el producto hacer, incluyendo funciones primarias y relacionadas para identificar funciones innecesarias que pudieran incrementar los costos del producto Análisis de valor o ingeniería de valor Identifica y desarrolla la relación entre costos y bieneficios de cada función del producto. Es un método para controlar los costos mientras se conserva el desempeño y los estándares de calidad

5 ANÁLISIS DEL PRODUCTO Técnicas Despliegue de función de calidad Identifica qué necesidades tiene el cliente y las traslada a requerimientos técnicos. Se utiliza en todas las fases de desarrollo. Ingeniería de sistemas Analiza el producto holísticamente, integrando factores como usuarios, ambiente de operación, y el software y hardware con el cual el producto debe funcionar

6 IDENTIFICACIÓN DE ALTERNATIVAS Definición Es el acto de generar diferentes planes para lograr las metas del proyecto Técnicas Pensamiento lateral Enfoque creativo para la solución de problemas en el cual el equipo trata de pensar en el problema en nuevas formas para generar soluciones innovadoras Lluvia de ideas Técnica general creativa para generar posibles alternativas. La meta es generar tantas ideas como sea posible de todos los miembros del equipo Técnica Delphi Técnica de grupo que extrae y resume anónimamente las entradas del grupo para escoger entre varias alternativas. Usada para consensuar estimados

7 OBJETIVOS DEL PROYECTO Definición Es el criterio usado para medir cuando un proyecto es exitoso o no. Los objetivos deben ser: Específicos en términos de ámbito Cuantificables en términos de tiempo, costo y calidad Realistas y alcanzables Consistentes con los planes, políticas y procedimientos de la organización Ejemplo Desarrollar un juego matemático interactivo para dispositivos móviles dirigido a niños de tres a seis años que incluya cuatro niveles de instrucción, práctica y evaluación en las habilidades matemáticas básicas, basado en el estándar nacional de matemáticas para el 1 de junio de 2008, por menos de $100 000.00 pesos. Un proyecto puede tener uno o más objetivos. Se pueden agregar objetivos secundarios para clarificar las metas del proyecto

8 CREACIÓN DEL ENUNCIADO DE ÁMBITO Guías para la definición del ámbito Refinar los objetivos del proyecto, entregables, descripción del alcance del producto del documento de visión Reexaminar los requerimientos del proyecto ¿deben priorizarse según el análisis de los participantes? Revise los límites del proyecto ¿qué expectativas tienen los participantes? Actualice las restricciones, riesgos y supuestos del proyecto. Crear hitos del calendario para que el cliente y el equipo tengan fechas para establecer metas y medir el progreso Incluir una revisión general de los estimados de costo y defina cualquier limitación en los costos Identifique y documente riesgos conocidos Proyecte la organización interna de personal en el proyecto Documente las especificaciones del proyecto y los requerimientos de aprobación Finalice el procedimiento para la aceptación de productos completos

9 DESARROLLO DE LA WORK BREAKDOWN STRUCTURE (WBS Estructura de trabajo detallada, estructura de descomposición de trabajo, estructura de desglose de trabajo Después de refinar los objetivos y principales entregables éstos últimos se pueden descomponer en piezas más pequeñas y manejables La creación efectiva del WBS ayuda a mejorar la precisión de los estimados de tiempo, costo y recursos y provee una línea base para las mediciones de desempeño y control del proyecto WBS Es un agrupamiento lógico de los entregables del proyecto organizados en una estructura jerárquica El WBS define el ámbito completo del trabajo requerido para completar el proyecto El trabajo que no está en el WBS está fuera del alcance del proyecto

10 WBS En la WBS, los principales componentes pueden agruparse por Principales entregables del proyecto Fases del ciclo de vida Responsabilidad organizacional o funcional Localización geográfica Enfoque abajo-arriba para validar un WBS Es una manera fácil de validar, siempre y cuando Se especifiquen los componentes necesarios y suficientes de niveles inferiores para completar cada elemento descompuesto Cada elemento se describe como entregable (nombre) y se distingue de todos los demás Cada elemento puede ser adecuadamente presupuestado, calendarizado y asignado a un individuo o grupo

11 WBS Generalmente se presenta en forma de organigrama Cada elemento debe tener un nombre breve y claro que describa el concepto Se recomienda que tenga de 3 a 5 niveles Se sugiere numerar las partes Contiene mayor nivel de detalle conforme se avanza en la ejecución de los ciclos del proyecto Se recomienda que la duración de una actividad sea menor a 80 horas

12 HERRAMIENTAS Y TÉCNICAS Plantillas del WBS Utilice un WBS existente de un proyecto anterior o estandarice un nuevo para los futuros proyectos Descomposición Descomponga el producto final separando los entregables y su trabajo requerido en paquetes de trabajo específico Código de cuentas Es un sistema mediante el cual los elementos del WBS se numeran de forma única. Facilita el seguimiento, principalmente del desempeño y de costos

13 DIAGRAMA DEL WBS

14 PROCEDIMIENTO PARA GENERAR UN WBS Obtener el material de referencia Determinar la forma de organizar el trabajo Identificar los principales entregables o subproyectos. Analice cada elemento para determinar cuando está suficientemente dividido ¿Puede cualquier entregable ser adecuadamente calendarizado, presupuestado y asignado a un individuo o grupo? Respuesta afirmativa se logró el nivel de paquete de trabajo Descomponer cada elemento del WBS hasta alcanzar el nivel de paquete de trabajo Validar el WBS usando un enfoque de arriba abajo Usando el código de cuentas, asigne un identificador numérico para el seguimiento e informes de desempeño y costo

15 EJEMPLO DE WBS

16 ESTIMACIÓN PARA PROYECTOS DE SOFTWARE McConnell presenta la siguiente visión del mundo real de la planificación del proyecto: “Muchos trabajadores técnicos preferirán realizar el trabajo técnico en lugar de pasar el tiempo en la planificación. Muchos gestores técnicos no tienen suficiente entrenamiento en la gestión técnica para sentirse seguros de que su planificación mejorará el resultado de un proyecto. Puesto que ninguna parte quiere hacer la planificación, con frecuencia no se realiza” El proyecto promedio gasta 80 por ciento de su tiempo en reelaboración (corrigiendo errores)

17 FASES DE LA PLANEACIÓN Consta de cinco grandes fases: Estimación Programa de trabajo Análisis de riesgos Planificación de la gestión del cambio Estimación Intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto específico basado en software

18 OBSERVACIONES ACERCA DE LA ESTIMACIÓN Existen técnicas para realizar estimaciones de tiempo y esfuerzo Las métricas del proceso y del proyecto ofrecen la perspectiva histórica La experiencia de la gente involucrada puede auxiliar conforme se desarrollan y revisan las estimaciones La estimación coloca la base para las demás tareas de la planificación

19 PROCESO DE PLANIFICACIÓN DEL PROYECTO Proporciona un marco de trabajo que permite al gestor estimar razonablemente recursos, costo y programa de trabajo. Las estimaciones deben intentar definir El escenario del mejor caso El escenario del peor caso El plan tiene un grado inherente de incertidumbre Se puede adaptar y actualizar conforme avance el proyecto

20 ÁMBITO DEL SOFTWARE Y FACTIBILIDAD Ámbito del software Describe las funciones y características que se entregarán a los usuarios finales Los datos que son entrada y salida El contenido que se presenta a los usuarios como consecuencia de usar el software El desempeño, las restricciones y la confiabilidad

21 ÁMBITO DEL SOFTWARE Y FACTIBILIDAD Técnicas para definir el ámbito del software Después de la comunicación con todos los participantes se desarrolla una descripción narrativa del ámbito del software Los usuarios finales desarrollan un conjunto de casos de uso Se evalúa el enunciado de ámbito o se refinan los casos de uso para proporcionar más detalles antes de comenzar la estimación Consideraciones de Desempeño: Requisitos de procesamiento y tiempo de respuesta Restricciones: limitaciones impuestas por el hardware, la memoria disponible u otros sistemas existentes

22 ÁMBITO DEL SOFTWARE Y FACTIBILIDAD Determinar la factibilidad ¿Es posible construir el software para satisfacer este ámbito? ¿El proyecto es factible? En muchas ocasiones no se presta atención a estas cuestiones y se embarcan en un proyecto condenado al fracaso Dimensiones de la factibilidad Tecnología, Finanzas, Tiempo y Recursos

23 ÁMBITO DEL SOFTWARE Y FACTIBILIDAD Dimensiones de la factibilidad Tecnología ¿El proyecto es técnicamente factible? ¿Está dentro del terreno de la disciplina? ¿Los defectos se pueden reducir a tal grado que se emparejen con las necesidades de la aplicación? Finanzas ¿Es financieramente factible? ¿Se puede completar el desarrollo a un costo que la organización de software, su cliente o el mercado puedan enfrentar? Tiempo ¿El proyecto legará al mercado antes y vencerá a la competencia? Recursos ¿La organización tiene los recursos necesarios para triunfar?

24 RECURSOS La segunda tarea de la planificación es la estimación de recursos necesarios para completar el esfuerzo de desarrollo de software Tipos de recursos Personal Número, habilidades, ubicación Entorno Herramientas de software, de hardware y de red Software reutilizable Cada recurso se especifica con 4 características Descripción del recurso, informe de disponibilidad, cuándo se requerirá y por cuánto tiempo (ventana de tiempo)

25 RECURSOS Recursos humanos Se evalúa el ámbito Se determinan las habilidades requeridas para completar el desarrollo Se especifica la posición organizacional (gestor, ingeniero de software ejecutivo, diseñador) y la especialidad (telecomunicaciones, base de datos, java) En proyectos relativamente pequeños (pocas personas-mes) un solo individuo puede realizar todas las tareas de ingeniería de software y consultar con especialistas conforme se requiera En equipos mayores, el recurso humano puede estar geográficamente distribuido. Aquí se especifica la ubicación de cada recurso El número de personas se determina después de hacer la estimación de esfuerzo de desarrollo (persona-mes)

26 RECURSOS Recursos de software reutilizables La ingeniería de software basada en componentes enfatiza la reutilización Creación y reutilización de componentes que deben catalogarse para consultarlos con facilidad, estandarizarse y validarse Componentes ya desarrollados El software se puede adquirir de un tercero o se desarrolló en un proyecto previo. Los Componentes comerciales ya desarrollados están listos para utilizarse y han sido ampliamente validados Componentes experimentados Especificaciones, diseños, código o datos de prueba existentes que se desarrollaron para proyectos previos son similares al software que se construirá en el proyecto actual. El personal ya tiene la experiencia y los cambios serán de bajo riesgo Componentes de experiencia parcial Artefactos desarrollados en proyectos previos pero que requieren de modificaciones sustanciales para utilizarse. Los miembros del equipo tienen experiencia limitada en el área de aplicación Componentes nuevos El equipo de software debe construir los componentes de software específicamente para las necesidades del proyecto actua

27 RECURSOS DEL ENTORNO Entorno de la ingeniería del software incorpora hardware y software El administrador del proyecto debe prescribir la ventana de tiempo requerida por el hardware y el software y verificar que estos recursos estarán disponibles Cuando se requiere hardware especial el planificador del proyecto debe especificar cada elemento de hardware

28 ESTIMACIÓN DE PROYECTOS DE SOFTWARE La estimación del costo y esfuerzo nunca será una ciencia exacta Están involucradas demasiadas variables: humanas, técnicas, ambientales, políticas que pueden afectar el costo final del proyecto y el esfuerzo aplicado a desarrollarlo Para lograr estimaciones confiables de costo y esfuerzo Demorar la estimación hasta más tarde en el proyecto No es práctica Basar las estimaciones en proyectos similares La experiencia no ha sido un buen indicador de resultados futuros Emplear técnicas de descomposición para generar estimaciones Utilizan enfoque divide y vencerás, dependen de la base de datos histórica Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo

29 TÉCNICAS DE DESCOMPOSICIÓN En muchas ocasiones el problema que debe resolverse es muy complejo como para considerarlo una sola pieza Se descompone en partes más manejables empleando un enfoque de descomposición del problema o del proceso A partir del ámbito realizar una estimación del tamaño

30 TAMAÑO DEL SOFTWARE Factores de manifestación de la estimación El grado con el cual se ha estimado correctamente el tamaño del producto que se construirá La habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero El grado en el cual el plan del proyecto refleja las habilidades del equipo de software La estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería del software

31 Es el primer desafío La definición del tamaño determina el proceso de estimación Tamaño se refiere a un resultado cuantificable del proyecto de software Enfoque directo (líneas de código) Enfoque indirecto (puntos de función)

32 Enfoques al problema de determinación del tamaño Tamaño de lógica difusa Identificar el tipo de aplicación, establecer su magnitud en una escala cualitativa y luego refinar la magnitud dentro del rango original Tamaño de punto de función Realiza estimaciones de las características del dominio de la información Tamaño de componentes estándar El software está formado por componente estándar, los cuales son diferentes y genéricos de un área particular de la aplicación (módulos, pantallas, reportes, archivos, etc). Se estima el número de ocurrencias de cada componente estándar y luego aplica datos de proyectos históricos para determinar el tamaño de la entrega Tamaño del cambio Estima el número y tipo de las modificaciones que deberán realizarse

33 ESTIMACIÓN BASADA EN EL PROBLEMA Las líneas de código y los puntos de función se utilizan como medidas básicas sobre las cuales se calculan métricas de productividad El administrador del proyecto utiliza estas estimaciones a partir de la descomposición del problema Calcula LOC y FP para cada subproblema Aplica métricas de la línea base de productividad LOC/pm o FP/pm (pm: persona-mes) Deriva el costo o esfuerzo de la función Combina las estimaciones obtenidas para obtener la estimación global del proyecto Para que sea utilizable esta estimación los datos históricos de los proyectos deben agruparse por tamaño de equipo, área de aplicación, complejidad y otros parámetros.

34 Un nuevo proyecto debe ubicarse en un dominio y luego aplicar los promedios de la base de datos de línea base para generar la estimación Para cada una de las funciones o dominio de información el administrador debe Estimar el valor optimista, más probable y pesimista Calcular el valor esperado Promedio ponderado S=(S opt + 4S m + S pes ) / 6 Supuesto Existe una probabilidad muy pequeña que el tamaño real resultante se ubique fuera de los valores optimista y pesimista Contrastar la estimación con otro enfoque

35 EJEMPLO ESTIMACIÓN BASADA EN LOC Proyecto CAD para componentes mecánicos FunciónLOC Estimadas Facilidades de interfaz del usuario y control (FIUC) Análisis geométrico bidimensional (AG2D) Análisis geométrico tridimensional (AG3D) Gestión de base de datos (GBD) Facilidades de presentación gráfica de computadora (FPGC) Función de control de periféricos (FCP) Módulos de análisis de diseño (MAD) 2 300 5 300 6 800 3 350 4 950 2 100 8 400

36 EJEMPLO La revisión de datos históricos indica que Promedio organizacional de productividad para sistemas de este tipo 620 LOC/pm Tarifa laboral es de $ 8 000.00 pesos por persona-mes Tarifa de la línea de código $13.00 pesos Calcular el costo y esfuerzo del nuevo proyecto Costo total estimado = costo de una LOC * tamaño del proyecto en LOC Costo total estimado = 13.00 * 33 200 = 431 600 Costo total estimado $ 432 000.00 Esfuerzo requerido Esfuerzo estimado requerido = tamaño del proyecto / promedio de esfuerzo Esfuerzo requerido = 33 200 / 620 = 53.54 Esfuerzo requerido = 54 personas-mes

37 PUNTOS DE FUNCIÓN Se utiliza como medio para mediar la funcionalidad que entrega un sistema Emplea datos históricos para Estimar el costo y esfuerzo requerido para diseñar, codificar y probar el software Predecir el número de errores que se encontrarán durante la prueba Pronosticar el número de componentes o líneas de código proyectadas en el sistema implementado Los puntos de función se derivan empleando una relación basada en medidas contables (directas) del dominio de la información del software Considera cinco dominios de la información

38 PUNTOS DE FUNCIÓN Número de entradas externas (EE) Cada EE se origina en un usuario o es trasmitida desde otra aplicación y proporciona distintos datos orientados a la aplicación o información de control Número de salidas externas (SE) Cada SE se deriva del interior de la aplicación y proporciona información al usuario. Se cuenta cada informe, pantalla, mensaje de error. No se cuentan los elementos individuales de cada artefacto Número de consultas externas (CE) Se define como la entrada en línea que lleva a la generación de alguna respuesta inmediata por parte del software, en la forma de salida en línea ( a menudo recuperada de un ALI) Número de archivos lógicos internos (ALI) Cada ALI es un agrupamiento lógico de datos que reside dentro de los límites de la aplicación y que se mantiene mediante entradas externas Número de archivos de interfaz externa (AIE) Cada AIE es un agrupamiento lógico de datos externo a la aplicación pero que proporciona datos que podrían usarse en ésta

39 PUNTOS DE FUNCIÓN Factores de ajuste de valor de puntos de función 1. ¿El sistema requiere respaldo y recuperación confiables? 2. ¿Se requieren comunicaciones de datos especializadas para transferir información a la aplicación, u obtenerla de ella? 3. ¿Hay funciones distribuidas de procesamiento? 4. ¿El desempeño es crítico? 5. ¿El sistema se ejecutará en un entorno existente que tiene un uso pesado de operaciones? 6. ¿El sistema requiere entrada de datos en línea? 7. ¿La entrada de datos en línea requiere que la transacción de entrada se construya en varias pantallas u operaciones? 8. ¿Los ALI se actualizan en línea? 9. ¿ Las entradas, las salidas, los archivos o las consultas son complejos? 10. ¿Es complejo el procesamiento interno? 11. ¿El código diseñado será reutilizable? 12. ¿Se incluyen la conversión e instalación el diseño? 13. ¿Está diseñado el sistema para instalaciones múltiples en diferentes organizaciones? 14. ¿La aplicación está diseñada para facilitar el cambio y para que el usuario lo use fácilmente? Cada pregunta se responde empleando una escala que va de 0 (no importante o aplicable) a 5 (absolutamente esencial)

40 EJEMPLO HOGAR SEGURO

41 EJEMPLO SISTEMA HOGAR SEGURO

42 Determinar el costo y esfuerzo Productividad organizacional promedio 10 PF/pm Salario por persona: $8 000.00 pesos Costo por PF = 800.00 Costo total estimado del proyecto Costo total = 56 * 800.00 = 44 800.00 Esfuerzo estimado requerido Esfuerzo estimado = 56 /10 = 5.6 Esfuerzo estimado: 6 persona-mes

43 LA DECISIÓN DESARROLLAR-COMPRAR Decisiones que debe tomar un administrador al inicio de un proyecto Se puede adquirir la licencia de un producto ya desarrollado Se pueden comprar componentes y luego modificarse para satisfacer las necesidades específicas El software se puede construir por medio de un contratista externo Aspectos por considerar La importancia del software para el logro de los objetivos organizacionales Costo final

44 LA DECISIÓN DESARROLLAR-COMPRAR Aspectos por considerar ¿El producto de software estará disponible antes que el software desarrollado de manera interna? ¿El costo de adquisición más el costo de personalización será menor que el costo de desarrollar el software de manera interna? ¿El costo de soporte externo será menor que el costo del soporte interno? Estas condiciones se aplican a cada una de las opciones por desarrollar Se usa la técnica de árbol de decisión Otros aspectos Disponibilidad, experiencia del desarrollador-vendedor- contratista, concordancia con los requisitos, políticas locales, y probabilidad de cambiar

45 CALENDARIZACIÓN DE PROYECTOS DE SOFTWARE Causas de la entrega con retrasos en los proyectos de software Fecha límite irrealizable impuesta al grupo de ingeniería de software Cambios en los requisitos que no se reflejan en la planeación Subestimación del esfuerzo o recursos Riesgos que no se consideraron Dificultades técnicas Falta de comunicación Falla en la gestión del proyecto (supervisión y dirección

46 MANEJO DE FECHAS IMPOSIBLES Realizar una estimación detallada utilizando datos históricos Esfuerzo y duración estimados para el proyecto Aplicar un modelo de proceso incremental Entregar en la fecha impuesta la funcionalidad crítica y demorar la restante Reunirse con el cliente y explicarle por qué la fecha es inalcanzable Ofrezca estrategia de desarrollo incremental Presente alternativas: ventajas y desventajas

47 CALENDARIZACIÓN DEL PROYECTO ¿Cómo se retrasan los proyectos de software? ¡Un día a la vez!

48 CALENDARIZACIÓN DEL PROYECTO El objetivo del gestor Definir todas las tareas del proyecto Construir una red de tareas que bosqueje las interdependencias Identificar las tareas cruciales dentro de la red Seguir el progreso Calendarización del proyecto de software Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas específicas de ingeniería de software

49 CALENDARIZACIÓN DE PROYECTOS Principios que guían la calendarización Desglose El proyecto debe dividirse en compartimentos en varias actividades, acciones y tareas manejables Interdependencia Determinar la interdependencia de cada actividad Asignación del tiempo A cada tarea se le debe asignar cierto número de unidades de trabajo (pm). Asignar fecha de inicio y fin Validación del esfuerzo Asegurarse que el esfuerzo planeado sea consistente con el personal asignado al proyecto Definición de responsabilidades Toda tarea calendarizada debe estar asignada a un miembro específico del equipo Definición de resultados Toda tarea debe tener un resultado definido (artefacto o parte de él) Definición de hitos Cualquier tarea o grupo de tareas debe estar asociado a un hito. Un hito se logra cuando se ha revisado la calidad de uno o más productos de trabajo y se han aprobado

50 Distribución del esfuerzo Recomendación Regla 40-20-40 Análisis y diseño: 40% Codificación: 20% Pruebas: 40% Consideraciones Planeación del proyecto: 2 – 3 % Análisis de requisitos: 10 – 25 % Diseño de software: 20 – 25 % Considerar el tiempo utilizado en la revisión del diseño y la subsiguiente iteración Codificación: 15 – 20 % Pruebas y depuración: 30 – 40 % El carácter crucial del software dicta la cantidad de pruebas que se requieren

51 TIPOS DE PROYECTOS El conjunto de tareas varía de acuerdo al tipo de proyecto: Desarrollo de conceptos Exploran algunas aplicaciones o conceptos de negocios de alguna nueva tecnología Desarrollo de nuevas aplicaciones Se llevan a cabo a petición del cliente Mantenimiento de aplicación Corrigen, adaptan o extienden el software existente Reingeniería Reconstruir un sistema existente (heredado)

52 FACTORES A CONSIDERAR AL ESTABLECER LAS TAREAS DEL PROYECTO Tamaño del proyecto Número de usuarios potenciales Crucial de la misión Duración de la aplicación Estabilidad de los requisitos Facilidad de comunicación con el usuario Madurez de la tecnología Restricciones de desempeño Características (anidadas y no anidadas) Equipo del proyecto Factores de reingeniería

53 PROYECTO DE DESARROLLO DE CONCEPTO Actividades Determinación del ámbito del concepto Planeación preliminar del concepto Valoración del riesgo de la tecnología Prueba del concepto Implementación del concepto Reacción del cliente

54 PROYECTO DE DESARROLLO DE CONCEPTO Determinación del ámbito del concepto: Identificar necesidades, beneficios y clientes potenciales Definir eventos de salida/control y entradas deseados: RTF: Revisar descripción escrita de la necesidad Derivar una lista de salidas/entradas visibles al cliente RTF: Revisar salidas/entradas con el cliente y modificar en caso necesario Definir la funcionalidad/comportamiento para cada función principal RTF: Revisar entradas/salidas de la tarea 1.2. Derivar un modelo de funciones/comportamientos RTF: Revisar funciones/comportamiento con el cliente y modificar Aislar aquellos elementos de la tecnología que se implementarán en software Disponibilidad de investigación del software existente Definir factibilidad técnica Realizar estimación rápida del tamaño Crear una definición de ámbito

55 DEFINICIÓN DE UNA RED DE TAREAS Una red de tareas o red de actividad Es una representación gráfica del flujo de tareas en un proyecto Muestra la secuencia y dependencias de tareas Las tareas se pueden realizar de forma concurrente Ruta crítica Tareas que deben completarse en la calendarización si el proyecto como un todo se debe completar a tiempo

56 RED DE TAREAS

57 Ruta crítica: 1 – 2 – 3 – 4 – 8 – 9 Duración del proyecto: 27 horas Tiempo total del proyecto: 34 horas Duración del proyecto: 1.5 + 2 + 2 + 2.5 + 5+ 0.5 = 13.5 días

58 CALENDARIZACIÓN Se utilizan La técnica de evaluación y revisión de programa (PERT) El método de ruta crítica (CPM) Entradas Estimación del esfuerzo Descomposición de la función del producto Selección del modelo de proceso y conjunto de tareas apropiado Descomposición de las tareas Ofrecen herramientas cuantitativas para Determinar la trayectoria crítica Establecer estimaciones de tiempo aplicando modelos estadísticas Calculan los tiempos límite que definen una ventana de tiempo para una tarea particular

59 CRONOGRAMAS A partir del conjunto de tareas (estructura de análisis del trabajo) se introduce Esfuerzo, duración, fecha de inicio de cada tarea Asignación de responsable Esta información se representa en el cronograma o gráfica de Gantt Las herramientas permiten la creación de cronogramas y generan la tabla de recursos del proyecto Lista de todas las tareas del proyecto, fechas de inicio y conclusión (planeadas y reales) y recursos asignados

60 SEGUIMIENTO DE LA CALENDARIZACIÓN A partir del plan, con tareas e hitos bien definidos se puede controlar el proyecto Reuniones periódicas para valorar el estado del proyecto Evaluación de los resultados de todas las revisiones realizadas en el proyecto Determinación del logro de los hitos formales Comparación de la fecha de inicio real con la fecha de inicio prevista Reunirse de manera informal con el equipo para obtener su evaluación subjetiva del progreso y de problemas que se vislumbran Con el uso del análisis del valor ganado para evaluar el progreso cuantitativamente

61 ANÁLISIS DEL VALOR GANADO Es una medida del progreso del proyecto Permite valorar el porcentaje realizado de un proyecto utilizando un enfoque cuantitativo Procedimiento Determinar el valor planeado de las actividades del periodo a evaluar Determinar el valor ganado de las actividades realizadas Determinar el valor real de las actividades realizadas en el periodo

62 GRÁFICA DE GANTT

63 VALOR GANADO

64

65 SEGUIMIENTO DEL COSTO

66 CONTROL DEL PROYECTO Objetivo Lograr un producto de calidad dentro de las restricciones acordadas con el cliente Si la evaluación indica que todo va bien ¨Evaluar los riesgos para el siguiente periodo y tomar las acciones correctivas necesarias Si la evaluación indica que existe retraso en el proyecto ¨Valorar el cambio de estrategia de trabajo (time- boxing) ¨Evaluar la posibilidad de cambiar la fecha de entrega o el número de funciones a entregar