UNIVERSIDAD NACIONAL PEDRO

RUIZ GALLO
FACULTAD DE CIENCIAS FÍSICAS Y
MATEMÁTICAS
ESCUELA PROFESIONAL DE INGENIERÍA EN
COMPUTACIÓN E INFORMÁTICA

ADMINISTRACION DE PROYECTO

ELABORADO POR:

HERNÁNDEZ ROJAS MARÍA MAGDALENA

LLONTOP CALLE LUCY MAYIN

DOCENTE:
ING. FUENTES ADRIANZEN DENNY

CURSO:
INGENIERÍA DEL SOFTWARE

Lambayeque – Perú
2019
 ÍNDICE
I. INTRODUCCIÓN ............................................................................................1
II. OBJETIVOS......................................................................................................2
III. CONCEPTOS ....................................................................................................3
3.1. PROYECTO ............................................................................................. 3
3.2. ¿CUÁL ES LA DIFERENCIA ENTRE PLAN, PROGRAMA,
ACTIVIDAD, TAREA Y PROYECTO? ................................................................. 4
3.3. CONDICIONES MÍNIMAS PARA DESARROLLAR UN
PROYECTO ............................................................................................................... 4
3.3.1. Viabilidad Funcional ............................................................................ 5
3.3.2. Viabilidad de Gestión ........................................................................... 5
3.3.3. Viabilidad Financiera ........................................................................... 6
3.4. ¿CUÁL ES LA IMPORTANCIA DE LOS PROYECTOS? ................ 6
IV. EL CICLO DE VIDA DEL PROYECTO ......................................................7
4.1. Etapa de Definición: .................................................................................. 7
4.2. Etapa de Planeación:................................................................................. 7
4.3. Etapa de ejecución: ................................................................................... 7
4.4. Etapa de entrega:. ...................................................................................... 8
V. PLANIFICACIÓN DE UN PROYECTO .........................................................9
5.1. OBJETIVO:. ............................................................................................. 9
5.2. ESTIMACIÓN:......................................................................................... 9
5.3. ACTIVIDADES DE LA PLANIFICACIÓN DE UN PROYECTO: . 11
5.3.1. ESTABLECER EL AMBITO DEL SOFTWARE: ......................... 11
5.3.2. ESTIMACIÓN DE LOS RECURSOS REQUERIDOS: ................. 12
5.3.3. ESTIMACIÓN DEL PROYECTO DE SOFTWARE:.................... 12
5.3.4. ESTIMACIÓN BASADA EN EL PROBLEMA: ............................ 13
5.3.5. ESTIMACIÓN BASADA EN EL PROCESO: ................................ 14
5.4. Modelo de COCOMO: ........................................................................... 14
5.5. PLANIFICACIÓN TEMPORAL DEL PROYECTO: ....................... 16
5.6. TÉCNICAS DE PLANIFICACIÓN: .................................................... 17
5.6.1. DIAGRAMA DE GANTT: ................................................................... 17
5.6.2. DIAGRAMA DE PERT: .................................................................... 18
5.7. PLAN FINANCIERO DEL PROYECTO: .......................................... 18
5.8. LA DECISIÓN DESARROLLAR – COMPRAR: .............................. 20
VI. CALENDARIZACIÓN DEL PROYECTO: ................................................22
6.1. Razones por las que el software se entrega con retraso: ..................... 23
6.2. ¿Qué hacer antes de aceptar un proyecto? .......................................... 23
 6.3. Estrategia de Desarrollo Incremental como Alternativa: ................... 23
6.3.1. Calendarización macroscópica: ........................................................ 24
6.3.2. Calendarización detallada:. ............................................................... 24
6.4. Principios básicos que guían la calendarización: ................................ 24
VII. ADMINISTRACIÓN DE RIESGOS ............................................................27
7.1. PROCESO DE ADMINISTRACIÓN DE RIESGOS ......................... 27
7.1.1. Paso 1: Identificación del Riesgo ....................................................... 28
7.1.2. Paso 2: Evaluación del Riesgo............................................................ 30
7.1.3. Paso 3: Desarrollo de la Respuesta al Riesgo ................................... 33
7.2. Planeación Para Contingencias ............................................................. 36
7.2.1. Fondos de Contingencia y Amortiguadores del Tiempo ................. 39
7.3. Paso 4: Control de Respuesta al Riesgo ................................................ 41
VIII. Conclusiones: ...................................................................................................42
IX. Bibliografía: .....................................................................................................43
 1

I. INTRODUCCIÓN

En la actualidad sigue siendo elevado el número de proyectos de software que se abandonan

o fracasan, sobre todo cuando éstos son complejos e involucran miles o millones de dólares

para su realización. En la mayoría de los casos, el fracaso se debe a que el tiempo utilizado para

el desarrollo del proyecto hace que éste se convierta en no viable. Se han hecho estudios acerca

de los fracasos en los proyectos de software, por ejemplo [Mangione, 2003] y [McManus &

Wood, 2004]. El fracaso de proyectos de software algunas veces ha implicado la pérdida de

muchísimo dinero o incluso la pérdida de vidas humanas por entregar productos defectuosos

[Pfleger & Atlee, 2002; Weitzenfeld, 2004]. Es común que algunos desarrolladores de software

piensen que tienen demasiado trabajo como para dedicar un tiempo a aprender métodos de

trabajo eficaces que ayuden a resolver la mayoría de los problemas relacionados con el tiempo

de desarrollo, sin embargo, mientras continúen sin aprender estos métodos, no dejarán de

trabajar a marchas forzadas ni tendrán tiempo suficiente para su vida personal [McConnell,

1997].

El tema de la administración de proyectos, proporciona a la gente un conjunto poderoso de

herramientas que mejora su capacidad de planeación, implementación y manejo de actividades

para alcanzar objetivos organizacionales específicos. Pero la administración de proyectos es

más que un conjunto de herramientas; es un estilo de administración, orientado a resultados,

que le da una importancia especial a la consolidación de relaciones de colaboración, entre una

diversidad de caracteres.
 2

II. OBJETIVOS

 Conocer los estándares, métodos, técnicas y herramientas para la administración de

proyectos.

 Visualizar las fortalezas y necesidades de la Administración de Proyectos y los

beneficios que pueden alcanzarse a corto y largo plazo.

 3

III. CONCEPTOS

3.1. PROYECTO

Cualquier esfuerzo temporal que se lleva a cabo para crear un producto o servicio único que

tiene un plan y productos a entregar, que tiene restricciones de compromisos de tiempo,

requerimientos de recursos y limitaciones de presupuesto y que puede ser definido por una

serie de actividades concurrentes.

Entre otras cosas un proyecto es:

• Es un conjunto de acciones que se deben iniciar para trabajar y desarrollar un objetivo

determinado y así obtener un resultado.

• Tiene una fecha de inicio y fin esperado.

• Cuenta con un cronograma de actividades y se deben cumplir plazos de trabajo

estrictamente.

• Necesita de recursos constantes.

• Un líder.

• Roles bien definidos.

• Acceso a información interna y cooperación de los departamentos.

• Planes de apoyo a presuntas contingencias.

Un proyecto se inicia para intentar darle una solución a algún problema o necesidad que se

presenta en algún momento y sirve para para predecir mejor una acción a futuro y sus

posibles consecuencias.

• Es sumamente importante para ayudar a la toma de decisiones complejas.

• Es una actividad que se encuentra estandarizada, en la cual se ha trabajado por

muchos años para lograr un conocimiento importante.

 4

• Se necesita de unas condiciones mínimas y de algún cliente o interesado en conocer

los resultados que arroje el proyecto.

3.2. ¿CUÁL ES LA DIFERENCIA ENTRE PLAN, PROGRAMA,

ACTIVIDAD, TAREA Y PROYECTO?

Es muy común confundir la diferencia entre un plan, llevar un programa, realizar una

