Ingeniería de Software. Unidad 2 Administración de Proyectos de Software

Transcripción

1 Ingeniería de Software Unidad 2 Administración de Proyectos de Software

2 Contenido Esquema del plan de administración del proyecto Técnicas de planificación Diagramas de GANTT Redes de precedencia (PERT) Métricas del proyecto Mediciones del software Métricas orientadas al tamaño (LDC) Métricas orientadas a la función Modelo de estimación de costos (COCOMO) Seguimiento y supervisión del proyecto Gestión de riesgos.

3 Esquema del plan de administración del proyecto Existen varias maneras de elaborar un plan de administración, sin embargo una de las mejores es el estándar IEEE 1058 [Schach, 2004]. El estándar refleja la experiencia de la industria y las universidades. Se diseño como marco de trabajo para usarlo con todo tipo de sistemas de información, sin importar el ciclo de vida o metodología. En el caso de sistemas pequeños algunas secciones no son relevantes. 1. Descripción general 1.1 Resumen del proyecto Propósito, alcance y objetivos Suposiciones y Restricciones Elementos del proyecto sujetos a entrega Calendario y resumen del presupuesto 1.2 Evolución del plan de administración del proyecto 2. Materiales de consulta 3. Definiciones y acrónimos 4. Organización del proyecto 4.1 Interfaces externas 4.2 Estructura interna 4.3 Funciones y responsabilidades 5. Planes del proceso administrativo 5.1 Plan inicial Plan de estimación Plan de contratación de personal Plan de adquisición de recursos Plan de capacitación para el personal del proyecto 5.2 Plan de trabajo Actividades de trabajo Asignación del calendario Asignación de recursos Asignación del presupuesto 5.3 Plan de control Plan de control de requisitos Plan de control del calendario Plan de control del presupuesto Plan de control de la calidad Plan de generación de informes Plan de recolección de mediciones 5.4 Plan de manejo de riesgos 5.5 Plan de cierre del proyecto 6. Planes del proceso técnico 6.1 Modelo del proceso 6.2 Métodos, herramientas y técnicas 6.3 Plan de infraestructura 6.4 Plan de aceptación del producto 7. Planes de procesos de soporte 7.1 Plan del control de la configuración 7.2 Plan de pruebas 7.3 Plan de documentación 7.4 Plan de aseguramiento de la calidad 7.5 Plan de revisiones y auditorias 7.6 Plan de resolución de problemas 7.7 Plan de control de los subcontratistas 7.8 Plan de mejora del proceso 8. Planes adicionales

4 Esquema del plan de administración del proyecto (2) 1.- Descripción general 1.1 Resumen del proyecto Propósito, alcance y objetivos. Se da una breve descripción del propósito y las posibilidades del sistema de información que se va a entregar, así como de los objetivos del proyecto Suposiciones y restricciones. Cualquier suposición subyacente al proyecto se define aquí, junto con restricciones como la fecha de entrega, el presupuesto, los recursos y artefactos que se van a utilizar Elementos del proyecto sujetos a entrega. Todos los elementos que se van a entregar al cliente se enlistan aquí, junto con las fechas correspondientes Calendario y resumen del presupuesto. El calendario general se presenta aquí, junto con el presupuesto. 1.2 Evolución del plan de administración del proyecto En esta sección se describen los procedimientos y mecanismos formales para cambiar el plan. 2.- Materiales de consulta Todos los documentos referidos en el plan de administración del proyecto se enlistan aquí. 3.- Definiciones y acrónimos Esta información asegura que todos comprendan el plan de administración del proyecto de la misma manera. 4.- Organización del proyecto 4.1 Interfaces externas Se deben establecer los mecanismos (quién, cuándo, dónde y propósito) de las reuniones entre el cliente y los miembros del proyecto. 4.2 Estructura interna En esta sección se describe la estructura de la empresa de desarrollo (grupo de desarrollo, de soporte, gerencial). 4.3 Funciones y responsabilidades. Para cada función del proyecto y para cada actividad debe identificarse al responsable individual.

