Upload
enrique-barreiro
View
1.658
Download
0
Embed Size (px)
DESCRIPTION
Transparencias del Tema 5 (Administración de Proyectos) de la asignatura Ingeniería del Software de Gestión de la Escuela Superior de Ingeniería Informática de la Universidad de Vigo.
Citation preview
tema 6 – administración deproyectos
enrique barreirodepartamento de informática
universidade de vigo
escuela superior de ingeniería informáticaingeniería del software de gestión
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
2 / 48
introducción a la administración de proyectos
años 60 y 70: fracaso de muchos grandes proyectos de softwareretrasos en las entregas, problemas de fiabilidad, costes más elevados de lo previsto, poco eficiente,...
motivo principal: enfoque de administración utilizadotécnicas de administración derivadas de otras disciplinas de la ingenieríapoco efectivas para el desarrollo de software
desarrollos profesionales de softwareimprescindible la administración: restricciones de presupuesto, recursos y calendario
responsabilidad del administrador de proyectosplanificación y calendario del proyectosupervisión del trabajo (aplicación de estándares)supervisión del progreso (cumplimiento de tiempo y presupuesto)
la naturaleza de la ingeniería de software dificulta la administraciónel producto es intangible: no se puede ver físicamente el progreso del productono existen procesos de software estándar según tipos de productosproyectos “únicos”: diferencias con proyectos previos, evolución tecnológica de la informática y las comunicaciones,...
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
3 / 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 administradoresredacción de propuestas de desarrollo
objetivos del proyecto y cómo se va a desarrollarincluye estimaciones de coste, tiempo, asignación a equipos,...
planificación y calendario del proyecto: identificación de actividades, hitos y entregas del proyecto
estimación económica del proyecto
supervisión y revisión del proyectoactividad continuaconocimiento del progresocomparación de progreso y coste con lo planificadomecanismos formales e informales
selección y evaluación del personal
redacción y presentación de informesinformes para el cliente, organizaciones contratantes e internosdocumentos concisos y coherentespresentaciones en las revisiones de progresoadministrador: necesidad de comunicación efectiva oral y escrita
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
4 / 48
actividades de la administración
el administrador tiene tres grandes áreas de actuaciónpersonal
participantes en el proyecto (ingenieros, programadores, clientes,...)jefes de equipoestructura del equipo de desarrollo
problemaámbito del software: función, rendimiento, restricciones, datos de entrada y salida,...descomposición del problema en subproblemas (subsistemas, funciones,...)
procesoelección de un modelo de desarrollocontrolar la evolución del problema y el procesodescomposición del proceso en actividades y tareas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
5 / 48
personal del proyecto
trabajo en grupo:equipos de distintos tamaños (desde 2 a varios cientos)
los grandes equipos se dividen en grupos por subproyectos o subsistemas (normalmente de un máximo de ocho)
imprescindible espíritu de equipomotivación por el éxito del grupo y por las propias metas personalesresponsabilidad de los administradores
factores que influyen en el trabajo en grupocomposición del grupo
cohesión del grupo
comunicación del grupo
organización del grupo
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
6 / 48
personal del proyecto: composición del grupo
composición del grupolos ingenieros de software tienen una especial motivación por su trabajo
ideas propias sobre la resolución de problemas técnicosproblemas: ignorar estándares de interfaz, rediseño de sistemas al codificar, embellecimiento innecesario y personal del sistema,...importante seleccionar los miembros correctos para un grupo
preferible un grupo con personalidades complementarias que uno seleccionado únicamente por su habilidad técnica
INTUITIVO
RACIONAL
INTR
OV
ER
TID
O
EX
TRO
VE
RTI
DO
Intuitivo introvertido
pregunta a otros
utiliza sentimientos y reacciones emocionales
Intuitivo extrovertido
dice a los otros
utiliza sentimientos y reacciones emocionales
Racional introvertido
pregunta a otros
decide lógicamente
Racional extrovertido
dice a los otros
decide lógicamente
los estilos de trabajo afectan a la interacción entre clientes, desarrolladores y usuarios
implican la elección de un trabajador para una tarea dada. Por ejemplo:
intuitivos prefieren análisis y diseño (requieren ideas nuevas) al mantenimiento (requiere atención a los detalles y análisis de resultados complejos)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
7 / 48
personal del proyecto: cohesión del grupo
cohesión del grupoel grupo piensa en sí mismo como un equipo más que como una colección de individuos que trabajan juntos
miembros leales al grupo identificados con las metas y con los demás miembros, protegen al grupo de interferencias exterioresesto hace que el grupo sea robusto y se pueda enfrentar a problemas y situaciones inesperadas
ventajasse puede desarrollar un estándar de calidad en el grupolos miembros se trabajan de forma cercana, fomentando el aprendizaje mutuolos miembros conocen el trabajo de los demás, lo que facilita la continuidad si un miembro abandona el grupoprogramación “sin ego”. los programas se consideran propiedad del grupo, no personal
factores que influyen en la cohesióncultura organizacional y personalidades del grupodemostrar confianza y facilitar acceso a la informaciónsentido de identidad (nombre y establecimiento de un territorio)involucrados en actividades de grupo (deportes, juegos,...)
problemasresistencia al cambio de liderazgo por alguien externopensamiento de grupo y “corporativismo”: la consideración de alternativas se reemplaza por lealtad a las normas y decisiones del grupo
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
8 / 48
personal del proyecto: comunicación
comunicación en el grupoimportante para el progreso del proyecto
factores que influyentamaño del equipo: hay n(n-1)/2 vínculos de comunicación (n: número de miembros). Unas son bidireccionales y otras unidireccionales, según el estatusestructura del grupo: los grupos informales se comunican de forma más efectiva que los jerárquicos y formalescomposición del grupo:
choques entre miembros con los mismos tipos de personalidadmejor comunicación en grupos de ambos sexos que en grupos de un solo sexo
entorno de trabajo físicoprivacidad (concentración y trabajo sin interrupción)conciencia del exterior (luz natural y vista del entorno exterior)personalización del entornoáreas comunes y de reuniones (formales e informales)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
9 / 48
personal del proyecto: organización del grupo
organización del grupofactores que influyen en la estructura más adecuada
experiencia y estilos de trabajo de los miembrostamaño del grupoestilos de gestión de clientes y desarrolladores
principales tipos de estructura organizativaestructura formal y jerárquica
jerarquías clarascomunicación verticalasignación de responsabilidades
estructura informalestructura democrática y decisiones por consensotareas asignadas por habilidad y experienciamejor cohesión y rendimientoejemplo: “programación extrema”
Pequeños proyectos
Técnicas o tecnologías nuevasGrandes proyectos
Necesidad de entrevistasRepetición
Proyectos con incertidumbre (p.e., cambio en requerimientos)
Proyectos con elevada certeza, estabilidad y uniformidad (requieren menos comunicación)
Escasamente estructuradasFuertemente estructuradas
Comparación de estructuras organizativas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
10 / 48
personal del proyecto: organización del grupo
estructura formal: Equipo del Jefe de Programadores, Chief Programmer Team
jefe de programadores (JP): responsable del diseño, desarrollo y pruebas de instalaciónlos demás informan al JP, quien tiene la última palabra en cada decisiónsupervisa a los demás, diseña programas, asigna tareas a los otros miembros del equipo
otros miembrosayudante JP: apoya al JP y lo reemplaza cuando es necesario, responsable de la validación del softwarebibliotecario: da soporte al equipo encargándose de la gestión de configuración (mantenimiento de la documentación, versiones,...), compila, ejecuta pruebas preliminares de módulos y objetos,...especialistas que trabajan temporal o permanentemente en el grupo:
programadoresespecialistas en sistemas operativosingenieros de pruebas...
fundamento: grandes diferencias entre habilidades de programación (hasta 25 veces más productivos unos que otros)
problemasno abunda el personal adecuado para ser JP (“superprogramador”)problemas de autoestima del resto del equipolos proyectos se resienten si el JP o el ayudante se vanmodelo difícil de acomodar en las estructuras organizacionales
Jefe deprogramadores
Ayudante JP
Programadoresexpertos Bibliotecario Administrador
Equipo depruebasProgramadores
noveles
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
11 / 48
planificación del proyecto
la administración efectiva depende de una completa planificación del progreso del proyecto
plan: hilo conductor del proyecto
anticipación de los problemas que pueden surgir
preparación de soluciones a esos problemas
el plan inicial evoluciona según el progreso del proyecto y la disponibilidad de información
enfoque pesimista al elaborar suposiciones y calendario: necesidad de disponer de holguras
Valores iniciales parámetros proy ecto
Def inir hitos y productos a entregar
Establecer programación en el tiempo del proy ecto
Iniciar activ idades según la programación
Esperar un tiempo (entre 2 y 3 semanas)
Rev isar progreso proy ecto
Rev isar estimaciones de los parámetros
Actualizar programación
Renegociar restricciones y productos a entregar
Iniciar rev isión técnica y posible rev isión
proy ecto no completado ni cancelado
existen retrasos
no existen retrasos
proy ecto completado o cancelado
negociación sin éxitonegociación con éxito
Establecer restricciones proy ecto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
12 / 48
planificación del proyecto
plan del proyectoapartados habituales del plan del proyecto
1. introducción: objetivos, restricciones,...2. organización del proyecto3. análisis de riesgo: riesgos, probabilidades de que ocurran, estrategias de
reducción,...4. requerimientos de recursos de hardware y software5. división del trabajo: identificación de actividades, hitos y productos a
entregar asociados a cada actividad6. programa del proyecto: dependencias entre actividades, tiempo estimado
para cada hito, asignación de personal a las actividades,...7. mecanismos de supervisión e informe: descripción de la administración de
informes, cuándo deben producirse,...
revisión regular durante el proyectopartes que cambian frecuentemente (p.e. calendario) y otras más estables (p.e. presupuesto)organización documental que permita reemplazar fácilmente las secciones
otros planesplan de calidad
plan de validación
plan de administración de la configuración
plan de mantenimiento
plan de desarrollo del personal
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
13 / 48
planificación del proyecto
hitos y productos a entregarinformación a los administradores
documentos que describen el estado del softwarepermite juzgar el proceso y actualizar costes y calendario
establecimiento de hitospuntos finales de una actividad o tarea del proceso del softwaredocumentación que se presenta al administrador: informes cortos de los logros en una actividadrepresentan el fin de una etapa lógica en el proyecto
productos a entregarresultado que se entrega al cliente al final de una actividad principal del proceso (análisis, diseño,...)los productos son hitos, pero los hitos no son necesariamente productos a entregar (resultados internos utilizados por el administrador)
Estudioviabilidad
Especificaciónrequerim. sistema
Estudiodel diseño
Desarrolloprototipos
Análisis derequerim.
informeviabilidad
requerim.usuarios
informeevaluación
diseñoarquitectónico
requerim.sistema
ACTIVIDADES
HITOS
PRODUCTO
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
14 / 48
planificación temporal
calendariodividir el proyecto en actividades
estimar el tiempo necesario para realizarlas (algunas se harán en paralelo)
los administradores coordinan las actividades organizan el trabajo para optimizar la mano de obraasignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...)
duración aconsejable de una actividad: entre 1 y 8 semanas
importante tener en cuenta posibles problemas (personal, hardware, software,...) que provocan retrasos
problemas previstos: incrementar un 30% la estimación inicialproblemas no previstos: incrementar un 20%
utilización de diagramas de Gantt y redes de actividades
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
15 / 48
planificación temporal
T11 (M8)10T12
T9 (M6)7T11
T5, T7 (M7)15T10
T3, T6 (M4)15T9
T4 (M5)25T8
T1 (M1)20T7
T1,T2 (M3)5T6
T2,T4 (M2)10T5
10T4
T1 (M1)15T3
15T2
8T1
DependenciasDuración (días)Tarea
camino críticotrayectoria más larga en la red de actividad
el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto)
los retrasos en las demás actividades no afectan necesariamente al proyecto
T1T1
T4
T2
INICIO
M1
M3
M5
M2 T5
T8
T7
T6
T3T3
M4
T9T9
M7
FINAL
T10
M6
T11T11
M8
T12T12
4/7/02
8 días
15 días
10 días 10 días
25 días
20 dias
15 días
5 días
15 días
7 días
15 días
10 días
25/7/02
25/7/02
18/7/02
14/7/02
4/8/02
25/8/02
5/9/0211/8/02
19/9/02
RED DE ACTIVIDADES
hito
fuente: Ingeniería de Software, I. Sommerville, pp. 80-83
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
16 / 48
planificación temporal
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
inicio
final
T4
T1
T2
M1T7
T3
M5
T8
M3
M2
T6
M4
T9
M7
T10
M6
T11M8
T12
DIAGRAMA DE GANTT
flexibilidad en la fecha de finalización
la calendarizacióninicial será, con toda seguridad, incorrecta.
durante el desarrollo se deben comparar las estimaciones previas con las reales para revisar la calendarizacióndel 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.
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
17 / 48
planificación temporal
FernandoT12
FernandoT11
AnaT10
JuanaT9
FernandoT8
JaimeT7
AnaT6
MaríaT5
FernandoT4
JuanaT3
AnaT2
JuanaT1
IngenieroTarea4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Fernando T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Juana
Ana
Jaime
María
Asignación de personasa actividades
Asignación de personas vs diagrama de Gantt
El personal no tiene que estar asignado al proyecto todo el tiempo. En los periodos intermedios puede participar en otros proyectos, asistir a cursos de formación, tomar vacaciones,...
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
18 / 48
medición y métricas del software
“Cuando pueda medir lo que está diciendo y expresarlo con números, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas expresar lo que dices con números, tu conocimiento es precario y deficiente.”
(Lord Kelvin)
Métricascualquier medida relacionada con un sistema, proceso o documentación de software.
medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE Standard Glossary of Software Engineering, 1993)
Ejemplos:métricas para calcular el tamaño del un producto en líneas de códigométricas de la claridad de un párrafo en un texto escrito, por ejemplo, en un manual (índice de Fog)número de errores localizados en un producto software entregadonúmero de personas-día necesarias para desarrollar un componente...
Se aplican a:Procesos (métricas de control): por ejemplo, tiempo y esfuerzo medios necesarios para corregir un error.Productos (métricas de predicción): complejidad ciclomática de un módulo, número de métodos y atributos asociados con los objetos de un diseño,...
Permiten tomar decisiones
Proceso desoftware
Proceso desoftware Producto de
softwareProducto de
software
Métricas depredicción
Métricas depredicciónMétricas de
controlMétricas de
control
DecisionesadministrativasDecisiones
administrativas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
19 / 48
medición y métricas del software
el proceso de mediciónseleccionar medidas a realizar
formular preguntas que la medición intenta responderdefinir las métricas requeridas para responder a esas preguntasno se recogen otras métricas que no respondan a esas preguntas
seleccionar componentes a valorarno es necesario ni deseable estimar los valores de las métricas de todo un sistema de software
conjunto representativocomponentes críticos y fundamentales (utilización continua)
medir características de los componentescalcular los valores de las métricas procesando la representación del componente (diseño, código,...) con herramientas adecuadas
identificar componentes anómaloscomparación de los resultados con mediciones previas registradas en una base de datosatención especial a los valores más altos y más bajos pues pueden indicar problemas.
analizar componentes con valores anómalosse examinan los componentes para decidir si los valores obtenidos indican que su calidad está en peligro.no siempre indican problemas (por ejemplo, la complejidad de un módulo puede ser alta pero necesaria)
Elegir medidasa realizar
Elegir medidasa realizar
Seleccionarcomponentes a
valorar
Seleccionarcomponentes a
valorar
Medircaracterísticas
de los componentes
Medircaracterísticas
de los componentes
Identificarmedidasanómalas
Identificarmedidasanómalas
Analizarcomponentes
anómalos
Analizarcomponentes
anómalos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
20 / 48
medición y métricas del software
métricas del productose refieren a las características del propio software
las relaciones entre características del software pueden variar dependiendo de diversos factores (proceso, tecnología de desarrollo, tipo de sistema,...)
es necesario construir una base de datos histórica la base de datos se usa para comprobar cómo se relacionan los atributos del producto con la calidad que la organización necesita
dos tipos de métricas de productodinámicas
recogidas por las mediciones hechas en un programa en ejecuciónrelación directa con los atributos de calidad del software ejemplo: medición de tiempo de ejecución como medida de la eficiencia del sistemaejemplo: registro del número y tipo de caídas del sistema y relación con la fiabilidad del software
estáticasrecogidas por las mediciones hechas en las representaciones del sistema (diseño, código, documentación,...)relación indirecta con los atributos de calidad del softwareejemplo: longitud del programa como predictor de la mantenibilidad o la complejidadejemplo:índice de Fog como predictor de la facilidad de comprensión de un documento de texto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
21 / 48
medición y métricas del software
Medida de la longitud promedio de las palabras y declaraciones en los documentos. Cuanto mayor sea el índice de Fog, más difícil será comprender el documento.
índice de Fog
Medida de la profundidad de anidamiento de las instrucciones if en un programa. Instrucciones if profundamente anidadas son difíciles de comprender y son potencialmente susceptibles a errores.
profundidad de los ifanidados
Medida de la longitud promedio de los diferentes identificadores de un programa. Cuanto mayor sea esta longitud, más probable es que tengan significado, y por tanto el programa será más comprensible.
longitud de los identificadores
Medida de la complejidad del control de un programa, y está relacionada con la comprensión del programa.
complejidad ciclomática
Medida del tamaño del programa en líneas de código (LDC). Cuanto mayor sea el tamaño de un componente, más complejo y susceptible de incorporar errores será.
longitud del código
fan-in: medida del número de funciones que llaman a otra función X
fan-out: número de funciones que son llamadas por una función X.
Un valor alto de fan-in indica que X está fuertemente acoplada al resto del diseño y que los cambios en X pueden tener efectos extensivos al resto del sistema. Un valor alto de fan-out indica que la complejidad de X podría ser excesiva, debido a la complejidad de la lógica de control necesaria para coordinar los componentes llamados.
fan-in / fan-out
descripciónmétrica de producto
Ejemplos de métricas estáticas del producto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
22 / 48
medición y métricas del software
1
2
3 4
5 6
7
8
9
R1
R2
R3
R4
Complejidad ciclomática
V(G) = 4
Número de regiones = 4
11 aristas – 9 nodos = 4
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
23 / 48
medición y métricas del software
métricas orientadas a objetos: métricas CK (Chidamber y Kemerer)
dos métodos son similares si comparten al menos un atributo de la clase. A mayor número de métodos similares, mayor cohesión hay en la clase.
carencia de cohesión en los métodos (CCM)
número de métodos que pueden ser ejecutados en respuesta a un mensaje recibido por un objeto de esa clase. Cuanto mayor sea RPC, mayor esfuerzo se requiere para su comprobación, y más complejo es el diseño.
respuesta para una clase (RPC)
es el número de colaboraciones de una clase, y cuanto mayor sea, menor será el grado de reutilización, además de complicarse las pruebas y el mantenimiento.
acoplamiento entre clases (AEC)
cuantos más descendientes, más reutilización, pero también es posible que algunos descendientes no sean miembros realmente apropiados de la superclase.
número de hijos (NDH)
longitud máxima del nodo a la raíz del árbol. Cuanto mayor sea, las clases de los niveles más bajos heredarán muchos métodos, lo que conlleva dificultades potenciales al predecir el comportamiento de una clase. Además, la complejidad de diseño será mayor. Sin embargo, valores de APH grandes indican mayor capacidad de reutilización de métodos.
profundidad del árbol de herencia (PAH)
asumen que se definen n métodos con complejidad c1, c2,...cn se definen para la clase C. La métrica de complejidad específica que se haya elegido (por ejemplo, la complejidad ciclomática) debe normalizarse de manera que la complejidad nominal para un método toma un valor de 10.
MPC = Σci para cada i=1 hasta n
El número de métodos y su complejidad indican la cantidad de esfuerzo para implementar y verificar una clase. Cuanto mayor sea el número de métodos, más complejo es el árbol de herencia. Además, a medida que crece el número de métodos para una clase dada, más específica se vuelve y, por lo tanto, menos reutilizable. Por eso, el MP debe mantenerse lo más bajo posible.
métodos ponderados por clase (MPC)
descripciónmétrica
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
24 / 48
medición y métricas del software
Botón OK
Ventanatamañoanchonombre_clientefecha_emisióntotalcompras
mostrar_factura()
Caja de texto
Cartas_reclamoFactura
fecha_emisión : Datefecha_pago : Date
precio()impuesto()cliente()lista_compras()
Comprafechatasa_impuesto
precio()impuesto()
1
1..*
1
1..*
1
0..*
1
1..*1..*0
-
3
-
0
0
4
factura
-
4
-
0
0
2
compra
-
2
-
1
0
0
cartas_reclamo
-
1
-
0
0
0
botón OK
--CCM
13AEC
--RPC
01PAH
00NDH
01MPC
caja de textoventanaMétrica
fuente: Ingeniería de software. Teoría y práctica. S.L. Pfleeger, p. 34
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
25 / 48
medición y métricas del software
métricas del procesodatos cuantitativos de los procesos del software
la recolección de métricas del proceso es esencial para la mejora del mismo, incluso en proyectos a pequeña escala
se utilizan para evaluar la eficiencia de un proceso o si ésta ha mejorado ha mejorado con los cambios realizados
tres tipos de métricas de procesotiempo requerido para completar un proceso en particular: total del proyecto, por ingeniero, por actividad,...recursos requeridos para un proceso en particular: esfuerzo en personas-día, costes de viajes, recursos de hardware,...número de ocurrencias de un eventoparticular:
número de defectos descubiertos durante la revisión del código, número de peticiones de cambio en requerimientos, número promedio de líneas de código (LDC) modificadas en respuesta a un cambio de requerimientos,...errores detectados por el usuario...
Ayudan a descubrir si los cambios en el proceso mejoran la eficiencia de un proceso. Por ejemplo, se puede medir el tiempo y esfuerzo necesarios para moverse de un hitos fijo a otro, como la aceptación de requerimientos, terminación de un diseño arquitectónico, etc. Esos valores ayudan a identificar áreas de mejora en el proceso.Una vez introducidos los cambios, las mediciones posteriores indican si los cambios han sido positivos
Ayudan a descubrir si los cambios en el proceso mejoran la eficiencia de un proceso. Por ejemplo, se puede medir el tiempo y esfuerzo necesarios para moverse de un hitos fijo a otro, como la aceptación de requerimientos, terminación de un diseño arquitectónico, etc. Esos valores ayudan a identificar áreas de mejora en el proceso.Una vez introducidos los cambios, las mediciones posteriores indican si los cambios han sido positivos
Tienen influencia directa en la calidad del software. Por ejemplo, incrementar el número de defectos descubiertos al cambiar el proceso de revisión del código probablemente se reflejará en una mejora de la calidad del producto, aunque tiene que confirmarse por mediciones posteriores del producto.
Tienen influencia directa en la calidad del software. Por ejemplo, incrementar el número de defectos descubiertos al cambiar el proceso de revisión del código probablemente se reflejará en una mejora de la calidad del producto, aunque tiene que confirmarse por mediciones posteriores del producto.
PERSONAS(destreza, motivación,... TECNOLOGÍA
PRODUCTO (complejidad,...)
PROCESO
Entorno dedesarrollo
Característicasdel cliente(comunicación)
DETERMINANTES DE LA CALIDADDEL SOFTWARE Y DE LAEFECTIVIDAD DE LAORGANIZACIÓN
Condicionesdel negocio (fechas, reglas,...)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
26 / 48
medición y métricas del software
paradigma GQM (Goal-Question-Metric) de Basili y Rombach
se utiliza para decidir qué mediciones hacer y cómo utilizarlas
se basa en la identificación demetas (goals): aquello que la organización intenta alcanzar. Por ejemplo, mejorar la productividad de los programadores, reducir tiempos de desarrollo, incrementar la fiabilidad,...preguntas (questions): refinamientos de las metas en las que se identifican áreas específicas de incertidumbre. Ejemplos:
¿cómo se puede incrementar el número de LDC depuradas?¿cómo se puede reducir el tiempo requerido para finalizar los requerimientos?¿cómo se pueden llevar a cabo evaluaciones de fiabilidad más efectivas?
métricas: las mediciones necesarias para ayudar a responder a las preguntas y confirmar si las mejoras del proceso cumplieron su objetivo. Ejemplos:
medir la productividad de los programadores en LDC y nivel de experienciamedir número de comunicaciones formales entre cliente y analista para cada cambio de requerimientosmedir el número de pruebas requeridas para provocar una caída en el producto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
27 / 48
PLANIFICACIÓNPLANIFICACIÓN
planificación de proyectos
planificación proporciona un marco de trabajo que permite al administrador delproyecto hacer estimaciones razonables de recursos, costes y planificación temporal.
actividades de la planificacióndelimitación del ámbito del softwareestimación de recursos necesarios (humanos, hardware, software,...)
ESTIMACIÓNESTIMACIÓN RIESGORIESGOEXPERIENCIAEXPERIENCIA
DATOSHISTÓRICOS
DATOSHISTÓRICOS
Complejidad basada enesfuerzos pasados
Grado de estructuración
Tamaño del esfuerzo
Ámbito de bajoriesgo
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
28 / 48
planificación de proyectos: ámbito
delimitación del ámbito del softwaredescribe los datos a procesar, la función, el rendimiento, las restricciones, interfaces y fiabilidad necesarias
se evalúan las funciones y se refinan con más detalles si es necesario
se obtiene mediante entrevistas preliminares entre analista y cliente
utilidad del ámbito del softwareestudiar la viabilidad del proyectorealizar estimaciones de recursos necesarios
ÁMBITO DELSOFTWARE
RENDIMIENTO
RESTRICCIONES
INTERFACES
FIABILIDAD
FUNCIÓN
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
29 / 48
planificación de proyectos: recursos
estimación de recursosse especifica cada recurso mediante cuatro características
descripcióninforme de disponibilidadfecha cronológica en la que se requiere el recursotiempo durante el que será aplicado
Especificar:•Habilidades requeridas•Disponibilidad•Duración tareas.•Fecha comienzo
Especificar:•Descripción•Disponibilidad•Duración del uso•Fecha de distribución
Personas
Herramientashardware/software
Componentessoftware
reutilizables
•Componentes desarrollados•Componentes experimentados•Componentes con experiencia parcial.•Componentes nuevos
RECURSOS
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
30 / 48
planificación de proyectos: estimación
estimación del esfuerzo y coste de un proyectonormalmente el problema es demasiado complejo. Se utilizan diferentes técnicas:
descomposición del problemadescomposición del proceso
antes de hacer estimaciones de esfuerzo y costeconocer el ámbito del softwarerealizar una estimación del tamaño
precisión de una estimación:grado en que se ha estimado adecuadamente el tamaño del producto
habilidad para traducir la estimación del tamaño a:esfuerzo humanotiempodinero
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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
31 / 48
planificación de proyectos: estimación
tamaño del softwaredos tipos de enfoque
directo: se utilizan las LDC para medir el tamañoindirecto: el tamaño se representa mediante puntos de función (PF)
problemas de la utilización de LDCno existe definición estándar de LDC (p.ej., ¿se consideran LDC los comentarios?)líneas físicas o lógicascontabilización del código reutilizableaplicaciones en diferentes lenguajesestilos individuales de programación
relación entre LDC y PF: depende del lenguaje escogido
Lenguaje LDC/PF (media)
Ensamblador 320C 128Cobol 105Fortran 105Pascal 90Ada 70Lenguajes OO 30L4G 20Lenguajes visuales 4
Lenguaje LDC/PF (media)
Ensamblador 320C 128Cobol 105Fortran 105Pascal 90Ada 70Lenguajes OO 30L4G 20Lenguajes visuales 4
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
32 / 48
planificación de proyectos: estimación
Puntos de función: relación empírica basada en medidas cuantitativas del dominio de información del software y valoraciones subjetivas acerca de la complejidad del software
Número entradas usuario x 3 4 6 =
Número salidas de usuario x 4 5 7 =
Número peticiones al usuario x 3 4 6 =
Número de archivos x 7 10 15 =
Número interfaces externos x 5 7 10 =
Cuenta total
Número entradas usuario x 3 4 6 =
Número salidas de usuario x 4 5 7 =
Número peticiones al usuario x 3 4 6 =
Número de archivos x 7 10 15 =
Número interfaces externos x 5 7 10 =
Cuenta total
Parámetro de medidaParámetro de medida CuentaCuenta SimpleSimple MedioMedio ComplejoComplejo
Factor de pesoFactor de peso
Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 5
0- Sin influencia1- Incidental2- Moderado3- Medio4- Significativo5- Esencial
1.¿Requiere el sistema copias de seguridad fiables?2.¿Se requieren comunicaciones de datos?3.¿Existen funciones de procesamiento distribuido?4.¿Es crítico el rendimiento?5.¿Será ejecutado el sistema en un entorno operativo existente y utilizado?6.¿Se requiere entrada de datos interactiva?7.¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?8.¿Se actualizan los archivos maestros de forma interactiva?9.¿Son complejas las entradas, las salidas, los archivos o las peticiones?10.¿Es complejo el procesamiento interno?11.¿Se ha diseñado el código para ser reutilizable?12.¿Están incluidas en el diseño la conversión y la instalación?13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?14.¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario?
PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]
Fi : valores de ajuste de complejidad
PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]
Fi : valores de ajuste de complejidad
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
33 / 48
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
34 / 48
estimación basada en el problema
descomposición del problema en
funciones a partir del ámbito del software
F1 F2 Fn
cálculo de las variables de
estimación (LDC y/o PF) de F1
estimación coste de F1
estimación de esfuerzo de F1
cálculo de las variables de
estimación (LDC y/o PF) de F2
aplicación de métricas de
productividad o coste
coste de F2aplicación de métricas de
productividad o coste
coste de F1
coste de Fn
esfuerzo de F2
esfuerzo de F1
esfuerzo de Fn
estimación global del coste del
proyecto
estimación global del esfuerzo del
proyecto
estimación coste de F2
estimación de esfuerzo de F2
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
35 / 48
estimación basada en el problema (LDC)
Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.
Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.
Funciones identificadas:interfaz de usuario y facilidades de control (IUFC)análisis geométrico de dos dimensiones (AG2D)análisis geométrico de tres dimensiones (AG3D)gestión de base de datos (GBD)facilidades de la interfaz gráfica (FIG)control periféricos (CP)módulos de análisis del diseño (MAD)
Funciones identificadas:interfaz de usuario y facilidades de control (IUFC)análisis geométrico de dos dimensiones (AG2D)análisis geométrico de tres dimensiones (AG3D)gestión de base de datos (GBD)facilidades de la interfaz gráfica (FIG)control periféricos (CP)módulos de análisis del diseño (MAD)
Estimación en LDC de AG3D:optimista: 4600más probable: 6900pesimista: 8600
Estimación en LDC de AG3D:optimista: 4600más probable: 6900pesimista: 8600
VE = (Sopt + 4Sm + Spes)/6VE = (Sopt + 4Sm + Spes)/6
Función LDC estimada
IUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400Total 33200
Función LDC estimada
IUFC 2300AG2D 5300AG3D 6800GBD 3350FIG 4950CP 2100MAD 8400Total 33200
Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pm
Tarifa laboral: 8000 $ /mes
Coste LDC: 13 $
Datos históricos:productividad media de la organización en proyectos similares: 620 LDC/pm
Tarifa laboral: 8000 $ /mes
Coste LDC: 13 $
desc
ompo
sici
ónde
func
ione
sde
scom
posi
ción
de fu
ncio
nes
mét
ricas
de
proy
ecto
s an
terio
res
mét
ricas
de
proy
ecto
s an
terio
res
Coste total proyecto: 431000 $
Esfuerzo estimado: 54 personas-mes
Coste total proyecto: 431000 $
Esfuerzo estimado: 54 personas-mes
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
36 / 48
estimación basada en el problema (PF)
Valor dominio información
Opt. Probable Pesimista Cuenta est
Peso Cuenta PF
Num. entradas 20 24 30 24 4 96 Num. salidas 12 15 22 16 5 80 Num. peticiones 16 22 28 22 4 88 Num. archivos 4 4 5 4 10 40 Num. interfaces ext. 2 2 3 2 7 14 Cuenta total 318
Copia de seguridad y recuperación 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5
Copia de seguridad y recuperación 4Comunicaciones 2Proceso distribuido 0Rendimiento crítico 4Entorno operativo existente 3Entrada de datos online 4Transacciones entrada en varias pant. 5Archivos maestros actualizados online 3Complejidad valores dominio información 5Complejidad procesamiento interno 5Código diseñado para reutilización 4Conversión en diseño 3Instalaciones múltiples 5Aplicación diseñada para cambios 5
PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)
PF estimado = 372PF estimado = 372
Coste total proyecto: 457000 $
Esfuerzo estimado: 58 personas-mes
Coste total proyecto: 457000 $
Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pm
Tarifa laboral: 8000 $ /mes
Coste por PF: 1.230 $
Datos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pm
Tarifa laboral: 8000 $ /mes
Coste por PF: 1.230 $mét
ricas
de
proy
ecto
s an
terio
res
mét
ricas
de
proy
ecto
s an
terio
res
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
37 / 48
estimación basada en el proceso
estimación basada en el procesoté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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
38 / 48
estimación basada en el proceso
Actividades Entrevistas Planificación Análisis
riesgo Ingeniería Construcción
entrega Evaluación
cliente Totales
Tareas Análisis Diseño Código Prueba Función IUFC AG2D AG3D GBD FIG CP MAD
0,50 0,75 0,50 0,50 0,50 0,25 0,50
2,50 4,00 4,00 3,00 3,00 2,00 2,00
0,40 0,60 1,00 1,00 0,75 0,50 0,50
5,00 2,00 3,00 1,50 1,50 1,50 2,00
n/a n/a n/a n/a n/a n/a n/a
8,40 7,35 8,50 6,00 5,75 4,25 5,00
Total 0,25 0,25 0,25 3,50 20,50 4,75 16,50 46,00 %esfuerzo 1% 1% 1% 8% 45% 10% 36%
Actividades Entrevistas Planificación Análisis
riesgo Ingeniería Construcción
entrega Evaluación
cliente Totales
Tareas Análisis Diseño Código Prueba Función IUFC AG2D AG3D GBD FIG CP MAD
0,50 0,75 0,50 0,50 0,50 0,25 0,50
2,50 4,00 4,00 3,00 3,00 2,00 2,00
0,40 0,60 1,00 1,00 0,75 0,50 0,50
5,00 2,00 3,00 1,50 1,50 1,50 2,00
n/a n/a n/a n/a n/a n/a n/a
8,40 7,35 8,50 6,00 5,75 4,25 5,00
Total 0,25 0,25 0,25 3,50 20,50 4,75 16,50 46,00 %esfuerzo 1% 1% 1% 8% 45% 10% 36%
Tarifa laboral: 8000 $ /mes
Coste total proyecto: 368.000 $
Esfuerzo estimado: 46 personas-mes
Tarifa laboral: 8000 $ /mes
Coste total proyecto: 368.000 $
Esfuerzo estimado: 46 personas-mes
Comparación de las distintas estimaciones
Estimación basada en el producto (LDC): 54 pm
Estimación basada en el producto (PF): 58 pm
Estimación basada en el proceso: 46 pm
Estimación media: 53 pm
Variación máxima: 13%
Comparación de las distintas estimaciones
Estimación basada en el producto (LDC): 54 pm
Estimación basada en el producto (PF): 58 pm
Estimación basada en el proceso: 46 pm
Estimación media: 53 pm
Variación máxima: 13%
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
39 / 48
modelos empíricos de estimación
Modelos empíricos de estimación:Utilizan fórmulas derivadas empíricamente para predecir el esfuerzo como una función de LDC o PF.
Datos empíricos obtenidos de una muestra de proyectos: difíciles de usar para todas las clases de software y todos los entornos de desarrollose deben calibrar para las condiciones específicas de una organización
E = A + B X (ev) cE = A + B X (ev) c
A y B: constantes obtenidas empíricamenteE: esfuerzo en meses/personaev: variable de estimación (LDC o PF)
E = 5,2 x (KLDC)0,91 Modelo de Walston-FelixE = 5,5 + 0,73 x (KLDC)1,16 Modelo de Bailey-BasiliE = 3,2 x (KLDC)1,05 Modelo simple de BoehmE = 5,288 x (KLDC)1,047 Modelo Doty para KLDC>9
E = 5,2 x (KLDC)0,91 Modelo de Walston-FelixE = 5,5 + 0,73 x (KLDC)1,16 Modelo de Bailey-BasiliE = 3,2 x (KLDC)1,05 Modelo simple de BoehmE = 5,288 x (KLDC)1,047 Modelo Doty para KLDC>9
MODELOS BASADOS EN LDC
E = -13,39 + 0,054 PF Modelo de Albrecht-GaffneyE = 60,62 x 7,728 x 10-8 PF3 Modelo de KemererE = 585,7 + 15,12 PF Modelo de Matson, Barnett
y Mellichamp
E = -13,39 + 0,054 PF Modelo de Albrecht-GaffneyE = 60,62 x 7,728 x 10-8 PF3 Modelo de KemererE = 585,7 + 15,12 PF Modelo de Matson, Barnett
y Mellichamp
MODELOS BASADOS EN PF
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
40 / 48
Tres tipos de proyectos:Orgánicos: relativamente pequeños y sencillos, en los que trabajan pequeños equipos con experiencia, sobre un conjunto de requisitos poco rígidos.
Semiacoplados: proyectos intermedios (en tamaño y complejidad) en los que participan equipos con variados niveles de experiencia, y que deben satisfacer requisitos poco o medio rígidos.
Empotrados: proyectos que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido.
MODELO 1 (COCOMO básico)calcula el esfuerzo y el coste del desarrollo en función del tamaño estimado del programa (LDC). Se utiliza para una aproximación rápida al principiodel ciclo de vida.
ESFUERZO: E = ab KLDCbb
TIEMPO: D = cb Edb
MODELO 1 (COCOMO básico)calcula el esfuerzo y el coste del desarrollo en función del tamaño estimado del programa (LDC). Se utiliza para una aproximación rápida al principiodel ciclo de vida.
ESFUERZO: E = ab KLDCbb
TIEMPO: D = cb Edb
MODELO 2 (COCOMO intermedio)calcula el esfuerzo y el coste en función del tamañoestimado del programa y de un conjunto de “guíasde coste” que incluyen una evaluación subjetiva del producto, hardware, personal y atributos del producto
ESFUERZO: E = ai KLDCbi x FAE (factorde ajuste del esfuerzo)
MODELO 2 (COCOMO intermedio)calcula el esfuerzo y el coste en función del tamañoestimado del programa y de un conjunto de “guíasde coste” que incluyen una evaluación subjetiva del producto, hardware, personal y atributos del producto
ESFUERZO: E = ai KLDCbi x FAE (factorde ajuste del esfuerzo)
MODELO 3 (COCOMO avanzado)incorpora las características del mod. 2 y evalúa elimpacto de los FAE en cada fase del desarrollo.
MODELO 3 (COCOMO avanzado)incorpora las características del mod. 2 y evalúa elimpacto de los FAE en cada fase del desarrollo.
MODELO COCOMO BÁSICO
Proyecto ab bb cb db
Orgánico 2,4 1,05 2,5 0,38
Semiacoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
MODELO COCOMO BÁSICO
Proyecto ab bb cb db
Orgánico 2,4 1,05 2,5 0,38
Semiacoplado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
modelos empíricos de estimación
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
41 / 48
el riesgo en el desarrollo de software
Riesgoel administrador de proyectos anticipa riesgos que pueden afectar al desarrollo o a la calidad del software y emprende acciones para evitarlos
riesgo: probabilidad de que ocurra una circunstancia adversa para el proyecto
amenazan el proyecto, el software y la propia organización
existen riesgos conocidos, predecibles e impredecibles
categorías de riesgos:riesgos del proyecto: afectan al presupuesto, los recursos, la planificación,...riesgos del producto: afectan a la calidad o al rendimiento del softwareriesgos del negocio: afectan a la organización (riesgos de mercado, estratégicos, de distribución, de pérdida del presupuesto o del personal,...)riesgos que entran en las tres categorías anteriores (por ejemplo, el abandono de un programador experto es un riesgo para el producto, el proyecto y el negocio)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
42 / 48
el riesgo en el desarrollo de software
un producto competitivo se pone en venta antes de que el sistema se completenegociocompetencia del
producto
la tecnología fundamental sobre la que se está construyendo el sistema es sustituida por una nuevanegociocambio de
tecnología
las herramientas CASE que ayudan al proyecto no tienen el rendimiento y las funcionalidades esperadasproducto
bajo rendimiento de la herramienta
CASE
el tamaño del sistema se ha subestimadoproyecto y producto
subestimación del tamaño
retrasos en la especificación
cambios de requerimientos
no disponibilidad del hardware
cambio de administración
rotación de personal
riesgo
retrasos en las especificaciones de interfaces esencialesproyecto y producto
existencia de más cambios de requerimientos de los previstos inicialmente
proyecto y producto
el hardware necesario para el proyecto no se recibe a tiempoproyecto
cambio de administración organizativa con diferentes prioridadesproyecto
personal con experiencia abandona el proyecto antes de que finalice
proyecto, producto y
negocio
descripcióntipo de riesgo
Ejemplos de posibles riesgos en el desarrollo de software
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
43 / 48
el riesgo en el desarrollo de software
la administración de riesgos es un proceso iterativo que se aplica durante todo el proyecto
etapas de la administración de riesgosidentificación de riesgos: se identifican los posibles riesgos para el proyecto, el producto y el negocio
análisis de riesgos: se valoran las probabilidades y las posibles consecuencias de los riesgos identificados
planificación de riesgos: se crean planes para abordar los riesgos, tanto para evitarlos como para minimizar sus efectos
supervisión de riesgos: se valora constantemente los riesgos y se revisan los planes para su mitigación tan pronto como la información de los riesgos está disponible
los resultados de la administración de riesgos se documentan en un plan de administración de riesgos supervisión
de riesgossupervisiónde riesgos
planificación de riesgos
planificación de riesgos
análisis de riesgosanálisis
de riesgos
identificaciónde riesgos
identificaciónde riesgos
valoración deriesgos
anulación deriesgos yplanes de
contingencia
listado depriorizaciónde riesgos
listado deriesgos
potenciales
fuente: Ingeniería de Software. I. Sommerville, p. 85
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
44 / 48
el riesgo en el desarrollo de software
identificación de riesgosdescubrimiento 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,...)
cambian las leyes imponiendo restricciones que no estaban previstaslegales
el tiempo requerido para desarrollar el software está subestimadola tasa de reparación de defectos está subestimadael tamaño del software está subestimado
estimación
requerimientos
herramientas
organizativos
personal
tecnología
tipo de riesgo
cambios de requerimientos que precisan modificaciones en el diseñolos clientes no comprenden el impacto de los cambios en los requerimientos
las herramientas CASE generan código ineficientelas distintas herramientas CASE no se pueden integrar
la organización se reestructura y una nueva administración se responsabiliza del proyectolos problemas financieros de la organización reducen el presupuesto del proyecto
imposible contratar personal con los conocimientos requeridospersonal clave enfermo o no disponible en momentos críticos
la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperabalos componentes de software a reutilizar tienen defectos que limitan su funcionalidad
ejemplos de posibles riesgos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
45 / 48
el riesgo en el desarrollo de software
análisis de riesgosse considera cada riesgo por separado y se valora en intervalos su probabilidad e impacto:
probabilidad del riesgo valorada como muy bajo (<10%), bajo (10-25%), moderado(25-50%), alto (50-75%) o muy alto (>75%)efectos del riesgo valorados como catastrófico, serio, tolerable o insignificanteel resultado se coloca en una tabla ordenada por la seriedad del riesgo
se decide cuáles son los más importantes (riesgos clave) y que se van a considerar durante el proyecto (por ejemplo, todos los serios o catastróficos con cualquier probabilidad), y que debe ser un número manejable.
insignificantemoderadalas herramientas CASE generan código ineficiente
tolerablealtael tamaño del software está subestimado
tolerablemoderadala tasa de reparación de defectos está subestimada
tolerablemoderadalos clientes no comprenden el impacto de los cambios en los requerimientos
tolerablealtalas distintas herramientas CASE no se pueden integrar
serioaltael tiempo requerido para desarrollar el software está subestimado
la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba
la organización se reestructura y una nueva administración se responsabiliza del proyecto
cambios de requerimientos que precisan modificaciones en el diseño
los componentes de software a reutilizar tienen defectos que limitan su funcionalidad
personal clave enfermo o no disponible en momentos críticos
imposible contratar personal con los conocimientos requeridos
los problemas financieros de la organización reducen el presupuesto del proyecto
riesgo
seriomoderada
serioalta
moderada
moderada
moderada
alta
baja
probab.
serio
serio
serio
catastrófico
catastrófico
efectos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
46 / 48
el riesgo en el desarrollo de software
planificación de riesgosse considera cada uno de los riesgos clave identificados y las estrategias para administrarlo, que vendrán dadas por el juicio y la experiencia del administrador del proyecto
estrategias de anulación: intentan reducir la probabilidad de que surja el riesgoestrategias de disminución: intentan reducir el impacto del riesgoplanes de contingencia: se dispone de ellos para estar preparados por si el riesgo ocurre y poder actuar con una estrategia determinada
alertar al cliente de las dificultades potenciales y las posibilidades de retrasotiempo de desarrollo subestimado
rendimiento de la base de datos
reestructuración organizativa
cambios en los requerimientos
componentes defectuosos
enfermedad del personal
problemas de reclutamiento
problemas financieros de la organización
riesgo
investigar la posibilidad de comprar una base de datos con el rendimiento preciso
preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio
rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos
reemplazar los componentes defectuosos con los comprados de fiabilidad conocida
reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del equipo comprendan el trabajo de los demás
organizar cursos de capacitación para el personal ya existente, investigar la posibilidad de contratar en otras regiones o países
preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio
estrategia
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
47 / 48
el riesgo en el desarrollo de software
supervisión de riesgosvalora 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
estimación
requerimientos
herramientas
organizacional
personal
tecnología
tipo de riesgo
fracaso en el cumplimiento de los tiempos planificados
peticiones de muchos cambios en los requerimientosquejas del cliente
rechazo de los miembros del equipo a utilizar herramientasquejas sobre las herramientas CASEpeticiones de estaciones de trabajo más potentes
rumores en la empresafalta de iniciativa de la dirección de la empresa
baja moral del personal, malas relaciones entre miembros del equipo, disponibilidad de empleo
entrega retrasada del hardware o del softwareexistencia de informes sobre problemas tecnológicos
indicadores potenciales
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 6 - administración de proyectos
48 / 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