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

introducción a la administración de proyectos
tema 6 - administración de proyectos
años 60 y 70: fracaso de muchos grandes proyectos de software
retrasos en las entregas, problemas de fiabilidad, costes más
elevados de lo previsto, poco eficiente,...
motivo principal: enfoque de administración utilizado
técnicas de administración derivadas de otras disciplinas de la ingeniería
poco efectivas para el desarrollo de software
desarrollos profesionales de software
imprescindible la administración: restricciones de presupuesto,
recursos y calendario
responsabilidad del administrador de proyectos
planificación y calendario del proyecto
supervisión del trabajo (aplicación de estándares)
supervisión del progreso (cumplimiento de tiempo y presupuesto)
la naturaleza de la ingeniería de software dificulta la administración
el producto es intangible: no se puede ver físicamente el progreso del
producto
no existen procesos de software estándar según tipos de productos
proyectos “únicos”: diferencias con proyectos previos, evolución
tecnológica de la informática y las comunicaciones,...
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 48

actividades de la administración
tema 6 - administración de proyectos
la administración puede variar mucho según la organización,
tipo de producto, etc.
actividades responsabilidad de los administradores
redacción de propuestas de desarrollo
objetivos del proyecto y cómo se va a desarrollar
incluye estimaciones de coste, tiempo, asignación a equipos,...
planificación y calendario del proyecto: identificación de actividades,
hitos y entregas del proyecto
estimación económica del proyecto
supervisión y revisión del proyecto
actividad continua
conocimiento del progreso
comparación de progreso y coste con lo planificado
mecanismos formales e informales
selección y evaluación del personal
redacción y presentación de informes
informes para el cliente, organizaciones contratantes e internos
documentos concisos y coherentes
presentaciones en las revisiones de progreso
administrador: necesidad de comunicación efectiva oral y escrita
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 3 / 48

actividades de la administración
tema 6 - administración de proyectos
el administrador tiene tres grandes áreas de actuación
personal
participantes en el proyecto (ingenieros, programadores,
clientes,...)
jefes de equipo
estructura del equipo de desarrollo
problema
ámbito del software: función, rendimiento, restricciones, datos
de entrada y salida,...
descomposición del problema en subproblemas (subsistemas,
funciones,...)
proceso
elección de un modelo de desarrollo
controlar la evolución del problema y el proceso
descomposición del proceso en actividades y tareas
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 4 / 48

personal del proyecto
tema 6 - administración de proyectos
trabajo en grupo:
equipos de distintos tamaños (desde 2 a varios cientos)
los grandes equipos se dividen en grupos por subproyectos o
subsistemas (normalmente de un máximo de ocho)
imprescindible espíritu de equipo
motivación por el éxito del grupo y por las propias metas
personales
responsabilidad de los administradores
factores que influyen en el trabajo en grupo
composición del grupo
cohesión del grupo
comunicación del grupo
organización del grupo
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 5 / 48

personal del proyecto: composición del grupo
tema 6 - administración de proyectos
composición del grupo
los ingenieros de software tienen una especial motivación por su
trabajo
ideas propias sobre la resolución de problemas técnicos
problemas: ignorar estándares de interfaz, rediseño de sistemas al
codificar, embellecimiento innecesario y personal del sistema,...
importante seleccionar los miembros correctos para un grupo
preferible un grupo con personalidades complementarias que uno
seleccionado únicamente por su habilidad técnica
INTUITIVO
Intuitivo introvertido Intuitivo extrovertido
los estilos de trabajo afectan
pregunta a otros dice a los otros
a la interacción entre clientes,
EXTROVERTIDO
INTROVERTIDO
utiliza sentimientos utiliza sentimientos desarrolladores y usuarios
y reacciones y reacciones
emocionales emocionales implican la elección de un
trabajador para una tarea
dada. Por ejemplo:
Racional introvertido Racional extrovertido
intuitivos prefieren análisis y
pregunta a otros dice a los otros
diseño (requieren ideas
nuevas) al mantenimiento
decide lógicamente decide lógicamente
(requiere atención a los
detalles y análisis de
resultados complejos)
RACIONAL
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 6 / 48

personal del proyecto: cohesión del grupo
tema 6 - administración de proyectos
cohesión del grupo
el grupo piensa en sí mismo como un equipo más que como una
colección de individuos que trabajan juntos
miembros
leales al grupo
identificados con las metas y con los demás miembros,
protegen al grupo de interferencias exteriores
esto hace que el grupo sea robusto y se pueda enfrentar a problemas y
situaciones inesperadas
ventajas
se puede desarrollar un estándar de calidad en el grupo
los miembros se trabajan de forma cercana, fomentando el aprendizaje
mutuo
los miembros conocen el trabajo de los demás, lo que facilita la continuidad
si un miembro abandona el grupo
programación “sin ego”. los programas se consideran propiedad del grupo,
no personal
factores que influyen en la cohesión
cultura organizacional y personalidades del grupo
demostrar confianza y facilitar acceso a la información
sentido de identidad (nombre y establecimiento de un territorio)
involucrados en actividades de grupo (deportes, juegos,...)
problemas
resistencia al cambio de liderazgo por alguien externo
pensamiento de grupo y “corporativismo”: la consideración de alternativas
se reemplaza por lealtad a las normas y decisiones del grupo
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 7 / 48

personal del proyecto: comunicación
tema 6 - administración de proyectos
comunicación en el grupo
importante para el progreso del proyecto
factores que influyen
tamaño del equipo: hay n(n-1)/2 vínculos de
comunicación (n: número de miembros). Unas
son bidireccionales y otras unidireccionales,
según el estatus
estructura del grupo: los grupos informales se
comunican de forma más efectiva que los
jerárquicos y formales
composición del grupo:
choques entre miembros con los mismos tipos de
personalidad
mejor comunicación en grupos de ambos sexos
que en grupos de un solo sexo
entorno de trabajo físico
privacidad (concentración y trabajo sin
interrupción)
conciencia del exterior (luz natural y vista del
entorno exterior)
personalización del entorno
áreas comunes y de reuniones (formales e
informales)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 8 / 48

personal del proyecto: organización del grupo
tema 6 - administración de proyectos
organización del grupo
factores que influyen en la estructura más adecuada
experiencia y estilos de trabajo de los miembros
tamaño del grupo
estilos de gestión de clientes y desarrolladores
principales tipos de estructura organizativa
estructura formal y jerárquica
jerarquías claras
comunicación vertical
asignación de responsabilidades
estructura informal
estructura democrática y decisiones por consenso
tareas asignadas por habilidad y experiencia
mejor cohesión y rendimiento
ejemplo: “programación extrema”
Comparación de estructuras organizativas
Fuertemente estructuradas Escasamente estructuradas
Proyectos con elevada certeza, estabilidad y
Proyectos con incertidumbre (p.e., cambio
uniformidad (requieren menos
en requerimientos)
comunicación)
Repetición Necesidad de entrevistas
Grandes proyectos Técnicas o tecnologías nuevas
Pequeños proyectos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 9 / 48

