is-lade: introducción a la is · del equipo de is. gestores ejecutivos: coordinan la relación...

Tema 4:Introducción a la Gestión de Proyectos

Departamento de Lenguajes y Sistemas Informáticos II

www.kybele.urjc.es

Introducción a la gestión de proyectos www.kybele.urjc.es

Introducción

“He visitado docenas de tiendas comerciales, tanto buenas como malas, y he observado registros de gerentes de procesamiento de datos, de nuevo, tanto buenos como malos. Con mucha frecuencia he visto con horror cómo dichos gerentes luchaban inútilmente con proyectos de pesadilla, sufriendo por fechas límites imposibles o por sistemas ya entregados que indignaron a sus usuarios y devoraron enormes cantidades de tiempo de mantenimiento” (Meilir Page-Jones)

2


¿Qué es un proyecto?

Definición 1: Es un conjunto de actividades planificadas, ejecutadas y supervisadas que, con recursos finitos, tiene como objetivo crear un producto o servicio único.

Definición 2:Un proyecto es una actividad que tiene un inicio, que se lleva a cabo para conseguir unos objetivos definidos y tiene un final previsto.

ObjetivoEl objetivo principal es obtener un resultado en forma de bien o producto para un cliente que da una especificaciones y marca unos objetivos a cumplir para que el proyecto se lleve a cabo.

3


Gestión de Proyectos: Definición

¿Qué es?: La GP involucra la planificación, supervisión y control del personal, el proceso y los eventos que ocurren mientras el sw evoluciona desde una idea preliminar hasta una implementación operativa.

¿Quién la hace?: Todos gestionan (a su escala).IS: Gestiona sus actividades diarias; planifica, supervisa y controla labores técnicas.Gestores de Proyecto: Planifican, supervisan y controlan el trabajo del equipo de IS.Gestores Ejecutivos: Coordinan la relación entre el negocio y los profesionales del software.

¿Por qué es importante?: La construcción de software involucra a mucha gente que trabaja durante mucho tiempo Actividad compleja que necesita ser gestionada.

4


Diferencias con otras ingenierías

Diferencias entre la gestión de Proyectos Software y otros tipos de proyectos

El producto es intangible Un proyecto de ingeniería Civil puede verse mientras se está

desarrollando. Si hay un desfase en el calendario “se puede ver” relativamente fácil (partes de la estructura del puente no están terminadas cuando deberían)…en software no es “tan fácil” ver el progreso.

No existen procesos del software estándar Proceso de construcción de un rascacielos se comprende bien. Ej.

Mínimas diferencias en los tiempos de construcción de las 4 Torres de Madrid. En software no siempre se puede asegurar que un determinado proceso va a funcionar mejor que otro.

A menudo los proyectos grandes son únicos Generalmente los proyectos suelen ser diferentes. Pocas compañías

desarrollan siempre el mismo tipo de proyectos No existe experiencia previa incertidumbre

5


Gestión de Proyectos

La gestión eficaz de un proyecto software se centra en lo que denominamos las “4P”:

Personal.- Organizado para el trabajo con efectividad

Producto.- La comunicación entre el cliente y el equipo debe permitir comprender el ámbito y los requisitos del producto

Proceso.- Se debe seleccionar un proceso adecuado para el personal y para el producto.

Proyecto.- Se debe: estimar el tiempo y el esfuerzo para cumplir los objetivos; definir productos de trabajo; establecer puntos de control de calidad; identificar mecanismos de supervisión y control del trabajo planificado.

6


Cómo Comienza un Proyecto: Necesidad Interna

Orígenes en la decisión de emprender un proyecto:Variación en los requisitos del software (cambios en la legislación, estándares…)Petición cliente o usuarioPropuesta generada dentro de la organización de desarrolloNecesidad detectada por el departamento de marketingRecomendación del personal de mantenimiento de aplicaciones existentesNecesidad detectada por el personal informático (quejas, sugerencias...)

Priorización por plan estratégico de Sistemas de Información (si existe)

Se recomienda:Obtener una idea clara de lo que se pretende hacerEvaluar la viabilidad del proyecto analizando beneficios/gastos

7


Cómo Comienza un Proyecto: Solicitud Externa

Orígenes en la decisión de emprender un proyecto:Respuesta a la demanda de un cliente como resultado de una labor comercial concreta.