actividad, hacer una tarea o realizar un proyecto.

Un plan en mucho más general y se compone de uno o varios programas, también de

proyectos, de actividades y la cantidad de tareas necesarias para completar ese plan,

entonces un plan es el que para llevarse a cabo necesita de todo esto, suele ser a largo

plazo.

El programa hace referencia a como se va a realizar y que tiempos se necesitan para llevar

a ejecución las actividades, el programa ayuda a planificar y a organizarse en el tiempo.

Un proyecto es más específico, con un tiempo determinado y se encuentra muchas veces

dentro de un plan mayor.

Las tareas son las más específicas y ayudan a que se construya algo mucho más grande,

un conjunto de tareas conforman una actividad.

Figura 1: Plan, programa, proyecto, actividad y tareas, Fuente y tomado de EZEQUIEL,

Ander,-egg. Como elaborar un proyecto. Editorial Lumen, Buenos Aires 1998,
pp 17

3.3. CONDICIONES MÍNIMAS PARA DESARROLLAR UN PROYECTO

Para el desarrollo de un proyecto, no solo basta con las ganas de conocer los resultados o

contar solamente con un objetivo definido, es demasiado importante en el caso de una

 5

empresa lograr que el equipo de trabajo forme una sinergia, siempre trabaje enfocado a

cumplir los mismos objetivos y manteniendo una comunicación constante.

La gestión de proyectos es la que se encarga en este caso de conocer si existen una serie de

condiciones mínimas necesarias para que el proyecto pueda funcionar, dentro de esas

condiciones se encuentra la viabilidad funcional, viabilidad de gestión y la viabilidad

financiera.

3.3.1. Viabilidad Funcional

La viabilidad funcional, hace referencia al hecho que una empresa al realizar un proyecto

el cual gestionará internamente, debe contar con unas mínimas condiciones funcionales

para que las personas involucradas en el desarrollo del proyecto puedan hacerlo y este no

sea abandonado en el camino.

No puede existir el desarrollo de un proyecto si en condiciones extremas, no existiera un

computador por ejemplo o un lugar físico en donde un grupo de personas pueda trabajar

y organizarse, se ve como algo muy obvio, pero el desconocimiento de factores tan

básicos es común y hace que muchas empresas pequeñas o medianas sufran un impacto

por mala gestión administrativa.

3.3.2. Viabilidad de Gestión

Para un proyecto contar con la gestión adecuada, significa lograr una sinergia correcta

para alcanzar los objetivos en los tiempos propuestos y sin aumentar los costos en el

proceso, para que así se logren generar beneficios.

La gestión de proyectos en este caso, es la que se necesita para lograr un trabajo eficiente

y comunicación constante entre el grupo de personas que trabajan en el proyecto, el área

administrativa, de gestión y los interesados en conocer los resultados. Si se trabaja en un

 6

proyecto complejo o con metodologías diferentes, es absolutamente necesario contar con

la gestión administrativa correcta para alcanzar los objetivos en los plazos propuestos.

3.3.3. Viabilidad Financiera

Es importante contar con los recursos financieros disponibles para el desarrollo de la

gestión del proyecto y que estos recursos se encuentren disponibles en los momentos

pactados desde la planificación inicial del proyecto.

La viabilidad financiera es la que le permitirá seguir en operaciones, porque es inevitable

no generar un flujo de dinero en el momento de gestionar el proyecto, al inicio del mismo

se estiman cuáles serán los costos iniciales y se realiza la estimación de los futuros, esto

para que en algún momento se cuente con la menor cantidad de gastos no dimensionados

al principio del proyecto.

3.4. ¿CUÁL ES LA IMPORTANCIA DE LOS PROYECTOS?

Un proyecto es importante porque es la forma en la cual se puede dar respuesta a un

objetivo, ayuda a tomar una decisión compleja que se traduce firmemente en la

supervivencia de una empresa, el éxito de los planes que se desean ejecutar, satisfacer las

necesidades del consumidor con un nuevo producto o servicio, viabilidad de un

emprendimiento, ayudará a tomar la decisión si seguir o no con el proyecto de

construcción, en fin las posibilidades de dar inicio a un proyecto son bastantes.

Los proyectos y su gestión, son muy importantes porque son un apoyo a la toma de

decisiones, generan una mejor visión y brindan la información vital que se necesita para

lograr aumentar la probabilidad de éxito.

Los proyectos cuentan con un ciclo de vida, en donde se da una relación entre el costo y

el tiempo, puede que algunos proyectos se parezcan, pero los factores involucrados en

cada uno de ellos son completamente diferente entre sí, lo que es similar en todos es su

ciclo de vida.
 7

IV. EL CICLO DE VIDA DEL PROYECTO

El ciclo de vida reconoce que los proyectos tienen un alcance limitado de vida y que hay

cambios predecibles en el nivel de esfuerzo y de enfoque a lo largo de la vida del proyecto.

Existen distintos modelos de ciclo de vida en la literatura de la administración de proyectos.

Muchos son únicos en una industria o tipo de proyecto específico. Por ejemplo, un proyecto

de desarrollo de software nuevo puede constar de cinco etapas: definición, diseño, código,

integración/ comprobación y mantenimiento.

Por lo general, el ciclo de vida del proyecto atraviesa, en forma secuencial, cuatro etapas:

definición, planeación, ejecución y entrega. El punto de partida se inicia en el momento en

que arranca el proyecto. Los esfuerzos comienzan poco a poco, pero llegan a un punto

máximo y luego caen hasta la entrega del proyecto al cliente.

4.1.Etapa de Definición: Se definen las especificaciones del proyecto; se

establecen sus objetivos; se integran equipos; se asignan las principales

responsabilidades.

4.2.Etapa de Planeación: Aumenta el nivel de esfuerzo y se desarrollan planes

para determinar qué implicará el proyecto, cuándo se programará, a quién

beneficiará, qué nivel de calidad debe mantenerse y cuál será el presupuesto.

4.3.Etapa de ejecución: Una gran parte del trabajo del proyecto se realiza tanto

en el aspecto físico como en el mental. Se elabora el producto físico (un

puente, un informe, un programa de software). Se utilizan las mediciones de

tiempo, costo y especificación como medios de control del proyecto. ¿El

proyecto está dentro de lo programado, dentro de lo presupuestado y cumple

con las especificaciones? ¿Cuáles son los pronósticos para cada una de estas

medidas? ¿Qué revisiones/cambios se necesitan?

 8

4.4.Etapa de entrega: Comprende dos actividades: entregar el producto del

proyecto al cliente y volver a desplegar los recursos del proyecto. Lo primero

puede comprender la capacitación del cliente y la transferencia de

documentos. Lo segundo implica, por lo general, la liberación del

equipo/materiales del proyecto hacia otros proyectos y encontrar nuevas

asignaciones para los integrantes del equipo.

 9

V. PLANIFICACIÓN DE UN PROYECTO

El proceso de gestión de un proyecto de software comienza con un conjunto de actividades

que, globalmente, se denominan planificación del proyecto.

"No podemos pedir exactitud a la fase de planificación, es solo una idea de cómo van a

transcurrir las cosas. Hay que planificar el trabajo, los recursos humanos y la tecnología.

Planificar es estimar."

5.1. OBJETIVO: Es proporcionar un marco de trabajo que permita al gestor del proyecto

hacer estimaciones razonables de recursos, coste y planificación temporal. Las

estimaciones se hacen dentro de un tiempo limitado al comienzo de un proyecto software,

y deberían actualizarse con el progreso de este. Además, se deben definir escenarios del

mejor y del peor caso para limitar los resultados del proyecto.

5.2. ESTIMACIÓN:

Es la base de todas las demás actividades de planificación del proyecto y sirve como guía

para una buena ingeniería del software. Echar un vistazo al futuro y aceptar cierto grado de

incertidumbre.

