Tema 6 - Admin de Proyectos

tema 6 administracin de proyectos
enrique barreiro departamento de informtica universidade de vigo escuela superior de ingeniera informtica ingeniera del software de gestin
introduccin a la administracin de proyectos

tema 6 - administracin de proyectos
aos 60 y 70: fracaso de muchos grandes proyectos de software

retrasos en las entregas, problemas de fiabilidad, costes ms elevados de lo previsto, poco eficiente,... motivo principal: enfoque de administracin utilizado
tcnicas de administracin derivadas de otras disciplinas de la ingeniera poco efectivas para el desarrollo de software
desarrollos profesionales de software

imprescindible la administracin: restricciones de presupuesto, recursos y calendario responsabilidad del administrador de proyectos
planificacin y calendario del proyecto supervisin del trabajo (aplicacin de estndares) supervisin del progreso (cumplimiento de tiempo y presupuesto)
la naturaleza de la ingeniera de software dificulta la administracin

el producto es intangible: no se puede ver fsicamente el progreso del producto no existen procesos de software estndar segn tipos de productos proyectos nicos: diferencias con proyectos previos, evolucin tecnolgica de la informtica y las comunicaciones,...
enrique barreiro alonso universidade de vigo - departamento de informtica
escuela superior de ingeniera informtica ingeniera del software de gestin
2 / 48
actividades de la administracin
la administracin puede variar mucho segn la organizacin, tipo de producto, etc. actividades responsabilidad de los administradores
redaccin de propuestas de desarrollo
objetivos del proyecto y cmo se va a desarrollar incluye estimaciones de coste, tiempo, asignacin a equipos,...
planificacin y calendario del proyecto: identificacin de actividades, hitos y entregas del proyecto estimacin econmica del proyecto supervisin y revisin del proyecto
actividad continua conocimiento del progreso comparacin de progreso y coste con lo planificado mecanismos formales e informales
seleccin y evaluacin del personal
redaccin y presentacin de informes

informes para el cliente, organizaciones contratantes e internos documentos concisos y coherentes presentaciones en las revisiones de progreso administrador: necesidad de comunicacin efectiva oral y escrita
3 / 48
actividades de la administracin
el administrador tiene tres grandes reas de actuacin

personal
participantes en el proyecto (ingenieros, programadores, clientes,...) jefes de equipo estructura del equipo de desarrollo
problema
mbito del software: funcin, rendimiento, restricciones, datos de entrada y salida,... descomposicin del problema en subproblemas (subsistemas, funciones,...)
proceso
eleccin de un modelo de desarrollo controlar la evolucin del problema y el proceso descomposicin del proceso en actividades y tareas
4 / 48
personal del proyecto

trabajo en grupo:
equipos de distintos tamaos (desde 2 a varios cientos)
los grandes equipos se dividen en grupos por subproyectos o subsistemas (normalmente de un mximo de ocho)
imprescindible espritu de equipo
motivacin por el xito del grupo y por las propias metas personales responsabilidad de los administradores
factores que influyen en el trabajo en grupo

composicin del grupo cohesin del grupo comunicacin del grupo organizacin del grupo
5 / 48
personal del proyecto: composicin del grupo

composicin del grupo

los ingenieros de software tienen una especial motivacin por su trabajo
ideas propias sobre la resolucin de problemas tcnicos problemas: ignorar estndares de interfaz, rediseo 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 tcnica
INTUITIVO
Intuitivo introvertido pregunta a otros Intuitivo extrovertido dice a los otros utiliza sentimientos y reacciones emocionales Racional extrovertido dice a los otros decide lgicamente
utiliza sentimientos y reacciones emocionales Racional introvertido pregunta a otros decide lgicamente
EXTROVERTIDO
INTROVERTIDO
los estilos de trabajo afectan a la interaccin entre clientes, desarrolladores y usuarios implican la eleccin de un trabajador para una tarea dada. Por ejemplo:
intuitivos prefieren anlisis y diseo (requieren ideas nuevas) al mantenimiento (requiere atencin a los detalles y anlisis de resultados complejos)
RACIONAL
6 / 48
personal del proyecto: cohesin del grupo

cohesin del grupo

el grupo piensa en s mismo como un equipo ms que como una coleccin de individuos que trabajan juntos miembros
leales al grupo identificados con las metas y con los dems 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 estndar de calidad en el grupo los miembros se trabajan de forma cercana, fomentando el aprendizaje mutuo los miembros conocen el trabajo de los dems, lo que facilita la continuidad si un miembro abandona el grupo programacin sin ego. los programas se consideran propiedad del grupo, no personal
factores que influyen en la cohesin

cultura organizacional y personalidades del grupo demostrar confianza y facilitar acceso a la informacin sentido de identidad (nombre y establecimiento de un territorio) involucrados en actividades de grupo (deportes, juegos,...)
problemas
resistencia al cambio de liderazgo por alguien externo pensamiento de grupo y corporativismo: la consideracin de alternativas se reemplaza por lealtad a las normas y decisiones del grupo
7 / 48
personal del proyecto: comunicacin

comunicacin en el grupo
importante para el progreso del proyecto
factores que influyen