Respuesta a la demanda de un cliente como consecuencia de una solicitud de propuestas (RFP) (p.e. una oferta pública)

Se recomienda :Obtener una idea clara de las necesidades del cliente

Valorar la viabilidad del proyecto

Criterios para tomar la decisión de emprender o no un proyecto:

Relacionados con el negocio (beneficios, objetivos…):

Relacionados con los riesgos (complejidad, esfuerzo, relación con otros proyectos, …)

8


Personal – Jefes de proyecto

Selección del jefe de proyectoDecisión posterior a la de emprender el proyecto, pero recomendable que intervenga desde el principio del proceso.

Es el elemento más crítico para el éxito del proyecto.

Cada proyecto requiere un jefe de proyecto con una cualificación diferente.

Es importante un buen nivel en: Relación con el negocio

Competencias personales

Competencias interpersonales

Dotes de gestión (competencias técnicas de gestión), liderazgo

Resolución del problema

Incentivos por logros

Motivación del espíritu de equipo. Control en cada situación.

9


Personal – Jefes de proyecto

Buen técnico ≠ Buen jefe

“En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia”. Lawrence J. Peter

Un excelente programador puede ser un pésimo analista y un excelente analista puede llegar a ser un pésimo Jefe de Proyecto. Las capacidades y habilidades de cada una de estos roles son distintos.

Desafortunadamente, en muchas ocasiones las personas acaban desempeñando funciones de gestión de proyecto “porque toca”, sin la necesaria formación para desempeñar sus funciones.

10

http://es.wikipedia.org/wiki/Principio_de_Peter


Gestión de Proyectos

Gestión de proyectos

Planificación

Estimación

Seguimiento y supervisión

Análisis y gestión del riesgo

Definición de la calidad del producto

Gestión de la configuración

…

11


Gestión de Proyectos: Planificación

Planificación de proyectos. Definición

Conjunto de actividades previas a la puesta en marcha del proyecto

Objetivo

Proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal

12


Gestión de Proyectos:Planificación

Objetivos del plan de proyecto

Proporcionar un resumen del proyecto a los directivos que les ayude a tomar las decisiones de aprobación que afecten al proyecto.

Permitir tanto al jefe de proyecto como a los clientes supervisar el progreso del proyecto, desde el inicio hasta el final.

Presentarse como un documento orientado al cliente.

Constituir un documento base del proyecto con la aprobación del cliente y actualizable, a medida que avanza el proyecto

13



Contenido del plan de proyectoResumen del proyectoEntregables de forma que se pueda comprobar que se ajustan al plan Lista de hitosProcedimientos y estándares a aplicar. Una especificación del proceso de revisión que determine quién, cómo y cuándo se puede revisar la planificación del proyecto y con qué objetivo Plan de comunicación entre la organización y el cliente. Diagrama de descomposición del trabajo (WBS) Lista del personal del proyecto y su asignación en relación con la WBS. Red de actividades que muestre la secuencia de tareas en el tiempo y su relación entre ellasResponsables de todas las actividadesEstimaciones de esfuerzo y dinero, así como calendarios y plazos

14


Gestión de Proyectos:Planificación: Std IEEE

15

Página de título Hoja de revisión Prefacio Tabla de contenidos Lista de figuras Lista de tablas Introducción

Visión General del proyectoProductos finalesEvolución del Plan de ProyectoDocumentos de referenciaDefiniciones y acrónimos

Organización del ProyectoModelo de procesosEstructura organizativaFronteras y interfaces organizativasResponsabilidades

Proceso de GestiónObjetivos y prioridades de gestiónSuposiciones, dependencias y restriccionesGestión de riesgosMecanismos de supervisión y controlPlan de personal

Proceso TécnicoMetodología, técnicas y herramientasDocumentación softwareFunciones de apoyo al proyecto

Plan de DesarrolloPaquetes de trabajoDependencias RecursosPresupuesto y distribución de recursosCalendario

Secciones adicionales Índice Apéndices



En secciones adicionales:Planes de subcontratación: procedimientos de selección y control de las tareas y de las personas o empresas que se van a subcontratar

Aseguramiento de calidad. Recursos para realizar el aseguramiento de calidad, estándares y normativas aplicables al proyecto, las revisiones y auditorias que se van a llevar a cabo, etc. También puede incluir la planificación de las pruebas o referenciar a un Plan de Pruebas como documento aparte