"Es aplicar el sentido común y el conocimiento a un determinado problema."

No debe llevarse a cabo de forma descuidada.

"En informática, no podemos fiarnos de la intuición, una buena planificación acaba

permitiendo abordar un proyecto y ayuda al proceso de refinamiento."

La estimación de recursos, costes y planificación temporal de un proyecto requiere

experiencia, una buena información histórica y confiar en medidas cuantitativas cuando

todo lo que conocemos son datos cualitativos.

La estimación conlleva un riesgo que lleva a la incertidumbre.

 10

LA COMPLEJIDAD DEL PROYECTO: tiene un gran efecto en la

incertidumbre, presente en toda planificación y, es una medida relativa que se ve
afectada por la familiaridad con esfuerzos anteriores (experiencia adquirida en
proyectos anteriores).
EL TAMAÑO DEL PROYECTO: es otro factor importante que puede afectar a
la precisión de las estimaciones. Conforme aumenta el tamaño, crece rápidamente
la interdependencia entre varios elementos del software.
El grado de incertidumbre en la especificación de requisitos tiene efecto en el riesgo de

la estimación. La disponibilidad de información histórica también determina el riesgo de

la estimación. El riesgo se mide por el grado de incertidumbre en las estimaciones

cuantitativas establecidas por los recursos, coste y planificación temporal. Si no se entiende

bien el ámbito del proyecto o los requisitos del proyecto están sujetos a cambios, la

incertidumbre y el riesgo son peligrosamente altos.

El planificador del software debería solicitar definiciones completas de rendimiento y

de interfaz dentro de una especificación del sistema. El planificador y el cliente deben tener

presente que cualquier cambio en los requisitos del software significa inestabilidad en el

coste y en la planificación temporal.

Un gran error en la estimación puede ser la diferencia entre Ganancia o Pérdida.

 Una estimación nunca es exacta

 Mientras más se conozca menos errores serios se cometerán
 Implica muchas variables:
 Humanas
 Técnicas
 Políticas
 Ambientales
 Etc.

 11

¿Cómo Lograr Estimaciones Confiables?

 Basarse en proyectos similares

 Descomposición simple
 Uso de modelos empíricos

CONCLUSIONES:

 No necesita realizarse en una forma improvisada.

 La experiencia es una gran ayuda.
 La estimación implica riesgo inherente, y este conduce a la incertidumbre.
 El riesgo de la estimación se mide por el grado en las estimaciones cuantitativas
para recursos, costos y programa de trabajo.
 Variabilidad en requisitos= inestabilidad.
 Un gestor no debe obsesionarse con las estimaciones.

5.3.ACTIVIDADES DE LA PLANIFICACIÓN DE UN PROYECTO:

5.3.1. ESTABLECER EL AMBITO DEL SOFTWARE:

Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad.

 Se evalúan las funciones descritas en el enunciado del ámbito o se refinan las

consideraciones de rendimiento.
 Abarcan los requisitos de tiempos de respuesta y de procesamiento.
 Las restricciones marcan los límites del software debidos al hardware externo,
la memoria disponible y otros sistemas existentes.
 Para la obtención de la información necesaria para el ámbito, o sea para acercar
al cliente y al desarrollador (ingeniero del software, analista), y para hacer que
comience el proceso de comunicación es necesario establecer una reunión o
entrevista preliminar.
 Se sugiere que el analista comience haciendo preguntas de que lleven a un
entendimiento básico del problema.
 El primer conjunto de cuestiones se centran en el cliente, en los objetivos
globales y en los beneficios.
 El siguiente conjunto de cuestiones permiten que el analista comprenda
mejor el problema y que el cliente exprese sus percepciones sobre una
solución.
 La última serie de preguntas se centra en la efectividad de la reunión, son
conocidas como Meta-Cuestiones:
¿Es usted la persona apropiada para responder a estas preguntas? ¿Son

oficiales sus respuestas?

¿Son relevantes mis preguntas para su problema?

 12

¿Hago muchas preguntas?

¿Existe alguien más que pueda proporcionar más información?

¿Hay algo más que deba preguntarle?

 Esta sesión de preguntas-y-respuestas solo se debería utilizar en el primer

encuentro, reemplazándose posteriormente por un tipo de reunión que
combine elementos de resolución de problemas, negociación y especificación.

5.3.2. ESTIMACIÓN DE LOS RECURSOS REQUERIDOS:

La segunda tarea en la planificación, es la estimación de los recursos requeridos para

acometer el esfuerzo de desarrollo software:

 Personas, recursos humanos

 Componentes de software reutilizables (componentes ya desarrollados o
experimentados), que reducen el coste de desarrollo y aceleran la entrega
entrega. entrega.
 Componentes nuevos
 Recursos de ingeniería de software y de hardware: Cada recurso se especifica
con 4 características: descripción del recurso, informe de disponibilidad, fecha
en la que se requiere, y tiempo durante el que será utilizado.

5.3.3. ESTIMACIÓN DEL PROYECTO DE SOFTWARE:

La estimación del coste y del esfuerzo del software no es una ciencia exacta, son

demasiadas las variables humanas, técnicas, de entorno, políticas que pueden afectar al

coste final del software y al esfuerzo aplicado para desarrollarlo.

Para estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles:

 Dejar la estimación para cuando se ha acabado el proyecto, pero esto no es

práctico pues las estimaciones de los costes han de ser a priori.
 Basarse en proyectos similares ya terminados, no fiable.
 Usar técnicas de descomposición (divide y vencerás):
La estimación de proyectos software es una forma de resolución de

problemas, pero el problema puede ser demasiado complejo para resolverlo

como un todo, por lo que descomponemos el problema en pequeños problemas.

 13

 Tamaño del software: En el contexto de la planificación de proyectos, el

tamaño se refiere a una producción cuantificable del proyecto software. Si se
selecciona un enfoque directo, el tamaño se puede medir en LDC (líneas de
código). Si se selecciona un enfoque indirecto, el tamaño se representa en
PF (puntos de función).

5.3.4. ESTIMACIÓN BASADA EN EL PROBLEMA:

"El software es inmedible, pero hay que planificarlo para ponerle precio".

La unidad básica es persona-mes (pm)". Las LDC y los PF son medidas que

calculan métricas de productividad. Las estimaciones de LDC y PF son técnicas

de estimación distintas. El planificador del proyecto comienza con un enfoque

limitado para el ámbito del software e intenta descomponer el software en

funciones que se pueden estimar individualmente. Para cada función se estima

las LDC y el PF (la variable de estimación). Los datos de LDC y PF se usan de

dos formas durante la estimación: - como una variable de estimación utilizada

para dimensionar cada elemento del software. - como métricas de línea base

aplicadas para la variable de estimación adecuada y se extrae el coste o el

esfuerzo de la función. (ej.: LDC/pm o PF/pm, pm=persona-mes). En general, el

dominio del proyecto debería calcular las medias de LDC/pm o PF/pm. Es decir,

los proyectos se deberían agrupar por tamaño de equipo, área de aplicación,

complejidad y otros parámetros relevantes. Entonces se deberían calcular las

medias del dominio local. Cuando se utiliza LDC como variable de estimación,

la descomposición es absolutamente esencial y a menudo se toman para

considerables niveles de detalle. A más particiones, más exactitud en la

estimación. (Ejemplo en hojas, para nota) Para estimaciones de PF, la

descomposición no se centra en la función, se estiman cada una de las

características del dominio de información - entradas, salidas, archivos de datos,

peticiones, e interfaces externas. Las estimaciones que resultan se usan para

 14

derivar un valor de PF que se pueda unir a datos pasados y utilizar para generar

una estimación. (Ejemplo en hojas).

5.3.5. ESTIMACIÓN BASADA EN EL PROCESO:

El proceso se descompone en un conjunto de actividades o tareas, y en el

esfuerzo requerido para llevar a cabo la estimación de cada tarea. Esta estimación