5 Esquema del plan de administración del proyecto (3) 5.- Planes del proceso administrativo 5.1 Plan inicial Plan de estimación. Las técnicas utilizadas para estimar la duración y el costo del proyecto se enlistan aquí, así como la manera en que se rastrearán y, en caso de ser necesario, se modificarán mientras el proyecto está en proceso Plan de contratación de personal. Se enlista la cantidad y el tipo de personal requerido, junto con los periodos para los cuales se necesita Plan de capacitación para el personal del proyecto. Toda la capacitación necesaria para una finalización exitosa del proyecto se enlista en esta subsección. 5.2 Plan de trabajo Actividades de trabajo. Se especifican todas las actividades de trabajo, hasta el nivel de tarea en caso de ser necesario Asignación del calendario. En general, existe una relación cercana entre los paquetes de trabajo y la dependencia de eventos externos (análisis primero, después diseño, ). Aquí se especifican las dependencias relevantes Asignación de recursos. Los diversos recursos enlistados antes se asignan a las funciones, actividades y tareas propias del proyecto Asignación del presupuesto. Esta subsección se divide el presupuesto general en los niveles de función, actividad y tarea del proyecto. 5.3 Plan de control Plan de control de requisitos. Se describen los mecanismos para controlar y vigilar los cambios que se dan en los requisitos Plan de control del calendario. Se enlistan los mecanismos para medir el progreso, junto con una descripción de las medidas que se deben tomar en caso de que el progreso real no corresponda con el esperado Plan de control del presupuesto. Los mecanismos para vigilar cuando el costo real excede al presupuestado, así como las medidas a tomar si esto ocurre Plan de control de la calidad. Las formas en que se medirá y controlará la calidad se describen en esta sección.

6 Esquema del plan de administración del proyecto (4) Plan de generación de informes. Con el fin de vigilar los requisitos, el calendario, el presupuesto y la calidad, es necesario establecer los mecanismos para la generación de informes Plan de recolección de mediciones. Se enlistan las mediciones que se van a recopilar (LDC, PF, ) 5.4 Plan de manejo de riesgos Los riesgos deben identificarse, ponerse en orden de prioridad, mitigarse y darles seguimiento. En esta sección se deben describir todos los aspectos del manejo de riesgos. 5.5 Plan de cierre del proyecto Las acciones por realizar una vez que el proyecto está terminado, incluyendo la reasignación del personal y crear el archivo de los artefactos. 6.- Planes del soporte técnico 6.1 Modelo del proceso En esta sección se da una descripción detallada del modelo del ciclo de vida que se va a utilizar. 6.2 Métodos, herramientas y técnicas Las metodologías de desarrollo y los lenguajes de programación que se van a usar se describen aquí. 6.3 Plan de infraestructura Los aspectos técnicos de hardware y software se describen con detalle en esta subsección (equipo, SO, la red, SW, CASE, ), tanto los que se van a utilizar para desarrollar el sistema de información, así como aquellos en los cuales se ejecutará dicho sistema. 6.4 Plan de aceptación del producto Se deben preparar los criterios de aceptación; el cliente debe aceptarlos por escrito y los desarrolladores deben entonces asegurar que se cumplan. La manera en que se realizará lo anterior debe quedar por escrito. 7.- Planes de procesos de soporte 7.1 Plan de control de la configuración Se da una descripción detallada de los medios por los cuales todos los artefactos se pondrán bajo el control de la configuración.

7 Esquema del plan de administración del proyecto (5) 7.2 Plan de pruebas Se necesita de una planeación cuidadosa que incluya los recursos para su aplicación y el calendario específico de que prueba ha de realizarse. 7.3 Plan de documentación Una descripción de toda la documentación ya sea que se entreguen o no al cliente. 7.4 Plan de aseguramiento de la calidad Todos los aspectos del aseguramiento de la calidad, incluidas las pruebas, los estándares y las revisiones se engloban en esta sección. 7.5 Plan de revisiones y auditorias Se presentan detalles relacionados con la manera como se realizan las revisiones. 7.6 Plan de resolución de problemas Se describe la forma y mecanismos de resolver problemas en cualquiera de las fases del desarrollo del sistema. 7.7 Plan de control de los subcontratistas Se aplica cuando se requiere y el método para seleccionar y manejar a los subcontratistas debe aparecer aquí. 7.8 Plan de mejora del proceso Las estrategias para la mejora del proceso se incluyen aquí. 8. Planes adicionales Para ciertos proyectos, los componentes adicionales tal vez necesiten aparecer en el plan. En términos del marco de trabajo del IEEE, aparecen al final. Los componentes adicionales pueden incluir planes de seguridad, de prevención, de conversión de datos, de instalación y el plan de mantenimiento del sistema de información.