personal del proyecto: organización del grupo
tema 6 - administración de proyectos
estructura formal: Equipo del Jefe de
Programadores, Chief Programmer Team
jefe de programadores (JP):
responsable del diseño, desarrollo y pruebas de instalación
Jefe de los demás informan al JP, quien tiene la última palabra en
cada decisión
programadores
supervisa a los demás, diseña programas, asigna tareas a
los otros miembros del equipo
otros miembros
ayudante JP: apoya al JP y lo reemplaza cuando es
Ayudante JP
necesario, responsable de la validación del software
bibliotecario: da soporte al equipo encargándose de la
gestión de configuración (mantenimiento de la
documentación, versiones,...), compila, ejecuta pruebas
preliminares de módulos y objetos,...
Programadores especialistas que trabajan temporal o permanentemente
Bibliotecario Administrador
expertos en el grupo:
programadores
especialistas en sistemas operativos
Equipo de
Programadores pruebas ingenieros de pruebas
noveles ...
fundamento: grandes diferencias entre habilidades de
programación (hasta 25 veces más productivos unos
que otros)
problemas
no abunda el personal adecuado para ser JP
(“superprogramador”)
problemas de autoestima del resto del equipo
los proyectos se resienten si el JP o el ayudante se van
modelo difícil de acomodar en las estructuras
organizacionales
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 10 / 48

planificación del proyecto
Establecer restricciones Valores iniciales Def inir hitos y
tema 6 - administración de proyectos
proy ecto parámetros proy ecto productos a entregar
Establecer programación
en el tiempo del proy ecto
la administración efectiva depende
de una completa planificación del
Iniciar activ idades según la
progreso del proyecto
programación
plan: hilo conductor del proyecto
anticipación de los problemas que
Esperar un tiempo
pueden surgir
(entre 2 y 3 semanas)
preparación de soluciones a esos
problemas
Rev isar progreso
proy ecto
el plan inicial evoluciona según el
progreso del proyecto y la
disponibilidad de información
Rev isar estimaciones
de los parámetros
enfoque pesimista al elaborar
suposiciones y calendario:
necesidad de disponer de holguras
Actualizar
programación
existen retrasos Renegociar restricciones y
productos a entregar
no existen retrasos
negociación con éxito negociación sin éxito
Iniciar rev isión técnica
y posible rev isión
proy ecto no completado ni cancelado
proy ecto completado o cancelado
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 11 / 48

planificación del proyecto
tema 6 - administración de proyectos
plan del proyecto
apartados habituales del plan del proyecto
1. introducción: objetivos, restricciones,...
2. organización del proyecto
3. análisis de riesgo: riesgos, probabilidades de que ocurran, estrategias de
reducción,...
4. requerimientos de recursos de hardware y software
5. división del trabajo: identificación de actividades, hitos y productos a
entregar asociados a cada actividad
6. programa del proyecto: dependencias entre actividades, tiempo estimado
para cada hito, asignación de personal a las actividades,...
7. mecanismos de supervisión e informe: descripción de la administración de
informes, cuándo deben producirse,...
revisión regular durante el proyecto
partes que cambian frecuentemente (p.e. calendario) y otras más
estables (p.e. presupuesto)
organización documental que permita reemplazar fácilmente las secciones
otros planes
plan de calidad
plan de validación
plan de administración de la configuración
plan de mantenimiento
plan de desarrollo del personal
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 12 / 48

planificación del proyecto
tema 6 - administración de proyectos
hitos y productos a entregar
información a los administradores
documentos que describen el estado del software
permite juzgar el proceso y actualizar costes y calendario
establecimiento de hitos
puntos finales de una actividad o tarea del proceso del software
documentación que se presenta al administrador: informes cortos de los
logros en una actividad
representan el fin de una etapa lógica en el proyecto
productos a entregar
resultado que se entrega al cliente al final de una actividad principal del
proceso (análisis, diseño,...)
los productos son hitos, pero los hitos no son necesariamente productos a
entregar (resultados internos utilizados por el administrador)
Estudio Análisis de Desarrollo Estudio Especificación
ACTIVIDADES viabilidad requerim. prototipos del diseño requerim. sistema
informe requerim. informe diseño requerim.
HITOS
viabilidad usuarios evaluación arquitectónico sistema
PRODUCTO
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 13 / 48

planificación temporal
tema 6 - administración de proyectos
calendario
dividir el proyecto en actividades
estimar el tiempo necesario para realizarlas (algunas se
harán en paralelo)
los administradores
coordinan las actividades
organizan el trabajo para optimizar la mano de obra
asignan y planifican recursos (personal, hardware, software,
presupuesto para viajes,...)
duración aconsejable de una actividad: entre 1 y 8 semanas
importante tener en cuenta posibles problemas (personal,
hardware, software,...) que provocan retrasos
problemas previstos: incrementar un 30% la estimación inicial
problemas no previstos: incrementar un 20%
utilización de diagramas de Gantt y redes de actividades
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 14 / 48

planificación temporal
tema 6 - administración de proyectos
RED DE ACTIVIDADES
Duración
Tarea Dependencias 14/7/02 15 días 15 días
(días)
M1 T3 T9
T3 T9
8 días 4/8/02
T1 8
hito 5 días 25/8/02
T1 M4
T1
T2 15 4/7/02 T6 M6
25/7/02
T3 15 T1 (M1) INICIO M3
15 días
20 dias
T4 10 7 días
T2
T7 T11
T11
T5 10 T2,T4 (M2)
T6 5 T1,T2 (M3) 25/7/02 5/9/02
10 días
10 días 11/8/02
M8
T4 M2 T5
T7 20 T1 (M1) M7
15 días
T8 25 T4 (M5)
M5
T10 T12
T12
25 días
T9 15 T3, T6 (M4) 18/7/02
10 días
T8
T10 15 T5, T7 (M7)
FINAL
camino crítico 19/9/02
T11 7 T9 (M6)
trayectoria más larga en la red de actividad
T12 10 T11 (M8)
el calendario completo depende de este camino
(los retrasos en estas actividades afectan a todo
el proyecto)
fuente: Ingeniería de Software, I. Sommerville, pp. 80-83
los retrasos en las demás actividades no afectan
necesariamente al proyecto
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 15 / 48

planificación temporal
tema 6 - administración de proyectos
DIAGRAMA DE GANTT
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
inicio
la calendarización
inicial será, con
T4
toda seguridad,
T1
flexibilidad en la fecha de finalización incorrecta.
T2
durante el
M1
desarrollo se
T7
deben comparar
las estimaciones
T3
previas con las
M5 reales para
revisar la
T8
calendarización
M3
del resto del
proyecto.
M2
al conocer cifras
T6
reales, se debe
M4
revisar la red de
actividades y
T9
reorganizar las
M7
actividades
T10 posteriores para
reducir la longitud
M6
de la trayectoria
T11
crítica.
M8
T12
final
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 16 / 48