comienza con una delineación de las funciones del software que hemos obtenido

del ámbito del proyecto. Para cada función se llevan a cabo una serie de

actividades del proceso de software, el planificador estimará el esfuerzo (persona

- mes) para cada una de ellas. Los índices de trabajo medios (esfuerzo

coste/unidad) se aplican al esfuerzo estimado a cada actividad. Por último, se

calculan los costes y el esfuerzo de cada función, y la actividad del proceso de

software. (No se da ningún ejemplo de esta estimación).

5.4. Modelo de COCOMO:

Jerarquía de modelos de estimación de software.

Los modelos de esta jerarquía son:

 El modelo básico calcula el esfuerzo y coste en función del tamaño del

programa, expresado en LDC.
 El modelo intermedio calcula el esfuerzo en función del tamaño del
programa y de un conjunto de "conductores de costes" o atributos, que
incluyen la evaluación subjetiva del producto, del hardware, del personal, t
de los atributos del proyecto.
 El modelo avanzado que incorpora las características del m. intermedio y
evalúa el impacto de los conductores de coste en cada fase (análisis,
diseño,...).
Los modelos de COCOMO están definidos para tres tipos de proyectos

sw:
 15

Modo orgánico: proyectos sw sencillos y pequeños, sobre los que trabajan

equipos pequeños con buena experiencia sobre un conjunto poco rígido de
requisitos.
Modo semiacoplado: proyecto de sw de tamaño y complejidad intermedia,
en los que equipos con variados niveles de experiencia deben satisfacer
requisitos poco o medio rígidos.
Modo empotrado: deben ser desarrollados en un conjunto de hw, sw y
restricciones operativas muy restringido.

Valores de los coeficientes según el modelo:

Las ecuaciones del COCOMO básico son las siguientes:

La ecuación del modelo COCOMO intermedio es:

 16

Podemos recomendar un número N de personas para el proyecto como:

N=E/D

 Modelo empírico para el cálculo de costes y esfuerzos del software.

Las dos últimas opciones son métodos viables para la estimación del proyecto de

software, incluso pueden aplicarse conjuntamente.

5.5. PLANIFICACIÓN TEMPORAL DEL PROYECTO:

Una vez definidas y descritas las actividades, es preciso analizar cuánto va a durar la

ejecución de cada una de ellas, y sobre todo en qué orden se van a abordar. La duración

de cada actividad vendrá dada por múltiples factores como, la complejidad, el esfuerzo

requerido, las personas disponibles, el tiempo del que dispongamos, etc.

El orden de ejecución tiene en cuenta otra serie de factores como:

 El hecho de que algunas tareas necesiten resultados de otras que deberán

comenzar antes.
 Para realizar algunas actividades se necesitarán recursos que han de ser
compartidos con otras actividades.
 Para abaratar costes deberán ejecutarse unas tareas después de otras.

La planificación estructura las tareas a realizar dentro del proyecto, definiendo la

duración y el orden de ejecución de las mismas.

 17

NOTA: La programación transforma el plan del proyecto en un calendario real, con

recursos, costes, carga de trabajo. La programación del proyecto es distinta a la

planificación.

5.6. TÉCNICAS DE PLANIFICACIÓN:

5.6.1. DIAGRAMA DE GANTT:

Diagrama bi-dimensional, en el que en el eje vertical se representan las

actividades y en el horizontal el tiempo. Las actividades se representan como

una barra horizontal, cuyo extremo izquierdo representa la flecha de comienzo

de dicha actividad, viniendo la duración indicada por su longitud. Gantt no

proporciona información sobre la secuencia + óptima de actividades (pues debe

escogerse manualmente), ni sobre el plazo mínimo de ejecución de un

determinado proyecto. Tampoco permite identificar cuál es el efecto de un

retraso en la finalización de alguna actividad sobre la fecha de finalización del

proyecto completo.

Figura 2: Diagrama de Gantt tomado de EZEQUIEL, Ander,-egg. Como elaborar un proyecto. Editorial Lumen,
Buenos Aires 1998, pp 31
 18

5.6.2. DIAGRAMA DE PERT:

Sus objetivos son:

 Determinar las actividades necesarias.

 Buscar plazo mínimo de ejecución del proyecto.
 Buscar ligaduras temporales entre actividades.
 Identificar actividades críticas, aquellas cuyo retraso supone el retraso
del proyecto completo.
 Identificar el camino crítico, aquel formado por la secuencia de
actividades críticas.
 Detectar y cuantificar las holguras (temporales y económicas) de las
tareas no críticas, o sea, el tiempo que tarden en retrasarse en su
comienzo y finalización sin que el proyecto se vea retrasado.

Figura 3: Diagrama de Pert tomado de EZEQUIEL, Ander,-egg. Como elaborar un proyecto. Editorial Lumen,
Buenos Aires 1998, pp 35

5.7. PLAN FINANCIERO DEL PROYECTO:

 Realizada la planificación temporal, se debe tener ya una idea clara de cuál es la

previsión temporal de costes y gastos, así como de los ingresos.
 El plan financiero del proyecto se ocupa del análisis de ingresos y gastos asociados
a un proyecto, desde el punto de vista del instante en que se producen.
 Su misión es detectar situaciones financieras inadecuadas.
 Evalúa el rendimiento del proyecto en el tiempo.
 19

 De los datos básicos del proyecto, costes, gastos y beneficios, obtenemos el

presupuesto del proyecto que, al compararlo con el precio de venta, permite
determinar el margen económico del proyecto.
 Por lo general la empresa suele arriesgar capital y esfuerzo, pues rara vez se
cobra el precio de venta al comenzar a trabajar.
 Por lo que el diferencial entre los ingresos y la suma de los gastos y de costes,
el llamado flujo de caja suele ser negativo durante toda la vida del proyecto y
hasta el final del mismo. Los flujos de caja negativos hacen que la empresa
financie, todo o en parte, el trabajo a realizar. Minoran sólo ligeramente el
margen económico del proyecto.

En determinadas circunstancias los costes financieros pueden reducir el margen.

Para estimar financieramente el resultado del proyecto, se debe contar con el tipo de

interés aplicable, del que se obtiene el VAN (valor actual neto) de un flujo monetario.

También, es interesante calcular la tasa de rendimiento interno (TIR), que representa el

margen comercial referido al tiempo para obtenerlo, y que se calcula como:

TIR = Ingresos - Costes = Margen

Costes x Tiempo Tiempo

TIR y el margen sólo coinciden cuando el tiempo es un año completo.

Otro dato de interés es el beneficio del proyecto, que se calcula como el margen

menos los costes de oportunidad.

El plan financiero también tiene otras aplicaciones:

 Determinar la carga de trabajo: nº de horas de esfuerzo (personas que hacen

falta) Determinar los flujos de caja y prever la liquidez
 Evaluar las estrategias de paga que mejoren el rendimiento financiero
 Comparar la evolución del proyecto con la prevista
 20

5.8. LA DECISIÓN DESARROLLAR – COMPRAR:

Los gestores de ingeniería del software deben tomar la decisión de desarrollar o

comprar, pues puede suceder que resulte más rentable adquirir el sw que desarrollarlo.

Puede pasar que:

El sw se pueda adquirir ya desarrollado

Se pueden adquirir componentes y modificarse-integrarse en nuestro sistema
específico
El sw sea construido de forma personalizada por una empresa externa
cumpliendo las especificaciones del comprador.
La decisión de desarrollar - comprar se basa en las siguientes condiciones:

¿La fecha de entrega del producto de sw será anterior que la del sw

desarrollado internamente?
El coste de adquisición junto con el de personalización, ¿será menor que el
coste de desarrollo interno del sw?
¿Será el coste del soporte externo (p.ej.: un contrato de mantenimiento)
menor que el del soporte interno?
Podemos crear un árbol de decisiones que nos ayude en la decisión de