Gestión de configuración: cómo se van a identificar los elementos de configuración, cómo se controlarán sus cambios y sus versiones, y cómo se informará de su estado.

Estructura de integración hardware/software

Planes de seguridad

16



Pasos en el desarrollo de un calendario

Definición de los objetivos del proyecto

Descomposición de las actividades

Relación entre actividades

Estimación de tiempos y costes de las actividades

Ajuste del calendario a las restricciones del proyecto

Asignación de recursos. Organización del equipo

Revisión del calendario

17




Definición de los objetivos del proyecto

“Objetivo del proyecto”: enunciado que especifica los resultados que se deben conseguir

Características de un buen objetivo: asequible, definitivo, cuantificable y de duración específica

Descomposición de las actividades

Diagrama de descomposición de actividades

18




Descomposición de las actividades00

J.L. Fernández

Proyecto de

desarrollo X

10 20 30 40

J.L. Fernández

Gestión del

Proyecto

Ingeniería del

Sistema

Desarrollo del

Software

Pruebas de

integración y del

sistema

S. Alonso

S. AlonsoJ.L. Fernández T. Diez

J. Gómez V. Pérez

A. Ramirez P. Redondo S. Sánchez G. Alfonso

Gestión del

Proyecto

Gestión de

Configuración

Diseño del

SistemaAnálisis y

DiseñoProgramación Pruebas

Pruebas de

IntegraciónPruebas de

Aceptación

G. Fuentes

Nivel de Proyecto

Nivel de paquete de trabajo

Plan de Proyecto

UT. 111

11 12 21 31 32 33 41 42

Control de

Configuración

UT. 121

Construcción de

Software

UT. 122

Comunicaciones

UT. 211

Análisis de Requisitos

UT. 212

Gestión de la

Base de Datos

UT. 213

Arquitectura

UT. 214

Diseño Funcional

UT. 311

Diseño de

Algoritmos

UT. 312

Diseño de la

Base de Datos

UT. 313

Programación

UT. 321

Documentación

UT. 322

Soporte a las

Pruebas

UT. 323

Procedimientos

de Pruebas

UT. 331

Pruebas Unitarias

UT. 332

Análisis de las

Pruebas

UT. 333

Procedimientos

de Pruebas

UT. 411

Integración del

Sistema

UT. 412

Formación

UT. 413

Procedimientos

de Pruebas

UT. 421

Satisfacción

de Requisitos

UT. 422

Nivel de Unidad de Trabajo

19




Relación entre actividades

Técnicas para proyectos cortos: diagramas de hitos, diagramas de Gantt.

Técnicas para proyectos grandes: PERT (Program Evaluation and Review Tecnique) y CPM (Critical Path Method)

Estimación de tiempos y costes de las actividades

Suelen estar basadas en la experiencia del planificador en proyectos similares y deben incluir los retrasos normales.

Es una buena estrategia para el jefe de proyecto contrastar y negociar sus cálculos de tiempos y esfuerzos con los responsables de cada actividad, que suelen contar con buena precisión a la hora de estimar los costes reales en tiempo y esfuerzo.

20



Pasos en el desarrollo de un calendarioAjuste del calendario a las restricciones del proyecto. Objetivos Determinar la duración total del proyecto cualquier técnica para la

determinación del calendario Identificar las actividades que contribuyen a la duración total del proyecto

(actividades críticas) Redes de precedencia Calcular las holguras de las actividades que no son críticas Redes de

precedencia

Asignación de recursos. Organización del equipo Ajustar el calendario en función de los recursos disponibles Importancia de las holguras Ajuste de las actividades no críticas en función de los solapamientos de

actividades críticas

Revisión del calendario ¿Es realista? Efectos de la vida laboral en el calendario (vacaciones, enfermedad, etc.) Asegurar que es flexible

21


Gestión de Proyectos:Técnicas de planificación

Técnicas

Diagrama de hitos

Diagrama de Gantt

Redes de precedencia: PERT

22


Gestión de Proyectos:Técnicas de planificación: Diagramas de hitos

Técnicas Diagramas de hitos Es un cuadro o tabla formada por dos columnas:

Ventajas: facilidad de uso (es el método más simple) y mínimo coste de preparación (todo el mundo lo comprende inmediatamente)

Desventajas: incertidumbre existente sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas.

Se utiliza para resumir calendarios complejos

