Upload
enrique-martinez
View
49
Download
4
Embed Size (px)
Citation preview
tema 6 – administración deproyectos
enrique barreirodepartamento de informática
universidade de vigo
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
2 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
introducción a la 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 utilizadotécnicas de administración derivadas de otras disciplinas de la ingenieríapoco efectivas para el desarrollo de software
desarrollos profesionales de software
imprescindible la administración: restricciones de presupuesto, recursos y calendario
responsabilidad del administrador de proyectosplanificación y calendario del proyectosupervisió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ónel producto es intangible: no se puede ver físicamente el progreso del productono existen procesos de software estándar según tipos de productosproyectos “únicos”: diferencias con proyectos previos, evolución tecnológica de la informática y las comunicaciones,...
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
3 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
actividades de la administración
la administración puede variar mucho según la organización, tipo de producto, etc.
actividades responsabilidad de los administradoresredacción de propuestas de desarrollo
objetivos del proyecto y cómo se va a desarrollarincluye 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 proyectoactividad continuaconocimiento del progresocomparación de progreso y coste con lo planificadomecanismos formales e informales
selección y evaluación del personal
redacción y presentación de informesinformes para el cliente, organizaciones contratantes e internosdocumentos concisos y coherentespresentaciones en las revisiones de progresoadministrador: necesidad de comunicación efectiva oral y escrita
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
4 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
actividades de la administración
el administrador tiene tres grandes áreas de actuación
personalparticipantes en el proyecto (ingenieros, programadores, clientes,...)jefes de equipoestructura 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,...)
procesoelección de un modelo de desarrollocontrolar la evolución del problema y el procesodescomposición del proceso en actividades y tareas
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
5 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
personal del proyecto
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 equipomotivación por el éxito del grupo y por las propias metas personalesresponsabilidad 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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
6 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
personal del proyecto: composición del grupo
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écnicosproblemas: 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
RACIONAL
INT
RO
VE
RT
IDO
EX
TR
OV
ER
TID
O
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
los estilos de trabajo afectan a la interacción entre clientes, desarrolladores y usuarios
implican la elección de un trabajador para una tarea dada. Por ejemplo:
intuitivos prefieren análisis y diseño (requieren ideas nuevas) al mantenimiento (requiere atención a los detalles y análisis de resultados complejos)
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
7 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
personal del proyecto: cohesión del grupo
cohesión del grupoel 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 exterioresesto hace que el grupo sea robusto y se pueda enfrentar a problemas y situaciones inesperadas
ventajasse puede desarrollar un estándar de calidad en el grupolos miembros se trabajan de forma cercana, fomentando el aprendizaje mutuolos miembros conocen el trabajo de los demás, lo que facilita la continuidad si un miembro abandona el grupoprogramación “sin ego”. los programas se consideran propiedad del grupo, no personal
factores que influyen en la cohesióncultura organizacional y personalidades del grupodemostrar confianza y facilitar acceso a la informaciónsentido de identidad (nombre y establecimiento de un territorio)involucrados en actividades de grupo (deportes, juegos,...)
problemasresistencia al cambio de liderazgo por alguien externopensamiento de grupo y “corporativismo”: la consideración de alternativas se reemplaza por lealtad a las normas y decisiones del grupo
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
8 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
personal del proyecto: comunicación
comunicación en el grupoimportante para el progreso del proyecto
factores que influyentamañ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 estatusestructura del grupo: los grupos informales se comunican de forma más efectiva que los jerárquicos y formalescomposición del grupo:
choques entre miembros con los mismos tipos de personalidadmejor comunicación en grupos de ambos sexos que en grupos de un solo sexo
entorno de trabajo físicoprivacidad (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)
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
9 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
personal del proyecto: organización del grupo
organización del grupo
factores que influyen en la estructura más adecuadaexperiencia y estilos de trabajo de los miembrostamaño del grupoestilos de gestión de clientes y desarrolladores
principales tipos de estructura organizativaestructura formal y jerárquica
jerarquías clarascomunicación verticalasignación de responsabilidades
estructura informalestructura democrática y decisiones por consensotareas asignadas por habilidad y experienciamejor cohesión y rendimientoejemplo: “programación extrema”
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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
10 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
personal del proyecto: organización del grupo
estructura formal: Equipo del Jefe de Programadores, Chief Programmer Team
jefe de programadores (JP): responsable del diseño, desarrollo y pruebas de instalaciónlos demás informan al JP, quien tiene la última palabra en cada decisiónsupervisa a los demás, diseña programas, asigna tareas a los otros miembros del equipo
otros miembrosayudante JP: apoya al JP y lo reemplaza cuando es necesario, responsable de la validación del softwarebibliotecario: 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,...especialistas que trabajan temporal o permanentemente en el grupo:
programadoresespecialistas en sistemas operativosingenieros de pruebas...
fundamento: grandes diferencias entre habilidades de programación (hasta 25 veces más productivos unos que otros)
problemasno abunda el personal adecuado para ser JP (“superprogramador”)problemas de autoestima del resto del equipolos proyectos se resienten si el JP o el ayudante se vanmodelo difícil de acomodar en las estructuras organizacionales
Jefe deprogramadores
Ayudante JP
Programadoresexpertos Bibliotecario Administrador
Equipo depruebasProgramadores
noveles
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
11 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación del proyecto
la administración efectiva depende de una completa planificación del progreso del proyecto
plan: hilo conductor del proyecto
anticipación de los problemas que pueden surgir
preparación de soluciones a esos problemas
el plan inicial evoluciona según el progreso del proyecto y la disponibilidad de información
enfoque pesimista al elaborar suposiciones y calendario: necesidad de disponer de holguras
Valores iniciales parámetros proy ecto
Def inir hitos y productos a entregar
Establecer programación en el tiempo del proy ecto
Iniciar activ idades según la programación
Esperar un tiempo (entre 2 y 3 semanas)
Rev isar progreso proy ecto
Rev isar estimaciones de los parámetros
Actualizar programación
Renegociar restricciones y productos a entregar
Iniciar rev isión técnica y posible rev isión
proy ecto no completado ni cancelado
existen retrasos
no existen retrasos
proy ecto completado o cancelado
negociación sin éxitonegociación con éxito
Establecer restricciones proy ecto
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
12 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación del proyecto
plan del proyectoapartados habituales del plan del proyecto
1. introducción: objetivos, restricciones,...2. organización del proyecto3. análisis de riesgo: riesgos, probabilidades de que ocurran, estrategias de
reducción,...4. requerimientos de recursos de hardware y software5. división del trabajo: identificación de actividades, hitos y productos a
entregar asociados a cada actividad6. 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 proyectopartes 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 planesplan de calidad
plan de validación
plan de administración de la configuración
plan de mantenimiento
plan de desarrollo del personal
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
13 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación del proyecto
hitos y productos a entregar
información a los administradoresdocumentos que describen el estado del softwarepermite juzgar el proceso y actualizar costes y calendario
establecimiento de hitospuntos finales de una actividad o tarea del proceso del softwaredocumentación que se presenta al administrador: informes cortos de los logros en una actividadrepresentan el fin de una etapa lógica en el proyecto
productos a entregarresultado 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)
Estudioviabilidad
Especificaciónrequerim. sistema
Estudiodel diseño
Desarrolloprototipos
Análisis derequerim.
informeviabilidad
requerim.usuarios
informeevaluación
diseñoarquitectónico
requerim.sistema
ACTIVIDADES
HITOS
PRODUCTO
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
14 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación temporal
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 obraasignan 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 inicialproblemas no previstos: incrementar un 20%
utilización de diagramas de Gantt y redes de actividades
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
15 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación temporal
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)
camino crítico
trayectoria más larga en la red de actividad
el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto)
los retrasos en las demás actividades no afectan necesariamente al proyecto
T1T1
T4
T2
INICIO
M1
M3
M5
M2 T5
T8
T7
T6
T3T3
M4
T9T9
M7
FINAL
T10
M6
T11T11
M8
T12T12
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/0211/8/02
19/9/02
RED DE ACTIVIDADES
hito
fuente: Ingeniería de Software, I. Sommerville, pp. 80-83
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
16 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación temporal
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
M1T7
T3
M5
T8
M3
M2
T6
M4
T9
M7
T10
M6
T11M8
T12
DIAGRAMA DE GANTT
flexibilidad en la fecha de finalización
la calendarización inicial será, con toda seguridad, incorrecta.
durante el desarrollo se deben comparar las estimaciones previas con las reales para revisar la calendarización del resto del proyecto.
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.
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
17 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación temporal
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
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 personasa 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,...
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
18 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
“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étricascualquier 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 Standard Glossary of Software Engineering, 1993)
Ejemplos:métricas para calcular el tamaño del un producto en líneas de códigométricas de la claridad de un párrafo en un texto escrito, por ejemplo, en un manual (índice de Fog)número de errores localizados en un producto software entregadonúmero de personas-día necesarias para desarrollar un componente...
Se aplican a: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
Proceso desoftware
Proceso desoftware Producto de
software
Producto desoftware
Métricas depredicción
Métricas depredicciónMétricas de
control
Métricas decontrol
Decisionesadministrativas
Decisionesadministrativas
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
19 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
el proceso de mediciónseleccionar medidas a realizar
formular preguntas que la medición intenta responderdefinir las métricas requeridas para responder a esas preguntasno se recogen otras métricas que no respondan a esas preguntas
seleccionar componentes a valorarno es necesario ni deseable estimar los valores de las métricas de todo un sistema de software
conjunto representativocomponentes críticos y fundamentales (utilización continua)
medir características de los componentescalcular los valores de las métricas procesando la representación del componente (diseño, código,...) con herramientas adecuadas
identificar componentes anómaloscomparación de los resultados con mediciones previas registradas en una base de datosatención especial a los valores más altos y más bajos pues pueden indicar problemas.
analizar componentes con valores anómalosse examinan los componentes para decidir si los valores obtenidos indican que su calidad está en peligro.no siempre indican problemas (por ejemplo, la complejidad de un módulo puede ser alta pero necesaria)
Elegir medidasa realizar
Elegir medidasa realizar
Seleccionarcomponentes a
valorar
Seleccionarcomponentes a
valorar
Medircaracterísticas
de los componentes
Medircaracterísticas
de los componentes
Identificarmedidas
anómalas
Identificarmedidas
anómalas
Analizarcomponentes
anómalos
Analizarcomponentes
anómalos
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
20 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
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 productodinámicas
recogidas por las mediciones hechas en un programa en ejecuciónrelación directa con los atributos de calidad del software ejemplo: medición de tiempo de ejecución como medida de la eficiencia del sistemaejemplo: registro del número y tipo de caídas del sistema y relación con la fiabilidad del software
estáticasrecogidas por las mediciones hechas en las representaciones del sistema (diseño, código, documentación,...)relación indirecta con los atributos de calidad del softwareejemplo: longitud del programa como predictor de la mantenibilidad o la complejidadejemplo:índice de Fog como predictor de la facilidad de comprensión de un documento de texto
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
21 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
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 FogMedida 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.
Ejemplos de métricas estáticas del producto
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
22 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
23 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
métricas orientadas a objetos: métricas CK (Chidamber y Kemerer)
métrica descripción
métodos ponderados por clase (MPC)
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.
MPC = Σci 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.
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
24 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
Botón OK
Ventana
tamañoanchonombre_clientefecha_emisióntotalcompras
mostrar_factura()
Caja de texto
Cartas_reclamoFactura
fecha_emisión : Datefecha_pago : Date
precio()impuesto()cliente()lista_compras()
Compra
fechatasa_impuesto
precio()impuesto()
1
1..*
1
1..*
1
0..*
1
1..*1..*0Métrica factura compra cartas_
reclamobotó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 - - - - - -
fuente: Ingeniería de software. Teoría y práctica. S.L. Pfleeger, p. 34
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
25 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
métricas del procesodatos cuantitativos de los procesos del software
la recolección de métricas del proceso es esencial para la mejora del mismo, incluso en proyectos a pequeña escala
se utilizan para evaluar la eficiencia de un proceso o si ésta ha mejorado ha mejorado con los cambios realizados
tres tipos de métricas de procesotiempo requerido para completar un proceso en particular: total del proyecto, por ingeniero, por actividad,...recursos requeridos para un proceso en particular: esfuerzo en personas-día, costes de viajes, recursos de hardware,...número de ocurrencias de un evento particular:
número de defectos descubiertos durante la revisión del código, número de peticiones de cambio en requerimientos, número promedio de líneas de código (LDC) modificadas en respuesta a un cambio de requerimientos,...errores detectados por el usuario...
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
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.
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 dedesarrollo
Característicasdel cliente(comunicación)
DETERMINANTES DE LA CALIDADDEL SOFTWARE Y DE LAEFECTIVIDAD DE LAORGANIZACIÓN
Condicionesdel negocio (fechas, reglas,...)
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
26 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
medición y métricas del software
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 demetas (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 experienciamedir número de comunicaciones formales entre cliente y analista para cada cambio de requerimientosmedir el número de pruebas requeridas para provocar una caída en el producto
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
27 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
PLANIFICACIÓNPLANIFICACIÓN
planificació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óndelimitación del ámbito del softwareestimación de recursos necesarios (humanos, hardware, software,...)
ESTIMACIÓNESTIMACIÓN RIESGORIESGOEXPERIENCIA
EXPERIENCIA
DATOSHISTÓRICOS
DATOSHISTÓRICOS
Complejidad basada enesfuerzos pasados
Grado de estructuración
Tamaño del esfuerzo
Ámbito de bajoriesgo
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
28 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación de proyectos: ámbito
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 softwareestudiar la viabilidad del proyectorealizar estimaciones de recursos necesarios
ÁMBITO DELSOFTWARE
RENDIMIENTO
RESTRICCIONES
INTERFACES
FIABILIDAD
FUNCIÓN
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
29 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación de proyectos: recursos
estimación de recursos
se especifica cada recurso mediante cuatro característicasdescripcióninforme de disponibilidadfecha cronológica en la que se requiere el recursotiempo durante el que será aplicado
Especificar:•Habilidades requeridas•Disponibilidad•Duración tareas.•Fecha comienzo
Especificar:•Descripción•Disponibilidad•Duración del uso•Fecha de distribución
Personas
Herramientashardware/software
Componentessoftware
reutilizables
•Componentes desarrollados•Componentes experimentados•Componentes con experiencia parcial.•Componentes nuevos
RECURSOS
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
30 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación de proyectos: estimación
estimación del esfuerzo y coste de un proyectonormalmente el problema es demasiado complejo. Se utilizan diferentes técnicas:
descomposición del problemadescomposición del proceso
antes de hacer estimaciones de esfuerzo y costeconocer el ámbito del softwarerealizar 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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
31 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación de proyectos: estimación
tamaño del software
dos tipos de enfoquedirecto: se utilizan las LDC para medir el tamañoindirecto: el tamaño se representa mediante puntos de función (PF)
problemas de la utilización de LDCno existe definición estándar de LDC (p.ej., ¿se consideran LDC los comentarios?)líneas físicas o lógicascontabilización del código reutilizableaplicaciones en diferentes lenguajesestilos individuales de programación
relación entre LDC y PF: depende del lenguaje escogido
Lenguaje LDC/PF (media)
Ensamblador 320C 128Cobol 105Fortran 105Pascal 90Ada 70Lenguajes OO 30L4G 20Lenguajes visuales 4
Lenguaje LDC/PF (media)
Ensamblador 320C 128Cobol 105Fortran 105Pascal 90Ada 70Lenguajes OO 30L4G 20Lenguajes visuales 4
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
32 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
planificación de proyectos: estimación
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
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
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 medidaParámetro de medida CuentaCuenta SimpleSimple MedioMedio ComplejoComplejo
Factor de pesoFactor de peso
Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 5
0- Sin influencia1- Incidental2- Moderado3- Medio4- Significativo5- Esencial
1.¿Requiere el sistema copias de seguridad fiables?2.¿Se requieren comunicaciones de datos?3.¿Existen funciones de procesamiento distribuido?4.¿Es crítico el rendimiento?5.¿Será ejecutado el sistema en un entorno operativo existente y utilizado?6.¿Se requiere entrada de datos interactiva?7.¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?8.¿Se actualizan los archivos maestros de forma interactiva?9.¿Son complejas las entradas, las salidas, los archivos o 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 instalación?13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?14.¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario?
PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]
Fi : valores de ajuste de complejidad
PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]
Fi : valores de ajuste de complejidad
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
33 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
estimación basada en el problema
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:
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)
ejemplo: VE = (Sopt + 4Sm + Spes)/6
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
34 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
estimación basada en el problema
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 F2aplicació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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
35 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
estimación basada en el problema (LDC)
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.
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)
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: 4600más probable: 6900pesimista: 8600
Estimación en LDC de AG3D:optimista: 4600más probable: 6900pesimista: 8600
VE = (Sopt + 4Sm + Spes)/6VE = (Sopt + 4Sm + Spes)/6
Función LDC estimada
IUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400Total 33200
Función LDC estimada
IUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400Total 33200
Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pm
Tarifa laboral: 8000 $ /mes
Coste LDC: 13 $
Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pm
Tarifa laboral: 8000 $ /mes
Coste LDC: 13 $
de
sco
mp
osi
ció
nd
e f
un
cio
ne
s
de
sco
mp
osi
ció
nd
e f
un
cio
ne
s
mé
tric
as
de
pro
yect
os
an
terio
res
mé
tric
as
de
pro
yect
os
an
terio
res
Coste total proyecto: 431000 $
Esfuerzo estimado: 54 personas-mes
Coste total proyecto: 431000 $
Esfuerzo estimado: 54 personas-mes
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
36 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
estimación basada en el problema (PF)
Valor dominio información
Opt. Probable Pesimista Cuenta est
Peso Cuenta 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 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5
Copia de seguridad y recuperación 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5
PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)
PF estimado = 372PF estimado = 372
Coste total proyecto: 457000 $
Esfuerzo estimado: 58 personas-mes
Coste total proyecto: 457000 $
Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pm
Tarifa laboral: 8000 $ /mes
Coste por PF: 1.230 $
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é
tric
as
de
pro
yect
os
an
terio
res
mé
tric
as
de
pro
yect
os
an
terio
res
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
37 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
estimación basada en el proceso
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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
38 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
estimación basada en el proceso
Actividades Entrevistas Planificación Análisis
riesgo Ingeniería Construcción
entrega Evaluación
cliente Totales
Tareas Análisis Diseño Código Prueba Función IUFC AG2D AG3D GBD FIG CP MAD
0,50 0,75 0,50 0,50 0,50 0,25 0,50
2,50 4,00 4,00 3,00 3,00 2,00 2,00
0,40 0,60 1,00 1,00 0,75 0,50 0,50
5,00 2,00 3,00 1,50 1,50 1,50 2,00
n/a n/a n/a n/a n/a n/a n/a
8,40 7,35 8,50 6,00 5,75 4,25 5,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%
Actividades Entrevistas Planificación Análisis
riesgo Ingeniería Construcción
entrega Evaluación
cliente Totales
Tareas Análisis Diseño Código Prueba Función IUFC AG2D AG3D GBD FIG CP MAD
0,50 0,75 0,50 0,50 0,50 0,25 0,50
2,50 4,00 4,00 3,00 3,00 2,00 2,00
0,40 0,60 1,00 1,00 0,75 0,50 0,50
5,00 2,00 3,00 1,50 1,50 1,50 2,00
n/a n/a n/a n/a n/a n/a n/a
8,40 7,35 8,50 6,00 5,75 4,25 5,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%
Tarifa laboral: 8000 $ /mes
Coste total proyecto: 368.000 $
Esfuerzo estimado: 46 personas-mes
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%
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%
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
39 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
modelos empíricos de estimación
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 desarrollose deben calibrar para las condiciones específicas de una organización
E = A + B X (ev) cE = A + B X (ev) c
A y B: constantes obtenidas empíricamenteE: esfuerzo en meses/personaev: variable de estimación (LDC o PF)
E = 5,2 x (KLDC)0,91 Modelo de Walston-FelixE = 5,5 + 0,73 x (KLDC)1,16 Modelo de Bailey-BasiliE = 3,2 x (KLDC)1,05 Modelo simple de BoehmE = 5,288 x (KLDC)1,047 Modelo Doty para KLDC>9
E = 5,2 x (KLDC)0,91 Modelo de Walston-FelixE = 5,5 + 0,73 x (KLDC)1,16 Modelo de Bailey-BasiliE = 3,2 x (KLDC)1,05 Modelo simple de BoehmE = 5,288 x (KLDC)1,047 Modelo Doty para KLDC>9
MODELOS BASADOS EN LDC
E = -13,39 + 0,054 PF Modelo de Albrecht-GaffneyE = 60,62 x 7,728 x 10-8 PF3 Modelo de KemererE = 585,7 + 15,12 PF Modelo de Matson, Barnett
y Mellichamp
E = -13,39 + 0,054 PF Modelo de Albrecht-GaffneyE = 60,62 x 7,728 x 10-8 PF3 Modelo de KemererE = 585,7 + 15,12 PF Modelo de Matson, Barnett
y Mellichamp
MODELOS BASADOS EN PF
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
40 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
Tres tipos de proyectos:
Orgánicos: relativamente pequeños y sencillos, en los que trabajan pequeños equipos con experiencia, sobre un conjunto de requisitos poco rígidos.
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.
Empotrados: proyectos que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido.
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 principiodel ciclo de vida.
ESFUERZO: E = ab KLDCbb
TIEMPO: D = cb Edb
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 principiodel ciclo de vida.
ESFUERZO: E = ab KLDCbb
TIEMPO: D = cb Edb
MODELO 2 (COCOMO intermedio)calcula el esfuerzo y el coste en función del tamañoestimado del programa y de un conjunto de “guíasde coste” que incluyen una evaluación subjetiva del producto, hardware, personal y atributos del producto
ESFUERZO: E = ai KLDCbi x FAE (factorde ajuste del esfuerzo)
MODELO 2 (COCOMO intermedio)calcula el esfuerzo y el coste en función del tamañoestimado del programa y de un conjunto de “guíasde coste” que incluyen una evaluación subjetiva del producto, hardware, personal y atributos del producto
ESFUERZO: E = ai KLDCbi x FAE (factorde ajuste del esfuerzo)
MODELO 3 (COCOMO avanzado)incorpora las características del mod. 2 y evalúa elimpacto de los FAE en cada fase del desarrollo.
MODELO 3 (COCOMO avanzado)incorpora las características del mod. 2 y evalúa elimpacto de los FAE en cada fase del desarrollo.
MODELO COCOMO BÁSICO
Proyecto ab bb cb db
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
MODELO COCOMO BÁSICO
Proyecto ab bb cb db
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
modelos empíricos de estimación
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
41 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo en el desarrollo de software
Riesgoel 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 softwareriesgos 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)
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
42 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo 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
Ejemplos de posibles riesgos en el desarrollo de software
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
43 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo en el desarrollo de software
la administración de riesgos es un proceso iterativo que se aplica durante todo el proyecto
etapas de la administración de riesgosidentificación de riesgos: se identifican los posibles riesgos para el proyecto, el producto y el negocio
análisis de riesgos: se valoran las 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
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
los resultados de la administración de riesgos se documentan en un plan de administración de riesgos
supervisiónde riesgos
supervisiónde riesgos
planificación de riesgos
planificación de riesgos
análisis de riesgos
análisis de riesgos
identificaciónde riesgos
identificaciónde riesgos
valoración deriesgos
anulación deriesgos yplanes de
contingencia
listado depriorizaciónde riesgos
listado deriesgos
potenciales
fuente: Ingeniería de Software. I. Sommerville, p. 85
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
44 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo en el desarrollo de software
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
tecnologíala base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperabalos componentes de software a reutilizar tienen defectos que limitan su funcionalidad
personal imposible contratar personal con los conocimientos requeridospersonal clave enfermo o no disponible en momentos críticos
organizativosla organización se reestructura y una nueva administración se responsabiliza del proyectolos problemas financieros de la organización reducen el presupuesto del proyecto
herramientas las herramientas CASE generan código ineficientelas distintas herramientas CASE no se pueden integrar
requerimientos cambios de requerimientos que precisan modificaciones en el diseñolos clientes no comprenden el impacto de los cambios en los requerimientos
estimaciónel tiempo requerido para desarrollar el software está subestimadola tasa de reparación de defectos está subestimadael tamaño del software está subestimado
legales cambian las leyes imponiendo restricciones que no estaban previstas
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
45 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo en el desarrollo de software
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 insignificanteel 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 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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
46 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo en el desarrollo de software
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 riesgoestrategias de disminución: intentan reducir el impacto del riesgoplanes 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 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
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
47 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
el riesgo en el desarrollo de software
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
tecnología entrega retrasada del hardware o del softwareexistencia de informes sobre problemas tecnológicos
personal baja moral del personal, malas relaciones entre miembros del equipo, disponibilidad de empleo
organizacional rumores en la empresafalta de iniciativa de la dirección de la empresa
herramientasrechazo de los miembros del equipo a utilizar herramientasquejas sobre las herramientas CASEpeticiones de estaciones de trabajo más potentes
requerimientos peticiones de muchos cambios en los requerimientosquejas del cliente
estimación fracaso en el cumplimiento de los tiempos planificados
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
48 / 48escuela superior de ingeniería informática
ingeniería del software de gestión
bibliografía
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