Ingeniería de Software

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

2. Unidad 2 Ingeniería de software 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. Unidad 2 Ingeniería de software 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 1.1.1 Propósito, alcance y objetivos 1.1.2 Suposiciones y Restricciones 1.1.3 Elementos del proyecto sujetos a entrega 1.1.4 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 5.1.1 Plan de estimación 5.1.2 Plan de contratación de personal 5.1.3 Plan de adquisición de recursos 5.1.4 Plan de capacitación para el personal del proyecto 5.2 Plan de trabajo 5.2.1 Actividades de trabajo 5.2.2 Asignación del calendario 5.2.3 Asignación de recursos 5.2.4 Asignación del presupuesto 5.3 Plan de control 5.3.1 Plan de control de requisitos 5.3.2 Plan de control del calendario 5.3.3 Plan de control del presupuesto 5.3.4 Plan de control de la calidad 5.3.5 Plan de generación de informes 5.3.6 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. Unidad 2 Ingeniería de software Esquema del plan de administración del proyecto … (2) • 1.- Descripción general • 1.1 Resumen del proyecto • 1.1.1 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. • 1.1.2 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. • 1.1.3 Elementos del proyecto sujetos a entrega. Todos los elementos que se van a entregar al cliente se enlistan aquí, junto con las fechas correspondientes. • 1.1.4 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. Unidad 2 Ingeniería de software Esquema del plan de administración del proyecto … (3) • 5.- Planes del proceso administrativo • 5.1 Plan inicial • 5.1.1 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. • 5.1.2 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. • 5.1.3 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 • 5.2.1 Actividades de trabajo. Se especifican todas las actividades de trabajo, hasta el nivel de tarea en caso de ser necesario. • 5.2.2 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. • 5.2.3 Asignación de recursos. Los diversos recursos enlistados antes se asignan a las funciones, actividades y tareas propias del proyecto. • 5.2.4 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 • 5.3.1 Plan de control de requisitos. Se describen los mecanismos para controlar y vigilar los cambios que se dan en los requisitos. • 5.3.2 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. • 5.3.3 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. • 5.3.4 Plan de control de la calidad. Las formas en que se medirá y controlará la calidad se describen en esta sección.

6. Unidad 2 Ingeniería de software Esquema del plan de administración del proyecto … (4) • 5.3.5 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. • 5.3.6 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. Unidad 2 Ingeniería de software 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. Unidad 2 Ingeniería de software 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.

9. Unidad 2 Ingeniería de software 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). • Dentro del diagrama se pueden incluir fases que engloben diferentes tareas: su duración es la necesaria para terminar dichas tareas.

10. Unidad 2 Ingeniería de software 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.

11. Unidad 2 Ingeniería de software 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. • El siguiente paso es la determinación de las relaciones entre las actividades. A 1 2 Representación de actividad y suceso en PERT

12. Unidad 2 Ingeniería de software Técnica PERT … (2) • Tipos de relaciones de precedencia A A B B 1 2 3 3 3 3 A A 1 1 1 1 B B B D 2 2 2 2 2 2 4 5 C C C C C 3 3 3 3 3 3 3 3 B 3 3 3 A A A C 1 1 2 4 4 4 D 5 5

13. Unidad 2 Ingeniería de software 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 D A B B F E C E C Ejemplo de resolución del conflicto PERT Ejemplo de conflicto PERT

14. Unidad 2 Ingeniería de software 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

15. Unidad 2 Ingeniería de software Técnica PERT … (5) • Ejemplo … (continuación) • La red resultante del ejemplo es la siguiente: 3 E B 6 F C H A 1 2 4 D 7 G 5

16. Unidad 2 Ingeniería de software Técnica PERT … (6) • Asignación de los tiempos de cada actividad • Estimación de tiempo pesimista (tp) • 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 (tn) • 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 (to) • 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:

