tema 6 administracin de proyectos

1
tema 6 administración deproyectos
enrique barreiro departamento de
informática universidade de vigo escuela
superior de ingeniería informática ingeniería del
software de gestión
2
introducción a la administración de proyectos

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

3
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

4
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

5
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

6
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 pregunta a otros utiliza
sentimientos y reacciones emocionales
Intuitivo extrovertido dice a los otros utiliza
sentimientos y reacciones emocionales

• los estilos de trabajo afectan a la interacción
  entre clientes, desarrolladores y usuarios
• implican la elección de un trabajador para una
  tarea dada. Por ejemplo
• intuitivos prefieren análisis y diseño (requieren
  ideas nuevas) al mantenimiento (requiere atención
  a los detalles y análisis de resultados
  complejos)

INTROVERTIDO
EXTROVERTIDO
Racional introvertido pregunta a otros decide
lógicamente
Racional extrovertido dice a los otros decide
lógicamente
RACIONAL
7
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

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

9
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

10
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
• los demás informan al JP, quien tiene la última
  palabra en cada decisión
• 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
  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,...
• especialistas que trabajan temporal o
  permanentemente en el grupo
• programadores
• especialistas en sistemas operativos
• ingenieros de pruebas
• ...
• 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

11
planificación del proyecto

• la administración efectiva depende de una
  completa planificación del progreso del proyecto
• plan hilo conductor del proyecto
• anticipación de los problemas que pueden surgir
• preparación de soluciones a esos problemas
• el plan inicial evoluciona según el progreso del
  proyecto y la disponibilidad de información
• enfoque pesimista al elaborar suposiciones y
  calendario necesidad de disponer de holguras

12
planificación del proyecto

• plan del proyecto
• apartados habituales del plan del proyecto
• introducción objetivos, restricciones,...
• organización del proyecto
• análisis de riesgo riesgos, probabilidades de
  que ocurran, estrategias de reducción,...
• requerimientos de recursos de hardware y software
• división del trabajo identificación de
  actividades, hitos y productos a entregar
  asociados a cada actividad
• programa del proyecto dependencias entre
  actividades, tiempo estimado para cada hito,
  asignación de personal a las actividades,...
• 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

13
planificación del proyecto

• 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 viabilidad
Especificación requerim. sistema
Estudio del diseño
Desarrollo prototipos
Análisis de requerim.
ACTIVIDADES
informe viabilidad
requerim. usuarios
informe evaluación
diseño arquitectónico
requerim. sistema
HITOS
PRODUCTO
14
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

15
planificación temporal
hito

• camino crítico
• trayectoria más larga en la red de actividad
• el calendario completo depende de este camino
  (los retrasos en estas actividades afectan a todo
  el proyecto)
• los retrasos en las demás actividades no afectan
  necesariamente al proyecto

fuente Ingeniería de Software, I. Sommerville,
pp. 80-83
16
planificación temporal
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 toda
  seguridad, incorrecta.
• durante el desarrollo se deben comparar las
  estimaciones previas con las reales para revisar
  la calendarización del resto del proyecto.
• al conocer cifras reales, se debe revisar la red
  de actividades y reorganizar las actividades
  posteriores para reducir la longitud de la
  trayectoria crítica.

T4
T1
flexibilidad en la fecha de finalización
T2
M1
T7
T3
M5
T8
M3
M2
T6
M4
T9
M7
T10
M6
T11
M8
T12
final
17
planificación temporal
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
Fernando
T4
T8
T11
T12
T1
Juana
T3
T9
T2
Ana
T6
T10
T7
Jaime
T5
María
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,...
18
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
  Standard Glossary of Software Engineering, 1993)
• 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 ejemplo, en un manual (índice de
  Fog)
• número de errores localizados en un producto
  software entregado
• número de personas-día necesarias para
  desarrollar un componente
• ...
• Se aplican a
• Procesos (métricas de control) por ejemplo,
  tiempo y esfuerzo medios necesarios para corregir
  un error.
• Productos (métricas de predicción) complejidad
  ciclomática de un módulo, número de métodos y
  atributos asociados con los objetos de un
  diseño,...
• Permiten tomar decisiones

Proceso de software
Producto de software
Métricas de predicción
Métricas de control
Decisiones administrativas
19
medición y métricas del software

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

Elegir medidas a realizar
Seleccionar componentes a valorar
Medir características de los componentes
Identificar medidas anómalas
Analizar componentes anómalos
20
medición y métricas del software

• métricas del producto
• se refieren a las características del propio
  software
• las relaciones entre características del software
  pueden variar dependiendo de diversos factores
  (proceso, tecnología de desarrollo, tipo de
  sistema,...)
• es necesario construir una base de datos
  histórica
• la base de datos se usa para comprobar cómo se
  relacionan los atributos del producto con la
  calidad que la organización necesita