Tarea Fecha fin

Tarea 1.1 Marzo-2006

Tarea 1.2 Mayo-2006

Tarea 1.3 Junio-2006

Tarea 2.1 Mayo-2006

Tarea 2.2 Agosto-2006

Tarea 2.3 Octubre-2006

23


Gestión de Proyectos:Técnicas de planificación: Gantt

Técnicas

Diagrama de Gantt

Diagrama de barras en forma de tabla donde se hace una referencia cruzada entre las tareas (filas) y los tiempos de duración (unidades de tiempo) de las mismas (columnas)

Muestra claramente la duración de las actividades y la precedencia de unas tareas con respecto a otras.

Inconveniente: NO permite representar las dependencias entre actividades.

Ventajas: SÍ expresa claramente los solapamientos entre actividades.

24


Gestión de Proyectos:Técnicas de planificación: Gantt

Técnicas

Diagrama de Gantt

Unidades de tiempo

1 2 3 4 5 6 7 8 9 10

Tarea 1.1

Tarea 1.2

Tarea 1.3

Tarea 2.1

Tarea 2.2

Tarea 2.3

25


Gestión de Proyectos:Técnicas de planificación: Redes de

precedencia

Técnicas Redes de precedencia. Modelo gráfico que señala las relaciones secuenciales entre los

sucesos claves en un proyecto. Permiten tratar la relación coste/duración de las actividades. Concepto de coste mínimo como principio de la planificación de

proyectos• Camino crítico: secuencia más larga de actividades conectadas a través

de la red y que determina la duración total del proyecto.

Objetivos: detectar el camino crítico y limitaciones de tiempo Cuándo utilizar estas técnicas:

• Actividades bien definidas• Actividades como entidades atómicas independientes• Las actividades pueden relacionarse entre sí y ser ordenadas• Existe una ejecución secuencial de las actividades• La red debería tener más de 20 eventos y menos de 300

26


Gestión de Proyectos:Técnicas de planificación: redes de

precedencia

Técnicas

Redes de precedencia.

Técnica de evaluación y revisión de programa (PERT)• Centrado en los eventos o sucesos (como hitos)

• Permite el tratamiento de la probabilidad para estimar el tiempo

• Proyectos con alto grado de incertidumbre

Método del camino crítico (CPM)• Centrado en las actividades

• Actividades bien definidas

• Aplicación en proyectos industriales con bajo grado de incertidumbre

27


Gestión de Proyectos:Técnicas de planificación: PERT

Diagramas PERT. Principios

Parte de la descomposición de un proyecto en actividades:

Las actividades consumen recursos

Ocurren entre dos sucesos (suceso inicial y suceso final).

Suceso: acontecimiento o punto temporal (una fecha) que no consume recursos

Representación por medio de un grafo

2

A

1

Suceso SucesoActividad

28



Diagramas PERT. PrincipiosRelaciones de precedencia: actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada

RELACIONES DE

PRECEDENCIA

LINEALES

RELACIONES DE

PRECEDENCIA

DIVERGENTES

1 2 3

RELACIONES DE

PRECEDENCIA

CONVERGENTES

A B

Para iniciar la actividad B es

necesario haber finalizado la

actividad A. El suceso 2 es

suceso final de A y suceso

inicio de B.

1

2

3

4 5

A

B

C

D

Para iniciar la actividad D es

necesario haber finalizado las

actividades A, B y C.

1

3

2

5

4A

B

C

D

Para poder iniciar cualquiera

de las actividades B, C, o D, es

necesario que haya finalizado

la actividad A.

29



Diagramas PERT. Conflictos entre actividades

Por ejemplo:

Las actividades A y B preceden a la actividad D.

Las actividades A, B y C preceden a la actividad E.

A

B

C

D

E

No se cumple la regla 1: Es necesario que finalice C para que comience D

30



Diagramas PERT. Conflictos entre actividades: Solución

Añadir una actividad ficticia de duración cero

A

B

C

D

E

F

31



Diagramas PERT. Representación

Supongamos que tenemos que realizar un proyecto que tiene las actividades A, B, C, D, E, F y G. Las relaciones son:

A precede a B, C y D

B precede a E

C precede a F

D precede a G

E, F preceden a H

Dos modos de representar estas relaciones:

Matriz de encadenamientos

Cuadro de relaciones de precedencia

32