planificación temporal
tema 6 - administración de proyectos
Asignación de personas vs diagrama de Gantt
Asignación de personas
a actividades
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Tarea Ingeniero
Fernando T4
T1 Juana
T8 T11
T2 Ana
T12
T3 Juana Juana T1
T3
T4 Fernando
T9
T5 María
T6 Ana Ana T2
T6 T10
T7 Jaime
T8 Fernando
Jaime T7
T9 Juana
T10 Ana
María T5
T11 Fernando
T12 Fernando
El personal no tiene que estar asignado al proyecto todo el tiempo. En los periodos
intermedios puede participar en otros proyectos, asistir a cursos de formación, tomar
vacaciones,...
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 17 / 48

medición y métricas del software
tema 6 - administración de proyectos
“Cuando pueda medir lo que está diciendo y expresarlo con números,
ya conoces algo sobre ello; cuando no puedas medir, cuando no
puedas expresar lo que dices con números, tu conocimiento es
precario y deficiente.”
(Lord Kelvin)
Métricas
cualquier medida relacionada con un sistema, proceso o
documentación de software.
medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado (IEEE Producto de
Proceso de
Standard Glossary of Software Engineering, 1993) Producto de
Proceso de software
software
software
software
Ejemplos:
métricas para calcular el tamaño del un producto en líneas de
código
métricas de la claridad de un párrafo en un texto escrito, por Métricas de Métricas de
ejemplo, en un manual (índice de Fog) Métricas de predicciónde
Métricas
control
número de errores localizados en un producto software control predicción
entregado
número de personas-día necesarias para desarrollar un
componente
... Decisiones
Decisiones
Se aplican a: administrativas
administrativas
Procesos (métricas de control): por ejemplo, tiempo y esfuerzo
medios necesarios para corregir un error.
Productos (métricas de predicción): complejidad ciclomática de
un módulo, número de métodos y atributos asociados con los
objetos de un diseño,...
Permiten tomar decisiones
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 18 / 48

medición y métricas del software
tema 6 - administración de proyectos
el proceso de medición
seleccionar medidas a realizar
formular preguntas que la medición intenta responder
Elegir medidas
definir las métricas requeridas para responder a esas Elegir medidas
a realizar
preguntas a realizar
no se recogen otras métricas que no respondan a esas
preguntas
seleccionar componentes a valorar Seleccionar
Seleccionar
no es necesario ni deseable estimar los valores de las componentes a
componentes a
métricas de todo un sistema de software valorar
valorar
conjunto representativo
componentes críticos y fundamentales (utilización continua)
Medir
medir características de los componentes Medir
características
características
calcular los valores de las métricas procesando la de los componentes
de los componentes
representación del componente (diseño, código,...) con
herramientas adecuadas
identificar componentes anómalos Identificar
Identificar
medidas
comparación de los resultados con mediciones previas medidas
anómalas
registradas en una base de datos anómalas
atención especial a los valores más altos y más bajos
pues pueden indicar problemas.
analizar componentes con valores anómalos
Analizar
se examinan los componentes para decidir si los Analizar
componentes
valores obtenidos indican que su calidad está en componentes
anómalos
peligro. anómalos
no siempre indican problemas (por ejemplo, la
complejidad de un módulo puede ser alta pero
necesaria)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 19 / 48

medición y métricas del software
tema 6 - administración de proyectos
métricas del producto
se refieren a las características del propio software
las relaciones entre características del software pueden variar
dependiendo de diversos factores (proceso, tecnología de desarrollo,
tipo de sistema,...)
es necesario construir una base de datos histórica
la base de datos se usa para comprobar cómo se relacionan los atributos
del producto con la calidad que la organización necesita
dos tipos de métricas de producto
dinámicas
recogidas por las mediciones hechas en un programa en ejecución
relación directa con los atributos de calidad del software
ejemplo: medición de tiempo de ejecución como medida de la eficiencia del
sistema
ejemplo: registro del número y tipo de caídas del sistema y relación con la
fiabilidad del software
estáticas
recogidas por las mediciones hechas en las representaciones del sistema (diseño,
código, documentación,...)
relación indirecta con los atributos de calidad del software
ejemplo: longitud del programa como predictor de la mantenibilidad o la
complejidad
ejemplo:índice de Fog como predictor de la facilidad de comprensión de un
documento de texto
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 20 / 48

medición y métricas del software
tema 6 - administración de proyectos
Ejemplos de métricas estáticas del producto
métrica de
descripción
producto
fan-in: medida del número de funciones que llaman a otra función X
fan-out: número de funciones que son llamadas por una función X.
Un valor alto de fan-in indica que X está fuertemente acoplada al resto del diseño
fan-in / fan-out
y que los cambios en X pueden tener efectos extensivos al resto del sistema. Un
valor alto de fan-out indica que la complejidad de X podría ser excesiva, debido a
la complejidad de la lógica de control necesaria para coordinar los componentes
llamados.
Medida del tamaño del programa en líneas de código (LDC). Cuanto mayor sea el
longitud del código tamaño de un componente, más complejo y susceptible de incorporar errores
será.
complejidad Medida de la complejidad del control de un programa, y está relacionada con la
ciclomática comprensión del programa.
Medida de la longitud promedio de los diferentes identificadores de un programa.
longitud de los
Cuanto mayor sea esta longitud, más probable es que tengan significado, y por
identificadores
tanto el programa será más comprensible.
Medida de la profundidad de anidamiento de las instrucciones if en un programa.
profundidad de los if
Instrucciones if profundamente anidadas son difíciles de comprender y son
anidados
potencialmente susceptibles a errores.
Medida de la longitud promedio de las palabras y declaraciones en los
índice de Fog documentos. Cuanto mayor sea el índice de Fog, más difícil será comprender el
documento.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 21 / 48

medición y métricas del software
tema 6 - administración de proyectos
1
R1 Complejidad ciclomática
2
V(G) = 4
3 4
Número de regiones = 4
R2
11 aristas – 9 nodos = 4
5 6
R3
7
8
R4
9
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 22 / 48

medición y métricas del software
tema 6 - administración de proyectos
métricas orientadas a objetos: métricas CK (Chidamber y
Kemerer)
métrica descripción
asumen que se definen n métodos con complejidad c1, c2,...cn se definen para la
clase C. La métrica de complejidad específica que se haya elegido (por ejemplo, la
complejidad ciclomática) debe normalizarse de manera que la complejidad
nominal para un método toma un valor de 10.
métodos ponderados MPC = Σci para cada i=1 hasta n
por clase (MPC)
El número de métodos y su complejidad indican la cantidad de esfuerzo para
implementar y verificar una clase. Cuanto mayor sea el número de métodos, más
complejo es el árbol de herencia. Además, a medida que crece el número de
métodos para una clase dada, más específica se vuelve y, por lo tanto, menos
reutilizable. Por eso, el MP debe mantenerse lo más bajo posible.
longitud máxima del nodo a la raíz del árbol. Cuanto mayor sea, las clases de los
niveles más bajos heredarán muchos métodos, lo que conlleva dificultades
profundidad del árbol
potenciales al predecir el comportamiento de una clase. Además, la complejidad
de herencia (PAH)
de diseño será mayor. Sin embargo, valores de APH grandes indican mayor
capacidad de reutilización de métodos.
número de hijos cuantos más descendientes, más reutilización, pero también es posible que
(NDH) algunos descendientes no sean miembros realmente apropiados de la superclase.
acoplamiento entre es el número de colaboraciones de una clase, y cuanto mayor sea, menor será el
clases (AEC) grado de reutilización, además de complicarse las pruebas y el mantenimiento.
número de métodos que pueden ser ejecutados en respuesta a un mensaje
respuesta para una
recibido por un objeto de esa clase. Cuanto mayor sea RPC, mayor esfuerzo se
clase (RPC)
requiere para su comprobación, y más complejo es el diseño.
carencia de cohesión dos métodos son similares si comparten al menos un atributo de la clase. A
en los métodos (CCM) mayor número de métodos similares, mayor cohesión hay en la clase.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 23 / 48

medición y métricas del software
tema 6 - administración de proyectos
Ventana
Cartas_reclamo
tamaño
Factura
ancho
fecha_emisión : Date
nombre_cliente
fecha_pago : Date
fecha_emisión
total
precio()
compras
impuesto()
cliente()
mostrar_factura()
lista_compras() 1..*
1
0..*
Compra
1
Caja de texto fecha
Botón OK
tasa_impuesto
precio()
1..*
impuesto()
cartas_ botón caja de
Métrica 0
factura compra ventana
reclamo OK texto
MPC 4 2 0 0 1 0
NDH 0 0 0 0 0 0
PAH 0 0 1 0 1 0
RPC - - - - - -
AEC 3 4 2 1 3 1
CCM - - - - - -
fuente: Ingeniería de software. Teoría y práctica. S.L. Pfleeger, p. 34
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 24 / 48