17. Unidad 2 Ingeniería de software 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 (TEj)será igual a: TEj = máx [TEi + Tij], j • El Tiempo late (TLi) del último suceso coincide con su tiempo early y el resto de los tiempos late se calculan como: TLi = min [TLj - Tij], 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 A TEi TLi TEj TLj Suceso i Suceso j Tij: duración de la actividad que comienza en el suceso i y finaliza en el suceso j

18. Unidad 2 Ingeniería de software 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: 3 13 19 6 5 E 6 21 B 1 8 7 3 2 4 6 0 8 14 H 22 F C A 7 5 24 D 9 5 13 G TEj = máx [TEi + Tij], j

19. Unidad 2 Ingeniería de software Técnica PERT … (9) • Ejemplo … (continuación) • El cálculo de los tiempos late es: TLi = min [TLj - Tij], j • La holgura total de una actividad está dada por: HT = TLj – TEi - Tij • Representa el número de unidades de 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. 3 13 15 6 5 E 6 21 21 B 10 10 1 8 2 7 3 4 6 0 0 8 8 14 14 H F C A 7 5 24 24 D 9 5 13 15 G

20. Unidad 2 Ingeniería de software 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 cuando 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

21. Unidad 2 Ingeniería de software 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

22. Unidad 2 Ingeniería de software 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.

23. Unidad 2 Ingeniería de software 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

24. Unidad 2 Ingeniería de software 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. • A partir de los datos de la tabla se pueden obtener métricas simples orientadas al tamaño. • Errores por KLDC • Defectos por KLDC • páginas documentación x KLDC • Errores persona-mes • LDC por persona-mes • $ por página de documentación

25. Unidad 2 Ingeniería de software Métricas orientadas a la función • Se mide la funcionalidad a partir de mediciones directas. • Se utiliza una medida llamada punto de función [Albretch], derivado con una relación empírica según las medidas contables (directas) del dominio de la información y las evaluaciones de la complejidad 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, 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 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 pase 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.

26. Unidad 2 Ingeniería de software 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 (Fi) según las respuestas (en un rango de 0 a 5) a una serie de preguntas. • Así se tiene que:

27. Unidad 2 Ingeniería de software 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. Sensores Sensor de prueba Configuración de zona Contraseña Usuario Funciones de interacción del usuario con Hogar Seguro Suponiendo: (moderadamente complejo) Mensajes Consulta de zona Usuario Consulta de sensor Estado del sensor Se tiene: Interruptor de emergencia Activar/Desactivar 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 mes- persona produce 12 PF. ¿Cuál es tamaño y esfuerzo?. Activar/desactivar Subsistema de monitorización Alerta de alarma Contraseñas, sensores, … Datos de configuración del sistema

28. Unidad 2 Ingeniería de software 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.

29. Unidad 2 Ingeniería de software Modelo de estimación de costos (COCOMO) … (2) Ecuaciones de esfuerzo y tiempo de COCOMO [BOEHM, 1981] • En su forma más general, la ecuación del esfuerzo se expresa como: • Esfuerzo = A  TamañoB • 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 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

30. Unidad 2 Ingeniería de software 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 COCOMMO 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

31. Unidad 2 Ingeniería de software 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 = 113.79 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: Esfuerzoa = 113.79 PM  1.15 (complejidad)  0.70 (personal)  0.91 (experiencia) Esfuerzoa = 83.35 PM Coste = 83.35  1350 = 112522.5 euros Tiempo = 2.5  83.350.38 = 13.42 meses No Promedio de personas = 83.35 / 13.42 = 6.2 personas ¿Sería más rentable emplear a personas de nivel medio cuyo salario es 1275 euros? Haciendo cálculos: Esfuerzoa = 113.79 PM  1.15 (complejidad)  0.91 (personal) = 119.08 PM Coste = 119.08  1275 = 151827 euros (es más caro)

32. Unidad 2 Ingeniería de software 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]

33. Unidad 2 Ingeniería de software 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

34. Unidad 2 Ingeniería de software 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.

35. Unidad 2 Ingeniería de software 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]

36. Unidad 2 Ingeniería de software 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. • 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).

37. Unidad 2 Ingeniería de software 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.