tamao del equipo: hay n(n-1)/2 vnculos de comunicacin (n: nmero de miembros). Unas son bidireccionales y otras unidireccionales, segn el estatus estructura del grupo: los grupos informales se comunican de forma ms efectiva que los jerrquicos y formales composicin del grupo:
choques entre miembros con los mismos tipos de personalidad mejor comunicacin en grupos de ambos sexos que en grupos de un solo sexo privacidad (concentracin y trabajo sin interrupcin) conciencia del exterior (luz natural y vista del entorno exterior) personalizacin del entorno reas comunes y de reuniones (formales e informales)
entorno de trabajo fsico
8 / 48
personal del proyecto: organizacin del grupo

organizacin del grupo

factores que influyen en la estructura ms adecuada
experiencia y estilos de trabajo de los miembros tamao del grupo estilos de gestin de clientes y desarrolladores
principales tipos de estructura organizativa

estructura formal y jerrquica
jerarquas claras comunicacin vertical asignacin de responsabilidades
estructura informal
estructura democrtica y decisiones por consenso tareas asignadas por habilidad y experiencia mejor cohesin y rendimiento ejemplo: programacin extrema
Comparacin de estructuras organizativas Fuertemente estructuradas

Proyectos con elevada certeza, estabilidad y uniformidad (requieren menos comunicacin)
Escasamente estructuradas
Proyectos con incertidumbre (p.e., cambio en requerimientos)
Repeticin Grandes proyectos
Necesidad de entrevistas Tcnicas o tecnologas nuevas

Pequeos proyectos
9 / 48
personal del proyecto: organizacin del grupo

estructura formal: Equipo del Jefe de Programadores, Chief Programmer Team

jefe de programadores (JP):
Jefe de programadores responsable del diseo, desarrollo y pruebas de instalacin los dems informan al JP, quien tiene la ltima palabra en cada decisin supervisa a los dems, disea programas, asigna tareas a los otros miembros del equipo
otros miembros
Ayudante JP ayudante JP: apoya al JP y lo reemplaza cuando es necesario, responsable de la validacin del software bibliotecario: da soporte al equipo encargndose de la gestin de configuracin (mantenimiento de la documentacin, versiones,...), compila, ejecuta pruebas preliminares de mdulos y objetos,... especialistas que trabajan temporal o permanentemente en el grupo: programadores especialistas en sistemas operativos ingenieros de pruebas ...
Programadores expertos
Bibliotecario
Administrador Equipo de pruebas
Programadores noveles
fundamento: grandes diferencias entre habilidades de programacin (hasta 25 veces ms 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 difcil de acomodar en las estructuras organizacionales
10 / 48
planificacin del proyecto

Establecer restricciones proy ecto Valores iniciales parmetros proy ecto Def inir hitos y productos a entregar
Establecer programacin en el tiempo del proy ecto
Iniciar activ idades segn la programacin
la administracin efectiva depende de una completa planificacin del progreso del proyecto
plan: hilo conductor del proyecto
anticipacin de los problemas que pueden surgir preparacin de soluciones a esos problemas el plan inicial evoluciona segn el progreso del proyecto y la disponibilidad de informacin enfoque pesimista al elaborar suposiciones y calendario: necesidad de disponer de holguras
Esperar un tiempo (entre 2 y 3 semanas)
Rev isar progreso proy ecto
Rev isar estimaciones de los parmetros
Actualizar programacin
existen retrasos
Renegociar restricciones y productos a entregar
no existen retrasos negociacin con xito negociacin sin xito Iniciar rev isin tcnica y posible rev isin proy ecto no completado ni cancelado proy ecto completado o cancelado
11 / 48

plan del proyecto

apartados habituales del plan del proyecto
1. introduccin: objetivos, restricciones,... 2. organizacin del proyecto 3. anlisis de riesgo: riesgos, probabilidades de que ocurran, estrategias de reduccin,... 4. requerimientos de recursos de hardware y software 5. divisin del trabajo: identificacin de actividades, hitos y productos a entregar asociados a cada actividad 6. programa del proyecto: dependencias entre actividades, tiempo estimado para cada hito, asignacin de personal a las actividades,... 7. mecanismos de supervisin e informe: descripcin de la administracin de informes, cundo deben producirse,...
revisin regular durante el proyecto

partes que cambian frecuentemente (p.e. calendario) y otras ms estables (p.e. presupuesto) organizacin documental que permita reemplazar fcilmente las secciones
otros planes
plan de calidad
plan de validacin plan de administracin de la configuracin plan de mantenimiento plan de desarrollo del personal
escuela superior de ingeniera informtica ingeniera del software de gestin 12 / 48

hitos y productos a entregar

informacin 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 documentacin que se presenta al administrador: informes cortos de los logros en una actividad representan el fin de una etapa lgica en el proyecto
productos a entregar
resultado que se entrega al cliente al final de una actividad principal del proceso (anlisis, diseo,...) los productos son hitos, pero los hitos no son necesariamente productos a entregar (resultados internos utilizados por el administrador) ACTIVIDADES Estudio viabilidad Anlisis de requerim. Desarrollo prototipos Estudio del diseo Especificacin requerim. sistema
HITOS
informe viabilidad
requerim. usuarios
informe evaluacin
diseo arquitectnico
requerim. sistema
PRODUCTO
13 / 48
planificacin temporal
calendario
dividir el proyecto en actividades
estimar el tiempo necesario para realizarlas (algunas se harn 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,...)
duracin 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 estimacin inicial problemas no previstos: incrementar un 20%
utilizacin de diagramas de Gantt y redes de actividades
14 / 48
RED DE ACTIVIDADES
Tarea Duracin (das) Dependencias
8 das 14/7/02 M1 15 das T3 5 das 25/7/02 M3 15 das T2 T6 4/8/02 M4 15 das T9
T1
T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
8
15 15 10 10 5 20 25 15 15 7 10 T1 (M1)
hito
4/7/02 INICIO
T1
25/8/02
M6
20 dias T7
7 das T11
T2,T4 (M2) T1,T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)
10 das T4 25/7/02 M2 10 das T5 11/8/02 M7 15 das
5/9/02
M8
M5
18/7/02 25 das T8
T10
T12 10 das FINAL 19/9/02
camino crtico
trayectoria ms larga en la red de actividad
fuente: Ingeniera de Software, I. Sommerville, pp. 80-83
el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto) los retrasos en las dems actividades no afectan necesariamente al proyecto
15 / 48
4/7
11/7 inicio
18/7
25/7
1/8
8/8
15/8
22/8
29/8
5/9
12/9
19/9
DIAGRAMA DE GANTT
la calendarizacin inicial ser, con toda seguridad, incorrecta. durante el desarrollo se deben comparar las estimaciones previas con las reales para revisar la calendarizacin del resto del proyecto.
T4 T1
flexibilidad en la fecha de finalizacin