8 Técnicas de planificación En la planificación de proyectos existen una serie de técnicas, estas herramientas sirven de guía para detectar el tipo de actividades a realizar, el tiempo, los posibles recursos, la duración y las rutas a seguir. Nos brindan una gama de ventajas para pesar a priori, permite la toma de decisiones y nos ayuda a medir el tiempo de una serie de actividades, nos determina el programa o curso de acción a seguir.

9 Técnicas de planificación Las técnicas contribuyen en la realización del calendario. Diagramas de GANTT Es la técnica más utilizada cuando se pretende mostrar el tiempo previsto para diferentes tareas o actividades Se utiliza en proyectos pequeños (aproximadamente 25 actividades) Permite visualizar los solapamientos de tareas, pero no la dependencia entre ellas Redes de precedencia La planificación se realiza en base a grafos. Las dos técnicas principales son: PERT (Program Evaluation and Review Technique) y CPM (Crítical Path Method) Son convenientes cuando: Todas las actividades están bien definidas Las actividades se pueden comenzar, interrumpir y realizar de forma separada dentro de una secuencia dada. Las actividades se pueden relacionar con otras Las actividades están organizadas de forma que se pueda seguir una secuencia. Una vez comenzada una actividad, debe continuar sin interrupción hasta su finalización.

10 Diagramas de GANTT Es un diagrama de barras en forma de tabla donde se hace una referencia cruzada entre las tareas (filas) y los tiempos de duración de las mismas (columnas), ésta puede estar estipulada en horas, días, semanas, meses, etc. Dentro del diagrama se pueden incluir fases que engloben diferentes tareas: su duración es la necesaria para terminar dichas tareas.

11 Diagramas de GANTT Un diagrama de Gantt es una herramienta gráfica sencilla y útil, que se emplea en la gestión de proyectos. Plasma de manera muy visual, a través de un cronograma de barras horizontales, las actividades que forman parte de un proyecto y su temporalización. Además, facilita el control de la progresión en la realización de las tareas y de los recursos destinados al proyecto.

12 Diagrama de GANTT Elaborar un diagrama de Gantt, sea cual sea el método empleado o el software elegido, pasa por unas etapas necesarias e ineludibles: En primer lugar, una definición de tareas exige puntualizar bien qué actividades requiere el proyecto y qué implicaciones tiene cada una de ellas, en cuanto a recursos personales y materiales. Después, toca marcar fechas de inicio y de fin de cada actividad, su duración y orden de consecución. La dependencia entre tareas es un aspecto fundamental para encajar bien los tiempos y evitar holguras o tiempos muertos. A partir de aquí y con los datos anteriores claros, se podrá ya generar el gráfico. Hacen visual un proyecto y, en consecuencia, más comprensible. Su diseño implica un orden, con lo cual, contribuye a organizar las ideas y tener claras las prioridades a los jefes de proyecto. El diagrama de Gantt ayuda a los directores de proyectos a tomar decisiones que afectan directamente a la rentabilidad del plan.

13 Software para diagrama de Gantt

14 Diagrama Gantt Elaborar el siguiente resumen de actividades en un diagrama de Gantt

15 Redes de precedencia Se trata de un modelo gráfico que señala las relaciones secuenciales entre sucesos clave en un proyecto. Esta técnica permite visualizar el camino crítico que es la base para la planificación. Las reglas a considerar al desarrollar una red son: Mínimo unos 20 eventos. Si se gestiona manualmente no mas de 300 eventos, de lo contrario utilizar algún software de gestión. Útil para proyectos con alto riesgo o incertidumbre, que involucren muchas personas u organizaciones, los técnicamente complejos o con tareas a realizar en distintas localizaciones geográficas.

