tema 6 - admin de proyectos.ppt

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

© enrique barreiro alonsouniversidade de vigo - departamento de informática

tema 6 - administración de proyectos

2 / 48escuela superior de ingeniería informática

ingeniería del software de gestión

introducción a la administración de proyectos

años 60 y 70: fracaso de muchos grandes proyectos de software

retrasos en las entregas, problemas de fiabilidad, costes más elevados de lo previsto, poco eficiente,...

motivo principal: enfoque de administración utilizadotécnicas de administración derivadas de otras disciplinas de la ingenieríapoco efectivas para el desarrollo de software

desarrollos profesionales de software

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





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





actividades de la administración

el administrador tiene tres grandes áreas de actuación

personalparticipantes 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





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 grupo

composición del grupo

cohesión del grupo

comunicación del grupo

organización del grupo





personal del proyecto: composición del grupo

composición del grupo

los ingenieros de software tienen una especial motivación por su trabajo

ideas propias sobre la resolución de problemas té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

INT

RO

VE

RT

IDO

EX

TR

OV

ER

TID

O

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)





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





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)





personal del proyecto: organización del grupo

organización del grupo

factores que influyen en la estructura más adecuadaexperiencia 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”

Comparación de estructuras organizativas

Fuertemente estructuradas Escasamente estructuradas

Proyectos con elevada certeza, estabilidad y uniformidad (requieren menos comunicación)

Proyectos con incertidumbre (p.e., cambio en requerimientos)

Repetición Necesidad de entrevistas

Grandes proyectos Técnicas o tecnologías nuevas

Pequeños proyectos





personal del proyecto: organización del grupo

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

jefe de programadores (JP): responsable del diseño, desarrollo y pruebas de instalació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





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






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






hitos y productos a entregar

información a los administradoresdocumentos 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





planificación temporal

calendario

dividir el proyecto en actividades

estimar el tiempo necesario para realizarlas (algunas se harán en paralelo)

los administradores coordinan las actividades organizan el trabajo para optimizar la mano de 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






Tarea Duración (días) Dependencias

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2,T4 (M2)

T6 5 T1,T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

camino crítico

trayectoria más larga en la red de actividad

el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto)

los retrasos en las demás actividades no afectan necesariamente al proyecto

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






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ón inicial será, con toda seguridad, incorrecta.

durante el desarrollo se deben comparar las estimaciones previas con las reales para revisar la calendarización del resto del proyecto.

al conocer cifras reales, se debe revisar la red de actividades y reorganizar las actividades posteriores para reducir la longitud de la trayectoria crítica.






Tarea Ingeniero

T1 Juana

T2 Ana

T3 Juana

T4 Fernando

T5 María

T6 Ana

T7 Jaime

T8 Fernando

T9 Juana

T10 Ana

T11 Fernando

T12 Fernando

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fernando T4

T8 T11

T12

T1

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





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

software

Producto desoftware

Métricas depredicción

Métricas depredicciónMétricas de

control

Métricas decontrol

Decisionesadministrativas

Decisionesadministrativas






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

Identificarmedidas

anómalas

Identificarmedidas

anómalas

Analizarcomponentes

anómalos

Analizarcomponentes

anómalos






métricas del producto

se refieren a las características del propio software

las relaciones entre características del software pueden variar dependiendo de diversos factores (proceso, tecnología de desarrollo, tipo de sistema,...)

es necesario construir una base de datos histórica la base de datos se usa para comprobar cómo se relacionan los atributos del producto con la calidad que la organización necesita

dos tipos de métricas de 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






métrica de producto descripción

fan-in / fan-out

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.

longitud del código 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á.

complejidad ciclomática

Medida de la complejidad del control de un programa, y está relacionada con la comprensión del programa.

longitud de los identificadores

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.

profundidad de los if anidados

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.

índice de FogMedida 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.

Ejemplos de métricas estáticas del producto






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






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

métrica descripción

métodos ponderados por clase (MPC)

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.

profundidad del árbol de herencia (PAH)

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.

número de hijos (NDH)

cuantos más descendientes, más reutilización, pero también es posible que algunos descendientes no sean miembros realmente apropiados de la superclase.

acoplamiento entre clases (AEC)

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.

respuesta para una clase (RPC)

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.

carencia de cohesión en los métodos (CCM)

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.






Botón OK

Ventana

tamañoanchonombre_clientefecha_emisióntotalcompras

mostrar_factura()

Caja de texto

Cartas_reclamoFactura

fecha_emisión : Datefecha_pago : Date