T2
M1 T7 T3 M5 T8 M3 M2
T6
M4 T9 M7 T10 M6 T11 M8 T12 final
al conocer cifras reales, se debe revisar la red de actividades y reorganizar las actividades posteriores para reducir la longitud de la trayectoria crtica.
16 / 48
Asignacin de personas a actividades Tarea T1 T2 T3 T4 Ingeniero Juana Ana Juana Fernando

Juana T1 4/7 Fernando T4 11/7
Asignacin de personas vs diagrama de Gantt

18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T8
T11 T12
T3 T9
T5
T6 T7 T8 T9 T10 T11 T12
Mara
Ana Jaime Fernando Juana Ana Fernando Fernando
Mara T5 Jaime T7
Ana
T2 T6 T10
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 formacin, tomar vacaciones,...
escuela superior de ingeniera informtica ingeniera del software de gestin 17 / 48
medicin y mtricas del software

Cuando pueda medir lo que est diciendo y expresarlo con nmeros, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas expresar lo que dices con nmeros, tu conocimiento es precario y deficiente. (Lord Kelvin)
Mtricas
cualquier medida relacionada con un sistema, proceso o documentacin 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:
mtricas para calcular el tamao del un producto en lneas de cdigo mtricas de la claridad de un prrafo en un texto escrito, por ejemplo, en un manual (ndice de Fog) nmero de errores localizados en un producto software entregado nmero de personas-da necesarias para desarrollar un componente ... Proceso de software Producto de software
Mtricas de control
Mtricas de prediccin
Se aplican a:
Procesos (mtricas de control): por ejemplo, tiempo y esfuerzo medios necesarios para corregir un error. Productos (mtricas de prediccin): complejidad ciclomtica de un mdulo, nmero de mtodos y atributos asociados con los objetos de un diseo,...
Decisiones administrativas
Permiten tomar decisiones
18 / 48

el proceso de medicin
seleccionar medidas a realizar
formular preguntas que la medicin intenta responder definir las mtricas requeridas para responder a esas preguntas no se recogen otras mtricas que no respondan a esas preguntas
Elegir medidas a realizar
seleccionar componentes a valorar

no es necesario ni deseable estimar los valores de las mtricas de todo un sistema de software
conjunto representativo componentes crticos y fundamentales (utilizacin continua)
Seleccionar componentes a valorar
medir caractersticas de los componentes

calcular los valores de las mtricas procesando la representacin del componente (diseo, cdigo,...) con herramientas adecuadas
Medir caractersticas de los componentes
identificar componentes anmalos

comparacin de los resultados con mediciones previas registradas en una base de datos atencin especial a los valores ms altos y ms bajos pues pueden indicar problemas.
Identificar medidas anmalas
analizar componentes con valores anmalos

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 mdulo puede ser alta pero necesaria)
Analizar componentes anmalos
19 / 48

mtricas del producto

se refieren a las caractersticas del propio software
las relaciones entre caractersticas del software pueden variar dependiendo de diversos factores (proceso, tecnologa de desarrollo, tipo de sistema,...)
es necesario construir una base de datos histrica la base de datos se usa para comprobar cmo se relacionan los atributos del producto con la calidad que la organizacin necesita
dos tipos de mtricas de producto

dinmicas
recogidas por las mediciones hechas en un programa en ejecucin relacin directa con los atributos de calidad del software ejemplo: medicin de tiempo de ejecucin como medida de la eficiencia del sistema ejemplo: registro del nmero y tipo de cadas del sistema y relacin con la fiabilidad del software
estticas
recogidas por las mediciones hechas en las representaciones del sistema (diseo, cdigo, documentacin,...) relacin 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 comprensin de un documento de texto
20 / 48

Ejemplos de mtricas estticas del producto mtrica de producto descripcin

fan-in: medida del nmero de funciones que llaman a otra funcin X fan-out: nmero de funciones que son llamadas por una funcin X. fan-in / fan-out Un valor alto de fan-in indica que X est fuertemente acoplada al resto del diseo 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 podra ser excesiva, debido a la complejidad de la lgica de control necesaria para coordinar los componentes llamados. Medida del tamao del programa en lneas de cdigo (LDC). Cuanto mayor sea el tamao de un componente, ms complejo y susceptible de incorporar errores ser. Medida de la complejidad del control de un programa, y est relacionada con la comprensin del programa. Medida de la longitud promedio de los diferentes identificadores de un programa. Cuanto mayor sea esta longitud, ms probable es que tengan significado, y por tanto el programa ser ms comprensible. Medida de la profundidad de anidamiento de las instrucciones if en un programa. Instrucciones if profundamente anidadas son difciles de comprender y son potencialmente susceptibles a errores. Medida de la longitud promedio de las palabras y declaraciones en los documentos. Cuanto mayor sea el ndice de Fog, ms difcil ser comprender el documento.
longitud del cdigo complejidad ciclomtica longitud de los identificadores profundidad de los if anidados ndice de Fog
21 / 48

R1
Complejidad ciclomtica V(G) = 4
3 R2
Nmero de regiones = 4 11 aristas 9 nodos = 4
5 R3
7 R4 8
22 / 48

mtricas orientadas a objetos: mtricas CK (Chidamber y Kemerer)

mtrica descripcin
asumen que se definen n mtodos con complejidad c1, c2,...cn se definen para la clase C. La mtrica de complejidad especfica que se haya elegido (por ejemplo, la complejidad ciclomtica) debe normalizarse de manera que la complejidad nominal para un mtodo toma un valor de 10. mtodos ponderados por clase (MPC)
MPC = ci para cada i=1 hasta n

El nmero de mtodos y su complejidad indican la cantidad de esfuerzo para implementar y verificar una clase. Cuanto mayor sea el nmero de mtodos, ms complejo es el rbol de herencia. Adems, a medida que crece el nmero de mtodos para una clase dada, ms especfica se vuelve y, por lo tanto, menos reutilizable. Por eso, el MP debe mantenerse lo ms bajo posible. longitud mxima del nodo a la raz del rbol. Cuanto mayor sea, las clases de los niveles ms bajos heredarn muchos mtodos, lo que conlleva dificultades potenciales al predecir el comportamiento de una clase. Adems, la complejidad de diseo ser mayor. Sin embargo, valores de APH grandes indican mayor capacidad de reutilizacin de mtodos.
profundidad del rbol de herencia (PAH)
nmero de hijos (NDH)

acoplamiento entre clases (AEC) respuesta para una clase (RPC) carencia de cohesin en los mtodos (CCM)
cuantos ms descendientes, ms reutilizacin, pero tambin es posible que algunos descendientes no sean miembros realmente apropiados de la superclase.
es el nmero de colaboraciones de una clase, y cuanto mayor sea, menor ser el grado de reutilizacin, adems de complicarse las pruebas y el mantenimiento. nmero de mtodos 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 comprobacin, y ms complejo es el diseo. dos mtodos son similares si comparten al menos un atributo de la clase. A mayor nmero de mtodos similares, mayor cohesin hay en la clase.
23 / 48

Ventana tamao ancho nombre_cliente fecha_emisin total compras mostrar_factura() Cartas_reclamo Factura fecha_emisin : Date fecha_pago : Date precio() impuesto() cliente() lista_compras()
1..* 1 Compra 0..* fecha tasa_impuesto 1
Botn OK
Caja de texto
Mtrica
factura
compra
cartas_ reclamo
botn OK
ventana
caja de texto
precio() impuesto()
1..* 0
MPC NDH PAH RPC AEC CCM
4 0 0 3 -
2 0 0 4 -
0 0 1 2 -
0 0 0 1 -
1 0 1 3 -
0 0 0 1 fuente: Ingeniera de software. Teora y prctica. S.L. Pfleeger, p. 34
24 / 48

DETERMINANTES DE LA CALIDAD DEL SOFTWARE Y DE LA EFECTIVIDAD DE LA ORGANIZACIN
mtricas del proceso

PRODUCTO (complejidad,...)
datos cuantitativos de los procesos del software la recoleccin de mtricas del proceso es esencial para la mejora del mismo, incluso en proyectos a pequea escala se utilizan para evaluar la eficiencia de un proceso o si sta ha mejorado ha mejorado con los cambios realizados tres tipos de mtricas 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 personasda, costes de viajes, recursos de hardware,... nmero de ocurrencias de un evento particular:
nmero de defectos descubiertos durante la revisin del cdigo, nmero de peticiones de cambio en requerimientos, nmero promedio de lneas de cdigo (LDC) modificadas en respuesta a un cambio de requerimientos,... errores detectados por el usuario ...
Caractersticas del cliente (comunicacin) PROCESO PERSONAS (destreza, motivacin,... Entorno de desarrollo
Condiciones del negocio (fechas, reglas,...)
TECNOLOGA
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 aceptacin de requerimientos, terminacin de un diseo arquitectnico, 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 nmero de defectos descubiertos al cambiar el proceso de revisin del cdigo probablemente se reflejar en una mejora de la calidad del producto, aunque tiene que confirmarse por mediciones posteriores del producto.
25 / 48

paradigma GQM (Goal-Question-Metric) de Basili y Rombach

se utiliza para decidir qu mediciones hacer y cmo utilizarlas
se basa en la identificacin de
metas (goals): aquello que la organizacin 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 especficas de incertidumbre. Ejemplos:
cmo se puede incrementar el nmero de LDC depuradas? cmo se puede reducir el tiempo requerido para finalizar los requerimientos? cmo se pueden llevar a cabo evaluaciones de fiabilidad ms efectivas?
mtricas: 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 nmero de comunicaciones formales entre cliente y analista para cada cambio de requerimientos medir el nmero de pruebas requeridas para provocar una cada en el producto
26 / 48
planificacin de proyectos
planificacin
proporciona un marco de trabajo que permite al administrador del proyecto hacer estimaciones razonables de recursos, costes y planificacin temporal. actividades de la planificacin
delimitacin del mbito del software estimacin de recursos necesarios (humanos, hardware, software,...)
PLANIFICACIN
EXPERIENCIA
Grado de estructuracin
ESTIMACIN
RIESGO
DATOS HISTRICOS
mbito de bajo riesgo
Complejidad basada en esfuerzos pasados
Tamao del esfuerzo
27 / 48
planificacin de proyectos: mbito

delimitacin del mbito del software

describe los datos a procesar, la funcin, el rendimiento, las restricciones, interfaces y fiabilidad necesarias se evalan las funciones y se refinan con ms 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
FUNCIN
RENDIMIENTO
RESTRICCIONES
MBITO DEL SOFTWARE
INTERFACES
FIABILIDAD
28 / 48
planificacin de proyectos: recursos

estimacin de recursos
se especifica cada recurso mediante cuatro caractersticas
descripcin informe de disponibilidad fecha cronolgica en la que se requiere el recurso tiempo durante el que ser aplicado
RECURSOS
Especificar: Habilidades requeridas Disponibilidad Duracin tareas. Fecha comienzo Componentes desarrollados Componentes experimentados Componentes con experiencia parcial. Componentes nuevos Especificar: Descripcin Disponibilidad Duracin del uso Fecha de distribucin
Personas
Componentes software reutilizables Herramientas hardware/software
29 / 48
planificacin de proyectos: estimacin

estimacin del esfuerzo y coste de un proyecto

normalmente el problema es demasiado complejo. Se utilizan diferentes tcnicas:
descomposicin del problema descomposicin del proceso
antes de hacer estimaciones de esfuerzo y coste

conocer el mbito del software realizar una estimacin del tamao
precisin de una estimacin:

grado en que se ha estimado adecuadamente el tamao del producto habilidad para traducir la estimacin del tamao 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 ingeniera del software
opciones para la estimacin:

dejar la estimacin para ms adelante basar las estimaciones en proyectos similares anteriores utilizar tcnicas de descomposicin (divide y vencers) desarrollar o aplicar un modelo emprico para calcular costes y esfuerzo
30 / 48

tamao del software

dos tipos de enfoque
directo: se utilizan las LDC para medir el tamao indirecto: el tamao se representa mediante puntos de funcin (PF)
problemas de la utilizacin de LDC

no existe definicin estndar de LDC (p.ej., se consideran LDC los comentarios?) lneas fsicas o lgicas contabilizacin del cdigo reutilizable aplicaciones en diferentes lenguajes estilos individuales de programacin
relacin entre LDC y PF: depende del lenguaje escogido

Lenguaje Ensamblador C Cobol Fortran Pascal Ada Lenguajes OO L4G Lenguajes visuales
LDC/PF (media) 320 128 105 105 90 70 30 20 4
31 / 48

Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 5
Puntos de funcin: relacin emprica basada en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivas acerca de la complejidad del software
Factor de peso Parmetro de medida Nmero entradas usuario Nmero salidas de usuario Nmero peticiones al usuario Nmero de archivos Cuenta Simple x3 x4 x3 x7 Medio 4 5 4 10 Complejo 6 7 6 15 = = = =
0- Sin influencia 1- Incidental 2- Moderado 3- Medio 4- Significativo 5- Esencial 1.Requiere el sistema copias de seguridad fiables? 2.Se requieren comunicaciones de datos? 3.Existen funciones de procesamiento distribuido? 4.Es crtico 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 mltiples 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 diseado el cdigo para ser reutilizable? 12.Estn incluidas en el diseo la conversin y la instalacin? 13.Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14.Se ha diseado la aplicacin para facilitar los cambios y ser fcilmente utilizada por el usuario?
32 / 48
Nmero interfaces externos

Cuenta total
x5
10
PF = Cuenta Total x [0,65 + 0,01 x SUM(Fi)]

Fi : valores de ajuste de complejidad
estimacin basada en el problema

al estimar el proyecto, las LDC y los PF se utilizan como:

variables de estimacin que permiten dimensionar cada elemento del software mtricas de proyectos anteriores (mtricas de lnea de base):
productividad (LDC / persona-mes) coste ($ / persona-mes) ...
pasos:
estimacin de un rango de valores para cada funcin especificada en el mbito del software 3 valores para cada funcin: optimista, ms probable y ms pesimista (indica el grado de incertidumbre)
valor esperado: ejemplo: VE = (Sopt + 4Sm + Spes)/6
tcnicas estadsticas: clculo de la desviacin de las estimaciones
aplicacin de mtricas de proyectos anteriores (en LDC o PF)

33 / 48
estimacin basada en el problema

descomposicin del problema en funciones a partir del mbito del software
F1
F2
Fn
clculo de las variables de estimacin (LDC y/o PF) de F1
estimacin coste de F1 estimacin de esfuerzo de F1
clculo de las variables de estimacin (LDC y/o PF) de F2
estimacin coste de F2 estimacin de esfuerzo de F2
coste de F1
esfuerzo de F1 esfuerzo de F2 esfuerzo de Fn
aplicacin de mtricas de productividad o coste
aplicacin de mtricas de productividad o coste
coste de F2 coste de Fn
estimacin global del coste del proyecto
estimacin global del esfuerzo del proyecto
34 / 48
estimacin basada en el problema (LDC)

tema 6 - administracin de proyectos Hay que desarrollar un software CAD que aceptar datos geomtricos de 2 o 3 dimensiones por parte del ingeniero. ste controlar el sistema CAD por medio de una interfaz que debe tener un diseo de buena calidad. Una base de datos CAD contiene todos los datos geomtricos y la informacin de soporte. Se desarrollarn mdulos de anlisis de diseo para producir la salida requerida que se va a visualizar en varios dispositivos grficos. El software se disear para controlar e interconectar diversos perifricos, como un ratn, un digitalizador y una impresora lser.
Funciones identificadas: interfaz de usuario y facilidades de control (IUFC) anlisis geomtrico de dos dimensiones (AG2D) anlisis geomtrico de tres dimensiones (AG3D) gestin de base de datos (GBD) facilidades de la interfaz grfica (FIG) control perifricos (CP) mdulos de anlisis del diseo (MAD) Datos histricos: productividad media de la organizacin en proyectos similares: 620 LDC/pm Tarifa laboral: 8000 $ /mes Coste LDC: 13 $
descomposicin de funciones
Estimacin en LDC de AG3D: optimista: 4600 ms probable: 6900 pesimista: 8600
VE = (Sopt + 4Sm + Spes)/6
mtricas de proyectos anteriores
Funcin IUFC AG2D AG3D GBD FIG CP MAD Total
LDC estimada 2300 5300 6800 3350 4950 2100 8400 33200
Coste total proyecto: 431000 $ Esfuerzo estimado: 54 personas-mes
35 / 48
estimacin basada en el problema (PF)

Valor dominio informacin Num. entradas Num. salidas Num. peticiones Num. archivos Num. interfaces ext. Cuenta total Opt. Probable Pesimista 20 12 16 4 2 24 15 22 4 2 30 22 28 5 3 Cuenta est 24 16 22 4 2 Peso 4 5 4 10 7 Cuenta PF 96 80 88 40 14 318
Copia de seguridad y recuperacin Comunicaciones Proceso distribuido Rendimiento crtico Entorno operativo existente Entrada de datos online Transacciones entrada en varias pant. Archivos maestros actualizados online Complejidad valores dominio informacin Complejidad procesamiento interno Cdigo diseado para reutilizacin Conversin en diseo Instalaciones mltiples Aplicacin diseada para cambios
4 2 0 4 3 4 5 3 5 5 4 3 5 5
PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)
PF estimado = 372
Coste total proyecto: 457000 $
mtricas de proyectos anteriores
Datos histricos: productividad media de la organizacin en proyectos similares: 6,5 PF/pm Tarifa laboral: 8000 $ /mes Coste por PF: 1.230 $
Esfuerzo estimado: 58 personas-mes
36 / 48
estimacin basada en el proceso