16 Técnica PERT Parte de la descomposición del proyecto en actividades. Las actividades ocurren entre dos sucesos (inicial y final), entendiendo como suceso un acontecimiento o punto temporal. La representación se realiza por medio de un grafo en donde las actividades se reflejan mediante arcos y los sucesos mediante vértices. A 1 2 Representación de actividad y suceso en PERT El siguiente paso es la determinación de las relaciones entre las actividades.

17 Técnica PERT (2) Tipos de relaciones de precedencia Relaciones de precedencia lineales A B Para iniciar la actividad B es necesario haber finalizado la actividad A. El suceso 2 es suceso final de A y suceso inicio de B. Relaciones de precedencia convergentes A B C D 4 5 Para iniciar la actividad D es necesario haber finalizado las actividades A, B, y C. Relaciones de precedencia divergentes A 1 2 B C D Para poder iniciar cualquiera de las actividades B, C, o D, es necesario que haya finalizado la actividad A.

18 Técnica PERT (3) Algunas combinaciones de precedencia pueden generar conflictos. Por ejemplo: Las actividades A y B preceden a la actividad D. Las actividades A, B, y C preceden a la actividad E. Para resolver el problema se añade una actividad ficticia F, de duración cero. A D A D B C E B C F E Ejemplo de conflicto PERT Ejemplo de resolución del conflicto PERT

19 Técnica PERT (4) Ejemplo: Supongamos que se tiene que realizar un proyecto que tiene las siguientes actividades: A, B, C, D, E, F y G. Las relaciones entre las actividades son las siguientes: A precede a B, C y D B precede a E C precede a F D precede a G E, F preceden a H Existen dos formas de manipular las relaciones de precedencia: Matriz de encadenamientos Matriz de precedencia Matriz de encadenamientos Cuadro de relaciones de precedencia

20 Técnica PERT (5) Ejemplo (continuación) La red resultante del ejemplo es la siguiente: A 1 2 B C 3 4 F E 6 H D G 7 5

21 Técnica PERT (6) Asignación de los tiempos de cada actividad Estimación de tiempo pesimista (t p ) Representa el tiempo máximo en que podría finalizarse la actividad si aparecen todas las circunstancias negativas que pueden darse durante su ejecución. Estimación de tiempo más probable (t n ) Representa el tiempo normal de duración de la actividad considerando que hay problemas durante las actividades, pero no aparecen en su totalidad. Estimación de tiempo optimista (t o ) Representa el tiempo mínimo si no aparece ningún problema durante la ejecución de la actividad. Basándose en las estimaciones anteriores se puede trabajar con un tiempo simplificado PERT (T ) que se calcula como: T t p 4t n to 6

22 Técnica PERT (7) Cálculo de los tiempos más temprano posible (early) y más tardíos (late). El tiempo early del suceso j (TE j ) será igual a: TE j = máx [TE i + T ij ], j El Tiempo late (TL i ) del último suceso coincide con su tiempo early y el resto de los tiempos late se calculan como: TL i = min [TL j - T ij ], j Tiempo más temprano para comenzar la actividad A (Tiempo early) Tiempo más temprano para finalizar actividad A Tiempo más tardío para comenzar la actividad A (Tiempo late) Tiempo más tardío para finalizar actividad A TE i TL i A TE j TL j Suceso i T ij : duración de la actividad que comienza en el suceso i y finaliza en el suceso j Suceso j

23 Técnica PERT (8) Ejemplo: Tomando la red del ejemplo anterior y suponiendo que se tienen calculados los tiempos PERT para cada actividad, el cálculo de los tiempos early es: B A 2 C 4 5 D TE j = máx [TE i + T ij ], j E 7 F G H

24 Técnica PERT (9) Ejemplo (continuación) El cálculo de los tiempos late es: TL i = min [TL j - T ij ], j A 2 C 4 5 D La holgura total de una actividad está dada por: H T = TL j TE i - T ij Representa el número de unidades de 5 tiempo que puede retrasarse la actividad sin que aumente la duración del proyecto. Las actividades que tienen un holgura total igual a cero se denominan actividades críticas. La unión de todas las actividades críticas forman el camino crítico. 5 B E 7 F G H