medición y métricas del software
tema 6 - administración de proyectos
métricas del proceso
DETERMINANTES DE LA CALIDAD
DEL SOFTWARE Y DE LA
EFECTIVIDAD DE LA PRODUCTO (complejidad,...)
datos cuantitativos de los procesos del
ORGANIZACIÓN
software
Características Condiciones
la recolección de métricas del proceso
del cliente del negocio (fechas, reglas,...)
es esencial para la mejora del mismo,
(comunicación)
incluso en proyectos a pequeña escala
PROCESO
PERSONAS
se utilizan para evaluar la eficiencia
(destreza, motivación,... TECNOLOGÍA
Entorno de
de un proceso o si ésta ha mejorado
desarrollo
ha mejorado con los cambios
realizados
tres tipos de métricas de proceso
tiempo requerido para completar un
Ayudan aa descubrir si los cambios en el proceso
Ayudan descubrir si los cambios en el proceso proceso en particular: total del
mejoran la eficiencia de un proceso. Por ejemplo, proyecto, por ingeniero, por
mejoran la eficiencia de un proceso. Por ejemplo,
se puede medir el tiempo yy esfuerzo necesarios
se puede medir el tiempo esfuerzo necesarios actividad,...
para moverse de un hitos fijo aa otro, como la
para moverse de un hitos fijo otro, como la recursos requeridos para un proceso
aceptación de requerimientos, terminación de un en particular: esfuerzo en personas-
aceptación de requerimientos, terminación de un
diseño arquitectónico, etc. Esos valores ayudan aa día, costes de viajes, recursos de
diseño arquitectónico, etc. Esos valores ayudan
identificar áreas de mejora en el proceso. hardware,...
identificar áreas de mejora en el proceso.
Una vez introducidos los cambios, las mediciones número de ocurrencias de un evento
Una vez introducidos los cambios, las mediciones
posteriores indican si los cambios han sido positivos particular:
posteriores indican si los cambios han sido positivos
número de defectos descubiertos
durante la revisión del código,
Tienen influencia directa en la calidad del
Tienen influencia directa en la calidad del número de peticiones de cambio en
software. Por ejemplo, incrementar el número
software. Por ejemplo, incrementar el número requerimientos,
de defectos descubiertos al cambiar el proceso
de defectos descubiertos al cambiar el proceso número promedio de líneas de código
de revisión del código probablemente se (LDC) modificadas en respuesta a un
de revisión del código probablemente se
reflejará en una mejora de la calidad del cambio de requerimientos,...
reflejará en una mejora de la calidad del errores detectados por el usuario
producto, aunque tiene que confirmarse por
producto, aunque tiene que confirmarse por ...
mediciones posteriores del producto.
mediciones posteriores del producto.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 25 / 48

medición y métricas del software
tema 6 - administración de proyectos
paradigma GQM (Goal-Question-Metric) de Basili y
Rombach
se utiliza para decidir qué mediciones hacer y cómo
utilizarlas
se basa en la identificación de
metas (goals): aquello que la organización intenta alcanzar.
Por ejemplo, mejorar la productividad de los programadores,
reducir tiempos de desarrollo, incrementar la fiabilidad,...
preguntas (questions): refinamientos de las metas en las que
se identifican áreas específicas de incertidumbre. Ejemplos:
¿cómo se puede incrementar el número de LDC depuradas?
¿cómo se puede reducir el tiempo requerido para finalizar los
requerimientos?
¿cómo se pueden llevar a cabo evaluaciones de fiabilidad más
efectivas?
métricas: las mediciones necesarias para ayudar a responder
a las preguntas y confirmar si las mejoras del proceso
cumplieron su objetivo. Ejemplos:
medir la productividad de los programadores en LDC y nivel de
experiencia
medir número de comunicaciones formales entre cliente y analista
para cada cambio de requerimientos
medir el número de pruebas requeridas para provocar una caída en
el producto
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 26 / 48

planificación de proyectos
tema 6 - administración de proyectos
planificación
proporciona un marco de trabajo que permite al administrador del
proyecto hacer estimaciones razonables de recursos, costes y
planificación temporal.
actividades de la planificación
delimitación del ámbito del software
estimación de recursos necesarios (humanos, hardware, software,...)
PLANIFICACIÓN
PLANIFICACIÓN
EXPERIENCIA
EXPERIENCIA
Grado de estructuración ESTIMACIÓN RIESGO
ESTIMACIÓN RIESGO
DATOS
DATOS
HISTÓRICOS
HISTÓRICOS
Ámbito de bajo
riesgo
Tamaño del esfuerzo
Complejidad basada en
esfuerzos pasados
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 27 / 48

planificación de proyectos: ámbito
tema 6 - administración de proyectos
delimitación del ámbito del software
describe los datos a procesar, la función, el rendimiento, las
restricciones, interfaces y fiabilidad necesarias
se evalúan las funciones y se refinan con más detalles si es necesario
se obtiene mediante entrevistas preliminares entre analista y cliente
utilidad del ámbito del software
estudiar la viabilidad del proyecto
realizar estimaciones de recursos necesarios
FUNCIÓN
RENDIMIENTO
ÁMBITO DEL
RESTRICCIONES
SOFTWARE
INTERFACES
FIABILIDAD
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 28 / 48

planificación de proyectos: recursos
tema 6 - administración de proyectos
estimación de recursos
se especifica cada recurso mediante cuatro características
descripción
informe de disponibilidad
fecha cronológica en la que se requiere el recurso
tiempo durante el que será aplicado
Especificar:
RECURSOS
•Habilidades requeridas
•Disponibilidad
•Duración tareas.
•Fecha comienzo
Personas •Componentes desarrollados
•Componentes experimentados
•Componentes con experiencia parcial.
Componentes
•Componentes nuevos
software
reutilizables Especificar:
•Descripción
Herramientas •Disponibilidad
hardware/software •Duración del uso
•Fecha de distribución
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 29 / 48

planificación de proyectos: estimación
tema 6 - administración de proyectos
estimación del esfuerzo y coste de un proyecto
normalmente el problema es demasiado complejo. Se utilizan diferentes
técnicas:
descomposición del problema
descomposición del proceso
antes de hacer estimaciones de esfuerzo y coste
conocer el ámbito del software
realizar una estimación del tamaño
precisión de una estimación:
grado en que se ha estimado adecuadamente el tamaño del producto
habilidad para traducir la estimación del tamaño a:
esfuerzo humano
tiempo
dinero
grado en que el plan del proyecto refleja la capacidad del equipo de desarrollo
estabilidad de los requisitos y el entorno del esfuerzo que da soporte a las
actividades de ingeniería del software
opciones para la estimación:
dejar la estimación para más adelante
basar las estimaciones en proyectos similares anteriores
utilizar técnicas de descomposición (“divide y vencerás”)
desarrollar o aplicar un modelo empírico para calcular costes y esfuerzo
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 30 / 48

planificación de proyectos: estimación
tema 6 - administración de proyectos
tamaño del software
dos tipos de enfoque
directo: se utilizan las LDC para medir el tamaño
indirecto: el tamaño se representa mediante puntos de función (PF)
problemas de la utilización de LDC
no existe definición estándar de LDC (p.ej., ¿se consideran LDC los
comentarios?)
líneas físicas o lógicas
contabilización del código reutilizable
aplicaciones en diferentes lenguajes
estilos individuales de programación
relación entre LDC y PF: depende del lenguaje escogido
Lenguaje LDC/PF (media)
Lenguaje LDC/PF (media)
Ensamblador 320
Ensamblador 320
C 128
C 128
Cobol 105
Cobol 105
Fortran 105
Fortran 105
Pascal 90
Pascal 90
Ada 70
Ada 70
Lenguajes OO 30
Lenguajes OO 30
L4G 20
L4G 20
Lenguajes visuales 44
Lenguajes visuales
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 31 / 48

planificación de proyectos: estimación
tema 6 - administración de proyectos
Factores de Ajuste de Complejidad: evaluar cada factor
de 0 a 5
0- Sin influencia
Puntos de función: relación empírica 1- Incidental
basada en medidas cuantitativas del 2- Moderado
dominio de información del software y 3- Medio
valoraciones subjetivas acerca de la 4- Significativo
complejidad del software 5- Esencial
Factor de peso 1.¿Requiere el sistema copias de seguridad fiables?
Factor de peso
2.¿Se requieren comunicaciones de datos?
Parámetro de medida Cuenta Simple Medio Complejo
Parámetro de medida Cuenta Simple Medio Complejo
3.¿Existen funciones de procesamiento distribuido?
4.¿Es crítico el rendimiento?
Número entradas usuario x3 4 6 =
Número entradas usuario x3 4 6 = 5.¿Será ejecutado el sistema en un entorno operativo
existente y utilizado?
Número salidas de usuario x4 5 7 =
Número salidas de usuario x4 5 7 =
6.¿Se requiere entrada de datos interactiva?
7.¿Requiere la entrada interactiva que las transacciones
Número peticiones al usuario x3 4 6 =
Número peticiones al usuario x3 4 6 =
de entrada se hagan sobre múltiples pantallas o variadas
operaciones?
Número de archivos x7 10 15 =
Número de archivos x7 10 15 =
8.¿Se actualizan los archivos maestros de forma
Número interfaces externos x5 7 10 = interactiva?
Número interfaces externos x5 7 10 =
9.¿Son complejas las entradas, las salidas, los archivos o
Cuenta total
Cuenta total las peticiones?
10.¿Es complejo el procesamiento interno?
11.¿Se ha diseñado el código para ser reutilizable?
12.¿Están incluidas en el diseño la conversión y la
PF = Cuenta Total xx[0,65 + 0,01 xxSUM(Fi)]
PF = Cuenta Total [0,65 + 0,01 SUM(Fi)] instalación?
13.¿Se ha diseñado el sistema para soportar múltiples
instalaciones en diferentes organizaciones?
FF: : valores de ajuste de complejidad
i valores de ajuste de complejidad
14.¿Se ha diseñado la aplicación para facilitar los
i
cambios y ser fácilmente utilizada por el usuario?
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 32 / 48

estimación basada en el problema
tema 6 - administración de proyectos
al estimar el proyecto, las LDC y los PF se utilizan como:
variables de estimación que permiten dimensionar cada
elemento del software
métricas de proyectos anteriores (“métricas de línea de
base”):
productividad (LDC / persona-mes)
coste ($ / persona-mes)
...
pasos:
estimación de un rango de valores para cada función
especificada en el ámbito del software
3 valores para cada función: optimista, más probable y más
pesimista (indica el grado de incertidumbre)
valor esperado:
ejemplo: VE = (Sopt + 4Sm + Spes)/6
técnicas estadísticas: cálculo de la desviación de las
estimaciones
aplicación de métricas de proyectos anteriores (en LDC o PF)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 33 / 48

estimación basada en el problema
tema 6 - administración de proyectos
descomposición del
problema en
funciones a partir del
ámbito del software
F1 F2 Fn
estimación estimación
cálculo de las cálculo de las
coste de F1 coste de F2
variables de variables de
estimación (LDC estimación (LDC
y/o PF) de F1 y/o PF) de F2
estimación de estimación de
esfuerzo de F1 esfuerzo de F2
coste de F1 esfuerzo de F1
aplicación de aplicación de
métricas de métricas de coste de F2 esfuerzo de F2
productividad productividad
o coste o coste coste de Fn esfuerzo de Fn
estimación global estimación global
del coste del del esfuerzo del
proyecto proyecto
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 34 / 48

estimación basada en el problema (LDC)
tema 6 - administración de proyectos
Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el
sistema CAD por medio de una interfazque aceptará datos diseño de buena2 o 3 dimensiones por datos del ingeniero. Éste controlará el
Hay que desarrollar un software CAD que debe tener un geométricos de calidad. Una base de parte CAD contiene todos los datos
geométricos y la información una soporte. que desarrollarán módulosde buena calidad. Unapara producir laCAD contiene todos los datos
sistema CAD por medio de de interfaz Se debe tener un diseño de análisis de diseño base de datos salida requerida que se va a
visualizar en varios dispositivosde soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a
geométricos y la información gráficos.
El software en varios dispositivos gráficos.
visualizar se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.
El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.
Funciones identificadas:
Funciones identificadas: Estimación en LDC de AG3D:
descomposición
interfaz de usuario yy facilidades de control (IUFC)
interfaz de usuario facilidades de control (IUFC)
Estimación en LDC de AG3D:
descomposición
de funciones
optimista: 4600
de funciones
análisis geométrico de dos dimensiones (AG2D) optimista: 4600
análisis geométrico de dos dimensiones (AG2D) más probable: 6900
análisis geométrico de tres dimensiones (AG3D) más probable: 6900
análisis geométrico de tres dimensiones (AG3D) pesimista: 8600
gestión de base de datos (GBD) pesimista: 8600
gestión de base de datos (GBD)
facilidades de la interfaz gráfica (FIG)
facilidades de la interfaz gráfica (FIG)
control periféricos (CP)
control periféricos (CP)
módulos de análisis del diseño (MAD) VE ==(Sopt ++4Sm ++Spes)/6
módulos de análisis del diseño (MAD) VE (Sopt 4Sm Spes)/6
Datos históricos:
Datos históricos:
productividad media de la organización en
métricas de
Función LDC estimada
anteriores
productividad media de la organización en
proyectos
métricas de
Función LDC estimada
anteriores
proyectos similares: 620 LDC/pm
proyectos
proyectos similares: 620 LDC/pm
IUFC 2300
IUFC 2300
Tarifa laboral: 8000 $$ /mes
Tarifa laboral: 8000 /mes AG2D 5300
AG2D 5300
AG3D 6800
AG3D 6800
Coste LDC: 13 $$ GBD 3350
Coste LDC: 13 GBD 3350
FIG 4950
FIG 4950
CP 2100
CP 2100
MAD 8400
MAD 8400
Total 33200
Total 33200
Coste total proyecto: 431000 $$
Coste total proyecto: 431000
Esfuerzo estimado: 54 personas-mes
Esfuerzo estimado: 54 personas-mes
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 35 / 48

estimación basada en el problema (PF)
tema 6 - administración de proyectos
Valor dominio Opt. Probable Pesimista Cuenta Peso Cuenta
información est PF
Num. entradas 20 24 30 24 4 96
Num. salidas 12 15 22 16 5 80
Num. peticiones 16 22 28 22 4 88
Num. archivos 4 4 5 4 10 40
Num. interfaces ext. 2 2 3 2 7 14
Cuenta total 318
Copia de seguridad y recuperación 4
Copia de seguridad y recuperación 24
Comunicaciones
Comunicaciones 02
Proceso distribuido
Proceso distribuido 40
Rendimiento crítico
PF estimado == cuenta total x (0,65 + 0,01 x Suma (Fi)
PF estimado cuenta total x (0,65 + 0,01 x Suma (Fi)
Rendimiento crítico 34
Entorno operativo existente
Entorno operativo existente 43
Entrada de datos online
Entrada de datos online 54
Transacciones entrada en varias pant.
Transacciones entrada en varias pant. 35
Archivos maestros actualizados online
Complejidad valores actualizados online
Archivos maestros dominio información 53
Complejidad valores dominio información 55
Complejidad procesamiento interno PF estimado ==372
Complejidad procesamiento interno 45 PF estimado 372
Código diseñado para reutilización
Conversión en diseño reutilización
Código diseñado para 34
Instalaciones en diseño
Conversión múltiples 53
Instalaciones múltiples 55
Aplicación diseñada para cambios
Aplicación diseñada para cambios 5
Coste total proyecto: 457000 $
Coste total proyecto: 457000 $
Datos históricos: Esfuerzo estimado: 58 personas-mes
Datos históricos: Esfuerzo estimado: 58 personas-mes
productividad media de la organización en
métricas de
anteriores
productividad media de la organización en
proyectos
métricas de
anteriores
proyectos similares: 6,5 PF/pm
proyectos
proyectos similares: 6,5 PF/pm
Tarifa laboral: 8000 $$ /mes
Tarifa laboral: 8000 /mes
Coste por PF: 1.230 $$
Coste por PF: 1.230
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 36 / 48

estimación basada en el proceso
tema 6 - administración de proyectos
estimación basada en el proceso
técnica más habitual
el proceso se descompone en actividades o tareas y el
esfuerzo requerido para llevar a cabo cada tarea
pasos:
delimitar las funciones obtenidas a partir del ámbito del
software
actividades del proceso para cada función
estimación de esfuerzo (persona-mes) para cada actividad
en cada función
aplicación de índices de trabajo medios (esfuerzo
coste/unidad) al esfuerzo estimado para cada actividad
cálculo de costes y esfuerzo de cada función y de la
actividad
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 37 / 48

estimación basada en el proceso
tema 6 - administración de proyectos
Actividades
Actividades
Entrevistas Planificación Análisis Ingeniería Construcción Evaluación Totales
Entrevistas Planificación Análisis Ingeniería Construcción Evaluación Totales
riesgo entrega cliente
riesgo entrega cliente
Tareas Análisis Diseño Código Prueba
Tareas Análisis Diseño Código Prueba
Función
Función
IUFC 0,50 2,50 0,40 5,00 n/a 8,40
IUFC 0,50 2,50 0,40 5,00 n/a 8,40
AG2D 0,75 4,00 0,60 2,00 n/a 7,35
AG2D 0,75 4,00 0,60 2,00 n/a 7,35
AG3D 0,50 4,00 1,00 3,00 n/a 8,50
AG3D 0,50 4,00 1,00 3,00 n/a 8,50
GBD 0,50 3,00 1,00 1,50 n/a 6,00
GBD 0,50 3,00 1,00 1,50 n/a 6,00
FIG 0,50 3,00 0,75 1,50 n/a 5,75
FIG 0,50 3,00 0,75 1,50 n/a 5,75
CP 0,25 2,00 0,50 1,50 n/a 4,25
CP 0,25 2,00 0,50 1,50 n/a 4,25
MAD 0,50 2,00 0,50 2,00 n/a 5,00
MAD 0,50 2,00 0,50 2,00 n/a 5,00
Total 0,25 0,25 0,25 3,50 20,50 4,75 16,50 46,00
Total 0,25 0,25 0,25 3,50 20,50 4,75 16,50 46,00
%esfuerzo 1% 1% 1% 8% 45% 10% 36%
%esfuerzo 1% 1% 1% 8% 45% 10% 36%
Comparación de las distintas estimaciones
Comparación de las distintas estimaciones
Tarifa laboral: 8000 $$ /mes
Tarifa laboral: 8000 /mes
Estimación basada en el producto (LDC): 54 pm
Estimación basada en el producto (LDC): 54 pm
Coste total proyecto: 368.000 $$
Coste total proyecto: 368.000
Estimación basada en el producto (PF): 58 pm
Esfuerzo estimado: 46 personas-mes Estimación basada en el producto (PF): 58 pm
Esfuerzo estimado: 46 personas-mes
Estimación basada en el proceso: 46 pm
Estimación basada en el proceso: 46 pm
Estimación media: 53 pm
Estimación media: 53 pm
Variación máxima: 13%
Variación máxima: 13%
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 38 / 48

modelos empíricos de estimación
tema 6 - administración de proyectos
Modelos empíricos de estimación:
Utilizan fórmulas derivadas empíricamente para predecir el esfuerzo como una función
de LDC o PF.
Datos empíricos obtenidos de una muestra de proyectos:
difíciles de usar para todas las clases de software y todos los entornos de desarrollo
se deben calibrar para las condiciones específicas de una organización
A y B: constantes obtenidas
empíricamente
E = A + B X (ev) c c E: esfuerzo en meses/persona
E = A + B X (ev)
ev: variable de estimación (LDC o PF)
MODELOS BASADOS EN LDC
E = 5,2 x (KLDC)0,91 Modelo de Walston-Felix
E = 5,2 x (KLDC)0,91 Modelo de Walston-Felix
E = 5,5 + 0,73 x (KLDC)1,16 Modelo de Bailey-Basili
(KLDC)1,16
E = 5,5 + 0,73 x1,05 Modelo de Bailey-Basili
E = 3,2 x (KLDC) 1,05 Modelo simple de Boehm
E = 3,2 x (KLDC) 1,047 Modelo simple de Boehm
E = 5,288 x (KLDC) 1,047 Modelo Doty para KLDC>9
E = 5,288 x (KLDC) Modelo Doty para KLDC>9 MODELOS BASADOS EN PF
E = -13,39 + 0,054 PF Modelo de Albrecht-Gaffney
E = -13,39 + 0,054 PF Modelo de Albrecht-Gaffney
E = 60,62 x 7,728 x 10-8 PF3 Modelo de Kemerer
E = 60,62 x 7,728 x 10-8 PF3 Modelo de Kemerer
E = 585,7 + 15,12 PF Modelo de Matson, Barnett
E = 585,7 + 15,12 PF Modelo de Matson, Barnett
y Mellichamp
y Mellichamp
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 39 / 48

modelos empíricos de estimación
tema 6 - administración de proyectos
MODELO 1 (COCOMO básico) Tres tipos de proyectos:
MODELO 1 (COCOMO básico)
calcula el esfuerzo y el coste del desarrollo en
calcula el esfuerzo y el coste del desarrollo en
Orgánicos: relativamente pequeños y sencillos,
función del tamaño estimado del programa (LDC).
función del tamaño estimado del programa (LDC).
en los que trabajan pequeños equipos con
Se utiliza para una aproximación rápida al principio
Se utiliza para una aproximación rápida al principio
experiencia, sobre un conjunto de requisitos
del ciclo de vida.
del ciclo de vida.
poco rígidos.
bb
ESFUERZO: EE = ab KLDC
ESFUERZO:
= ab KLDCbb Semiacoplados: proyectos intermedios (en
db
TIEMPO:
D == cb E
D c Edb tamaño y complejidad) en los que participan
TIEMPO: b
equipos con variados niveles de experiencia, y
que deben satisfacer requisitos poco o medio
rígidos.
Empotrados: proyectos que deben ser
desarrollados en un conjunto de hardware,
MODELO 2 (COCOMO intermedio)
MODELO 2 (COCOMO intermedio) software y restricciones operativas muy
calcula el esfuerzo y el coste en función del tamaño
restringido.
calcula el esfuerzo y el coste en función del tamaño
estimado del programa y de un conjunto de “guías
estimado del programa y de un conjunto de “guías
de coste” que incluyen una evaluación
de coste” que incluyen una evaluación
subjetiva del producto, hardware, personal y atributos
subjetiva del producto, hardware, personal y atributos
del producto
del producto
bi
ESFUERZO: EE = aKLDCbi xx FAE (factor
ESFUERZO: = ai i KLDC FAE (factor
MODELO COCOMO BÁSICO
MODELO COCOMO BÁSICO
de ajuste del esfuerzo)
de ajuste del esfuerzo) Proyecto ab bb cb db
Proyecto ab bb cb db
Orgánico 2,4 1,05 2,5 0,38
Orgánico 2,4 1,05 2,5 0,38
Semiacoplado 3,0 1,12 2,5 0,35
Semiacoplado 3,0 1,12 2,5 0,35
MODELO 3 (COCOMO avanzado)
MODELO 3 (COCOMO avanzado) Empotrado 3,6 1,20 2,5 0,32
incorpora las características del mod. 2 y evalúa el Empotrado 3,6 1,20 2,5 0,32
incorpora las características del mod. 2 y evalúa el
impacto de los FAE en cada fase del desarrollo.
impacto de los FAE en cada fase del desarrollo.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 40 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
Riesgo
el administrador de proyectos anticipa riesgos que pueden
afectar al desarrollo o a la calidad del software y emprende
acciones para evitarlos
riesgo: probabilidad de que ocurra una circunstancia adversa
para el proyecto
amenazan el proyecto, el software y la propia organización
existen riesgos conocidos, predecibles e impredecibles
categorías de riesgos:
riesgos del proyecto: afectan al presupuesto, los recursos, la
planificación,...
riesgos del producto: afectan a la calidad o al rendimiento del
software
riesgos del negocio: afectan a la organización (riesgos de
mercado, estratégicos, de distribución, de pérdida del
presupuesto o del personal,...)
riesgos que entran en las tres categorías anteriores (por
ejemplo, el abandono de un programador experto es un riesgo
para el producto, el proyecto y el negocio)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 41 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
Ejemplos de posibles riesgos en el desarrollo de software
riesgo tipo de riesgo descripción
proyecto,
rotación de personal con experiencia abandona el proyecto antes de que
producto y
personal finalice
negocio
cambio de cambio de administración organizativa con diferentes
proyecto
administración prioridades
no
proyecto el hardware necesario para el proyecto no se recibe a tiempo
disponibilidad
del hardware
cambios de proyecto y existencia de más cambios de requerimientos de los previstos
requerimientos producto inicialmente
retrasos en la proyecto y
retrasos en las especificaciones de interfaces esenciales
especificación producto
subestimación proyecto y
el tamaño del sistema se ha subestimado
del tamaño producto
bajo
las herramientas CASE que ayudan al proyecto no tienen el
rendimiento de
producto
rendimiento y las funcionalidades esperadas
la herramienta
CASE
cambio de la tecnología fundamental sobre la que se está construyendo el
negocio
tecnología sistema es sustituida por una nueva
competencia del un producto competitivo se pone en venta antes de que el
negocio
producto sistema se complete
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 42 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
la administración de riesgos es un proceso
iterativo que se aplica durante todo el listado de
identificación
proyecto identificación riesgos
de riesgos potenciales
de riesgos
etapas de la administración de riesgos
identificación de riesgos: se identifican los
posibles riesgos para el proyecto, el
producto y el negocio listado de
análisis
análisis
análisis de riesgos: se valoran las priorización
de riesgos de riesgos
de riesgos
probabilidades y las posibles consecuencias
de los riesgos identificados
planificación de riesgos: se crean planes
para abordar los riesgos, tanto para
evitarlos como para minimizar sus efectos anulación de
planificación riesgos y
supervisión de riesgos: se valora planificación
de riesgos planes de
constantemente los riesgos y se revisan los de riesgos contingencia
planes para su mitigación tan pronto como
la información de los riesgos está disponible
los resultados de la administración de
riesgos se documentan en un plan de supervisión valoración de
supervisión
administración de riesgos de riesgos riesgos
de riesgos
fuente: Ingeniería de Software. I. Sommerville, p. 85
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 43 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
identificación de riesgos
descubrimiento de los posibles riesgos
no se valoran o priorizan, aunque no se tienen en cuenta riesgos con
consecuencias pequeñas o con baja probabilidad
se realiza a través de diversas técnicas (tormentas de ideas,
experiencia del administrador,...)
tipo de riesgo ejemplos de posibles riesgos
la base de datos que se utiliza en el sistema no puede procesar tantas transacciones
por segundo como se esperaba
tecnología
los componentes de software a reutilizar tienen defectos que limitan su
funcionalidad
imposible contratar personal con los conocimientos requeridos
personal
personal clave enfermo o no disponible en momentos críticos
la organización se reestructura y una nueva administración se responsabiliza del
organizativos proyecto
los problemas financieros de la organización reducen el presupuesto del proyecto
las herramientas CASE generan código ineficiente
herramientas
las distintas herramientas CASE no se pueden integrar
cambios de requerimientos que precisan modificaciones en el diseño
requerimientos
los clientes no comprenden el impacto de los cambios en los requerimientos
el tiempo requerido para desarrollar el software está subestimado
estimación la tasa de reparación de defectos está subestimada
el tamaño del software está subestimado
legales cambian las leyes imponiendo restricciones que no estaban previstas
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 44 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
análisis de riesgos
se considera cada riesgo por separado y se valora en intervalos su probabilidad e
impacto:
probabilidad del riesgo valorada como muy bajo (<10%), bajo (10-25%), moderado
(25-50%), alto (50-75%) o muy alto (>75%)
efectos del riesgo valorados como catastrófico, serio, tolerable o insignificante
el resultado se coloca en una tabla ordenada por la seriedad del riesgo
se decide cuáles son los más importantes (riesgos clave) y que se van a
considerar durante el proyecto (por ejemplo, todos los serios o catastróficos con
cualquier probabilidad), y que debe ser un número manejable.
riesgo probab. efectos
los problemas financieros de la organización reducen el presupuesto del proyecto baja catastrófico
imposible contratar personal con los conocimientos requeridos alta catastrófico
personal clave enfermo o no disponible en momentos críticos moderada serio
los componentes de software a reutilizar tienen defectos que limitan su funcionalidad moderada serio
cambios de requerimientos que precisan modificaciones en el diseño moderada serio
la organización se reestructura y una nueva administración se responsabiliza del
alta serio
proyecto
la base de datos que se utiliza en el sistema no puede procesar tantas transacciones
moderada serio
por segundo como se esperaba
el tiempo requerido para desarrollar el software está subestimado alta serio
las distintas herramientas CASE no se pueden integrar alta tolerable
los clientes no comprenden el impacto de los cambios en los requerimientos moderada tolerable
la tasa de reparación de defectos está subestimada moderada tolerable
el tamaño del software está subestimado alta tolerable
las herramientas CASE generan código ineficiente moderada insignificante
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 45 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
planificación de riesgos
se considera cada uno de los riesgos clave identificados y las
estrategias para administrarlo, que vendrán dadas por el juicio y la
experiencia del administrador del proyecto
estrategias de anulación: intentan reducir la probabilidad de que surja el
riesgo
estrategias de disminución: intentan reducir el impacto del riesgo
planes de contingencia: se dispone de ellos para estar preparados por si
el riesgo ocurre y poder actuar con una estrategia determinada
riesgo estrategia
problemas financieros de la preparar un documento breve para la dirección de la empresa que muestra
organización que el proyecto hace contribuciones muy importantes a las metas del negocio
organizar cursos de capacitación para el personal ya existente, investigar la
problemas de reclutamiento
posibilidad de contratar en otras regiones o países
reorganizar el equipo de tal forma que se solapen el trabajo y los miembros
enfermedad del personal
del equipo comprendan el trabajo de los demás
reemplazar los componentes defectuosos con los comprados de fiabilidad
componentes defectuosos
conocida
rastrear la información para valorar el impacto de los requerimientos,
cambios en los requerimientos
maximizar la información oculta en ellos
preparar un documento breve para la dirección de la empresa que muestra
reestructuración organizativa
que el proyecto hace contribuciones muy importantes a las metas del negocio
investigar la posibilidad de comprar una base de datos con el rendimiento
rendimiento de la base de datos
preciso
tiempo de desarrollo subestimado alertar al cliente de las dificultades potenciales y las posibilidades de retraso
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 46 / 48

el riesgo en el desarrollo de software
tema 6 - administración de proyectos
supervisión de riesgos
valora cada uno de los riesgos identificados para decidir si es
más o menos probable y cuándo han cambiado sus posibles
efectos
hay que controlar factores que pueden indicar cambios en la
probabilidad y el impacto
tipo de riesgo indicadores potenciales
entrega retrasada del hardware o del software
tecnología
existencia de informes sobre problemas tecnológicos
baja moral del personal, malas relaciones entre miembros del equipo,
personal
disponibilidad de empleo
rumores en la empresa
organizacional
falta de iniciativa de la dirección de la empresa
rechazo de los miembros del equipo a utilizar herramientas
herramientas quejas sobre las herramientas CASE
peticiones de estaciones de trabajo más potentes
peticiones de muchos cambios en los requerimientos
requerimientos
quejas del cliente
estimación fracaso en el cumplimiento de los tiempos planificados
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 47 / 48

bibliografía
tema 6 - administración de proyectos
Sommerville, I. Ingeniería de Software, cap. 4 y 24 (pp. 547-554)
Pressman, R.S. Ingeniería del Software. Un enfoque práctico, cap. 4, 5 y 6
Bruegge, B., Dutoit, A.H., Ingeniería del Software Orientado a Objetos, cap. 3
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 48 / 48