precio()impuesto()cliente()lista_compras()

Compra

fechatasa_impuesto

precio()impuesto()

1

1..*

1

1..*

1

0..*

1

1..*1..*0Métrica factura compra cartas_

reclamobotón OK ventana caja de

texto

MPC 4 2 0 0 1 0

NDH 0 0 0 0 0 0

PAH 0 0 1 0 1 0

RPC - - - - - -

AEC 3 4 2 1 3 1

CCM - - - - - -

fuente: Ingeniería de software. Teoría y práctica. S.L. Pfleeger, p. 34






métricas del 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 evento particular:

número de defectos descubiertos durante la revisión del código, número de peticiones de cambio en requerimientos, número promedio de líneas de código (LDC) modificadas en respuesta a un cambio de requerimientos,...errores detectados por el usuario...

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






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





PLANIFICACIÓNPLANIFICACIÓN

planificación de proyectos

planificación proporciona un marco de trabajo que permite al administrador del proyecto hacer estimaciones razonables de recursos, costes y planificación temporal.

actividades de la planificacióndelimitación del ámbito del softwareestimación de recursos necesarios (humanos, hardware, software,...)

ESTIMACIÓNESTIMACIÓN RIESGORIESGOEXPERIENCIA

EXPERIENCIA

DATOSHISTÓRICOS

DATOSHISTÓRICOS

Complejidad basada enesfuerzos pasados

Grado de estructuración

Tamaño del esfuerzo

Ámbito de bajoriesgo





planificación de proyectos: ámbito

delimitación del ámbito del software

describe los datos a procesar, la función, el rendimiento, las restricciones, interfaces y fiabilidad necesarias

se evalúan las funciones y se refinan con más detalles si es necesario

se obtiene mediante entrevistas preliminares entre analista y cliente

utilidad del ámbito del softwareestudiar la viabilidad del proyectorealizar estimaciones de recursos necesarios

ÁMBITO DELSOFTWARE

RENDIMIENTO

RESTRICCIONES

INTERFACES

FIABILIDAD

FUNCIÓN





planificación de proyectos: recursos

estimación de recursos

se especifica cada recurso mediante cuatro característicasdescripció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





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 humano tiempo dinero

grado en que el plan del proyecto refleja la capacidad del equipo de desarrollo

estabilidad de los requisitos y el entorno del esfuerzo que da soporte a las actividades de ingeniería del software

opciones para la estimación:dejar la estimación para más adelante

basar las estimaciones en proyectos similares anteriores

utilizar técnicas de descomposición (“divide y vencerás”)

desarrollar o aplicar un modelo empírico para calcular costes y esfuerzo






tamaño del software

dos tipos de enfoquedirecto: 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






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





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





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





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


Coste LDC: 13 $

de

sco

mp

osi

ció

nd

e f

un

cio

ne

s

de

sco

mp

osi

ció

nd

e f

un

cio

ne

s

mé

tric

as

de

pro

yect

os

an

terio

res

mé

tric

as

de

pro

yect

os

an

terio

res

Coste total proyecto: 431000 $

Esfuerzo estimado: 54 personas-mes







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




Esfuerzo estimado: 58 personas-mesDatos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pm


Coste por PF: 1.230 $

Datos históricos:productividad media de la organización en proyectos similares: 6,5 PF/pm


Coste por PF: 1.230 $mé

tric

as

de

pro

yect

os

an

terio

res

mé

tric

as

de

pro

yect

os

an

terio

res





estimación basada en el proceso


técnica más habitual

el proceso se descompone en actividades o tareas y el esfuerzo requerido para llevar a cabo cada tarea

pasos:

delimitar las funciones obtenidas a partir del ámbito del software

actividades del proceso para cada función

estimación de esfuerzo (persona-mes) para cada actividad en cada función

aplicación de índices de trabajo medios (esfuerzo coste/unidad) al esfuerzo estimado para cada actividad

cálculo de costes y esfuerzo de cada función y de la actividad






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%


Coste total proyecto: 368.000 $



Coste total proyecto: 368.000 $


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%





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





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





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)






riesgo tipo de riesgo descripción

rotación de personal

proyecto, producto y

negocio

personal con experiencia abandona el proyecto antes de que finalice

cambio de administración proyecto cambio de administración organizativa con diferentes

prioridades

no disponibilidad del hardware

proyecto el hardware necesario para el proyecto no se recibe a tiempo

cambios de requerimientos

proyecto y producto

existencia de más cambios de requerimientos de los previstos inicialmente

retrasos en la especificación