25 Ejercicio Actividad sucesora Actividad predecesora A - 3 B A 3 C A 2 D B,C 4 E B 7 F C 2 G E 1 H G,D,F 5 I F 8 J I 3 K H 6 Duración actividad

26 Métricas del proyecto Las métricas de software se refieren a un amplio elenco de mediciones para el software de computadora. Hay cuatro razones para medir los procesos del software, los productos y los recursos Caracterizar Para comprender mejor los procesos, los productos, los recursos y los entornos y para establecer la líneas base para las comparaciones con evaluaciones futuras. Evaluar Para determinar el estado con respecto al diseño. Las medidas dicen cuándo el proyecto y los procesos están perdiendo la pista. También se evalúa para valorar el logro de los objetivos de calidad, el impacto de la tecnología y las mejoras en los productos y procesos. Predecir Para poder planificar. Medir para predecir implica aumentar la comprensión de las relaciones entre los procesos y los productos y la construcción de modelos de estas relaciones, logrando así establecer objetivos alcanzables para el coste, planificación y calidad. Además las predicciones y estimaciones basadas en datos históricos ayudan a analizar riesgos. Mejorar Cuando se recaba información cuantitativa es posible identificar obstáculos, problemas de raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el rendimiento del proceso

27 Métricas del proyecto (2) Una métrica es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado [IEEE93]. Una métrica de software relata de alguna forma las medidas individuales sobre algún aspecto (número promedio de errores encontrados por revisión). La recopilación de medidas y desarrollo de métricas se utilizan para obtener indicadores. Un indicador proporciona una visión profunda que permite al gestor del proyecto o a los ingenieros de software ajustar el producto, el proyecto o el proceso para que las cosas salgan mejor [Pressman, 2002]. Las métricas del software le permiten conocer cuándo reír y cuándo llorar [Tom Glib] No todo lo que se puede contar cuenta, y no todo lo que cuenta se puede contar

28 Métricas del proyecto (3) Las métricas del proyecto y los indicadores derivados de ellos son utilizados por un equipo de software y el gestor del proyecto para adaptar el flujo de trabajo del proyecto y las actividades técnicas. Regularmente las métricas de proyectos tienen su primera aplicación durante la estimación. Aquí se compara respecto a proyectos anteriores (esfuerzo y tiempo). Conforme avanza el proyecto se compara el tiempo y esfuerzo estimado con el tiempo y esfuerzo real para hacer los ajustes pertinentes. Durante el transcurso del trabajo técnico se miden índices de producción representados mediante páginas de documentación, horas de revisión, puntos de función, líneas fuente entregadas. Además se sigue la pista de los errores detectados durante todas las tareas. La recopilación de métricas técnicas durante la evolución de la especificación al diseño permite evaluar la calidad y proporciona indicadores para la generación y prueba del código. La utilización de métricas para el proyecto tiene dos aspectos Minimizar la planificación del desarrollo haciendo ajustes necesarios para evitar retrasos y reducir problemas y riesgos potenciales. Evaluar la calidad de los productos en el momento actual y cuando sea necesario, modificando el enfoque técnico que mejore la calidad.

29 Mediciones del software Al igual que en el mundo físico, en el software se pueden categorizar dos formas de medir: Medidas directas En el proceso: coste y esfuerzo aplicado. En el producto: líneas de código producidas, velocidad de ejecución, tamaño de memoria y los defectos detectados durante un periodo de tiempo establecido. Medidas indirectas Funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento y muchas otras capacidades

