Ingeniería del Software de Gestión. Tema 5

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Ingeniería del Software de Gestión. Tema 5 - Presentation Transcript

    1. tema 6 – administración de proyectos enrique barreiro departamento de informática universidade de vigo escuela superior de ingeniería informática ingeniería del software de gestión
    2. introducción a la administración de proyectos tema 6 - administración de proyectos años 60 y 70: fracaso de muchos grandes proyectos de software retrasos en las entregas, problemas de fiabilidad, costes más elevados de lo previsto, poco eficiente,... motivo principal: enfoque de administración utilizado técnicas de administración derivadas de otras disciplinas de la ingeniería poco efectivas para el desarrollo de software desarrollos profesionales de software imprescindible la administración: restricciones de presupuesto, recursos y calendario responsabilidad del administrador de proyectos planificación y calendario del proyecto supervisión del trabajo (aplicación de estándares) supervisión del progreso (cumplimiento de tiempo y presupuesto) la naturaleza de la ingeniería de software dificulta la administración el producto es intangible: no se puede ver físicamente el progreso del producto no existen procesos de software estándar según tipos de productos proyectos “únicos”: diferencias con proyectos previos, evolución tecnológica de la informática y las comunicaciones,... escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 48
    3. actividades de la administración tema 6 - administración de proyectos la administración puede variar mucho según la organización, tipo de producto, etc. actividades responsabilidad de los administradores redacción de propuestas de desarrollo objetivos del proyecto y cómo se va a desarrollar incluye estimaciones de coste, tiempo, asignación a equipos,... planificación y calendario del proyecto: identificación de actividades, hitos y entregas del proyecto estimación económica del proyecto supervisión y revisión del proyecto actividad continua conocimiento del progreso comparación de progreso y coste con lo planificado mecanismos formales e informales selección y evaluación del personal redacción y presentación de informes informes para el cliente, organizaciones contratantes e internos documentos concisos y coherentes presentaciones en las revisiones de progreso administrador: necesidad de comunicación efectiva oral y escrita escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 3 / 48
    4. actividades de la administración tema 6 - administración de proyectos el administrador tiene tres grandes áreas de actuación personal participantes en el proyecto (ingenieros, programadores, clientes,...) jefes de equipo estructura del equipo de desarrollo problema ámbito del software: función, rendimiento, restricciones, datos de entrada y salida,... descomposición del problema en subproblemas (subsistemas, funciones,...) proceso elección de un modelo de desarrollo controlar la evolución del problema y el proceso descomposición del proceso en actividades y tareas escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 4 / 48
    5. personal del proyecto tema 6 - administración de proyectos trabajo en grupo: equipos de distintos tamaños (desde 2 a varios cientos) los grandes equipos se dividen en grupos por subproyectos o subsistemas (normalmente de un máximo de ocho) imprescindible espíritu de equipo motivación por el éxito del grupo y por las propias metas personales responsabilidad de los administradores factores que influyen en el trabajo en grupo composición del grupo cohesión del grupo comunicación del grupo organización del grupo escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 5 / 48
    6. personal del proyecto: composición del grupo tema 6 - administración de proyectos composición del grupo los ingenieros de software tienen una especial motivación por su trabajo ideas propias sobre la resolución de problemas técnicos problemas: ignorar estándares de interfaz, rediseño de sistemas al codificar, embellecimiento innecesario y personal del sistema,... importante seleccionar los miembros correctos para un grupo preferible un grupo con personalidades complementarias que uno seleccionado únicamente por su habilidad técnica INTUITIVO Intuitivo introvertido Intuitivo extrovertido los estilos de trabajo afectan pregunta a otros dice a los otros a la interacción entre clientes, EXTROVERTIDO INTROVERTIDO utiliza sentimientos utiliza sentimientos desarrolladores y usuarios y reacciones y reacciones emocionales emocionales implican la elección de un trabajador para una tarea dada. Por ejemplo: Racional introvertido Racional extrovertido intuitivos prefieren análisis y pregunta a otros dice a los otros diseño (requieren ideas nuevas) al mantenimiento decide lógicamente decide lógicamente (requiere atención a los detalles y análisis de resultados complejos) RACIONAL escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 6 / 48
    7. personal del proyecto: cohesión del grupo tema 6 - administración de proyectos cohesión del grupo el grupo piensa en sí mismo como un equipo más que como una colección de individuos que trabajan juntos miembros leales al grupo identificados con las metas y con los demás miembros, protegen al grupo de interferencias exteriores esto hace que el grupo sea robusto y se pueda enfrentar a problemas y situaciones inesperadas ventajas se puede desarrollar un estándar de calidad en el grupo los miembros se trabajan de forma cercana, fomentando el aprendizaje mutuo los miembros conocen el trabajo de los demás, lo que facilita la continuidad si un miembro abandona el grupo programación “sin ego”. los programas se consideran propiedad del grupo, no personal factores que influyen en la cohesión cultura organizacional y personalidades del grupo demostrar confianza y facilitar acceso a la información sentido de identidad (nombre y establecimiento de un territorio) involucrados en actividades de grupo (deportes, juegos,...) problemas resistencia al cambio de liderazgo por alguien externo pensamiento de grupo y “corporativismo”: la consideración de alternativas se reemplaza por lealtad a las normas y decisiones del grupo escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 7 / 48
    8. personal del proyecto: comunicación tema 6 - administración de proyectos comunicación en el grupo importante para el progreso del proyecto factores que influyen tamaño del equipo: hay n(n-1)/2 vínculos de comunicación (n: número de miembros). Unas son bidireccionales y otras unidireccionales, según el estatus estructura del grupo: los grupos informales se comunican de forma más efectiva que los jerárquicos y formales composición del grupo: choques entre miembros con los mismos tipos de personalidad mejor comunicación en grupos de ambos sexos que en grupos de un solo sexo entorno de trabajo físico privacidad (concentración y trabajo sin interrupción) conciencia del exterior (luz natural y vista del entorno exterior) personalización del entorno áreas comunes y de reuniones (formales e informales) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 8 / 48
    9. personal del proyecto: organización del grupo tema 6 - administración de proyectos organización del grupo factores que influyen en la estructura más adecuada experiencia y estilos de trabajo de los miembros tamaño del grupo estilos de gestión de clientes y desarrolladores principales tipos de estructura organizativa estructura formal y jerárquica jerarquías claras comunicación vertical asignación de responsabilidades estructura informal estructura democrática y decisiones por consenso tareas asignadas por habilidad y experiencia mejor cohesión y rendimiento ejemplo: “programación extrema” Comparación de estructuras organizativas Fuertemente estructuradas Escasamente estructuradas Proyectos con elevada certeza, estabilidad y Proyectos con incertidumbre (p.e., cambio uniformidad (requieren menos en requerimientos) comunicación) Repetición Necesidad de entrevistas Grandes proyectos Técnicas o tecnologías nuevas Pequeños proyectos escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 9 / 48
    10. personal del proyecto: organización del grupo tema 6 - administración de proyectos estructura formal: Equipo del Jefe de Programadores, Chief Programmer Team jefe de programadores (JP): responsable del diseño, desarrollo y pruebas de instalación Jefe de los demás informan al JP, quien tiene la última palabra en cada decisión programadores supervisa a los demás, diseña programas, asigna tareas a los otros miembros del equipo otros miembros ayudante JP: apoya al JP y lo reemplaza cuando es Ayudante JP necesario, responsable de la validación del software bibliotecario: da soporte al equipo encargándose de la gestión de configuración (mantenimiento de la documentación, versiones,...), compila, ejecuta pruebas preliminares de módulos y objetos,... Programadores especialistas que trabajan temporal o permanentemente Bibliotecario Administrador expertos en el grupo: programadores especialistas en sistemas operativos Equipo de Programadores pruebas ingenieros de pruebas noveles ... fundamento: grandes diferencias entre habilidades de programación (hasta 25 veces más productivos unos que otros) problemas no abunda el personal adecuado para ser JP (“superprogramador”) problemas de autoestima del resto del equipo los proyectos se resienten si el JP o el ayudante se van modelo difícil de acomodar en las estructuras organizacionales escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 10 / 48
    11. planificación del proyecto Establecer restricciones Valores iniciales Def inir hitos y tema 6 - administración de proyectos proy ecto parámetros proy ecto productos a entregar Establecer programación en el tiempo del proy ecto la administración efectiva depende de una completa planificación del Iniciar activ idades según la progreso del proyecto programación plan: hilo conductor del proyecto anticipación de los problemas que Esperar un tiempo pueden surgir (entre 2 y 3 semanas) preparación de soluciones a esos problemas Rev isar progreso proy ecto el plan inicial evoluciona según el progreso del proyecto y la disponibilidad de información Rev isar estimaciones de los parámetros enfoque pesimista al elaborar suposiciones y calendario: necesidad de disponer de holguras Actualizar programación existen retrasos Renegociar restricciones y productos a entregar no existen retrasos negociación con éxito negociación sin éxito Iniciar rev isión técnica y posible rev isión proy ecto no completado ni cancelado proy ecto completado o cancelado escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 11 / 48
    12. planificación del proyecto tema 6 - administración de proyectos plan del proyecto apartados habituales del plan del proyecto 1. introducción: objetivos, restricciones,... 2. organización del proyecto 3. análisis de riesgo: riesgos, probabilidades de que ocurran, estrategias de reducción,... 4. requerimientos de recursos de hardware y software 5. división del trabajo: identificación de actividades, hitos y productos a entregar asociados a cada actividad 6. programa del proyecto: dependencias entre actividades, tiempo estimado para cada hito, asignación de personal a las actividades,... 7. mecanismos de supervisión e informe: descripción de la administración de informes, cuándo deben producirse,... revisión regular durante el proyecto partes que cambian frecuentemente (p.e. calendario) y otras más estables (p.e. presupuesto) organización documental que permita reemplazar fácilmente las secciones otros planes plan de calidad plan de validación plan de administración de la configuración plan de mantenimiento plan de desarrollo del personal escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 12 / 48
    13. planificación del proyecto tema 6 - administración de proyectos hitos y productos a entregar información a los administradores documentos que describen el estado del software permite juzgar el proceso y actualizar costes y calendario establecimiento de hitos puntos finales de una actividad o tarea del proceso del software documentación que se presenta al administrador: informes cortos de los logros en una actividad representan el fin de una etapa lógica en el proyecto productos a entregar resultado que se entrega al cliente al final de una actividad principal del proceso (análisis, diseño,...) los productos son hitos, pero los hitos no son necesariamente productos a entregar (resultados internos utilizados por el administrador) Estudio Análisis de Desarrollo Estudio Especificación ACTIVIDADES viabilidad requerim. prototipos del diseño requerim. sistema informe requerim. informe diseño requerim. HITOS viabilidad usuarios evaluación arquitectónico sistema PRODUCTO escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 13 / 48
    14. planificación temporal tema 6 - administración de proyectos calendario dividir el proyecto en actividades estimar el tiempo necesario para realizarlas (algunas se harán en paralelo) los administradores coordinan las actividades organizan el trabajo para optimizar la mano de obra asignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...) duración aconsejable de una actividad: entre 1 y 8 semanas importante tener en cuenta posibles problemas (personal, hardware, software,...) que provocan retrasos problemas previstos: incrementar un 30% la estimación inicial problemas no previstos: incrementar un 20% utilización de diagramas de Gantt y redes de actividades escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 14 / 48
    15. planificación temporal tema 6 - administración de proyectos RED DE ACTIVIDADES Duración Tarea Dependencias 14/7/02 15 días 15 días (días) M1 T3 T9 T3 T9 8 días 4/8/02 T1 8 hito 5 días 25/8/02 T1 M4 T1 T2 15 4/7/02 T6 M6 25/7/02 T3 15 T1 (M1) INICIO M3 15 días 20 dias T4 10 7 días T2 T7 T11 T11 T5 10 T2,T4 (M2) T6 5 T1,T2 (M3) 25/7/02 5/9/02 10 días 10 días 11/8/02 M8 T4 M2 T5 T7 20 T1 (M1) M7 15 días T8 25 T4 (M5) M5 T10 T12 T12 25 días T9 15 T3, T6 (M4) 18/7/02 10 días T8 T10 15 T5, T7 (M7) FINAL camino crítico 19/9/02 T11 7 T9 (M6) trayectoria más larga en la red de actividad T12 10 T11 (M8) el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto) fuente: Ingeniería de Software, I. Sommerville, pp. 80-83 los retrasos en las demás actividades no afectan necesariamente al proyecto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 15 / 48
    16. planificación temporal tema 6 - administración de proyectos DIAGRAMA DE GANTT 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 inicio la calendarización inicial será, con T4 toda seguridad, T1 flexibilidad en la fecha de finalización incorrecta. T2 durante el M1 desarrollo se T7 deben comparar las estimaciones T3 previas con las M5 reales para revisar la T8 calendarización M3 del resto del proyecto. M2 al conocer cifras T6 reales, se debe M4 revisar la red de actividades y T9 reorganizar las M7 actividades T10 posteriores para reducir la longitud M6 de la trayectoria T11 crítica. M8 T12 final escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 16 / 48
    17. planificación temporal tema 6 - administración de proyectos Asignación de personas vs diagrama de Gantt Asignación de personas a actividades 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Tarea Ingeniero Fernando T4 T1 Juana T8 T11 T2 Ana T12 T3 Juana Juana T1 T3 T4 Fernando T9 T5 María T6 Ana Ana T2 T6 T10 T7 Jaime T8 Fernando Jaime T7 T9 Juana T10 Ana María T5 T11 Fernando T12 Fernando El personal no tiene que estar asignado al proyecto todo el tiempo. En los periodos intermedios puede participar en otros proyectos, asistir a cursos de formación, tomar vacaciones,... escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 17 / 48
    18. medición y métricas del software tema 6 - administración de proyectos “Cuando pueda medir lo que está diciendo y expresarlo con números, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas expresar lo que dices con números, tu conocimiento es precario y deficiente.” (Lord Kelvin) Métricas cualquier medida relacionada con un sistema, proceso o documentación de software. medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE Producto de Proceso de Standard Glossary of Software Engineering, 1993) Producto de Proceso de software software software software Ejemplos: métricas para calcular el tamaño del un producto en líneas de código métricas de la claridad de un párrafo en un texto escrito, por Métricas de Métricas de ejemplo, en un manual (índice de Fog) Métricas de predicciónde Métricas control número de errores localizados en un producto software control predicción entregado número de personas-día necesarias para desarrollar un componente ... Decisiones Decisiones Se aplican a: administrativas administrativas Procesos (métricas de control): por ejemplo, tiempo y esfuerzo medios necesarios para corregir un error. Productos (métricas de predicción): complejidad ciclomática de un módulo, número de métodos y atributos asociados con los objetos de un diseño,... Permiten tomar decisiones escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 18 / 48
    19. medición y métricas del software tema 6 - administración de proyectos el proceso de medición seleccionar medidas a realizar formular preguntas que la medición intenta responder Elegir medidas definir las métricas requeridas para responder a esas Elegir medidas a realizar preguntas a realizar no se recogen otras métricas que no respondan a esas preguntas seleccionar componentes a valorar Seleccionar Seleccionar no es necesario ni deseable estimar los valores de las componentes a componentes a métricas de todo un sistema de software valorar valorar conjunto representativo componentes críticos y fundamentales (utilización continua) Medir medir características de los componentes Medir características características calcular los valores de las métricas procesando la de los componentes de los componentes representación del componente (diseño, código,...) con herramientas adecuadas identificar componentes anómalos Identificar Identificar medidas comparación de los resultados con mediciones previas medidas anómalas registradas en una base de datos anómalas atención especial a los valores más altos y más bajos pues pueden indicar problemas. analizar componentes con valores anómalos Analizar se examinan los componentes para decidir si los Analizar componentes valores obtenidos indican que su calidad está en componentes anómalos peligro. anómalos no siempre indican problemas (por ejemplo, la complejidad de un módulo puede ser alta pero necesaria) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 19 / 48
    20. medición y métricas del software tema 6 - administración de proyectos métricas del producto se refieren a las características del propio software las relaciones entre características del software pueden variar dependiendo de diversos factores (proceso, tecnología de desarrollo, tipo de sistema,...) es necesario construir una base de datos histórica la base de datos se usa para comprobar cómo se relacionan los atributos del producto con la calidad que la organización necesita dos tipos de métricas de producto dinámicas recogidas por las mediciones hechas en un programa en ejecución relación directa con los atributos de calidad del software ejemplo: medición de tiempo de ejecución como medida de la eficiencia del sistema ejemplo: registro del número y tipo de caídas del sistema y relación con la fiabilidad del software estáticas recogidas por las mediciones hechas en las representaciones del sistema (diseño, código, documentación,...) relación indirecta con los atributos de calidad del software ejemplo: longitud del programa como predictor de la mantenibilidad o la complejidad ejemplo:índice de Fog como predictor de la facilidad de comprensión de un documento de texto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 20 / 48
    21. medición y métricas del software tema 6 - administración de proyectos Ejemplos de métricas estáticas del producto métrica de descripción producto fan-in: medida del número de funciones que llaman a otra función X fan-out: número de funciones que son llamadas por una función X. Un valor alto de fan-in indica que X está fuertemente acoplada al resto del diseño fan-in / fan-out y que los cambios en X pueden tener efectos extensivos al resto del sistema. Un valor alto de fan-out indica que la complejidad de X podría ser excesiva, debido a la complejidad de la lógica de control necesaria para coordinar los componentes llamados. Medida del tamaño del programa en líneas de código (LDC). Cuanto mayor sea el longitud del código tamaño de un componente, más complejo y susceptible de incorporar errores será. complejidad Medida de la complejidad del control de un programa, y está relacionada con la ciclomática comprensión del programa. Medida de la longitud promedio de los diferentes identificadores de un programa. longitud de los Cuanto mayor sea esta longitud, más probable es que tengan significado, y por identificadores tanto el programa será más comprensible. Medida de la profundidad de anidamiento de las instrucciones if en un programa. profundidad de los if Instrucciones if profundamente anidadas son difíciles de comprender y son anidados potencialmente susceptibles a errores. Medida de la longitud promedio de las palabras y declaraciones en los índice de Fog documentos. Cuanto mayor sea el índice de Fog, más difícil será comprender el documento. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 21 / 48
    22. medición y métricas del software tema 6 - administración de proyectos 1 R1 Complejidad ciclomática 2 V(G) = 4 3 4 Número de regiones = 4 R2 11 aristas – 9 nodos = 4 5 6 R3 7 8 R4 9 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 22 / 48
    23. medición y métricas del software tema 6 - administración de proyectos métricas orientadas a objetos: métricas CK (Chidamber y Kemerer) métrica descripción asumen que se definen n métodos con complejidad c1, c2,...cn se definen para la clase C. La métrica de complejidad específica que se haya elegido (por ejemplo, la complejidad ciclomática) debe normalizarse de manera que la complejidad nominal para un método toma un valor de 10. métodos ponderados MPC = Σci para cada i=1 hasta n por clase (MPC) El número de métodos y su complejidad indican la cantidad de esfuerzo para implementar y verificar una clase. Cuanto mayor sea el número de métodos, más complejo es el árbol de herencia. Además, a medida que crece el número de métodos para una clase dada, más específica se vuelve y, por lo tanto, menos reutilizable. Por eso, el MP debe mantenerse lo más bajo posible. longitud máxima del nodo a la raíz del árbol. Cuanto mayor sea, las clases de los niveles más bajos heredarán muchos métodos, lo que conlleva dificultades profundidad del árbol potenciales al predecir el comportamiento de una clase. Además, la complejidad de herencia (PAH) de diseño será mayor. Sin embargo, valores de APH grandes indican mayor capacidad de reutilización de métodos. número de hijos cuantos más descendientes, más reutilización, pero también es posible que (NDH) algunos descendientes no sean miembros realmente apropiados de la superclase. acoplamiento entre es el número de colaboraciones de una clase, y cuanto mayor sea, menor será el clases (AEC) grado de reutilización, además de complicarse las pruebas y el mantenimiento. número de métodos que pueden ser ejecutados en respuesta a un mensaje respuesta para una recibido por un objeto de esa clase. Cuanto mayor sea RPC, mayor esfuerzo se clase (RPC) requiere para su comprobación, y más complejo es el diseño. carencia de cohesión dos métodos son similares si comparten al menos un atributo de la clase. A en los métodos (CCM) mayor número de métodos similares, mayor cohesión hay en la clase. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 23 / 48
    24. medición y métricas del software tema 6 - administración de proyectos Ventana Cartas_reclamo tamaño Factura ancho fecha_emisión : Date nombre_cliente fecha_pago : Date fecha_emisión total precio() compras impuesto() cliente() mostrar_factura() lista_compras() 1..* 1 0..* Compra 1 Caja de texto fecha Botón OK tasa_impuesto precio() 1..* impuesto() cartas_ botón caja de Métrica 0 factura compra ventana reclamo OK texto MPC 4 2 0 0 1 0 NDH 0 0 0 0 0 0 PAH 0 0 1 0 1 0 RPC - - - - - - AEC 3 4 2 1 3 1 CCM - - - - - - fuente: Ingeniería de software. Teoría y práctica. S.L. Pfleeger, p. 34 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 24 / 48
    25. medición y métricas del software tema 6 - administración de proyectos métricas del proceso DETERMINANTES DE LA CALIDAD DEL SOFTWARE Y DE LA EFECTIVIDAD DE LA PRODUCTO (complejidad,...) datos cuantitativos de los procesos del ORGANIZACIÓN software Características Condiciones la recolección de métricas del proceso del cliente del negocio (fechas, reglas,...) es esencial para la mejora del mismo, (comunicación) incluso en proyectos a pequeña escala PROCESO PERSONAS se utilizan para evaluar la eficiencia (destreza, motivación,... TECNOLOGÍA Entorno de de un proceso o si ésta ha mejorado desarrollo ha mejorado con los cambios realizados tres tipos de métricas de proceso tiempo requerido para completar un Ayudan aa descubrir si los cambios en el proceso Ayudan descubrir si los cambios en el proceso proceso en particular: total del mejoran la eficiencia de un proceso. Por ejemplo, proyecto, por ingeniero, por mejoran la eficiencia de un proceso. Por ejemplo, se puede medir el tiempo yy esfuerzo necesarios se puede medir el tiempo esfuerzo necesarios actividad,... para moverse de un hitos fijo aa otro, como la para moverse de un hitos fijo otro, como la recursos requeridos para un proceso aceptación de requerimientos, terminación de un en particular: esfuerzo en personas- aceptación de requerimientos, terminación de un diseño arquitectónico, etc. Esos valores ayudan aa día, costes de viajes, recursos de diseño arquitectónico, etc. Esos valores ayudan identificar áreas de mejora en el proceso. hardware,... identificar áreas de mejora en el proceso. Una vez introducidos los cambios, las mediciones número de ocurrencias de un evento Una vez introducidos los cambios, las mediciones posteriores indican si los cambios han sido positivos particular: posteriores indican si los cambios han sido positivos número de defectos descubiertos durante la revisión del código, Tienen influencia directa en la calidad del Tienen influencia directa en la calidad del número de peticiones de cambio en software. Por ejemplo, incrementar el número software. Por ejemplo, incrementar el número requerimientos, de defectos descubiertos al cambiar el proceso de defectos descubiertos al cambiar el proceso número promedio de líneas de código de revisión del código probablemente se (LDC) modificadas en respuesta a un de revisión del código probablemente se reflejará en una mejora de la calidad del cambio de requerimientos,... reflejará en una mejora de la calidad del errores detectados por el usuario producto, aunque tiene que confirmarse por producto, aunque tiene que confirmarse por ... mediciones posteriores del producto. mediciones posteriores del producto. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 25 / 48
    26. medición y métricas del software tema 6 - administración de proyectos paradigma GQM (Goal-Question-Metric) de Basili y Rombach se utiliza para decidir qué mediciones hacer y cómo utilizarlas se basa en la identificación de metas (goals): aquello que la organización intenta alcanzar. Por ejemplo, mejorar la productividad de los programadores, reducir tiempos de desarrollo, incrementar la fiabilidad,... preguntas (questions): refinamientos de las metas en las que se identifican áreas específicas de incertidumbre. Ejemplos: ¿cómo se puede incrementar el número de LDC depuradas? ¿cómo se puede reducir el tiempo requerido para finalizar los requerimientos? ¿cómo se pueden llevar a cabo evaluaciones de fiabilidad más efectivas? métricas: las mediciones necesarias para ayudar a responder a las preguntas y confirmar si las mejoras del proceso cumplieron su objetivo. Ejemplos: medir la productividad de los programadores en LDC y nivel de experiencia medir número de comunicaciones formales entre cliente y analista para cada cambio de requerimientos medir el número de pruebas requeridas para provocar una caída en el producto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 26 / 48
    27. planificación de proyectos tema 6 - administración de proyectos planificación proporciona un marco de trabajo que permite al administrador del proyecto hacer estimaciones razonables de recursos, costes y planificación temporal. actividades de la planificación delimitación del ámbito del software estimación de recursos necesarios (humanos, hardware, software,...) PLANIFICACIÓN PLANIFICACIÓN EXPERIENCIA EXPERIENCIA Grado de estructuración ESTIMACIÓN RIESGO ESTIMACIÓN RIESGO DATOS DATOS HISTÓRICOS HISTÓRICOS Ámbito de bajo riesgo Tamaño del esfuerzo Complejidad basada en esfuerzos pasados escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 27 / 48
    28. planificación de proyectos: ámbito tema 6 - administración de proyectos delimitación del ámbito del software describe los datos a procesar, la función, el rendimiento, las restricciones, interfaces y fiabilidad necesarias se evalúan las funciones y se refinan con más detalles si es necesario se obtiene mediante entrevistas preliminares entre analista y cliente utilidad del ámbito del software estudiar la viabilidad del proyecto realizar estimaciones de recursos necesarios FUNCIÓN RENDIMIENTO ÁMBITO DEL RESTRICCIONES SOFTWARE INTERFACES FIABILIDAD escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 28 / 48
    29. planificación de proyectos: recursos tema 6 - administración de proyectos estimación de recursos se especifica cada recurso mediante cuatro características descripción informe de disponibilidad fecha cronológica en la que se requiere el recurso tiempo durante el que será aplicado Especificar: RECURSOS •Habilidades requeridas •Disponibilidad •Duración tareas. •Fecha comienzo Personas •Componentes desarrollados •Componentes experimentados •Componentes con experiencia parcial. Componentes •Componentes nuevos software reutilizables Especificar: •Descripción Herramientas •Disponibilidad hardware/software •Duración del uso •Fecha de distribución escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 29 / 48
    30. planificación de proyectos: estimación tema 6 - administración de proyectos estimación del esfuerzo y coste de un proyecto normalmente el problema es demasiado complejo. Se utilizan diferentes técnicas: descomposición del problema descomposición del proceso antes de hacer estimaciones de esfuerzo y coste conocer el ámbito del software realizar una estimación del tamaño precisión de una estimación: grado en que se ha estimado adecuadamente el tamaño del producto habilidad para traducir la estimación del tamaño a: esfuerzo humano tiempo dinero grado en que el plan del proyecto refleja la capacidad del equipo de desarrollo estabilidad de los requisitos y el entorno del esfuerzo que da soporte a las actividades de ingeniería del software opciones para la estimación: dejar la estimación para más adelante basar las estimaciones en proyectos similares anteriores utilizar técnicas de descomposición (“divide y vencerás”) desarrollar o aplicar un modelo empírico para calcular costes y esfuerzo escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 30 / 48
    31. planificación de proyectos: estimación tema 6 - administración de proyectos tamaño del software dos tipos de enfoque directo: se utilizan las LDC para medir el tamaño indirecto: el tamaño se representa mediante puntos de función (PF) problemas de la utilización de LDC no existe definición estándar de LDC (p.ej., ¿se consideran LDC los comentarios?) líneas físicas o lógicas contabilización del código reutilizable aplicaciones en diferentes lenguajes estilos individuales de programación relación entre LDC y PF: depende del lenguaje escogido Lenguaje LDC/PF (media) Lenguaje LDC/PF (media) Ensamblador 320 Ensamblador 320 C 128 C 128 Cobol 105 Cobol 105 Fortran 105 Fortran 105 Pascal 90 Pascal 90 Ada 70 Ada 70 Lenguajes OO 30 Lenguajes OO 30 L4G 20 L4G 20 Lenguajes visuales 44 Lenguajes visuales escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 31 / 48
    32. planificación de proyectos: estimación tema 6 - administración de proyectos Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 5 0- Sin influencia Puntos de función: relación empírica 1- Incidental basada en medidas cuantitativas del 2- Moderado dominio de información del software y 3- Medio valoraciones subjetivas acerca de la 4- Significativo complejidad del software 5- Esencial Factor de peso 1.¿Requiere el sistema copias de seguridad fiables? Factor de peso 2.¿Se requieren comunicaciones de datos? Parámetro de medida Cuenta Simple Medio Complejo Parámetro de medida Cuenta Simple Medio Complejo 3.¿Existen funciones de procesamiento distribuido? 4.¿Es crítico el rendimiento? Número entradas usuario x3 4 6 = Número entradas usuario x3 4 6 = 5.¿Será ejecutado el sistema en un entorno operativo existente y utilizado? Número salidas de usuario x4 5 7 = Número salidas de usuario x4 5 7 = 6.¿Se requiere entrada de datos interactiva? 7.¿Requiere la entrada interactiva que las transacciones Número peticiones al usuario x3 4 6 = Número peticiones al usuario x3 4 6 = de entrada se hagan sobre múltiples pantallas o variadas operaciones? Número de archivos x7 10 15 = Número de archivos x7 10 15 = 8.¿Se actualizan los archivos maestros de forma Número interfaces externos x5 7 10 = interactiva? Número interfaces externos x5 7 10 = 9.¿Son complejas las entradas, las salidas, los archivos o Cuenta total Cuenta total las peticiones? 10.¿Es complejo el procesamiento interno? 11.¿Se ha diseñado el código para ser reutilizable? 12.¿Están incluidas en el diseño la conversión y la PF = Cuenta Total xx[0,65 + 0,01 xxSUM(Fi)] PF = Cuenta Total [0,65 + 0,01 SUM(Fi)] instalación? 13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? FF: : valores de ajuste de complejidad i valores de ajuste de complejidad 14.¿Se ha diseñado la aplicación para facilitar los i cambios y ser fácilmente utilizada por el usuario? escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 32 / 48
    33. estimación basada en el problema tema 6 - administración de proyectos al estimar el proyecto, las LDC y los PF se utilizan como: variables de estimación que permiten dimensionar cada elemento del software métricas de proyectos anteriores (“métricas de línea de base”): productividad (LDC / persona-mes) coste ($ / persona-mes) ... pasos: estimación de un rango de valores para cada función especificada en el ámbito del software 3 valores para cada función: optimista, más probable y más pesimista (indica el grado de incertidumbre) valor esperado: ejemplo: VE = (Sopt + 4Sm + Spes)/6 técnicas estadísticas: cálculo de la desviación de las estimaciones aplicación de métricas de proyectos anteriores (en LDC o PF) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 33 / 48
    34. estimación basada en el problema tema 6 - administración de proyectos descomposición del problema en funciones a partir del ámbito del software F1 F2 Fn estimación estimación cálculo de las cálculo de las coste de F1 coste de F2 variables de variables de estimación (LDC estimación (LDC y/o PF) de F1 y/o PF) de F2 estimación de estimación de esfuerzo de F1 esfuerzo de F2 coste de F1 esfuerzo de F1 aplicación de aplicación de métricas de métricas de coste de F2 esfuerzo de F2 productividad productividad o coste o coste coste de Fn esfuerzo de Fn estimación global estimación global del coste del del esfuerzo del proyecto proyecto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 34 / 48
    35. estimación basada en el problema (LDC) tema 6 - administración de proyectos Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfazque aceptará datos diseño de buena2 o 3 dimensiones por datos del ingeniero. Éste controlará el Hay que desarrollar un software CAD que debe tener un geométricos de calidad. Una base de parte CAD contiene todos los datos geométricos y la información una soporte. que desarrollarán módulosde buena calidad. Unapara producir laCAD contiene todos los datos sistema CAD por medio de de interfaz Se debe tener un diseño de análisis de diseño base de datos salida requerida que se va a visualizar en varios dispositivosde soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a geométricos y la información gráficos. El software en varios dispositivos gráficos. visualizar se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser. El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser. Funciones identificadas: Funciones identificadas: Estimación en LDC de AG3D: descomposición interfaz de usuario yy facilidades de control (IUFC) interfaz de usuario facilidades de control (IUFC) Estimación en LDC de AG3D: descomposición de funciones optimista: 4600 de funciones análisis geométrico de dos dimensiones (AG2D) optimista: 4600 análisis geométrico de dos dimensiones (AG2D) más probable: 6900 análisis geométrico de tres dimensiones (AG3D) más probable: 6900 análisis geométrico de tres dimensiones (AG3D) pesimista: 8600 gestión de base de datos (GBD) pesimista: 8600 gestión de base de datos (GBD) facilidades de la interfaz gráfica (FIG) facilidades de la interfaz gráfica (FIG) control periféricos (CP) control periféricos (CP) módulos de análisis del diseño (MAD) VE ==(Sopt ++4Sm ++Spes)/6 módulos de análisis del diseño (MAD) VE (Sopt 4Sm Spes)/6 Datos históricos: Datos históricos: productividad media de la organización en métricas de Función LDC estimada anteriores productividad media de la organización en proyectos métricas de Función LDC estimada anteriores proyectos similares: 620 LDC/pm proyectos proyectos similares: 620 LDC/pm IUFC 2300 IUFC 2300 Tarifa laboral: 8000 $$ /mes Tarifa laboral: 8000 /mes AG2D 5300 AG2D 5300 AG3D 6800 AG3D 6800 Coste LDC: 13 $$ GBD 3350 Coste LDC: 13 GBD 3350 FIG 4950 FIG 4950 CP 2100 CP 2100 MAD 8400 MAD 8400 Total 33200 Total 33200 Coste total proyecto: 431000 $$ Coste total proyecto: 431000 Esfuerzo estimado: 54 personas-mes Esfuerzo estimado: 54 personas-mes escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 35 / 48
    36. estimación basada en el problema (PF) tema 6 - administración de proyectos Valor dominio Opt. Probable Pesimista Cuenta Peso Cuenta información est PF Num. entradas 20 24 30 24 4 96 Num. salidas 12 15 22 16 5 80 Num. peticiones 16 22 28 22 4 88 Num. archivos 4 4 5 4 10 40 Num. interfaces ext. 2 2 3 2 7 14 Cuenta total 318 Copia de seguridad y recuperación 4 Copia de seguridad y recuperación 24 Comunicaciones Comunicaciones 02 Proceso distribuido Proceso distribuido 40 Rendimiento crítico PF estimado == cuenta total x (0,65 + 0,01 x Suma (Fi) PF estimado cuenta total x (0,65 + 0,01 x Suma (Fi) Rendimiento crítico 34 Entorno operativo existente Entorno operativo existente 43 Entrada de datos online Entrada de datos online 54 Transacciones entrada en varias pant. Transacciones entrada en varias pant. 35 Archivos maestros actualizados online Complejidad valores actualizados online Archivos maestros dominio información 53 Complejidad valores dominio información 55 Complejidad procesamiento interno PF estimado ==372 Complejidad procesamiento interno 45 PF estimado 372 Código diseñado para reutilización Conversión en diseño reutilización Código diseñado para 34 Instalaciones en diseño Conversión múltiples 53 Instalaciones múltiples 55 Aplicación diseñada para cambios Aplicación diseñada para cambios 5 Coste total proyecto: 457000 $ Coste total proyecto: 457000 $ Datos históricos: Esfuerzo estimado: 58 personas-mes Datos históricos: Esfuerzo estimado: 58 personas-mes productividad media de la organización en métricas de anteriores productividad media de la organización en proyectos métricas de anteriores proyectos similares: 6,5 PF/pm proyectos proyectos similares: 6,5 PF/pm Tarifa laboral: 8000 $$ /mes Tarifa laboral: 8000 /mes Coste por PF: 1.230 $$ Coste por PF: 1.230 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 36 / 48
    37. estimación basada en el proceso tema 6 - administración de proyectos estimación basada en el proceso técnica más habitual el proceso se descompone en actividades o tareas y el esfuerzo requerido para llevar a cabo cada tarea pasos: delimitar las funciones obtenidas a partir del ámbito del software actividades del proceso para cada función estimación de esfuerzo (persona-mes) para cada actividad en cada función aplicación de índices de trabajo medios (esfuerzo coste/unidad) al esfuerzo estimado para cada actividad cálculo de costes y esfuerzo de cada función y de la actividad escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 37 / 48
    38. estimación basada en el proceso tema 6 - administración de proyectos Actividades Actividades Entrevistas Planificación Análisis Ingeniería Construcción Evaluación Totales Entrevistas Planificación Análisis Ingeniería Construcción Evaluación Totales riesgo entrega cliente riesgo entrega cliente Tareas Análisis Diseño Código Prueba Tareas Análisis Diseño Código Prueba Función Función IUFC 0,50 2,50 0,40 5,00 n/a 8,40 IUFC 0,50 2,50 0,40 5,00 n/a 8,40 AG2D 0,75 4,00 0,60 2,00 n/a 7,35 AG2D 0,75 4,00 0,60 2,00 n/a 7,35 AG3D 0,50 4,00 1,00 3,00 n/a 8,50 AG3D 0,50 4,00 1,00 3,00 n/a 8,50 GBD 0,50 3,00 1,00 1,50 n/a 6,00 GBD 0,50 3,00 1,00 1,50 n/a 6,00 FIG 0,50 3,00 0,75 1,50 n/a 5,75 FIG 0,50 3,00 0,75 1,50 n/a 5,75 CP 0,25 2,00 0,50 1,50 n/a 4,25 CP 0,25 2,00 0,50 1,50 n/a 4,25 MAD 0,50 2,00 0,50 2,00 n/a 5,00 MAD 0,50 2,00 0,50 2,00 n/a 5,00 Total 0,25 0,25 0,25 3,50 20,50 4,75 16,50 46,00 Total 0,25 0,25 0,25 3,50 20,50 4,75 16,50 46,00 %esfuerzo 1% 1% 1% 8% 45% 10% 36% %esfuerzo 1% 1% 1% 8% 45% 10% 36% Comparación de las distintas estimaciones Comparación de las distintas estimaciones Tarifa laboral: 8000 $$ /mes Tarifa laboral: 8000 /mes Estimación basada en el producto (LDC): 54 pm Estimación basada en el producto (LDC): 54 pm Coste total proyecto: 368.000 $$ Coste total proyecto: 368.000 Estimación basada en el producto (PF): 58 pm Esfuerzo estimado: 46 personas-mes Estimación basada en el producto (PF): 58 pm Esfuerzo estimado: 46 personas-mes Estimación basada en el proceso: 46 pm Estimación basada en el proceso: 46 pm Estimación media: 53 pm Estimación media: 53 pm Variación máxima: 13% Variación máxima: 13% escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 38 / 48
    39. modelos empíricos de estimación tema 6 - administración de proyectos Modelos empíricos de estimación: Utilizan fórmulas derivadas empíricamente para predecir el esfuerzo como una función de LDC o PF. Datos empíricos obtenidos de una muestra de proyectos: difíciles de usar para todas las clases de software y todos los entornos de desarrollo se deben calibrar para las condiciones específicas de una organización A y B: constantes obtenidas empíricamente E = A + B X (ev) c c E: esfuerzo en meses/persona E = A + B X (ev) ev: variable de estimación (LDC o PF) MODELOS BASADOS EN LDC E = 5,2 x (KLDC)0,91 Modelo de Walston-Felix E = 5,2 x (KLDC)0,91 Modelo de Walston-Felix E = 5,5 + 0,73 x (KLDC)1,16 Modelo de Bailey-Basili (KLDC)1,16 E = 5,5 + 0,73 x1,05 Modelo de Bailey-Basili E = 3,2 x (KLDC) 1,05 Modelo simple de Boehm E = 3,2 x (KLDC) 1,047 Modelo simple de Boehm E = 5,288 x (KLDC) 1,047 Modelo Doty para KLDC>9 E = 5,288 x (KLDC) Modelo Doty para KLDC>9 MODELOS BASADOS EN PF E = -13,39 + 0,054 PF Modelo de Albrecht-Gaffney E = -13,39 + 0,054 PF Modelo de Albrecht-Gaffney E = 60,62 x 7,728 x 10-8 PF3 Modelo de Kemerer E = 60,62 x 7,728 x 10-8 PF3 Modelo de Kemerer E = 585,7 + 15,12 PF Modelo de Matson, Barnett E = 585,7 + 15,12 PF Modelo de Matson, Barnett y Mellichamp y Mellichamp escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 39 / 48
    40. modelos empíricos de estimación tema 6 - administración de proyectos MODELO 1 (COCOMO básico) Tres tipos de proyectos: MODELO 1 (COCOMO básico) calcula el esfuerzo y el coste del desarrollo en calcula el esfuerzo y el coste del desarrollo en Orgánicos: relativamente pequeños y sencillos, función del tamaño estimado del programa (LDC). función del tamaño estimado del programa (LDC). en los que trabajan pequeños equipos con Se utiliza para una aproximación rápida al principio Se utiliza para una aproximación rápida al principio experiencia, sobre un conjunto de requisitos del ciclo de vida. del ciclo de vida. poco rígidos. bb ESFUERZO: EE = ab KLDC ESFUERZO: = ab KLDCbb Semiacoplados: proyectos intermedios (en db TIEMPO: D == cb E D c Edb tamaño y complejidad) en los que participan TIEMPO: b equipos con variados niveles de experiencia, y que deben satisfacer requisitos poco o medio rígidos. Empotrados: proyectos que deben ser desarrollados en un conjunto de hardware, MODELO 2 (COCOMO intermedio) MODELO 2 (COCOMO intermedio) software y restricciones operativas muy calcula el esfuerzo y el coste en función del tamaño restringido. calcula el esfuerzo y el coste en función del tamaño estimado del programa y de un conjunto de “guías estimado del programa y de un conjunto de “guías de coste” que incluyen una evaluación de coste” que incluyen una evaluación subjetiva del producto, hardware, personal y atributos subjetiva del producto, hardware, personal y atributos del producto del producto bi ESFUERZO: EE = aKLDCbi xx FAE (factor ESFUERZO: = ai i KLDC FAE (factor MODELO COCOMO BÁSICO MODELO COCOMO BÁSICO de ajuste del esfuerzo) de ajuste del esfuerzo) Proyecto ab bb cb db Proyecto ab bb cb db Orgánico 2,4 1,05 2,5 0,38 Orgánico 2,4 1,05 2,5 0,38 Semiacoplado 3,0 1,12 2,5 0,35 Semiacoplado 3,0 1,12 2,5 0,35 MODELO 3 (COCOMO avanzado) MODELO 3 (COCOMO avanzado) Empotrado 3,6 1,20 2,5 0,32 incorpora las características del mod. 2 y evalúa el Empotrado 3,6 1,20 2,5 0,32 incorpora las características del mod. 2 y evalúa el impacto de los FAE en cada fase del desarrollo. impacto de los FAE en cada fase del desarrollo. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 40 / 48
    41. el riesgo en el desarrollo de software tema 6 - administración de proyectos Riesgo el administrador de proyectos anticipa riesgos que pueden afectar al desarrollo o a la calidad del software y emprende acciones para evitarlos riesgo: probabilidad de que ocurra una circunstancia adversa para el proyecto amenazan el proyecto, el software y la propia organización existen riesgos conocidos, predecibles e impredecibles categorías de riesgos: riesgos del proyecto: afectan al presupuesto, los recursos, la planificación,... riesgos del producto: afectan a la calidad o al rendimiento del software riesgos del negocio: afectan a la organización (riesgos de mercado, estratégicos, de distribución, de pérdida del presupuesto o del personal,...) riesgos que entran en las tres categorías anteriores (por ejemplo, el abandono de un programador experto es un riesgo para el producto, el proyecto y el negocio) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 41 / 48
    42. el riesgo en el desarrollo de software tema 6 - administración de proyectos Ejemplos de posibles riesgos en el desarrollo de software riesgo tipo de riesgo descripción proyecto, rotación de personal con experiencia abandona el proyecto antes de que producto y personal finalice negocio cambio de cambio de administración organizativa con diferentes proyecto administración prioridades no proyecto el hardware necesario para el proyecto no se recibe a tiempo disponibilidad del hardware cambios de proyecto y existencia de más cambios de requerimientos de los previstos requerimientos producto inicialmente retrasos en la proyecto y retrasos en las especificaciones de interfaces esenciales especificación producto subestimación proyecto y el tamaño del sistema se ha subestimado del tamaño producto bajo las herramientas CASE que ayudan al proyecto no tienen el rendimiento de producto rendimiento y las funcionalidades esperadas la herramienta CASE cambio de la tecnología fundamental sobre la que se está construyendo el negocio tecnología sistema es sustituida por una nueva competencia del un producto competitivo se pone en venta antes de que el negocio producto sistema se complete escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 42 / 48
    43. el riesgo en el desarrollo de software tema 6 - administración de proyectos la administración de riesgos es un proceso iterativo que se aplica durante todo el listado de identificación proyecto identificación riesgos de riesgos potenciales de riesgos etapas de la administración de riesgos identificación de riesgos: se identifican los posibles riesgos para el proyecto, el producto y el negocio listado de análisis análisis análisis de riesgos: se valoran las priorización de riesgos de riesgos de riesgos probabilidades y las posibles consecuencias de los riesgos identificados planificación de riesgos: se crean planes para abordar los riesgos, tanto para evitarlos como para minimizar sus efectos anulación de planificación riesgos y supervisión de riesgos: se valora planificación de riesgos planes de constantemente los riesgos y se revisan los de riesgos contingencia planes para su mitigación tan pronto como la información de los riesgos está disponible los resultados de la administración de riesgos se documentan en un plan de supervisión valoración de supervisión administración de riesgos de riesgos riesgos de riesgos fuente: Ingeniería de Software. I. Sommerville, p. 85 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 43 / 48
    44. el riesgo en el desarrollo de software tema 6 - administración de proyectos identificación de riesgos descubrimiento de los posibles riesgos no se valoran o priorizan, aunque no se tienen en cuenta riesgos con consecuencias pequeñas o con baja probabilidad se realiza a través de diversas técnicas (tormentas de ideas, experiencia del administrador,...) tipo de riesgo ejemplos de posibles riesgos la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba tecnología los componentes de software a reutilizar tienen defectos que limitan su funcionalidad imposible contratar personal con los conocimientos requeridos personal personal clave enfermo o no disponible en momentos críticos la organización se reestructura y una nueva administración se responsabiliza del organizativos proyecto los problemas financieros de la organización reducen el presupuesto del proyecto las herramientas CASE generan código ineficiente herramientas las distintas herramientas CASE no se pueden integrar cambios de requerimientos que precisan modificaciones en el diseño requerimientos los clientes no comprenden el impacto de los cambios en los requerimientos el tiempo requerido para desarrollar el software está subestimado estimación la tasa de reparación de defectos está subestimada el tamaño del software está subestimado legales cambian las leyes imponiendo restricciones que no estaban previstas escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 44 / 48
    45. el riesgo en el desarrollo de software tema 6 - administración de proyectos análisis de riesgos se considera cada riesgo por separado y se valora en intervalos su probabilidad e impacto: probabilidad del riesgo valorada como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%) efectos del riesgo valorados como catastrófico, serio, tolerable o insignificante el resultado se coloca en una tabla ordenada por la seriedad del riesgo se decide cuáles son los más importantes (riesgos clave) y que se van a considerar durante el proyecto (por ejemplo, todos los serios o catastróficos con cualquier probabilidad), y que debe ser un número manejable. riesgo probab. efectos los problemas financieros de la organización reducen el presupuesto del proyecto baja catastrófico imposible contratar personal con los conocimientos requeridos alta catastrófico personal clave enfermo o no disponible en momentos críticos moderada serio los componentes de software a reutilizar tienen defectos que limitan su funcionalidad moderada serio cambios de requerimientos que precisan modificaciones en el diseño moderada serio la organización se reestructura y una nueva administración se responsabiliza del alta serio proyecto la base de datos que se utiliza en el sistema no puede procesar tantas transacciones moderada serio por segundo como se esperaba el tiempo requerido para desarrollar el software está subestimado alta serio las distintas herramientas CASE no se pueden integrar alta tolerable los clientes no comprenden el impacto de los cambios en los requerimientos moderada tolerable la tasa de reparación de defectos está subestimada moderada tolerable el tamaño del software está subestimado alta tolerable las herramientas CASE generan código ineficiente moderada insignificante escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 45 / 48
    46. el riesgo en el desarrollo de software tema 6 - administración de proyectos planificación de riesgos se considera cada uno de los riesgos clave identificados y las estrategias para administrarlo, que vendrán dadas por el juicio y la experiencia del administrador del proyecto estrategias de anulación: intentan reducir la probabilidad de que surja el riesgo estrategias de disminución: intentan reducir el impacto del riesgo planes de contingencia: se dispone de ellos para estar preparados por si el riesgo ocurre y poder actuar con una estrategia determinada riesgo estrategia problemas financieros de la preparar un documento breve para la dirección de la empresa que muestra organización que el proyecto hace contribuciones muy importantes a las metas del negocio organizar cursos de capacitación para el personal ya existente, investigar la problemas de reclutamiento posibilidad de contratar en otras regiones o países reorganizar el equipo de tal forma que se solapen el trabajo y los miembros enfermedad del personal del equipo comprendan el trabajo de los demás reemplazar los componentes defectuosos con los comprados de fiabilidad componentes defectuosos conocida rastrear la información para valorar el impacto de los requerimientos, cambios en los requerimientos maximizar la información oculta en ellos preparar un documento breve para la dirección de la empresa que muestra reestructuración organizativa que el proyecto hace contribuciones muy importantes a las metas del negocio investigar la posibilidad de comprar una base de datos con el rendimiento rendimiento de la base de datos preciso tiempo de desarrollo subestimado alertar al cliente de las dificultades potenciales y las posibilidades de retraso escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 46 / 48
    47. el riesgo en el desarrollo de software tema 6 - administración de proyectos supervisión de riesgos valora cada uno de los riesgos identificados para decidir si es más o menos probable y cuándo han cambiado sus posibles efectos hay que controlar factores que pueden indicar cambios en la probabilidad y el impacto tipo de riesgo indicadores potenciales entrega retrasada del hardware o del software tecnología existencia de informes sobre problemas tecnológicos baja moral del personal, malas relaciones entre miembros del equipo, personal disponibilidad de empleo rumores en la empresa organizacional falta de iniciativa de la dirección de la empresa rechazo de los miembros del equipo a utilizar herramientas herramientas quejas sobre las herramientas CASE peticiones de estaciones de trabajo más potentes peticiones de muchos cambios en los requerimientos requerimientos quejas del cliente estimación fracaso en el cumplimiento de los tiempos planificados escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 47 / 48
    48. bibliografía tema 6 - administración de proyectos Sommerville, I. Ingeniería de Software, cap. 4 y 24 (pp. 547-554) Pressman, R.S. Ingeniería del Software. Un enfoque práctico, cap. 4, 5 y 6 Bruegge, B., Dutoit, A.H., Ingeniería del Software Orientado a Objetos, cap. 3 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 48 / 48
    SlideShare Zeitgeist 2009

    + Enrique BarreiroEnrique Barreiro Nominate

    custom

    401 views, 0 favs, 0 embeds more stats

    Transparencias del Tema 5 (Administración de Proye more

    More info about this document

    CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

    Go to text version

    • Total Views 401
      • 401 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 37
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories