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

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,...

© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 48

actividades de la administración

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


actividades de la administración

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


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 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


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é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


personal del proyecto: cohesión del grupo

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


personal del proyecto: comunicación

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)


personal del proyecto: organización del grupo

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


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ó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


planificación del proyecto
Establecer restricciones Valores iniciales Def inir hitos y
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



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



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


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 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



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



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



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,...


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é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



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)


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



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.



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



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.



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



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.



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


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ó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


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 software
estudiar la viabilidad del proyecto
realizar estimaciones de recursos necesarios

FUNCIÓN

RENDIMIENTO

ÁMBITO DEL
RESTRICCIONES
SOFTWARE

INTERFACES

FIABILIDAD


planificación de proyectos: recursos

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


planificación de proyectos: estimación

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



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



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?

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:
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)


estimación basada en el problema

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


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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

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

Similar to Ingeniería del Software de Gestión. Tema 5 (20)

More from Enrique Barreiro

More from Enrique Barreiro (10)

Recently uploaded

Recently uploaded (20)

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