30 Métricas orientadas al tamaño (LDC) Provienen de la normalización de las medidas de calidad y/o productividad considerando el tamaño del software producido. Se pueden mantener registros históricos sencillos y crear una tabla de datos orientados al tamaño. El coste y esfuerzo reflejados en la tabla involucran todas las actividades de la ingeniería de software (no solo la codificación). Para desarrollar métricas que se puedan comparar entre distintos proyectos, se seleccionan las líneas de código (LDC) como valor de normalización. Las métricas orientadas al tamaño son: Esfuerzo humano (personas/mes) Coste Pagina de documentación Número de errores Numero de defectos Una vez colectado el historico de estos atributos dentro de diferentes proyectos, pudiésemos calcular otros atributos utilizandos el LDC como factor de normalizacion: PRODUCTIVIDAD: KLDC / ESFUERZO HUMANO CALIDAD: NO. DE ERRORES / KLDC COSTE MEDIO: COSTE/KLDC DOCUMENTACION: PAGINAS DE DOCUMENTOS / KLDC

31 Métricas orientadas al tamaño (LDC) A partir de los datos de la tabla se pueden obtener métricas simples orientadas al tamaño. Errores por KLDC (miles de líneas de código) Defectos por KLDC páginas documentación por KLDC Errores persona-mes LDC por persona-mes $ por página de documentación Productividad = 12.1/24 = 0.50 Calidad = 134/12.1 = 11 Coste medio: 168/12.1 = 13.8 Documentacion = 365 / 12.1 = 30.16

32 Métricas orientadas a la función Se mide la funcionalidad a partir de mediciones directas, es decir, usan una medida de funcionalidad entregada por la aplicación como un valor de normalización Se utiliza una medida llamada punto de función [Albretch], como la de mayor uso se basa en características de dominio y de la complejidad de información del software. Se determinan cinco características de dominios de información: Número de entradas de usuario Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones o consultas, las cuales se cuentan de forma separada. Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada. Número de peticiones o consultas de usuario Una petición (consulta) de usuario se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada petición por separado. Número de archivos Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo independiente) Número de interfaces externas Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema.

33 Métricas orientadas a la función (2) Cuantificadas la cinco características del dominio de la información se debe determinar si una entrada en particular es simple, mediana o compleja. Sin embargo esta determinación suele ser subjetiva. Para calcular puntos de función (PF) también se debe calcular un factor de complejidad (F i ) según las respuestas (en un rango de 0 a 5) a una serie de preguntas. Así se tiene que: PF 14 CunetaTotal F 0 i

34 Métricas orientadas a la función (3) Ejemplo: Sistema hogar seguro La función gestiona la interacción con el usuario, aceptando una contraseña de usuario para activar/desactivar el sistema y permitiendo consultas sobre el estado de las zonas de seguridad y varios sensores de seguridad. Se identifican: Tres entradas de usuario: contraseña, interruptor de emergencia y activar/desactivar Dos consultas: consulta de zona y consulta de sensor Un archivo: datos de configuración del sistema Dos salidas de usuario: mensajes y estados del sensor Cuatro interfaces externas: sensor de prueba, configuración de zona, activar/desactivar y alerta de alarma. Usuario Contraseña Consulta de zona Consulta de sensor Interruptor de emergencia Activar/desactivar Contraseñas, sensores, Funciones de interacción del usuario con Hogar Seguro Sensor de prueba Datos de configuración del sistema Sensores Configuración de zona Mensajes Estado del sensor Alerta de alarma Activar/Desactivar Usuario Subsistema de monitorización 14 PF CunetaTotal i 1 Suponiendo: F 46 F 0 i (moderadamente complejo) Se tiene: PF ( ) 56 En base al valor calculado y los datos históricos de que se dispongan, se pueden estimar: LCD, esfuerzo, etc. Por ejemplo: un PF supone 60 líneas de código y un mespersona produce 12 PF. Cuál es tamaño y esfuerzo?.

35 Modelo de estimación de costos (COCOMO) COCOMO COnstructive COst MOdel Uno de los modelos más completos y detalladamente documentados para la estimación de costos por lo que también es el más conocido. Se trata de un modelado algorítmico de costos Se construye analizando los costos y atributos de los proyectos realizados. Se utiliza una fórmula matemática para predecir los costos basados en estimaciones de tamaño del proyecto (LDC), número de programadores y otros factores de los procesos y productos. La fórmula tiene un componente exponencial, lo que refleja el hecho de que los costos normalmente no se incrementan de forma lineal con el tamaño del proyecto.