tcnica ms 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 funcin estimacin de esfuerzo (persona-mes) para cada actividad en cada funcin aplicacin de ndices de trabajo medios (esfuerzo coste/unidad) al esfuerzo estimado para cada actividad clculo de costes y esfuerzo de cada funcin y de la actividad
37 / 48

Tareas Funcin IUFC AG2D AG3D GBD FIG CP MAD Total %esfuerzo
Actividades Entrevistas Planificacin Anlisis Ingeniera Construccin Evaluacin Totales riesgo entrega cliente Anlisis Diseo Cdigo Prueba 0,50 0,75 0,50 0,50 0,50 0,25 0,50 3,50 8% 2,50 4,00 4,00 3,00 3,00 2,00 2,00 20,50 45% 0,40 0,60 1,00 1,00 0,75 0,50 0,50 4,75 10% 5,00 2,00 3,00 1,50 1,50 1,50 2,00 16,50 36% 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 46,00
0,25 1%
0,25 1%
0,25 1%
Tarifa laboral: 8000 $ /mes Coste total proyecto: 368.000 $ Esfuerzo estimado: 46 personas-mes
Comparacin de las distintas estimaciones Estimacin basada en el producto (LDC): 54 pm Estimacin basada en el producto (PF): 58 pm Estimacin basada en el proceso: 46 pm Estimacin media: 53 pm Variacin mxima: 13%
38 / 48
modelos empricos de estimacin

Modelos empricos de estimacin:

Utilizan frmulas derivadas empricamente para predecir el esfuerzo como una funcin de LDC o PF. Datos empricos obtenidos de una muestra de proyectos:
difciles de usar para todas las clases de software y todos los entornos de desarrollo se deben calibrar para las condiciones especficas de una organizacin A y B: constantes obtenidas empricamente E: esfuerzo en meses/persona ev: variable de estimacin (LDC o PF)
E = A + B X (ev)
MODELOS BASADOS EN LDC E = 5,2 x (KLDC)0,91 E = 5,5 + 0,73 x (KLDC)1,16 E = 3,2 x (KLDC)1,05 E = 5,288 x (KLDC)1,047 Modelo de Walston-Felix Modelo de Bailey-Basili Modelo simple de Boehm Modelo Doty para KLDC>9
MODELOS BASADOS EN PF Modelo de Albrecht-Gaffney Modelo de Kemerer Modelo de Matson, Barnett y Mellichamp
E = -13,39 + 0,054 PF E = 60,62 x 7,728 x 10-8 PF3 E = 585,7 + 15,12 PF
39 / 48
modelos empricos de estimacin

MODELO 1 (COCOMO bsico)

calcula el esfuerzo y el coste del desarrollo en funcin del tamao estimado del programa (LDC). Se utiliza para una aproximacin rpida al principio del ciclo de vida.
Tres tipos de proyectos:

Orgnicos: relativamente pequeos y sencillos, en los que trabajan pequeos equipos con experiencia, sobre un conjunto de requisitos poco rgidos. Semiacoplados: proyectos intermedios (en tamao y complejidad) en los que participan equipos con variados niveles de experiencia, y que deben satisfacer requisitos poco o medio rgidos. Empotrados: proyectos que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido.
ESFUERZO: TIEMPO:
E = ab KLDCbb D = cb Edb
MODELO 2 (COCOMO intermedio)

calcula el esfuerzo y el coste en funcin del tamao estimado del programa y de un conjunto de guas de coste que incluyen una evaluacin subjetiva del producto, hardware, personal y atributos del producto
ESFUERZO: E = ai KLDCbi x FAE (factor de ajuste del esfuerzo)
MODELO COCOMO BSICO Proyecto Orgnico ab 2,4 bb 1,05 1,12 1,20 cb 2,5 2,5 2,5 db 0,38 0,35 0,32
Semiacoplado 3,0
MODELO 3 (COCOMO avanzado)

incorpora las caractersticas del mod. 2 y evala el impacto de los FAE en cada fase del desarrollo.
Empotrado
3,6
40 / 48
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 organizacin existen riesgos conocidos, predecibles e impredecibles
categoras de riesgos:
riesgos del proyecto: afectan al presupuesto, los recursos, la planificacin,... riesgos del producto: afectan a la calidad o al rendimiento del software riesgos del negocio: afectan a la organizacin (riesgos de mercado, estratgicos, de distribucin, de prdida del presupuesto o del personal,...) riesgos que entran en las tres categoras anteriores (por ejemplo, el abandono de un programador experto es un riesgo para el producto, el proyecto y el negocio)
41 / 48

Ejemplos de posibles riesgos en el desarrollo de software
riesgo
rotacin de personal cambio de administracin no disponibilidad del hardware cambios de requerimientos retrasos en la especificacin subestimacin del tamao bajo rendimiento de la herramienta CASE cambio de tecnologa competencia del producto
tipo de riesgo
proyecto, producto y negocio
proyecto proyecto proyecto y producto proyecto y producto proyecto y producto producto
descripcin
personal con experiencia abandona el proyecto antes de que finalice cambio de administracin organizativa con diferentes prioridades el hardware necesario para el proyecto no se recibe a tiempo existencia de ms cambios de requerimientos de los previstos inicialmente retrasos en las especificaciones de interfaces esenciales el tamao del sistema se ha subestimado las herramientas CASE que ayudan al proyecto no tienen el rendimiento y las funcionalidades esperadas la tecnologa fundamental sobre la que se est construyendo el sistema es sustituida por una nueva un producto competitivo se pone en venta antes de que el sistema se complete
negocio negocio
42 / 48

la administracin de riesgos es un proceso iterativo que se aplica durante todo el proyecto
identificacin de riesgos
etapas de la administracin de riesgos

identificacin de riesgos: se identifican los posibles riesgos para el proyecto, el producto y el negocio anlisis de riesgos: se valoran las probabilidades y las posibles consecuencias de los riesgos identificados planificacin de riesgos: se crean planes para abordar los riesgos, tanto para evitarlos como para minimizar sus efectos supervisin de riesgos: se valora constantemente los riesgos y se revisan los planes para su mitigacin tan pronto como la informacin de los riesgos est disponible
planificacin de riesgos anlisis de riesgos
listado de riesgos potenciales
listado de priorizacin de riesgos
anulacin de riesgos y planes de contingencia
los resultados de la administracin de riesgos se documentan en un plan de administracin de riesgos
supervisin de riesgos
valoracin de riesgos
fuente: Ingeniera de Software. I. Sommerville, p. 85
43 / 48

identificacin de riesgos
descubrimiento de los posibles riesgos no se valoran o priorizan, aunque no se tienen en cuenta riesgos con consecuencias pequeas o con baja probabilidad se realiza a travs de diversas tcnicas (tormentas de ideas, experiencia del administrador,...)
tipo de riesgo
tecnologa
ejemplos de posibles riesgos

la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba los componentes de software a reutilizar tienen defectos que limitan su funcionalidad imposible contratar personal con los conocimientos requeridos personal clave enfermo o no disponible en momentos crticos la organizacin se reestructura y una nueva administracin se responsabiliza del proyecto los problemas financieros de la organizacin reducen el presupuesto del proyecto las herramientas CASE generan cdigo ineficiente las distintas herramientas CASE no se pueden integrar cambios de requerimientos que precisan modificaciones en el diseo los clientes no comprenden el impacto de los cambios en los requerimientos el tiempo requerido para desarrollar el software est subestimado la tasa de reparacin de defectos est subestimada el tamao del software est subestimado cambian las leyes imponiendo restricciones que no estaban previstas
personal organizativos herramientas requerimientos estimacin legales
44 / 48