proyecto y producto retrasos en las especificaciones de interfaces esenciales

subestimación del tamaño

proyecto y producto el tamaño del sistema se ha subestimado

bajo rendimiento de la herramienta

CASE

producto las herramientas CASE que ayudan al proyecto no tienen el rendimiento y las funcionalidades esperadas

cambio de tecnología negocio la tecnología fundamental sobre la que se está construyendo el

sistema es sustituida por una nueva

competencia del producto negocio un producto competitivo se pone en venta antes de que el

sistema se complete

Ejemplos de posibles riesgos 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ónde riesgos

supervisiónde riesgos

planificación de riesgos


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






identificación de riesgos

descubrimiento de los posibles riesgos

no se valoran o priorizan, aunque no se tienen en cuenta riesgos con consecuencias pequeñas o con baja probabilidad

se realiza a través de diversas técnicas (tormentas de ideas, experiencia del administrador,...)

tipo de riesgo ejemplos de posibles riesgos

tecnologíala 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

personal imposible contratar personal con los conocimientos requeridospersonal clave enfermo o no disponible en momentos críticos

organizativosla organización se reestructura y una nueva administración se responsabiliza del proyectolos problemas financieros de la organización reducen el presupuesto del proyecto

herramientas las herramientas CASE generan código ineficientelas distintas herramientas CASE no se pueden integrar

requerimientos cambios de requerimientos que precisan modificaciones en el diseñolos clientes no comprenden el impacto de los cambios en los requerimientos

estimaciónel tiempo requerido para desarrollar el software está subestimadola tasa de reparación de defectos está subestimadael tamaño del software está subestimado

legales cambian las leyes imponiendo restricciones que no estaban previstas







se considera cada riesgo por separado y se valora en intervalos su probabilidad e impacto:

probabilidad del riesgo valorada como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%)efectos del riesgo valorados como catastrófico, serio, tolerable o 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.

riesgo probab. efectos

los problemas financieros de la organización reducen el presupuesto del proyecto baja catastrófico

imposible contratar personal con los conocimientos requeridos alta catastrófico

personal clave enfermo o no disponible en momentos críticos moderada serio

los componentes de software a reutilizar tienen defectos que limitan su funcionalidad moderada serio

cambios de requerimientos que precisan modificaciones en el diseño moderada serio

la organización se reestructura y una nueva administración se responsabiliza del proyecto alta serio

la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba moderada serio

el tiempo requerido para desarrollar el software está subestimado alta serio

las distintas herramientas CASE no se pueden integrar alta tolerable

los clientes no comprenden el impacto de los cambios en los requerimientos moderada tolerable

la tasa de reparación de defectos está subestimada moderada tolerable

el tamaño del software está subestimado alta tolerable

las herramientas CASE generan código ineficiente moderada insignificante







se considera cada uno de los riesgos clave identificados y las estrategias para administrarlo, que vendrán dadas por el juicio y la experiencia del administrador del proyecto

estrategias de anulación: intentan reducir la probabilidad de que surja el 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

riesgo estrategia

problemas financieros de la organización

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

problemas de reclutamiento organizar cursos de capacitación para el personal ya existente, investigar la posibilidad de contratar en otras regiones o países

enfermedad del personal reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del equipo comprendan el trabajo de los demás

componentes defectuosos reemplazar los componentes defectuosos con los comprados de fiabilidad conocida

cambios en los requerimientos rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos

reestructuración organizativa 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

rendimiento de la base de datos investigar la posibilidad de comprar una base de datos con el rendimiento preciso

tiempo de desarrollo subestimado alertar al cliente de las dificultades potenciales y las posibilidades de retraso






supervisión de riesgos

valora cada uno de los riesgos identificados para decidir si es más o menos probable y cuándo han cambiado sus posibles efectos

hay que controlar factores que pueden indicar cambios en la probabilidad y el impacto

tipo de riesgo indicadores potenciales

tecnología entrega retrasada del hardware o del softwareexistencia de informes sobre problemas tecnológicos

personal baja moral del personal, malas relaciones entre miembros del equipo, disponibilidad de empleo

organizacional rumores en la empresafalta de iniciativa de la dirección de la empresa

herramientasrechazo de los miembros del equipo a utilizar herramientasquejas sobre las herramientas CASEpeticiones de estaciones de trabajo más potentes

requerimientos peticiones de muchos cambios en los requerimientosquejas del cliente

estimación fracaso en el cumplimiento de los tiempos planificados





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

Documents

tema 6 - admin de proyectos.ppt