36 Modelo de estimación de costos (COCOMO) (2) En su forma más general, la ecuación del esfuerzo se expresa como: Esfuerzo = A Tamaño B Donde: A es un factor constante que depende de las prácticas organizacionales locales y del tipo de software que se desarrolla. Tamaño es una valoración del tamaño del código o una estimación de la funcionalidad. B por lo general se encuentra entre 1 y 1.5; refleja el esfuerzo requerido para proyectos grandes. Los tipos de proyectos pueden ser: Orgánico. Desarrollo en un entorno estable, con poca innovación técnica, con pocas presiones de tiempo y tamaño relativamente pequeño Empotrado Desarrollo de software con requisitos muy restrictivos, con gran volatilidad de requisitos, complejo, en un entorno con gran innovación técnica. Semi-libre Situaciones entre el modo orgánico y el empotrado Ecuaciones de esfuerzo y tiempo de COCOMO [BOEHM, 1981] La precisión de las estimaciones depende de la Información disponible del sistema. Conforme avanza el proceso, se dispone de más información y por tanto las estimaciones son más precisas. 4x 2x x 0.5x 0.25x Factibilidad Requerimientos Diseño Código Entrega

37 Modelo de estimación de costos (COCOMO) (3) Se distinguen tres modelos distintos que se corresponden con diferentes cantidades de información disponible en las etapas del ciclo de vida: COCOMO básico Para estimaciones iniciales moderadamente precisas al inicio del proyecto cuando no se dispone de detalles (por ejemplo, para empezar a negociar el contrato). Consiste en aplicar básicamente la ecuación del esfuerzo. COCOMO intermedio Cuando tenemos identificados los principales componentes del sistema (especificación de requisitos ± terminada). Se emplea para estimar el coste de los componentes y consiste en aplicar la ecuación del esfuerzo y hacer un ajuste incorporando 15 factores de coste. COCOMO detallado Cuando están identificados los componentes individuales del sistema (especificación de requisitos completa o diseño general bien definido). En este caso, el modelo COCOMO proporciona tablas para poder distribuir las cantidades, ajustadas a los entorno, del esfuerzo y el tiempo de desarrollo del proyecto a lo largo de las distintas fases del mismo. Incluso permite refinar el ajuste de los factores para adaptarlo a las peculiaridades de cada etapa del proyecto

38 Modelo de estimación de costos (COCOMO) (4) Ejemplo: Se trata de estimar el esfuerzo de desarrollo de un sistema de comunicaciones de 30 KLDC, de alta complejidad. Afortunadamente se puede emplear personal de muy alta calificación con una gran experiencia específica en ese tipo de software. El coste del salario mensual de cada persona es de 1350 euros al mes. Aplicando COCOMO, se puede observar que el esfuerzo estimado será: Esfuerzo = 3.2 (30) 1.05 = PM Se aplicó el modo orgánico porque la aplicación no supera las 50 KLDC y no hay datos que señalen alguna complejidad especial. El ajuste del esfuerzo sería: Esfuerzo a = PM 1.15 (complejidad) 0.70 (personal) 0.91 (experiencia) Esfuerzo a = PM Coste = = euros Tiempo = = meses No Promedio de personas = / = 6.2 personas Sería más rentable emplear a personas de nivel medio cuyo salario es 1275 euros? Haciendo cálculos: Esfuerzo a = PM 1.15 (complejidad) 0.91 (personal) = PM Coste = = euros (es más caro)

39 Seguimiento y supervisión del proyecto El seguimiento y supervisión del proyecto implica seguir, revisar y comparar los logros y los resultados obtenidos, frente a las estimaciones, los compromisos y los planes del proyecto, actualizándolos en función de estos resultados. Se puede decir que los objetivos que se pretenden con el seguimiento y supervisión del proyecto del software son: Comparar los resultados actuales con los previstos Tomar acciones correctivas cuando existan desviaciones significativas de los planes previstos Acordar compromisos con el personal afectado por las acciones correctivas. Si no sabes dónde estas, un mapa no te ayudará [Humphery, 1989]