anlisis de riesgos
se considera cada riesgo por separado y se valora en intervalos su probabilidad e impacto:
probabilidad del riesgo valorada como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%) efectos del riesgo valorados como catastrfico, serio, tolerable o insignificante el resultado se coloca en una tabla ordenada por la seriedad del riesgo
se decide cules son los ms importantes (riesgos clave) y que se van a considerar durante el proyecto (por ejemplo, todos los serios o catastrficos con cualquier probabilidad), y que debe ser un nmero manejable.
riesgo
los problemas financieros de la organizacin reducen el presupuesto del proyecto
imposible contratar personal con los conocimientos requeridos personal clave enfermo o no disponible en momentos crticos los componentes de software a reutilizar tienen defectos que limitan su funcionalidad cambios de requerimientos que precisan modificaciones en el diseo la organizacin se reestructura y una nueva administracin se responsabiliza del proyecto la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba el tiempo requerido para desarrollar el software est subestimado las distintas herramientas CASE no se pueden integrar los clientes no comprenden el impacto de los cambios en los requerimientos la tasa de reparacin de defectos est subestimada el tamao del software est subestimado las herramientas CASE generan cdigo ineficiente
probab.
baja
alta moderada moderada moderada alta moderada alta alta moderada moderada alta moderada
efectos
catastrfico
catastrfico serio serio serio serio serio serio tolerable tolerable tolerable tolerable insignificante
45 / 48

planificacin de riesgos
se considera cada uno de los riesgos clave identificados y las estrategias para administrarlo, que vendrn dadas por el juicio y la experiencia del administrador del proyecto
estrategias de anulacin: intentan reducir la probabilidad de que surja el riesgo estrategias de disminucin: intentan reducir el impacto del riesgo planes de contingencia: se dispone de ellos para estar preparados por si el riesgo ocurre y poder actuar con una estrategia determinada
riesgo problemas financieros de la organizacin problemas de reclutamiento enfermedad del personal componentes defectuosos cambios en los requerimientos reestructuracin organizativa rendimiento de la base de datos tiempo de desarrollo subestimado estrategia preparar un documento breve para la direccin de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio organizar cursos de capacitacin para el personal ya existente, investigar la posibilidad de contratar en otras regiones o pases
reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del equipo comprendan el trabajo de los dems
reemplazar los componentes defectuosos con los comprados de fiabilidad conocida rastrear la informacin para valorar el impacto de los requerimientos, maximizar la informacin oculta en ellos preparar un documento breve para la direccin de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio investigar la posibilidad de comprar una base de datos con el rendimiento preciso alertar al cliente de las dificultades potenciales y las posibilidades de retraso
46 / 48

supervisin de riesgos
valora cada uno de los riesgos identificados para decidir si es ms o menos probable y cundo han cambiado sus posibles efectos hay que controlar factores que pueden indicar cambios en la probabilidad y el impacto
tipo de riesgo
tecnologa personal organizacional herramientas requerimientos estimacin
indicadores potenciales
entrega retrasada del hardware o del software existencia de informes sobre problemas tecnolgicos baja moral del personal, malas relaciones entre miembros del equipo, disponibilidad de empleo
rumores en la empresa falta de iniciativa de la direccin de la empresa

rechazo de los miembros del equipo a utilizar herramientas quejas sobre las herramientas CASE peticiones de estaciones de trabajo ms potentes peticiones de muchos cambios en los requerimientos quejas del cliente fracaso en el cumplimiento de los tiempos planificados
47 / 48
bibliografa
Sommerville, I. Ingeniera de Software, cap. 4 y 24 (pp. 547-554) Pressman, R.S. Ingeniera del Software. Un enfoque prctico, cap. 4, 5 y 6 Bruegge, B., Dutoit, A.H., Ingeniera del Software Orientado a Objetos, cap. 3
48 / 48

Tema 6 - Admin de Proyectos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tema 6 - Admin de Proyectos

Hochgeladen von

Copyright:

Verfügbare Formate

tema 6 administracin de proyectos

introduccin a la administracin de proyectos

aos 60 y 70: fracaso de muchos grandes proyectos de software

desarrollos profesionales de software

la naturaleza de la ingeniera de software dificulta la administracin

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

seleccin y evaluacin del personal

redaccin y presentacin de informes

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

el administrador tiene tres grandes reas de actuacin

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

personal del proyecto

factores que influyen en el trabajo en grupo

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

personal del proyecto: composicin del grupo

composicin del grupo

escuela superior de ingeniera informtica ingeniera del software de gestin

personal del proyecto: cohesin del grupo

cohesin del grupo

factores que influyen en la cohesin

personal del proyecto: comunicacin

factores que influyen

entorno de trabajo fsico

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

personal del proyecto: organizacin del grupo

organizacin del grupo

principales tipos de estructura organizativa

Comparacin de estructuras organizativas Fuertemente estructuradas

Repeticin Grandes proyectos

Necesidad de entrevistas Tcnicas o tecnologas nuevas

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

personal del proyecto: organizacin del grupo

estructura formal: Equipo del Jefe de Programadores, Chief Programmer Team

Administrador Equipo de pruebas

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

planificacin del proyecto

tema 6 - administracin de proyectos

Establecer programacin en el tiempo del proy ecto

Iniciar activ idades segn la programacin

Esperar un tiempo (entre 2 y 3 semanas)

Rev isar progreso proy ecto

Rev isar estimaciones de los parmetros

Renegociar restricciones y productos a entregar

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

planificacin del proyecto

plan del proyecto

revisin regular durante el proyecto

planificacin del proyecto

hitos y productos a entregar

enrique barreiro alonso universidade de vigo - departamento de informtica

estimar el tiempo necesario para realizarlas (algunas se harn en paralelo)

utilizacin de diagramas de Gantt y redes de actividades

enrique barreiro alonso universidade de vigo - departamento de informtica

escuela superior de ingeniera informtica ingeniera del software de gestin

T12 10 das FINAL 19/9/02