• dos tipos de métricas de 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

21
medición y métricas del software
Ejemplos de métricas estáticas del producto
22
medición y métricas del software
1
2
R1
Complejidad ciclomática V(G) 4 Número de
regiones 4 11 aristas 9 nodos 4
3
4
R2
5
6
R3
7
8
R4
9
23
medición y métricas del software

• métricas orientadas a objetos métricas CK
  (Chidamber y Kemerer)

24
medición y métricas del software
fuente Ingeniería de software. Teoría y
práctica. S.L. Pfleeger, p. 34
25
medición y métricas del software
DETERMINANTES DE LA CALIDAD DEL SOFTWARE Y DE
LA EFECTIVIDAD DE LA ORGANIZACIÓN

• métricas del proceso
• datos cuantitativos de los procesos del software
• la recolección de métricas del proceso es
  esencial para la mejora del mismo, incluso en
  proyectos a pequeña escala
• se utilizan para evaluar la eficiencia de un
  proceso o si ésta ha mejorado ha mejorado con los
  cambios realizados
• tres tipos de métricas de proceso
• tiempo requerido para completar un proceso en
  particular total del proyecto, por ingeniero,
  por actividad,...
• recursos requeridos para un proceso en
  particular esfuerzo en personas-día, costes de
  viajes, recursos de hardware,...
• número de ocurrencias de un evento particular
• número de defectos descubiertos durante la
  revisión del código,
• número de peticiones de cambio en requerimientos,
  
• número promedio de líneas de código (LDC)
  modificadas en respuesta a un cambio de
  requerimientos,...
• errores detectados por el usuario
• ...

PRODUCTO (complejidad,...)
Características del cliente (comunicación)
Condiciones del negocio (fechas, reglas,...)
PROCESO
PERSONAS (destreza, motivación,...
TECNOLOGÍA
Entorno de desarrollo
Ayudan a descubrir si los cambios en el proceso
mejoran la eficiencia de un proceso. Por ejemplo,
se puede medir el tiempo y esfuerzo necesarios
para moverse de un hitos fijo a otro, como la
aceptación de requerimientos, terminación de un
diseño arquitectónico, etc. Esos valores ayudan a
identificar áreas de mejora en el proceso. Una
vez introducidos los cambios, las mediciones
posteriores indican si los cambios han sido
positivos
Tienen influencia directa en la calidad del
software. Por ejemplo, incrementar el número de
defectos descubiertos al cambiar el proceso de
revisión del código probablemente se reflejará en
una mejora de la calidad del producto, aunque
tiene que confirmarse por mediciones posteriores
del producto.
26
medición y métricas del software

• paradigma GQM (Goal-Question-Metric) de Basili y
  Rombach
• se utiliza para decidir qué mediciones hacer y
  cómo utilizarlas
• se basa en la identificación 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

27
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
ESTIMACIÓN
RIESGO
EXPERIENCIA
DATOS HISTÓRICOS
28
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

29
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

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

31
planificación de proyectos estimación

• 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) Ensamblador 320 C 128
Cobol 105 Fortran 105 Pascal 90 Ada
70 Lenguajes OO 30 L4G 20 Lenguajes
visuales 4
32
planificación de proyectos estimación

• Factores de Ajuste de Complejidad evaluar cada
  factor de 0 a 5
• 0- Sin influencia
• 1- Incidental
• 2- Moderado
• 3- Medio
• 4- Significativo
• 5- Esencial
• Requiere el sistema copias de seguridad fiables?
• Se requieren comunicaciones de datos?
• Existen funciones de procesamiento distribuido?
• Es crítico el rendimiento?
• Será ejecutado el sistema en un entorno
  operativo existente y utilizado?
• Se requiere entrada de datos interactiva?
• Requiere la entrada interactiva que las
  transacciones de entrada se hagan sobre múltiples
  pantallas o variadas operaciones?
• Se actualizan los archivos maestros de forma
  interactiva?
• Son complejas las entradas, las salidas, los
  archivos o las peticiones?
• Es complejo el procesamiento interno?

• Puntos de función relación empírica basada en
  medidas cuantitativas del dominio de información
  del software y valoraciones subjetivas acerca de
  la complejidad del software

PF Cuenta Total x 0,65 0,01 x SUM(Fi) Fi
valores de ajuste de complejidad
33
estimación basada en el problema

• al estimar el proyecto, las LDC y los PF se
  utilizan como
• variables de estimación que permiten dimensionar
  cada elemento del software
• métricas de proyectos anteriores (métricas de
  línea de base)
• productividad (LDC / persona-mes)
• coste ( / persona-mes)
• ...
• pasos
• estimación de un rango de valores para cada
  función especificada en el ámbito del software
• 3 valores para cada función optimista, más
  probable y más pesimista (indica el grado de
  incertidumbre)