40 Seguimiento y supervisión del proyecto (2) En la supervisión de los resultados actuales con los planes previstos se han de desarrollar: Estándares que establezcan las condiciones o medidas que deben cumplirse cuando se realicen las diferentes tareas del proyecto. Establecer sistemas de supervisión y de informes, para lo cual hay que determinar: los datos necesarios, quién los recibe y cuándo se reciben. Medir los resultados, lo que permite determinar la consecución o la desviación de los objetivos y estándares. Otros aspectos importantes a considerar son: Seguimiento de costes y calendario Seguimiento de aspectos técnicos Generación de datos históricos Seguimiento de hitos No tratare de estar bien hoy a expensas de mañana

41 Seguimiento y supervisión del proyecto (3) Acciones correctivas Cuando no se cumplen los planes, se ejecutan diversas acciones correctivas que pueden incluir desde la revisión del plan de administración del proyecto hasta la replanificación del mismo. La razón principal para el seguimiento y el estado del progreso es detectar problemas y resolverlos lo más rápido posible. Los dos objetivos esenciales del seguimiento y la supervisión son: Las acciones correctivas se realizan y gestionan cuando los resultados reales se desvían significativamente de los planes Los grupos y los individuos afectados llegan al acuerdo de los cambios en los compromisos. En general las acciones correctivas pueden ser: Ajustar/añadir personal o número de hora extra Reasignar a los empleados para mejorar la eficiencia Reducir el alcance o contenido de una entrega Alargar o retrasar el calendario, negociando con el cliente.

42 Gestión de riesgos Riesgo Se puede definir como cualquier elemento potencial que provoca resultados insatisfactorios en un proyecto. Es la forma de expresar la incertidumbre a lo largo del ciclo de vida: la probabilidad de que en un punto del ciclo de vida no se alcancen los objetivos propuestos con los recursos disponibles [AFSC, 1988]. Estrategias de riesgo Reactivas Escuela de gestión del riesgo de Indiana Jones (no te preocupes, pensaré en algo). En el mejor de los casos, supervisa el proyecto en previsión de posibles riesgos y no se hace nada hasta que algo sale mal. Proactivas Inicia mucho antes de que inicie el trabajo técnico. Se identifican los riesgos potenciales, se valúa su probabilidad e impacto y se establece un orden de prioridad. Una vez hecho el paso anterior se establece un plan para controlar el riesgo. El objetivo principal es evitar el riesgo, sin embargo no se pueden evitar todos ellos, por lo que también es necesario un plan de contingencia. Si usted no ataca los riesgos activamente, ellos le atacarán activamente a usted. [Tom Glib]

43 Gestión de riesgos (2) Categorías de riesgos Riesgos del proyecto Amenazan al plan del proyecto Si ocurren es probable que la planificación temporal del proyecto se retrace o que los costos aumenten. Identifican problemas potenciales de presupuesto, planificación temporal, personal, recursos, cliente y requisitos. Riesgos técnicos Amenazan la calidad y la planificación temporal del software. Si ocurre la implementación puede llegar a ser difícil o imposible. Identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento. Surgen porque el problema es mas dificil de resolver de lo que se pensaba. Riesgos del negocio Amenazan la viabilidad del software a construir. Los principales riesgos de negocios son: Construir un producto o sistema excelente que nadie quiere en realidad (riesgo de mercado). Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico). Construir un producto que el departamento de ventas no sabe cómo vender. Perder el apoyo de una gestión experta debido a cambios en el personal o de enfoque (riesgo de dirección). Perder presupuesto o personal asignado (riesgos de presupuesto).

44 Validación del impacto

45 Gestión de riesgos (3) Plan RSGR Es el Plan de Reducción, Supervisión y Gestión del Riesgo. La reducción del riesgo evita problemas La supervisión da seguimiento al proyecto con tres objetivos: Evaluar cuando un riesgo previsto ocurre Asegurarse de que los procedimientos para reducir los riesgos se apliquen apropiadamente Recopilar datos históricos Puede llevarse a la práctica documentando cada riesgo en una hoja de información de riesgo.