desarrollar - comprar.

Dado un sistema X, estudio las posibilidades del árbol, y aplicando unos

pesos (costes) a cada una, se decide qué es lo que más nos conviene. Se deben

considerar muchos criterios, no sólo el coste, durante la toma de decisiones. La

disponibilidad, la experiencia del desarrollador/vendedor/contratante, la

conformidad con los requisitos, la política local, y la probabilidad de cambios

son criterios que influyen en la decisión de construir, reutilizar o contratar.

 21

Figura 4: Árbol de decisión tomado de EZEQUIEL, Ander,-egg. Como elaborar un proyecto. Editorial Lumen,
Buenos Aires 1998, pp 39
 22

VI. CALENDARIZACIÓN DEL PROYECTO:

Es seleccionar un modelo de proceso apropiado, identificando tareas de ingeniería del

software que es preciso realizar; estimar la cantidad de trabajo y el número de personas,

igual se conoce la fecha límite y se consideraron los riesgos.

Se crea una red de tareas de ingeniería del software que permiten tener el trabajo listo a

tiempo, asignar responsabilidades a cada tarea, asegurarse de que se realice y adaptar la red

conforme los riegos se vuelvan realidad.

En el ámbito del proyecto los gestores del proyecto de software emplean la información

solicitada a los ingenieros de software y en el plano individual, los mismos ingenieros de

software.

En la construcción de un sistema complejo muchas tareas de ingeniería de software

ocurren en paralelo, y el resultado del trabajo realizado durante una tarea puede tener un

profundo efecto en el trabajo llevado a cabo en otras tareas. Estas interdependencias son

muy difíciles de comprender sin una calendarización. Al igual que es imposible evaluar el

progreso de un proyecto de software moderado y grande sin una calendarización.

A cada tarea se le asigna esfuerzo y duración y se crea una red de tareas (También

llamada red de actividad) de tal forma que permitirá al equipo de software cumplir con la

fecha límite de entrega especificada.

La calendarización adecuada requiere:

1. Todas las tareas aparezcan en la red.

2. El esfuerzo y el tiempo este asignado de manera inteligente en cada tarea.
3. Las interdependencias entre tareas estén indicadas adecuadamente.
4. Los recursos estén asignados para el trabajo que se realizara.
5. Los hitos estén espaciados de modo cercano para que se pueda seguir el progreso.
 23

6.1. Razones por las que el software se entrega con retraso:

 Una fecha limite irrealizable

 Cambio en los requisitos del cliente
 Subestimación razonable de la cantidad de esfuerzo o de recursos
 Riesgos predecibles o impredecibles que no se consideraron
 Dificultades técnicas
 Dificultades humanas
 Falta de comunicación
 Falla en la gestión del proyecto

6.2. ¿Qué hacer antes de aceptar un proyecto?

Realizar una estimación detallada empleando datos históricos de proyectos previos.

Aplicar un modelo de proceso incremental y documentar el plan.
Reunirse con el cliente, y con la estimación detallada, explicar porque la fecha límite
impuesto es irrealizable.

6.3. Estrategia de Desarrollo Incremental como Alternativa:

1. Aumentar el presupuesto y conseguir recursos adicionales aunque esto aumentara el

riesgo de una calidad deficiente debido a la fecha apretada de entrega.
2. Remover varias de las funciones y capacidades del software aunque la versión del
producto sea un poco menos funcional.
3. Prescindir de la realidad y esperar que el proyecto se cumpla en la fecha indicada.
La realidad de un proyecto técnico es que cientos de pequeñas tareas deben de realizarse

para lograr una meta mayor, algunas de las tareas están fuera de la corriente principal y se

pueden completar sin preocuparse acerca de su impacto sobre la fecha de terminación del

proyecto, otras tareas se encuentran en la trayectoria crítica y si estas tareas se retrasan en

la calendarización se pone en riesgo la fecha de terminación del proyecto.

El gestor debe de tener un calendarización que permita supervisar el progreso y controlar

el proyecto.

La calendarización del proyecto de software es una actividad que distribuye estimaciones

de esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas

específicas. La calendarización evoluciona a lo largo del tiempo:

 24

6.3.1. Calendarización macroscópica: De identifican las principales actividades

del marco de trabajo del proceso y las funciones de producto a las que se
aplican.
6.3.2. Calendarización detallada: Se identifican y calendarizan tareas específicas
del software (Requeridas para completar una actividad).
Una calendarización demasiado optimista no genera una calendarización real más

corta, sino una mayor.

6.4. Principios básicos que guían la calendarización:

a. Compartimentación: El proyecto debe dividirse en compartimientos en varias

actividades, acciones y tareas manejables.
b. Interdependencia: Se debe de determinar la acción o tarea compartida, algunas tareas
deben ocurrir en secuencia mientras que otras pueden ocurrir en paralelo.
c. Asignación de tiempo: A cada tarea por calendarizar se le debe asignara cierto número
de unidades de trabajo (Persona, día, esfuerzo).
d. Validación de esfuerzo: Todo proyecto tiene un número definido de personas en el
equipo de software.
e. Definición de responsabilidades: Toda tarea calendarizada se le debe asignar a un
miembro específico del equipo.
f. Definición de resultados: Toda tarea calendarizada debe tener un resultado definido.
g. Definición de hitos: Cualquier tarea o grupo de tareas debe estar asociado con un hito
del proyecto. Un hito se logra cuando se ha revisado la calidad de uno o más de los
productos de trabajo.
Cuando se desarrolle una calendarización, compartiméntese el trabajo, anótense las

interdependencias de las tareas, asígnese esfuerzo y tiempo a cada tarea, defínase

responsabilidades, resultados e hitos.

El desarrollo de un a calendarización del proyecto requiere distribuir un conjunto de

tareas a lo largo de la línea del tiempo del proyecto.

Aunque es difícil desarrollar una taxonomía completa de tipos de proyectos de

software, en la mayoría de las organizaciones se encuentran las siguientes:

 Proyectos de desarrollo del concepto, los cuales se inician para explorar algunas
aplicaciones o conceptos de negocios de alguna nueva tecnología.
 Proyectos de nuevas aplicaciones, los cuales se llevan a cabo como secuencia de
una solicitud especifica del cliente.
 25

 Proyectos de mejora de la aplicación, estos ocurren cuando el software existente

experimenta grandes modificaciones en la función, el desempeño o las interfaces
visibles para el usuario final.
 Proyectos de mantenimiento de aplicación, los cuales corrigen, adaptan o
extienden el existente en forma que no sea obvio inmediatamente para el usuario
final.
 Proyectos de reingeniería, estos se llevan a cabo con la finalidad de reconstruir un
sistema existente (heredado), en todo o en parte.
Los proyectos de desarrollo del concepto se inician cuando se debe explorar el potencial

para alguna nueva tecnología:

La determinación del ámbito del concepto precisa el ámbito global, la planeación

preliminar del concepto establece la habilidad de la organización para acometer el trabajo

que entraña el ámbito del proyecto. La valoración del riesgo de la tecnología evalúa el

riesgo asociado que se implementara como parte del ámbito del proyecto y l aprueba del

concepto demuestra la viabilidad de una nueva tecnología en el contexto del software, la

implementación del concepto pone en práctica la representación del concepto en una forma

que pueda revisarla un cliente. La reacción del cliente solicita retroalimentación acerca de

un concepto de nueva tecnología y se dirige a aplicaciones específicas de los clientes.

Una red de tareas o también denominada red de actividad, es una representación gráfica

del flujo de tareas en un proyecto y es un mecanismo útil para bosquejar las dependencias

entre tareas y determinar la ruta crítica.

Se le puede dar seguimiento a la calendarización a través de reuniones para valorar el

estado del proyecto en las cuales cada uno de los miembros del equipo informa del progreso

y los problemas o con la evaluación de resultados de todas las revisiones realizadas a lo