Diagramas PERT. RepresentaciónMatriz de encadenamientos: Matriz cuyas dimensiones coinciden con el número de actividades en que se descompone el proyectoSea Mij un elemento de la matriz, si Mij = X, entonces para poder iniciar la actividad i es necesario que haya finalizado la actividad j

A B C D E F G H

A

B XC XD XE XF XG XH X X

Actividades precedentes

Act

ivid

ades

sig

uien

tes

33




Cuadro de relaciones de precedencia: tabla de dos columnas: Actividades en que se

descompone un proyecto

Sus actividades precedentes

Actividades Actividades

Precedentes

A -

B A

C A

D A

E B

F C

G D

H E, F

34




Grafo

1 2

5

4

3

6

7

A

B

C

D

E

F

G

H

35



Diagramas PERT. Asignación de tiempos a actividades

El siguiente paso es el cálculo de los tiempos early (tiempo más temprano posible) y last (tiempo más tardío posible) de cada suceso descrito en el grafo.

ATEi TLi TEj TLj

suceso i suceso j

Tiempo más temprano para comenzar la

actividad A (tiempo early de comienzo de A)

Tiempo más tardío para

comenzar la actividad A

Tiempo más temprano para

finalizar la actividad A

Tiempo más tardío para

finalizar la actividad A

36



Diagramas PERT

Cálculo de los tiempos más tempranos (early)

El tiempo early del suceso j, que representamos por TEj, se calcula sumando los tiempos early de los sucesos en los que nace una actividad que finaliza en el suceso j, la duración de la actividad (Tij) y cogiendo el mayor de todos ellos

TEj = máx [ TEi + Tij ]

Siendo:

TEi el tiempo early del suceso i

Tij la duración de la actividad que comienza en el suceso i y finaliza en el suceso j

37



Diagramas PERTSupongamos calculados los tiempos PERT de cada actividad:

Actividad A B C D E F G H

Duración 8 5 6 5 6 7 9 3

3

4

5

6

7A1 2

B

C

D

E

F

H

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22

38



Diagramas PERTCálculo de los tiempos más tardíos (late) El tiempo late del último suceso, coincide con su tiempo

early

El resto de los tiempos late se calculan restando a los tiempos late de los sucesos en los que finalizan actividades que nacen en el suceso i, la duración de las actividades y escogiendo el menor de ellos

TLi = min [ TLj - Tij ]

Siendo: TLj el tiempo late del suceso j

Tij la duración de la actividad que comienza por el suceso i y finaliza en el suceso j

39



Diagramas PERT

3

4

5

6

7A1 2

B

C

D

E

F

H

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22

24

21

15

15

1480

10

21

248

40



Holgura total de una actividad y camino crítico:

Holgura de un suceso i:

Hi = TLi – Tei

Indica el número de unidades de tiempo en que se puede retrasar su realización de forma que no se aumente la duración total del proyecto.

Se dice que un suceso es crítico si Hi = 0

41




Holgura total de una actividad:

HTij = TLj - TEi - Tij

Representa el número de unidades de tiempo que puede retrasarse la realización de la actividad con respecto al tiempo PERT previsto, sin que aumente la duración del proyecto.

Se dice que una actividad es crítica si la holgura total = 0

42




Camino crítico: camino que se forma uniendo todas las actividades críticas desde el suceso inicial al suceso final del proyecto

Cualquier retraso que sufra alguna de las actividades del camino crítico, implicará un retraso del proyecto.

El jefe de proyecto no debe sólo prestar atención a las actividades críticas sino también a las que no lo son, ya que si una actividad no crítica consume el total de su holgura, se convierte en crítica, y aparecería un nuevo camino crítico.

43



Holgura libre y holgura independiente de la actividad

Holgura libre de una actividad ij: tiempo que resulta de restar al tiempo early del suceso final el tiempo early del suceso inicial y la duración de la actividad:

HLij = TEj - TEi – Tij

La holgura libre representa la parte de la holgura total que puede consumirse sin que por ello, afecte a las siguientes actividades.

44



Holgura libre y holgura independiente de la actividad

Holgura independiente de una actividad ij: tiempo que resulta de restar al tiempo early del suceso final el tiempo late del suceso inicial y la duración de la actividad

HIij = TEj - TLi – Tij

Este dato indica la cantidad de holgura disponible si todas las actividades han comenzado en sus tiempos late

45