• valor esperado
• técnicas estadísticas cálculo de la desviación
  de las estimaciones
• aplicación de métricas de proyectos anteriores
  (en LDC o PF)

ejemplo VE (Sopt 4Sm Spes)/6
34
estimación basada en el problema
descomposición del problema en funciones a
partir del ámbito del software
F1
F2
Fn
estimación coste de F1
estimación coste de F2
cálculo de las variables de estimación (LDC y/o
PF) de F1
cálculo de las variables de estimación (LDC y/o
PF) de F2
estimación de esfuerzo de F1
estimación de esfuerzo de F2
aplicación de métricas de productividad o coste
aplicación de métricas de productividad o coste
coste de F1
esfuerzo de F1
coste de F2
esfuerzo de F2
coste de Fn
esfuerzo de Fn
estimación global del coste del proyecto
estimación global del esfuerzo del proyecto
35
estimación basada en el problema (LDC)
Hay que desarrollar un software CAD que aceptará
datos geométricos de 2 o 3 dimensiones por parte
del ingeniero. Éste controlará el sistema CAD por
medio de una interfaz que debe tener un diseño de
buena calidad. Una base de datos CAD contiene
todos los datos geométricos y la información de
soporte. Se desarrollarán módulos de análisis de
diseño para producir la salida requerida que se
va a visualizar en varios dispositivos
gráficos. El software se diseñará para controlar
e interconectar diversos periféricos, como un
ratón, un digitalizador y una impresora láser.
Funciones identificadas interfaz de usuario y
facilidades de control (IUFC) análisis geométrico
de dos dimensiones (AG2D) análisis geométrico de
tres dimensiones (AG3D) gestión de base de datos
(GBD) facilidades de la interfaz gráfica
(FIG) control periféricos (CP) módulos de
análisis del diseño (MAD)
Estimación en LDC de AG3D optimista 4600 más
probable 6900 pesimista 8600
descomposición de funciones
VE (Sopt 4Sm Spes)/6
Datos históricos productividad media de la
organización en proyectos similares 620
LDC/pm Tarifa laboral 8000 /mes Coste LDC
13
Función LDC estimada IUFC 2300 AG2D 5300 A
G3D 6800 GBD 3350 FIG 4950 CP 2100 MAD 8400 Total
33200
métricas de proyectos anteriores
Coste total proyecto 431000 Esfuerzo
estimado 54 personas-mes
36
estimación basada en el problema (PF)
Copia de seguridad y recuperación 4 Comunicaciones
2 Proceso distribuido 0 Rendimiento
crítico 4 Entorno operativo existente 3 Entrada
de datos online 4 Transacciones entrada en
varias pant. 5 Archivos maestros actualizados
online 3 Complejidad valores dominio
información 5 Complejidad procesamiento
interno 5 Código diseñado para reutilización 4 Con
versión en diseño 3 Instalaciones
múltiples 5 Aplicación diseñada para cambios 5
PF estimado cuenta total x (0,65 0,01 x Suma
(Fi)
PF estimado 372
Coste total proyecto 457000 Esfuerzo
estimado 58 personas-mes
Datos históricos productividad media de la
organización en proyectos similares 6,5
PF/pm Tarifa laboral 8000 /mes Coste por PF
1.230
métricas de proyectos anteriores
37
estimación basada en el proceso

• estimación basada en el proceso
• técnica más habitual
• el proceso se descompone en actividades o tareas
  y el esfuerzo requerido para llevar a cabo cada
  tarea
• pasos
• delimitar las funciones obtenidas a partir del
  ámbito del software
• actividades del proceso para cada función
• estimación de esfuerzo (persona-mes) para cada
  actividad en cada función
• aplicación de índices de trabajo medios (esfuerzo
  coste/unidad) al esfuerzo estimado para cada
  actividad
• cálculo de costes y esfuerzo de cada función y de
  la actividad

38
estimación basada en el proceso
Comparación de las distintas estimaciones Estimac
ión basada en el producto (LDC) 54
pm Estimación basada en el producto (PF) 58
pm Estimación basada en el proceso 46
pm Estimación media 53 pm Variación máxima
13
Tarifa laboral 8000 /mes Coste total
proyecto 368.000 Esfuerzo estimado 46
personas-mes
39
modelos empíricos de estimación

• Modelos empíricos de estimación
• Utilizan fórmulas derivadas empíricamente para
  predecir el esfuerzo como una función de LDC o
  PF.
• Datos empíricos obtenidos de una muestra de
  proyectos
• difíciles de usar para todas las clases de
  software y todos los entornos de desarrollo
• se deben calibrar para las condiciones
  específicas de una organización

A y B constantes obtenidas empíricamente E
esfuerzo en meses/persona ev variable de
estimación (LDC o PF)
E A B X (ev) c
MODELOS BASADOS EN LDC
E 5,2 x (KLDC)0,91 Modelo de Walston-Felix E
5,5 0,73 x (KLDC)1,16 Modelo de Bailey-Basili E
3,2 x (KLDC)1,05 Modelo simple de Boehm E
5,288 x (KLDC)1,047 Modelo Doty para KLDCgt9
MODELOS BASADOS EN PF
E -13,39 0,054 PF Modelo de
Albrecht-Gaffney E 60,62 x 7,728 x 10-8
PF3 Modelo de Kemerer E 585,7 15,12 PF Modelo
de Matson, Barnett y Mellichamp
40
modelos empíricos de estimación
MODELO 1 (COCOMO básico) calcula el esfuerzo y el
coste del desarrollo en función del tamaño
estimado del programa (LDC). Se utiliza para una
aproximación rápida al principio del ciclo de
vida. ESFUERZO E ab KLDCbb TIEMPO D
cb Edb

• Tres tipos de proyectos
• Orgánicos relativamente pequeños y sencillos, en
  los que trabajan pequeños equipos con
  experiencia, sobre un conjunto de requisitos poco
  rígidos.
• Semiacoplados proyectos intermedios (en tamaño y
  complejidad) en los que participan equipos con
  variados niveles de experiencia, y que deben
  satisfacer requisitos poco o medio rígidos.
• Empotrados proyectos que deben ser desarrollados
  en un conjunto de hardware, software y
  restricciones operativas muy restringido.

MODELO 2 (COCOMO intermedio) calcula el esfuerzo
y el coste en función del tamaño estimado del
programa y de un conjunto de guías de coste que
incluyen una evaluación subjetiva del producto,
hardware, personal y atributos del
producto ESFUERZO E ai KLDCbi x FAE
(factor de ajuste del esfuerzo)
MODELO COCOMO BÁSICO Proyecto ab bb cb db Orgáni
co 2,4 1,05 2,5 0,38 Semiacoplado 3,0 1,12 2,5 0,
35 Empotrado 3,6 1,20 2,5 0,32
MODELO 3 (COCOMO avanzado) incorpora las
características del mod. 2 y evalúa el impacto de
los FAE en cada fase del desarrollo.
41
el riesgo en el desarrollo de software

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

42
el riesgo en el desarrollo de software
Ejemplos de posibles riesgos en el desarrollo de
software
43
el riesgo en el desarrollo de software

• la administración de riesgos es un proceso
  iterativo que se aplica durante todo el proyecto
• etapas de la administración de riesgos
• identificación de riesgos se identifican los
  posibles riesgos para el proyecto, el producto y
  el negocio
• análisis de riesgos se valoran las
  probabilidades y las posibles consecuencias de
  los riesgos identificados
• planificación de riesgos se crean planes para
  abordar los riesgos, tanto para evitarlos como
  para minimizar sus efectos
• supervisión de riesgos se valora constantemente
  los riesgos y se revisan los planes para su
  mitigación tan pronto como la información de los
  riesgos está disponible
• los resultados de la administración de riesgos se
  documentan en un plan de administración de riesgos

fuente Ingeniería de Software. I. Sommerville,
p. 85
44
el riesgo en el desarrollo de software

• identificación de riesgos
• descubrimiento de los posibles riesgos
• no se valoran o priorizan, aunque no se tienen en
  cuenta riesgos con consecuencias pequeñas o con
  baja probabilidad
• se realiza a través de diversas técnicas
  (tormentas de ideas, experiencia del
  administrador,...)

45
el riesgo en el desarrollo de software

• análisis de riesgos
• se considera cada riesgo por separado y se valora
  en intervalos su probabilidad e impacto
• probabilidad del riesgo valorada como muy bajo
  (lt10), bajo (10-25), moderado (25-50), alto
  (50-75) o muy alto (gt75)
• 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.

46
el riesgo en el desarrollo de software

• planificación de riesgos
• se considera cada uno de los riesgos clave
  identificados y las estrategias para
  administrarlo, que vendrán dadas por el juicio y
  la experiencia del administrador del proyecto
• estrategias de anulación intentan reducir la
  probabilidad de que surja el 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

47
el riesgo en el desarrollo de software

• supervisión de riesgos
• valora cada uno de los riesgos identificados para
  decidir si es más o menos probable y cuándo han
  cambiado sus posibles efectos
• hay que controlar factores que pueden indicar
  cambios en la probabilidad y el impacto

48
bibliografía
Sommerville, I. Ingeniería de Software, cap. 4 y
24 (pp. 547-554) Pressman, R.S. Ingeniería del
Software. Un enfoque práctico, cap. 4, 5 y
6 Bruegge, B., Dutoit, A.H., Ingeniería del
Software Orientado a Objetos, cap. 3