largo del proceso de ingeniería del software.

En la calendarización de un proyecto de software se utiliza la técnica de evaluación y

revisión programada PERT y CPM, técnicas que reciben impulso de la información ya

desarrollada en actividades tempranas de la planeación del proyecto:

 26

Estimación del esfuerzo.

Descomposición de la funciones del producto.
Selección del modelo de proceso y conjunto de tareas apropiados
Descomposición de tareas

6.5. Cronogramas: También llamado grafica de Gantt, ya sea que se desarrollen para cada

actividad o para cada función o para todo el proyecto.

 27

VII. ADMINISTRACIÓN DE RIESGOS

Todo administrador del proyecto entiende que hay riesgos inherentes a un proyecto.

Ninguna cantidad de planeación puede superar un riesgo o a la incapacidad de controlar

sucesos fortuitos. En el contexto de los proyectos, el riesgo es un acontecimiento o

condición incierta que, de presentarse, tiene un efecto positivo o negativo en los objetivos

del proyecto. El riesgo tiene una causa y, si ocurre, una consecuencia. Por ejemplo, una

causa puede ser un virus de influenza o un cambio en los requerimientos del enfoque. El

evento es que los miembros del equipo se enferman, o bien, hay que rediseñar el producto.

Si cualquiera de estos hechos inciertos se presenta, repercutirá en el costo, el programa y la

calidad del proyecto.

La administración de riesgos pretende reconocer y manejar aspectos problemáticos

potenciales e imprevistos que pueden darse cuando el proyecto se lleva a la práctica. La

administración de riesgos identifica tantos eventos de riesgo como es posible (lo que puede

ir mal), minimiza su efecto (lo que se puede hacer con respecto al evento antes de que el

proyecto se inicie), maneja las respuestas a los eventos que sí se materializan (planes de

contingencia) y suministra fondos de contingencia para cubrir eventos de riesgo que se

materializan.

7.1. PROCESO DE ADMINISTRACIÓN DE RIESGOS

La administración de riesgos es un enfoque proactivo y no reactivo. Es un proceso

preventivo diseñado para garantizar que las sorpresas se reduzcan y que se minimicen

las consecuencias negativas que se derivan de eventos indeseables. También prepara

al administrador de proyectos a aceptar riesgos cuando es posible tener una ventaja

técnica, o en tiempos y/o costos. La administración exitosa de los riesgos de un

proyecto le permite al administrador del proyecto controlar mejor el futuro y mejorar

 28

en forma significativa las probabilidades de cumplir a tiempo con los objetivos del

proyecto, dentro del presupuesto, y en cumplimiento del desempeño técnico

(funcional) requerido. Las fuentes de los riesgos del proyecto son ilimitadas. Hay

fuentes externas a la organización, como la inflación, la aceptación en el mercado, las

tasas de cambio y las regulaciones gubernamentales.

Los pasos que se deben tomar en cuenta para la administración de riesgos son:

7.1.1. Paso 1: Identificación del Riesgo

El proceso de administración del riesgo se inicia con el intento de generar una lista

de todos los posibles riesgos que podrían afectar al proyecto. En general, durante la

fase de planeación, el administrador del proyecto reúne a un equipo de administración

del riesgo que comprende a los miembros clave del equipo y otros interesados

importantes. El equipo recurre a la tormenta de ideas y otras técnicas de

identificación de problemas para distinguir las dificultades potenciales. Se alienta a

los participantes a mantener la mente abierta y generar tantos riesgos probables como

sea posible. Más de un proyecto ha fracasado por un evento que los miembros del

equipo consideraron inconcebible al principio.

Un error frecuente al comienzo del proceso de identificación de riegos es centrarse

en los objetivos y no en los eventos que podrían tener consecuencias. Por ejemplo,

los miembros del equipo pueden identificar como un riesgo importante el

incumplimiento del programa. Deben centrarse en los eventos que podrían causar

esto (digamos, estimados deficientes, clima negativo, retrasos en los embarques,

etc.).

Las organizaciones utilizan estructuras de descomposición del riesgo (EDR) junto

con otras de descomposición del trabajo (EDT) para ayudar a los equipos a identificar

y, por último, analizar los riesgos.

 29

Figura 5: La estructura de descomposición del riesgo (EDR), Fuente y tomado de A.A.

Gray & B.B. Larson. Administracion de Proyectos. Editorial MC Grau-Hill,
México 2009, pp 184

Un perfil de riesgos es otra herramienta útil. Éste consiste en una lista de preguntas

que cubre áreas tradicionales de incertidumbre en un proyecto. Las preguntas se han

desarrollado y perfeccionado a partir de lo sucedido en proyectos similares.

Figura 6: Perfil de riesgo parcial para el proyecto de desarrollo del producto (EDR), Fuente y
tomado de A.A. Gray & B.B. Larson. Administracion de Proyectos. Editorial MC
Grau-Hill, México 2009, pp 185
 30

El proceso de identificación de riesgos no debe limitarse al equipo central. Debe

solicitarse la opinión de los clientes, patrocinadores, subcontratistas, proveedores y

otros individuos interesados en el proyecto. Entre éstos, es posible entrevistar de

manera formal a los más importantes o incluirlos en el equipo de administración de

riesgos. Estos jugadores no sólo tienen una perspectiva valiosa, sino que al

involucrarlos en el proceso administrativo también se comprometerán más con el

éxito del proyecto.

7.1.2. Paso 2: Evaluación del Riesgo

En el paso 1 se produce una lista de los riesgos potenciales. Y no todos merecen

que se les preste atención. Algunos son triviales y puede ignorárseles, mientras que

otros representan amenazas importantes para el bienestar del proyecto. Los

administradores de proyecto deben desarrollar métodos para discriminar algunos de

los riesgos enumerados, eliminar los redundantes y los que no tienen consecuencias,

y ordenar a los importantes en términos de su importancia y su necesidad de

atención.

El análisis de escenarios constituye la técnica más sencilla y de uso más común en

el análisis de riesgos. Los miembros del equipo valoran la importancia de cada

evento de riesgo en términos de lo siguiente:

 Probabilidad del evento.

 Impacto del evento.

En pocas palabras, es necesario evaluar los riesgos en términos de la

probabilidad de que éste se presente y en su impacto o consecuencias. El riesgo de

que a un administrador de proyecto le caiga un rayo en el sitio de trabajo tendría un

efecto negativo importante en el proyecto, pero la probabilidad de que esto ocurra

 31

es tan baja que no vale la pena considerarlo. A la inversa, las personas cambian de

trabajo, por lo que un evento como la pérdida de personal clave tendría no sólo una

consecuencia adversa, sino también una alta probabilidad de presentarse en algunas

organizaciones. Si así sucediera, entonces sería inteligente que la organización

fuera proactiva y mitigara este riesgo al desarrollar esquemas de incentivos para

conservar especialistas y/o promover capacitación cruzada para reducir el efecto de

una rotación de personal.

En la figura 4 se proporciona un ejemplo de la manera en que las escalas de impacto

pueden definirse dados los objetivos de costo, tiempo, enfoque y calidad del

proyecto.

Figura 7. Condiciones definidas para las escalas de impacto de un riesgo en los objetivos más
importantes de un proyecto (sólo se incluyeron ejemplos para los impactos negativos),
Fuente y tomado de A.A. Gray & B.B. Larson. Administracion de Proyectos. Editorial
MC Grau-Hill, México 2009, pp 186

En la fi gura 5 se incluye un ejemplo parcial de la forma de evaluación de riesgos que

se utilizó en un proyecto IS que involucraba actualizar el Windows Office a Windows

Vista.
 32

Figura 8: Forma de evaluación del riesgo, Fuente y tomado de A.A. Gray & B.B. Larson.
Administracion de Proyectos. Editorial MC Grau-Hill, México 2009, pp 186