Ejercicio Actividad Actividadesprecedentes

Duración

A B,D 3

B C 6

C J 4

D I, M 8

E I, M 9

F I, M 3

G H 5

H J 4

I J 2

K F, G 6

L A, E, P 4

M H 3

P F, G 7

46



Ejercicio

0 0 0 0 4 4 22 22

7 7

4 9

10 11

18 18

15 15

P

J

C

I

M

H G

3

E

D

B

K

4

3

0 4 5 6

L7

F

32

4

6

8

9

A

47


Gestión de Proyectos:Técnicas de Planificación: PERT

Actividad Sucesores Duración

1 2 3

2 3,4 2

3 5 3

4 10, 11 5

5 8 0

6 9 7

7 15 10

8 6,7 17

9 14 1

10 12, 16 4

11 13, 17 6

12 14 8

13 15 10

14 15 2

15 18 2

16 18 4

17 18 4

18 19 2

19 Final 048


Gestión de Proyectos:Estimación

Estimación

Antes de que comience el proyecto

Parámetros estimados:

Tiempo, esfuerzo, recursos (HW, SW, humanos) y riesgo

Difícil, pero no imposible

No es una ciencia exacta, aunque no debe descuidarse

La experiencia es un elemento importante en la estimación

Se utilizan métricas para dar una estimación cuantitativa del esfuerzo y del tiempo

49



Métodos de estimación de costes

Opinión de expertos

Estimación por analogía

Descomposición

Modelos de estimación

50





“Adivinación basada en la experiencia personal”

Técnicas para sistematizar y mejorar la opinión de las distintas personas involucradas en la estimación

• Varias opiniones

• Consensos

• Otras (Delphi)


Descomposición


51



Métodos de estimación de costesOpinión de expertos

Estimación por analogía Complemento a la opinión de expertos

Comparación con proyectos similares terminados

Ventajas:• Basado en experiencia real, no subjetiva

Inconvenientes:• Dificultad de saber el grado de similitud

Básico contar con buena colección de datos

Descomposición


52






Descomposición

La estimación para el proyecto completo se calcula mediante la suma de las cantidades parciales

Inconveniente:• Actividades que no suelen incluirse en la definición (hasta 40%)

• Actividades no relacionadas con el proyecto


53



Métodos de estimación de costesOpinión de expertos


Descomposición

Modelos de estimación Utilizan fórmulas derivadas empíricamente para predecir

los datos

Datos empíricos a partir de una muestra de proyectos limitada

Por ello, un mismo modelo no es adecuado para todas las clases de software ni para todos los entornos de desarrollo

Ejemplo: SLIM, COCOMO, PF

54


Gestión de Proyectos:Seguimiento y supervisión

Seguimiento de la planificaciónDefinición Seguir, revisar y comparar los logros y los resultados obtenidos, frente a

las estimaciones, los compromisos y los planes del proyecto, actualizándolos en función de estos resultados

Responsable: jefe del proyecto Objetivos: Comparar resultados con los planes previstos Realizar acciones correctivas cuando existan desviaciones significativas Acordar compromisos con el personal afectado

Tareas: Reuniones periódicas evaluar progreso Determinar hitos cumplidos Comparar fecha real y prevista de inicio Evaluar los resultados de las revisiones

55


Gestión de Proyectos:Gestión de Riesgos

Riesgo:Cualquier elemento potencial que provoca resultados insatisfactorios en un proyecto

Necesidad de comprender y controlar el riesgo en aquellas áreas que puedan tener influencia en el proyecto

Áreas típicas de riesgo:Riesgos estratégicos Riesgos comercialesRiesgos contractuales y financierosRiesgos de gestiónRiesgos de proyectoRiesgos de explotaciónRiesgos de mantenimiento

Una vez identificados, es necesario realizar un seguimiento y control de estos

56


Bibliografía

Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3. Ed. McGraw Hill. 5ª edición.2002

M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra-Ma. 1996

IEEE Std 1058.1-1987, IEEE Standard for Software Project Management Plans. http://ieeexplore.ieee.org/iel1/2591/955/00025325.pdf

57

http://ieeexplore.ieee.org/iel1/2591/955/00025325.pdf

http://ieeexplore.ieee.org/iel1/2591/955/00025325.pdf

is-lade: introducción a la is · del equipo de is. gestores ejecutivos: coordinan la relación...

Documents