Admon De Proyectos

3,412 views
3,240 views

Published on

admón de proyectos

Published in: Education, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,412
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
197
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Admon De Proyectos

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

×