Observe que, además de evaluar la gravedad y la probabilidad de los eventos de

riesgo, el equipo debe valorar también cuándo puede presentarse el evento y cuáles

serán las dificultades para detectarlo. Esto último constituye una medida de qué tan

fácil sería detectar que el evento iba a presentarse en términos de tomar acciones para

mitigarlo, es decir, ¿cuánto cuidado debiéramos tener? A menudo las organizaciones

encuentran útil categorizar la gravedad de los diversos riesgos en alguna forma de

matriz de evaluación de los riesgos. La matriz se estructura en forma típica en torno al

impacto y a la probabilidad de un evento de riesgo. Por ejemplo, la que se presenta en

la fi gura 6 es una disposición 5 × 5 de los elementos, donde cada uno representa un

conjunto distinto de valores de impacto y probabilidad.

 33

Figura 9: Forma de evaluación del riesgo, Fuente y tomado de A.A. Gray & B.B. Larson.
Administración de Proyectos. Editorial MC Grau-Hill, México 2009, pp 186

7.1.3. Paso 3: Desarrollo de la Respuesta al Riesgo

Cuando se identifica y se evalúa un evento de riesgo, debe tomarse una decisión

acerca de la respuesta adecuada para el suceso específico. La respuesta al riesgo

puede clasificarse como mitigadora, de omisión, de transferencia, de distribución o

de retención.

i) Mitigación del Riesgo. En general, la reducción del riesgo es la primera

alternativa considerada. Sobre todo hay dos estrategias para mitigar el riesgo:

1) reducir la probabilidad de que el evento se presente y/o 2) disminuir el

efecto que el evento adverso podría tener en el proyecto. La mayoría de los

equipos de riesgo se centran primero en reducir la probabilidad de los eventos

de riesgo ya que, de tener éxito, pueden eliminar la necesidad de considerar

 34

la segunda estrategia, potencialmente costosa. A menudo, la comprobación y

la elaboración de un prototipo pueden utilizarse para evitar que surjan

problemas más adelante en un proyecto. Un ejemplo de comprobación puede

encontrarse en un proyecto de sistemas de información. El equipo del

proyecto era el responsable de instalar un nuevo sistema operativo en su

empresa matriz. Antes de poner el proyecto en práctica, el equipo probó el

nuevo sistema en una red aislada más pequeña. Al hacerlo descubrieron una

diversidad de problemas y pudieron obtener soluciones antes de la ejecución.

El equipo todavía se topó con algunos problemas de instalación, pero su

cantidad y gravedad se redujeron mucho.

ii) Omisión del Riesgo. Omitir el riesgo es modificar el plan del proyecto para

eliminar la contingencia o situación. Aunque resulta imposible eliminar todos

los eventos de riesgo, es posible evitar algunos peligros específicos antes de

iniciar el proyecto. Por ejemplo, la adopción de tecnología probada y no la

experimental puede excluir las fallas técnicas. Elegir un proveedor australiano y

no uno de Indonesia descartaría casi por completo las posibilidades de que una

crisis política interrumpa el suministro de materiales básicos.

iii) Transferencia del Riesgo. Es común transferir el riesgo a otra parte; este traslado

no cambia el riesgo. Hacerlo casi siempre resulta en que se paga una prima por

esta exención. Los contratos de precio fijo son el ejemplo clásico de transferir el

riesgo de un propietario a un contratista. Este último entiende que su empresa

pagará cualquier evento de riesgo que se materialice; por lo tanto, se añade un

factor de riesgo monetario al precio de la licitación. Antes de decidir la

transferencia del riesgo, el propietario debe determinar qué partido puede

controlar mejor las actividades, lo cual conduciría al riesgo. Además, ¿puede el

 35

contratista absorberlo? Es imperativo identificar y documentar la

responsabilidad para la absorción del riesgo. Una manera más obvia de transferir

el riesgo es un seguro. Sin embargo, en general esto es poco práctico porque

resulta difícil y caro definir el evento de riesgo del proyecto y esto lo condiciona

a que un corredor de seguros, que no conoce el proyecto, lo haga. Por supuesto,

es más fácil definir y obtener un seguro para los eventos de riesgo de poca

probabilidad y grandes consecuencias. Otros instrumentos financieros para

trasladar riesgos son los bonos por desempeño y las garantías de diversos tipos.

iv) Distribución del Riesgo. Al distribuirlo se asignan proporciones del riesgo a

distintas partes. Un ejemplo de distribución del riesgo se dio con el Airbus A340.

Se repartieron riesgos para investigación y desarrollo a países europeos como

Gran Bretaña y Francia. Por otro lado, la industria del entretenimiento formó un

consorcio para definir un formato común de operación para el disco de video

digital (DVD, Digital Video Disk) a fin de garantizar la compatibilidad entre

productos. Están surgiendo otras formas de distribuir riesgos.

También se ha usado la distribución del riesgo para reducir los costos de los

proyectos y fomentar la innovación.

v) Retención del Riesgo. En algunos casos se toma una decisión de aceptar el riesgo

de que ocurra un evento. Algunos riesgos son tan grandes que no es posible

considerar una transferencia o una reducción del evento (por ejemplo, un

terremoto o una inundación). El propietario del proyecto asume el riesgo porque

las probabilidades de que un evento así se presente son escasas. En otros casos,

los riesgos que se identifican en la reserva del presupuesto pueden absorberse si

se materializan. El riesgo se retiene al desarrollar un plan de contingencia para

el momento en que el primero se realice. En algunos casos es posible ignorar un

 36

evento de riesgo y aceptar un excedente en los costos si el evento se presenta.

Mientras mayor esfuerzo se haga para responder al riesgo antes de que el

proyecto se inicie, mayores serán las posibilidades de minimizar sorpresas en el

proyecto. Al saber que la respuesta a un evento se retendrá, transferirá o

compartirá, se elimina mucho estrés e incertidumbre cuando se presenta el

evento de riesgo. De nuevo, es posible mantener el control con este enfoque

estructurado.

7.2. Planeación Para Contingencias

Un plan de contingencias es una alternativa que se utilizará si un evento de riesgo

previsto y posible se convierte en realidad.

Figura 10: Matriz de respuesta al riesgo, Fuente y tomado de A.A. Gray & B.B. Larson.
Administración de Proyectos. Editorial MC Grau-Hill, México 2009, pp 193

Las matrices de respuesta a los riesgos, como la que se muestra en la fi gura 7 son

útiles para resumir de qué manera el equipo del proyecto planea manejar los riesgos

que se han identificado.

 37

A continuación se analizan algunos de los métodos más comunes para la

administración de riesgos.

i) Riesgos Técnicos. Los riesgos técnicos son problemáticos; a menudo

pueden propiciar la cancelación del proyecto. ¿Qué pasa si el proceso

o el sistema no funcionan? Se elaboran planes de contingencia o

respaldo para esas posibilidades impredecibles. Por ejemplo, Carrier

Transicold participó en el desarrollo de una nueva unidad Phoenix de

refrigeración para aplicaciones en camiones y tractocamiones. Esta

nueva unidad tendría que utilizar paneles redondos hechos de metales

especiales, lo que en ese momento era una nueva tecnología para

Transicold. Además, uno de sus competidores había intentado, sin

éxito, incorporar metales especiales similares en sus productos. El

equipo de proyecto estaba dispuesto a lograr que la nueva tecnología

funcionara, pero no fue sino hasta el final del proyecto que pudieron

lograr que los nuevos adhesivos pegaran de manera adecuada para

completar el proyecto. En el proceso, el equipo mantuvo un enfoque

de fabricación de paneles soldados, en caso de que no tuvieran éxito.

Si se hubiera necesitado este enfoque de contingencias, los costos de

producción se hubieran incrementado; pero, de cualquier manera, el

proyecto se hubiera terminado a tiempo.

Además de las estrategias de respaldo, los administradores de proyectos

necesitan desarrollar métodos para valorar pronto si se pueden resolver las

incertidumbres técnicas. El uso de programas complejos de CAD ha ayudado

mucho a solucionar problemas de diseño.

 38

ii) Riesgos de Programación. Muchas veces, las organizaciones difieren

la amenaza de retrasos en el proyecto hasta que ésta se hace evidente.

Aquí se apartan los fondos de contingencia para acelerar o “forzar” el

proyecto a fin de que éste “vuelva al redil”. Lo segundo, que es reducir

la duración del proyecto, se logra acortando (comprimiendo) una o

más actividades en la ruta crítica. Esto viene con costos y riesgo

adicionales.

iii) Riesgos de Costos. En los proyectos de larga duración es necesario

tener alguna contingencia para los cambios de precio, que por lo

general son al alza. El aspecto importante a recordar cuando se revisan

los precios es evitar la trampa de utilizar una suma fuerte para cubrir

el riesgo de que éstos aumenten. Por ejemplo, si la inflación ha estado

cerca de 3 por ciento, algunos gerentes añaden 3 por ciento a todos

los recursos que se utilizan en el proyecto.

iv) Riesgos de Fondeo. ¿Qué pasa si el fondeo para el proyecto se reduce

25 por ciento o las proyecciones para la terminación señalan que los

costos superarán mucho a los fondos disponibles? ¿Cuáles son las

probabilidades de que el proyecto se cancele antes de que concluya?

Los administradores de proyecto con experiencia reconocen que en

una evaluación completa de los riesgos se debe incluir una evaluación

del suministro de fondos. Esto es en particular cierto para los

proyectos que se financian con fondos públicos. Un ejemplo es el

helicóptero Comanche RAH-66, que tan mala suerte encontró y que

estaban desarrollando la Sikorsky Aircraft Corp., y la Boeing Co.,

para la armada estadounidense. Se habían invertido 8 000 millones de

 39

dólares para desarrollar un helicóptero de combate y reconocimiento

de avanzada cuando, en febrero de 2004, el Departamento de Defensa

recomendó que el proyecto fuera cancelado. Esta situación reflejaba

la necesidad de reducir costos y un cambio en el uso de aeronaves no

tripuladas para las misiones de reconocimiento y ataque.

Así como los proyectos del gobierno están sujetos a modificaciones de

estrategia y agenda política, las empresas de negocios a menudo

experimentan cambios en sus prioridades y en la alta dirección. Los proyectos

predilectos del nuevo director general sustituyen a los del anterior. Los

recursos se hacen escasos y una forma de financiar proyectos nuevos es

cancelando otros.

7.2.1. Fondos de Contingencia y Amortiguadores del Tiempo

Los fondos de contingencia se establecen para cubrir los riesgos

identificados y desconocidos de un proyecto. No se sabe cuándo, dónde y

cuánto dinero se gastará hasta que se presente el evento de riesgo. A

menudo, los “propietarios” del proyecto no están dispuestos a designar

fondos de contingencia para un proyecto que impliquen que el plan de éste

puede ser deficiente. Algunos perciben que el fondo de contingencia añade

una carga más. Otros afirman que permitirá hacerle frente al riesgo cuando

éste se materialice. En general, dicha renuencia a establecer reservas para

contingencias puede superarse al documentar la identificación del riesgo, su

valoración, los planes de contingencia y para el desembolso de los fondos.

i) Reservas presupuestarias. Estas reservas se identifican para

paquetes específicos de tareas o segmentos de un proyecto; se ubican

 40

en el presupuesto de base o en la estructura de descomposición del

trabajo. Por ejemplo, quizás sea posible añadir una cantidad de

reserva a la “programación de código de computadora” para cubrir

el riesgo de que la “ejecución del programa” muestre un problema

de código.

ii) Reservas de administración. Se necesitan fondos de reserva para cubrir

los principales riesgos no previstos y, de esta manera, se aplican a todo

el proyecto. Por ejemplo, quizá sea necesario modificar el enfoque a

medio camino. Como no se anticipó ni identificó este cambio, está

cubierto con la reserva de administración. Las reservas de

administración se establecen después de que se identifican las reservas

presupuestarias y se establecen los fondos. Las primeras son

independientes de las reservas presupuestarias y están controladas por

el administrador y el “propietario” del proyecto. Éste puede ser interno

(alta dirección) o externo a la organización del proyecto. La mayoría de

las reservas administrativas se establecen con datos históricos y juicios

relativos al carácter único y a la complejidad del proyecto.

iii) Amortiguadores de tiempo. Así como se establecen fondos de

contingencia para absorber costos no previstos, los gerentes utilizan los

amortiguadores de tiempo para prepararse ante retrasos potenciales en

el proyecto. Y al igual que los fondos de contingencia, la cantidad de

tiempo depende de la incertidumbre inherente al proyecto. Mientras

mayor sea la incertidumbre del proyecto, más tiempo deberá reservarse

para el programa. La estrategia consiste en asignar tiempo extra en los

 41

momentos críticos del proyecto. Por ejemplo, se añaden amortiguadores

a:

a. Actividades con riesgos graves.

b. Actividades de fusión que están expuestas a retrasos debido a

que alguna o varias de las actividades precedentes terminan

después de lo programado.

c. Actividades no críticas para reducir la probabilidad de que den

origen a otra ruta crítica.

d. Actividades que necesitan recursos escasos para garantizar que

éstos existan cuando se les necesita.

7.3. Paso 4: Control de Respuesta al Riesgo

El último paso en el proceso de administración de riesgos es el control de éstos; es

decir, ejecutar la estrategia de respuesta al riesgo, supervisar los eventos que lo

desatan, iniciar planes de contingencia y estar preparado para nuevos riesgos. El

establecimiento de un sistema de administración del cambio para manejar los

eventos que necesitan modificaciones formales de alcance, presupuesto y/o

programación del proyecto es un elemento esencial en el control de riesgos. Los

administradores de proyectos deben supervisar los riesgos de la misma manera en

que vigilan el avance del proyecto. La evaluación de los riesgos y la actualización

de las necesidades deben ser parte de todas las reuniones de estado y del sistema de

reporte de avance. El equipo del proyecto necesita estar siempre alerta para detectar

riesgos nuevos e imprevistos. La administración debe ser sensible a que los demás

no omitan riesgos y problemas nuevos. Cuando se admite que puede haber un virus

en el código de diseño o que los distintos componentes no son compatibles afecta

negativamente el desempeño individual.

 42

VIII. Conclusiones:

No podemos pedir exactitud a la fase de planificación, ya que es solo una idea de cómo van

a transcurrir las cosas. Sin embargo hay que planificar el trabajo, los recursos humanos y la

tecnología para obtener buenos resultados.

Para lograr un resultado final exitoso en el proyecto, es realmente necesario tener reuniones

permanentes dentro del equipo de trabajo, para así poder estar al tanto de sus fortalezas y

debilidades trabajando en equipo, además del avance continuo del proyecto, el cual estará

calendarizado adecuadamente para así no tener ningún inconveniente y evitar retrasos

inesperados.
 43

IX. Bibliografía:

 (2018). Recuperado de

http://informatica.uv.es/iiguia/2000/IPI/material/tema5.pdf

 Software, P. (2018). Planificación de proyectos de Software. Recuperado de

https://www.mindmeister.com/es/752793481/planificaci-n-de-proyectos-de-software

 (2016). Recuperado de http://informatica.uv.es/iiguia/2000/IPI/material/tema5.pdf

 (2019). Recuperado de

http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Admon_de_Proyectos_v2

_2.pdf

 (2017). Recuperado de

https://juanantonioleonlopez.files.wordpress.com/2017/05/administracion-de-

proyectos-4edi-gray.pdf

 (2015). Recuperado de

https://www.palermo.edu/economicas/cbrs/pdf/pbr12/BusinessReview12_02.pdf