TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE ACAPULCO

Carrera: Ingeniería en sistemas computacionales

Materia: Gestión de Proyectos

Profesora: Dra. Astudillo Hernández Carolina

Unidad 3: Planificación del proyecto

Alumna: N° de control:
Serrano Cruz Genesis Alexa 15321248

Hora: 08:00 – 09:00

Ciclo escolar: Agosto/Diciembre del 2018

Fecha de entrega: 14 de Octubre del 2018

i
 Índice

Introducción ___________________________________________________________ 1
3.1 Objetivo del proyecto ________________________________________________ 2
3.2 Estimaciones de tiempo _____________________________________________ 3
Jerarquía de Modelos COCOMO _______________________________________________ 3
3.3 Estimaciones de costos _____________________________________________ 4
3.4 Estimaciones de personal requerido __________________________________ 7
Modelo COCOMO Intermedio. _________________________________________________ 8
3.5 Análisis de riesgos _________________________________________________ 11
3.5.1 Tipos de riesgos _________________________________________________ 13
3.5.2 Identificación, Impacto y Proyección del riesgo _____________________ 16
3.5.3 Evaluación del riesgo _____________________________________________ 18
3.5.4 Estrategias frente al riesgo ________________________________________ 21
3.6 Análisis de la viabilidad del proyecto ________________________________ 22
Conclusión ___________________________________________________________ 23
Bibliografía ___________________________________________________________ 24

ii
 Introducción

Para la realización de una buena planeación de proyecto de software es elemental

conocer el análisis y síntesis de los conceptos más importantes sobre la gestión de
proyectos así como el personal que participa en el desarrollo de software.
La gestión de proyectos de software es una parte esencial de la ingeniería de
software. Los proyectos necesitan administrarse porque la ingeniería de software
profesional está sujeta siempre a restricciones organizacionales de presupuesto y
fecha. El trabajo del administrador del proyecto es asegurarse de que el proyecto
de software cumpla y supere tales restricciones, además de que entregue software
de alta calidad. La buena gestión no puede garantizar el éxito del proyecto. Sin
embargo, la mala gestión, por lo general, da como resultado una falla del proyecto:
el software puede entregarse tarde, costar más de lo estimado originalmente o no
cumplir las expectativas de los clientes.
Desde luego, los criterios de éxito para la gestión del proyecto varían de un proyecto
a otro, pero, para la mayoría de los proyectos, las metas importantes son:
1. Entregar el software al cliente en el tiempo acordado.
2. Mantener costos dentro del presupuesto general.
3. Entregar software que cumpla con las expectativas del cliente.
4. Mantener un equipo de desarrollo óptimo y con buen funcionamiento.
Tales metas no son únicas para la ingeniería de software, pero sí lo son para todos
los proyectos de ingeniería. Sin embargo, la ingeniería de software es diferente en
algunas formas a otros tipos de ingeniería que hacen a la gestión del software
particularmente desafiante.
La gestión de proyectos es una rama especializada en el campo de la gestión, cuya
evolución ha servido para coordinar y controlar algunas delas complejas actividades
de la industria moderna. No se trata, por supuesto, de un ejemplo aislado sobre una
habilidad en la gestión adquirida como resultado del reto presentado por el
desarrollo y la expansión industrial. De hecho, el fenómeno de la supervivencia
mediante la especialización, difícilmente pudo haberse originado en el mundo de la
industria y el comercio.

1
3.1 Objetivo del proyecto

Aplicar los conceptos sobre la gestión de proyectos al iniciar la planeación de un

proyecto de software adecuado al personal que colabora en tal proyecto.
Las metas a corto, mediano y largo plazo que se esperan alcanzar. Todo proyecto
debe tener claramente definidos sus objetivos en términos cuantitativos y
cualitativos, en forma tal que los responsables puedan utilizar instrumentos de
medición para poder confrontar las metas propuestas con las realmente alcanzadas
y, desde luego, aplicar correctivos en caso de desviaciones.
 Las actividades que se realizan para lograr los objetivos. Todo proyecto exige
un ordenamiento de las diferentes actividades que lo componen, desde la
generación de la idea hasta el momento de la puesta en marcha y operación
 Una localización espacial y geográfica claramente establecida.
 Su ubicación temporal; deslindando en lo posible los momentos de
preinversión, ejecución, puesta en marcha y operación.
 La magnitud de los recursos para ejecutarlo y ponerlo en funcionamiento.
Todo proyecto requiere recursos y por lo tanto precisa del montaje de un
sistema de monitoreo y control; el seguimiento de los proyectos se impone
con el fin de evitar costosas desviaciones en los recursos invertidos o
demoras significativas en los tiempos, que afecta necesariamente los costos
por vía de la inflación o el lucro cesante y costo de oportunidad al no iniciar
a tiempo las operaciones para producción de bienes o prestación de
servicios.
Desde hace algún tiempo se ve viene utilizando el término "CICLO DEL
PROYECTO" para señalar las diferentes etapas que recorre el proyecto desde que
se concibe la idea hasta que se materializa en una obra o acción concreta, estas
etapas son: la "preinversión", la "inversión" o "ejecución" y la etapa de
"funcionamiento" u "operación".
El proyecto insistimos se constituye en la unidad operativa del desarrollo (nacional,
regional, local e institucional), y se expresa como medio para la solución de
problemas; para atender necesidades sentidas de la población; como mecanismo
para la concertación y gestión de recursos (a través de los presupuestos); para la
coordinación de acciones interinstitucionales en actividades de interés común y,
desde luego, como instrumento de control de gestión que permita verificar la eficacia
social de los planes y programas.

Autor: Juan José Miranda Miranda

2
3.2 Estimaciones de tiempo

Los proyectos son constantemente utilizados dentro de la organización, esto,

porque constituyen el principal medio de crecimiento para ésta. Generalmente, los
proyectos han sido utilizados como un instrumento de “acción” para manejar
grandes inversiones en cualquier área de la organización. Por esto se busca una
forma práctica para estimar su esfuerzo y tiempo de ejecución, para así minimizar
la inversión.
Dado que la estimación del esfuerzo de un proyecto de software no es una ciencia
exacta, existen demasiadas variables humanas y técnicas influyendo y afectando al
producto final. Se trabajará sobre la base de Técnicas de Descomposición, de esta
manera se divide el problema en módulos pequeños más manejables que permitan
definir una estimación de tiempo, de cantidad de personas necesarias para llevar a
cabo el proyecto propuesto. La estimación de proyectos de software es una forma
de resolución de problemas y en la mayoría de los casos, el problema a resolver
(esto es desarrollar estimaciones de costo y de esfuerzo para un proyecto de
software), es demasiado complejo, por ello se debe separar en un conjunto de
pequeños problemas más manejables.
Jerarquía de Modelos COCOMO
La jerarquía de modelos COCOMO viene dada por el nivel de detalle empleado en
su utilización:
Modelo COCOMO básico: es un modelo univariable estático que calcula el
esfuerzo y el tiempo del desarrollo de software en función del tamaño del programa,
expresado en Líneas de Código (LDC) estimadas.
Las ecuaciones básicas del modelo se muestran en la Tabla 5.2.

Autor: Alejandro Bedini González

3
3.3 Estimaciones de costos

En todo proyecto existe un presupuesto asignado, el cual debe ser controlado y

respetado. Para realizar esto es necesario planificar adecuadamente el qué hacer,
por lo cual la primera actividad a realizar es la de estimar el costo del desarrollo, lo
que se realiza simultáneamente con la itineración.
Para estimar recursos, costo y tiempo en un proyecto de software se necesita
experiencia, acceso a información histórica y hacer uso de métricas cuantitativas
cuando existen los datos para ello. Las estimaciones tienen asociado en forma
inherente, un grado de riesgo e incertidumbre que incide en la probabilidad de éxito,
en la estimación y por ende en el resultado.

Los componentes principales de costos son:

 Hardware.
 Entrenamiento.
 Esfuerzo.
Existen siete técnicas posibles para estimar los costos del Software
 Modelos algorítmicos. Se utiliza un modelo basado en información histórica
que relaciona información histórica de costo con alguna métrica del proyecto.
 Juicio experto. El costo es obtenido por consenso de expertos en el
desarrollo. La experiencia debe ser en las tecnologías y aplicación a
desarrollar.
 Estimación por analogía. Se basa en el desarrollo previo de proyectos
similares.
 Ley de Parkinson. El trabajo se expande hasta llenar todo el tiempo
disponible.
 Precio para ganar. El costo se estima según el presupuesto disponible.
 Estimación top down. El costo se estima considerando la funcionalidad total
del producto y cómo ésta es provista por las subfunciones interactuantes. El
costo se basa en las funciones lógicas.
 Estimación bottom up. Se estima el costo de cada componente para luego
agregarse en un costo total.
Los factores que afectan a la estimación de un proyecto son básicamente dos: la
complejidad del proyecto y el tamaño del mismo. Al principio, el costo del software
constituía un pequeño porcentaje del costo total de los sistemas basados en
computadora. Un error considerable en las estimaciones del costo del software tenía
relativamente poco impacto. Hoy en día, el software es el elemento más caro de la
mayoría de los sistemas informáticos. Un gran error en la estimación del costo

4
puede ser lo que marque la diferencia entre beneficios y pérdidas. Sobrepasarse en
el costo puede ser desastroso para el equipo de desarrollo.
Desde un punto de vista ideal, se deben aplicar conjuntamente todas las técnicas
apropiadas, usando cada una de ellas como comprobación de las otras. Las
técnicas de descomposición utilizan un enfoque de «divide y vencerás» para la
estimación del proyecto de software.
Dentro de la mayor parte de las organizaciones, la estimación de costos se basa en
las experiencias pasadas. Los datos históricos se usan para identificar los factores
de costo y determinar la importancia relativa de los diversos factores dentro de la
organización. Lo anterior, por supuesto, significa que los datos de costos y
productividad de los proyectos actuales deben ser centralizados y almacenados
para un empleo posterior.
La estimación jerárquica hacia abajo se enfoca primero a los costos del nivel del
sistema, así como a los costos de manejo de la configuración, del control de calidad,
de la integración del sistema, del entrenamiento y de las publicaciones de
documentación. Los costos del personal relacionado se estiman mediante el
examen del costo de proyectos anteriores que resulten similares.
En la estimación jerárquica hacia arriba, primero se estima el costo del desarrollo
de cada módulo o subsistema; tales costos se integran para obtener un costo total.
Esta técnica tiene la ventaja de enfocarse directamente a los costos del sistema,
pero se corre el riesgo de despreciar diversos factores técnicos relacionados con
algunos módulos que se desarrollarán. La técnica subraya los costos asociados con
el desarrollo independiente de cada módulo o componente individual del sistema,
aunque puede fallar al no considerar los costos del manejo de la configuración o del
control de calidad.
En la práctica, ambas técnicas deben desarrollarse y compararse para que
iterativamente se eliminen las diferencias obtenidas.

En la Tabla 4.3 se muestran algunas de las variables para medir costos en proyectos
TI.

5
 Autor: Alejandro Bedini González

La estimación de los costos futuros constituye uno de los aspectos centrales del
trabajo del evaluador, tanto por la importancia de ellos en la determinación de la
rentabilidad del proyecto, como por la variedad de elementos sujetos a valorización
como desembolsos del proyecto. Lo anterior se explica, entre otras cosas, por el
hecho de que para definir todos los egresos, como los impuestos a las utilidades,
por ejemplo, se deberá proyectar previamente la situación contable sobre la cual
serán calculados. El objetivo es exponer los elementos fundamentales de la teoría
de costos y sus aplicaciones al campo del estudio de proyectos de inversión.

Autor: Nassir Sapag Chain y Reinaldo Sapag Chain

6
3.4 Estimaciones de personal requerido

Cabe destacar que las estimaciones relacionadas con el esfuerzo se expresan en

hombre-mes (tiempo que requeriría una sola persona para desarrollar el sistema),
considerando que la dedicación de una persona es de 152 horas al mes.

Donde el tamaño viene dado el KS, que corresponde a miles de líneas de código
fuente. Cabe mencionar que el número de personas empleadas en el proyecto a lo
largo de su desarrollo no es uniforme, el número medio de personas obtenido no
representa una cifra muy significativa, es decir, debe considerarse sólo como una
aproximación. Putnam (1978) establece que la forma óptima para asignar personal
en el proyecto es siguiendo una curva Rayleigh. La experiencia demuestra que no
es conveniente partir con mucha gente al inicio de éste.
De cualquier modo sería más conveniente analizar el personal requerido, en cada
etapa de desarrollo del proyecto, el cual también se comporta como una curva
Rayleigh para cada etapa como lo muestra la Figura 5.1:

7
En general el modelo de estimación nos entrega un orden de magnitud de la
cantidad de personal requerido para el desarrollo del proyecto, para esto, utiliza en
forma implícita la productividad estimada supuestamente obtenida de datos de
proyectos existentes. En el caso de proyectos orgánicos, la productividad es de 352
[LDC / h-m], lo que resulta en 16 [instrucciones / hd]. Para los proyectos integrados
la productividad implícita es de 105 [LDC / h-m], lo que resulta en cerca de 4
[instrucciones / h-d].

Modelo COCOMO Intermedio.

Este modelo es una versión ampliada del modelo Básico, en la que se presenta una
mayor precisión en las estimaciones, manteniendo prácticamente la misma
sencillez del anterior modelo. Esta mayor precisión viene dada por la
incorporación de 15 factores que reflejan la influencia de ciertos elementos
sobre el coste del software. Estos 15 factores se agruparon en cuatro grandes
grupos: Atributos del Producto, del Computador, del Personal y del Proyecto. Cada
uno de estos 15 atributos tiene asociado un factor multiplicador para estimar
el efecto de éste sobre el esfuerzo nominal. En la Tabla 5.4 se muestran las
ecuaciones del Esfuerzo Nominal.

Una vez obtenido el esfuerzo nominal, este debe multiplicarse por el producto de
la ponderación de los 15 atributos, ver Tabla 5.5.

8
 Tabla 5.5
La descripción de cada uno de ellos se muestra a continuación:
 Atributos del Producto
• Fiabilidad del Software: Indica las posibles consecuencias para el usuario en
el caso que todavía existan defectos en el producto. Una puntuación Muy
Baja indica que solamente hace falta eliminar los defectos sin ninguna otra
consecuencia mientras que una puntuación Muy Alta implica pérdidas de vidas
humanas.
• Tamaño de la Base de Datos: Un valor Bajo para este atributo significa que el
tamaño de la base de datos (en Bytes) es menor que 10*LDC. El valor Nominal
indica un tamaño entre 10 y 100 veces las LDC; un valor Muy Alto significa que la
base de datos es mayor que 1000 veces las LDC.
• Complejidad: El código de complejidad Baja usa operaciones de E/S,
estructuras de datos simples y codificación fácil. La complejidad Nominal

9
implica algún procesamiento de E/S, E/S de múltiples archivos, uso de rutinas
de biblioteca y comunicación ínter módulos. Complejidad Muy Alta implica el
uso de código recursivo, manejo de archivos complejos, procesamiento paralelo
y administración de datos complicada.
 Atributos del Computador
• Restricciones de tiempo de ejecución: Siempre será más exigente para un
programador escribir un programa que tiene una restricción en el tiempo de
ejecución. Esta puntuación se expresa en el porcentaje de tiempo de ejecución
disponible. Es Nominal cuando el porcentaje es el 50%, y Extremadamente Alto
cuando la restricción es del 95%.
• Restricciones de memoria virtual: Se espera que un cierto porcentaje del
almacenamiento principal sea utilizado por el programa. El esfuerzo de
programación se incrementa si el programa tiene que correr en un volumen
menor del almacenamiento principal. El esfuerzo extra de Nominal se presenta
cuando la reducción del almacenamiento principal es del 50% y Extremadamente
Alto indica una reducción del 95%.
• Volatilidad de la máquina virtual: Durante el desarrollo del software la máquina
virtual (combinación de hardware y software) en la que el programa se va a
desarrollar puede sufrir algunos cambios.
• Tiempo de respuesta: Cuanto menor sea el tiempo de respuesta requerido,
más alto será el esfuerzo humano.
 Atributos del Personal
• Capacidad de análisis: La capacidad del grupo de analistas, en términos de
habilidad de análisis, eficiencia y capacidad para cooperar tiene un impacto
significativo en el esfuerzo humano. Cuanto más capaz sea el grupo, menos
esfuerzo será necesario.
• Experiencia en aplicación: La experiencia del grupo en una aplicación similar
tiene una gran influencia en el esfuerzo. Los tiempos de experiencia para los
distintos niveles se muestran en la Tabla 5.6.

Autor: Alejandro Bedini González

10
3.5 Análisis de riesgos

Durante el proceso de análisis de riesgos, hay que considerar cada riesgo

identificado y realizar un juicio acerca de la probabilidad y gravedad de dicho riesgo.
No hay una forma sencilla de hacer esto. Usted debe apoyarse en su propio juicio y
en la experiencia obtenida en los proyectos anteriores y los problemas que surgieron
en ellos. No es posible hacer valoraciones precisas y numéricas de la probabilidad
y gravedad de cada riesgo. En vez de ello, habrá que asignar el riesgo a una de
ciertas bandas:
1. La probabilidad del riesgo puede valorarse como muy baja (< 10%), baja (del 10
al 25%), moderada (del 25 al 50%), alta (del 50 al 75%) o muy alta (> 75%).
2. Los efectos del riesgo pueden estimarse como catastróficos (amenazan la
supervivencia del proyecto), graves (causarían grandes demoras), tolerables
(demoras dentro de la contingencia permitida) o insignificantes.
Luego hay que tabular los resultados de este proceso de análisis mediante una tabla
clasificada de acuerdo con la gravedad del riesgo. Desde luego, aquí la valoración
de la probabilidad y seriedad son arbitrarias. Para hacer esta valoración, se necesita
información detallada del proyecto, el proceso, el equipo de desarrollo y la
organización.
Desde luego, tanto la probabilidad como la valoración de los efectos de un riesgo
pueden cambiar conforme se disponga de más información acerca del riesgo y a
medida que se implementen planes de gestión del riesgo.
Por lo tanto, esta tabla se debe actualizar durante cada iteración del proceso de
riesgo. Una vez analizados y clasificados los riesgos, valore cuáles son los más
significativos. Su juicio debe depender de una combinación de la probabilidad de
que el riesgo surja junto con los efectos de dicho riesgo. En general, los riesgos
catastróficos deben considerarse siempre, así como los riesgos graves con más de
una probabilidad moderada de ocurrencia.

11
Figura 22.4 Tipos de riesgos y ejemplos:

Boehm (1988) recomienda identificar y monitorizar los 10 riesgos principales, pero

considera que esta cifra es más bien arbitraria. El número correcto de riesgos a
monitorizar debe depender del proyecto. Pueden ser cinco o 15. Sin embargo, el
número de riesgos elegidos para monitorizar debe ser manejable. Un número de
riesgos muy grande requeriría recopilar demasiada información, es adecuado
considerar los ocho riesgos que tienen consecuencias catastróficas o graves (figura
22.5).

Autor: Ian Sommerville

12
3.5.1 Tipos de riesgos

1. Riesgos del proyecto: Los riesgos que alteran el calendario o los recursos del
proyecto. Un ejemplo de riesgo de proyecto es la renuncia de un diseñador
experimentado. Encontrar un diseñador de reemplazo con habilidades y experiencia
adecuadas puede demorar mucho tiempo y, en consecuencia, el diseño del software
tardará más tiempo en completarse.
2. Riesgos del producto: Los riesgos que afectan la calidad o el rendimiento del
software a desarrollar. Un ejemplo de riesgo de producto es la falla que presenta un
componente que se adquirió al no desempeñarse como se esperaba. Esto puede
afectar el rendimiento global del sistema, de modo que es más lento de lo previsto.
3. Riesgos empresariales: Riesgos que afectan a la organización que desarrolla
o ad- quiere el software. Por ejemplo, un competidor que introduce un nuevo
producto es un riesgo empresarial. La introducción de un producto competitivo
puede significar que las suposiciones hechas sobre las ventas de los productos de
software existentes sean excesivamente optimistas.
Desde luego, estos tipos de riesgos se traslapan. Si un programador experimentado
abandona un proyecto, esto puede ser un riesgo del proyecto porque, incluso si se
sustituye de manera inmediata, el calendario se alterará. Siempre se requiere
tiempo para que un nuevo miembro del proyecto comprenda el trabajo realizado, de
manera que no puede ser inmediatamente productivo. En consecuencia, la entrega
del sistema podría demorarse. La salida de un miembro del equipo también puede
ser un riesgo del producto, porque un sustituto tal vez no sea tan experimentado y,
por lo tanto, podría cometer errores de programación. Finalmente, puede ser un
riesgo empresarial, porque la experiencia de dicho programador es vital para
obtener nuevos contratos.
Es necesario registrar los resultados del análisis del riesgo en el plan del proyecto,
junto con un análisis de consecuencias, que establece las consecuencias del riesgo
para el proyecto, el producto y la empresa. La gestión de riesgos efectiva facilita
hacer frente a los problemas y asegurar que éstos no conduzcan a un presupuesto
inaceptable o a retrasos en el calendario. Los riesgos específicos que podrían
afectar un proyecto dependen del proyecto y el entorno de la organización donde
se desarrolla el software. Sin embargo, también existen riesgos comunes que no se
relacionan con el tipo de software a desarrollar y que pueden ocurrir en cualquier
proyecto.
La gestión del riesgo es particularmente importante para los proyectos de software,
debido a la incertidumbre inherente que enfrentan la mayoría de proyectos. Ésta se
deriva de requerimientos vagamente definidos, cambios de requerimientos que
obedecen a cambios las necesidades del cliente, dificultades en estimar el tiempo y
los recursos requeridos para el desarrollo de software, o bien, se deriva de

13
diferencias en las habilidades individuales. Es necesario anticipar los riesgos;
comprender el efecto de estos riesgos sobre el proyecto, el producto y la empresa;
y dar los pasos adecuados para evitar dichos riesgos. Tal vez se necesite diseñar
planes de contingencia de manera que, si ocurren los riesgos, se puedan tomar
acciones inmediatas de recuperación.
En la figura 22.1 se muestran algunos de estos riesgos comunes.

En la figura 22.2 se ilustra una idea general del proceso de gestión del riesgo.

Comprende varias etapas:

1. Identificación del riesgo Hay que identificar posibles riesgos para el proyecto, el
producto y la empresa.
2. Análisis de riesgos Se debe valorar la probabilidad y las consecuencias de dichos
riesgos.
3. Planeación del riesgo Es indispensable elaborar planes para enfrentar el riesgo,
evitarlo o minimizar sus efectos en el proyecto.
4. Monitorización del riesgo Hay que valorar regularmente el riesgo y los planes
para atenuarlo, y revisarlos cuando se aprenda más sobre el riesgo.

14
Es preciso documentar los resultados del proceso de gestión del riesgo en un plan
de gestión del riesgo. Éste debe incluir un estudio de los riesgos que enfrenta el
proyecto, un análisis de dichos riesgos e información de cómo se gestionará el
riesgo cuando es probable que se convierta en un problema. El proceso de gestión
del riesgo es un proceso iterativo que continúa a lo largo del proyecto. Una vez
desarrollado un plan de gestión del riesgo inicial, se monitoriza la situación para
detectar riesgos emergentes. Conforme está disponible más información referente
a los riesgos, habrá que volver a analizar los riesgos y decidir si cambió la prioridad
del riesgo. Entonces tal vez sea necesario cambiar los planes para evitar el riesgo
y gestionar la contingencia.

Figura 22.2 El proceso de gestión del riesgo

Autor: Ian Sommerville

Los riesgos vienen en todos los sabores (chocolate, vainilla y fresa) y todos los
sabores que se pueda imaginar. Algunos riesgos son obvios; otros, puede
conocerlos, pero no tienen una buena comprensión de su impacto; y hay riesgos
que no los conoce. Obviamente, no puede identificar los riesgos que no conocer
porque, por definición, no sabe lo que son.
Los riegos no solo vienen en todos los sabores; pueden ocurrir tanto en la
organización y fuera de la organización.
Los riegos internos surgen debido a la naturaleza del propio proyecto, las
decisiones o cambios de gestión, los problemas de organización, los problemas de
presupuestarios y los problemas de recursos.
Los riesgos externos ocurren también por muchas razones, como el clima, asuntos
jurídicos, problemas de mercado, el cronograma, las preocupaciones sociales, las
cuestiones medioambientales y cambios en las organizaciones de los proveedores.

Autor: Luis Angulo Aguirre

15
3.5.2 Identificación, Impacto y Proyección del riesgo

La identificación del riesgo es la primera etapa del proceso de gestión del riesgo.
Se ocupa de identificar los riesgos que pudieran plantear una mayor amenaza al
proceso de ingeniería de software, al software a desarrollar, o a la organización que
lo desarrolla. La identificación del riesgo puede ser un proceso de equipo en el que
este último se reúne para pensar en posibles riesgos. O bien, el administrador del
proyecto, con base en su experiencia, identifica los riesgos más probables o críticos.
Como punto de partida para la identificación del riesgo, se recomienda utilizar una
lista de verificación de diferentes tipos de riesgo. Existen al menos seis tipos de
riesgos que pueden incluirse en una lista de verificación:
1. Riesgos tecnológicos: Se derivan de las tecnologías de software o hardware
usadas para desarrollar el sistema.
2. Riesgos personales: Se asocian con las personas en el equipo de desarrollo.
3. Riesgos organizacionales: Se derivan del entorno organizacional donde se
desarrolla el software.
4. Riesgos de herramientas: Resultan de las herramientas de software y otro
software de soporte que se usa para desarrollar el sistema.
5. Riesgos de requerimientos: Proceden de cambios a los requerimientos del cliente
y del proceso de gestionarlos.
6. Riesgos de estimación: Surgen de las estimaciones administrativas de los
recursos requeridos para construir el sistema.
La identificación de los riesgos es un intento sistemático encaminado a especificar
las amenazas al plan del proyecto (estimaciones, calendarización, carga de
recursos, etc.). Al identificar los riesgos conocidos y predecibles, el gestor del
proyecto da un primer paso para evitarlos cuando es posible y a controlarlos cuando
es necesario.
Existen dos tipos distintos de riesgos para cada una de las categorías que se han
presentado. Los riesgos genéricos y los riesgos específicos del productor. Los
riesgos genéricos son una amenaza potencial para todo el proyecto de software.
Los riesgos específicos del producto los pueden identificar sólo aquellos con un
claro conocimiento de la tecnología, el personal y el entorno especifico del software
que se construirá. Los riesgos específicos del producto se identifican examinando
el plan del proyecto y la declaración del ámbito del software, así como desarrollando
una respuesta para la siguiente pregunta - ¿Qué características especiales de este
producto podrían amenazar el plan del proyecto?

16
La figura 22.3 brinda algunos ejemplos de posibles riesgos en cada una de
estas categorías.
Al concluir el proceso de identificación de riesgos, se tendrá una larga lista de
eventualidades que podrían ocurrir y afectar al producto, al proceso y a la empresa.
Entonces se necesita reducir esta lista a un tamaño razonable. Si existen
demasiados riesgos, será prácticamente imposible seguir la huella de todos ellos.

El proceso de planeación del riesgo considera cada uno de los riesgos clave
identificados y desarrolla estrategias para manejarlos. Para cada uno de los
riesgos, usted debe considerar las acciones que puede tomar para minimizar la
perturbación del proyecto si se produce el problema identificado en el riesgo.
También debe pensar en la información que tal vez necesite recopilar mientras
observa el proyecto para que pueda anticipar los problemas.

17
 Figura 22.5 Estrategias para gestionar el riesgo

Nuevamente, no hay un proceso simple que pueda seguirse para la planeación de

contingencias. Se apoya en el juicio y la experiencia del administrador del proyecto.
La figura 22.5 muestra posibles estrategias de gestión del riesgo que se identificaron
como los principales riesgos
Autor: Ian Sommerville

3.5.3 Evaluación del riesgo

La evaluación del riesgo consiste en analizar cada riesgo que ha identificado para
determinar que probabilidad de ocurrencia tiene el riesgo y qué impacto tendrá esto
en caso de ocurrir. El objetivo final de la evaluación de riesgos consiste en
determinar qué riesgos tienen planes de respuesta.
Después de analizar cada riesgo en la lista, se va a decidir cuáles planes basados
en su puntuación de riesgo. Antes de entrar en las técnicas de análisis, se tiene que
entender los niveles de tolerancia al riesgo de su organización.
Autor: Luis Angulo Aguirre

Tres factores afectan las consecuencias que son probables si un riesgo ocurre su
naturaleza, ámbito y tiempo. La naturaleza indica los problemas que son probables
si ocurre. Por ejemplo, una interfaz externa mal definida hacia el hardware del
cliente (un riesgo técnico) evitará un diseño y prueba tempranos y tal vez genere
problemas de integración del sistema más tarde. El ámbito combina la severidad

18
(¿Cuan serio es?) con su distribución global (¿Cuánto del proyecto se afectará,
cuántos clientes resultaran dañados?). Finalmente, el tiempo de un riesgo considera
cuándo y durante qué periodo se sentirá el impacto. En la mayoría de los casos un
gestor de proyectos tal vez quiera que ocurran las “malas noticias” tan pronto como
sea posible pero en algunos casos, mientras mayor sea la demora, mejor.
Regresando una vez más al enfoque de análisis de riesgo que propuso la Fuerza
Aérea de Estados Unidos [AFC88], se recomiendan los siguientes pasos para
determinar las consecuencias globales de un riesgo:
1. Determinar el valor promedio de la probabilidad de que ocurra para cada
componente de riesgo.
2. Determinar el impacto para cada componente, con base en los criterios
mostrados.
3. Completar la tabla de riesgos y analizar los resultados como se describe en
las secciones procedentes.
La exposición al riesgo global, ER, se determina mediante la siguiente relación
[HAL98]: ER = P X C
Donde P es la probabilidad de que ocurra un riesgo, y C, el costo al proyecto en
caso de que ocurra el riesgo.
Por ejemplo, suponga que el equipo de software define un riesgo de proyecto en la
forma siguiente:
Identificación del riesgo. De hecho solo 70 por ciento de los componentes de
software calendarizados para reutilización se integra en la aplicación. La
funcionalidad restante tendrá que desarrollarse de modo personalizado.
Probabilidad de riesgo. 80 por ciento (quizá).
Impacto del riesgo. Se planificaron 60 componentes de software reutilizables. Si
sólo se puede emplear el 70 por ciento, 18 componentes tendrían que desarrollarse
desde cero (además de otro software personalizado que se ha calendarizado para
desarrollo). Puesto que el componente promedio es 100 LDC y los datos locales
indican que el costo de ingeniería del software para cada uno es de 14 000 dólares,
el costo (impacto) global del desarrollo de los componentes seria 18x 100 x 14 = 25
200 dólares.
Exposición al riesgo. ER =0.80 X 25 200 dólares = 20 200 dólares.

Evaluación del riesgo global del proyecto

Las siguientes preguntas se basan en los datos de riesgo obtenidos al entrevistar,
en diferentes partes del mundo, a gestores de proyecto de software experimentados

19
[KE198]. Las preguntas están ordenadas según su importancia relativa en el éxito
de un proyecto.
1. ¿Los altos ejecutivos de software y del cliente se han comprometido
formalmente para apoyar el proyecto?
2. ¿Los usuarios finales están comprometidos con el proyecto y el
sistema/producto que se construirá?
3. ¿Los requisitos los han entendido completamente el equipo de ingeniería de
software y sus clientes?
4. ¿Los clientes estuvieron completamente involucrados en la definición de los
requisitos?
5. ¿Los usuarios finales tienen expectativas realistas?
6. ¿El ámbito del proyecto es estable?
7. ¿El equipo de ingeniería del software tiene la mezcla correcta de
habilidades?
8. ¿Los requisitos del proyecto son estables?
9. ¿El equipo del proyecto tiene experiencia con la tecnología que se
implementará?
10. ¿El número de personas en el equipo de proyecto es adecuado para realizar
el trabajo?
11. ¿Todos los votantes del cliente/usuario están de acuerdo en la importancia
del proyecto y en los requisitos para el sistema/producto que se construirá?
Si la respuesta a alguna de estas preguntas es negativa se deben instituir sin
demora los pasos de reducción, supervisión y gestión. El grado en el que el proyecto
está en riesgo es directamente proporcional al número de respuestas negativas a
estas preguntas.
Autor: Pressman, S. Roger.

La evaluación del riesgo del proyecto es una actividad que busca valorar el riesgo y
prever o establecer medidas que permitan disminuirlo. El riesgo es inherente a todo
proyecto, por lo que no podemos obviar ni olvidar, hay que enfrentarse a éste y lo
mejor es preverlo. El administrador del proyecto debe contar con la valoración de
los siguientes elementos el medio externo a la organización (las condiciones
legales, la competencia, las nuevas tecnologías, etcétera) y la valoración de las
condiciones de la organización (los recursos disponibles: financieros, recursos
humanos, infraestructura, equipos, etcétera), con el fin de reconocer aquellas
situaciones o recursos que generan mayor riesgo en el proyecto o que lo
fortalezcan.

Autor: Nuria Rodríguez & William Martínez

20
3.5.4 Estrategias frente al riesgo

La figura 22.5 muestra posibles estrategias de gestión del riesgo que se identificaron
como los principales riesgos (es decir, aquellos que son graves o intolerables).
Dichas estrategias se establecen en tres categorías:
1. Estrategias de evitación: Seguir estas estrategias significa que se reducirá la
probabilidad de que surja el riesgo. Un ejemplo de estrategia de evitación del riesgo
es la estrategia de enfrentar los componentes defectuosos que se muestran en la
figura 22.5.
2. Estrategias de minimización: Seguir estas estrategias significa que se reducirá
el efecto del riesgo. Un ejemplo de estrategia de minimización de un riesgo es la
estrategia para las enfermedades del personal que se indica en la figura 22.5.
3. Planes de contingencia: Seguir estas estrategias significa que se está
preparado para lo peor y se tiene una estrategia para hacer frente a ello. Un ejemplo
de estrategia de contingencia es la estrategia para los problemas financieros de la
organización que se indica en la figura 22.5
Aquí se observa una clara analogía con las estrategias utilizadas en los sistemas
críticos para garantizar fiabilidad, seguridad y protección, cuando hay que evitar,
tolerar o recuperarse de las fallas. Desde luego, es mejor usar una estrategia que
evitar el riesgo. Si esto no es posible, se debe usar una estrategia que reduzca las
posibilidades de que el riesgo cause graves efectos. Finalmente, se debe contar con
estrategias para enfrentar el riesgo cuando éste surja. Tales estrategias deben
reducir el efecto global de un riesgo en el proyecto o el producto.

Figura 22.6 Indicadores de riesgo

Autor: Ian Sommerville

21
3.6 Análisis de la viabilidad del proyecto

El éxito o fracaso de un proyecto a partir de una serie de datos base de naturaleza

empírica: medio ambiente del proyecto, rentabilidad, necesidades de mercado,
factibilidad política, aceptación cultural, legislación aplicable, medio físico, flujo de
caja de la operación, haciendo un énfasis en viabilidad financiera y de mercado.
Las expresiones de éxito y fracaso relacionadas con un proyecto, aunque
omnipresentes, son en parte subjetivas: dependen del cristal con que se mira. Es
difícil encontrar éxitos y fracasos completos en cualquier clase de proyectos. En
términos generales, un proyecto se considera un fracaso si…
 No se han alcanzado los objetivos o resultados previstos.
 Se han sobrepasado los tiempos asignados.
 Se han sobrepasado los recursos o costes previstos.
 No se han alcanzado los estándares de calidad deseados.
De nuevo, son estas variables (alcance, calidad, tiempo y coste) los indicadores
interdependientes de éxito o fracaso. Si tocamos uno, tocamos los demás.
Pero, ¿por qué fallan los proyectos con tanta frecuencia? Se puede pensar que los
proyectos fallan porque la gente no sabe hacerlos, por un desconocimiento
principalmente técnico. No es así, ni es la razón más frecuente. Un proyecto falla
por una gran variedad de razones.
El objetivo principal del análisis de la viabilidad de un proyecto es garantizar que
este sea técnicamente factible, económicamente justificable y, por supuesto, legal.
En pocas palabras, saber si la inversión que se va a realizar va a ser o no rentable.
Los principales beneficios de hacer un análisis de la viabilidad de un proyecto
pueden ser:
 Cercar las alternativas de negocio
 Lograr identificar una razón válida para desarrollar el proyecto
 Conseguir una claridad de gestión que dé lugar a una mayor rentabilidad
de la inversión.
La viabilidad de un proyecto intenta predecir el eventual éxito o fracaso de un
proyecto. Cualquier proyecto o empresa que se desee poner en marcha tiene que
tener como herramienta principal un plan de viabilidad que deje patente las
posibilidades de éxito que aquellas iniciativas pueden tener.

Autor: Ramón, J., García, J., & Lamarca, I.

22
 Conclusión

En todo proyecto de software existe la necesidad de tener una adecuada gestión de

los proyectos, para esto se debe contar con el mejor personal capacitado,
seleccionar el mejor proceso de acuerdo al problema que se vaya a tratar y tener
una buena planificación con el fin de tener un proyecto de calidad.
Las estimaciones de tiempo, costo y personal es de suma importancia, ya que es lo
más complejo en la planificación del proyecto, se debe tener experiencia al elaborar
esto, es decir una vez planificado se debe controlar y respetar las estimaciones que
se han elaborado.
Los riesgos del proyecto llevan a cabo la planificación de la gestión, el análisis, la
planificación de respuesta a los riesgos, así como su monitoreo y control en un
proyecto. Los objetivos de los riesgos del proyecto son aumentar la probabilidad y
el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos
negativos para el proyecto. Como vimos anteriormente existen diferentes tipos de
riesgos, riesgo del proyecto, del producto e empresariales, estos pueden ser
catastróficos si no se llevan a cabo de la mejor manera.
En el proyecto la meta siempre será la misma, es decir terminar sin rebasar el
presupuesto que nos da la estimación de costos, y con la calidad específica, si no
se proporciona esa calidad que distingue a la empresa de otras, el trabajo no será
recomendado hacia otras personas.
En conclusión existe un alto riesgo en la planificación de un proyecto, por ese motivo
se tiene que llevar un orden para poder ejecutarlo, es decir, tenemos que tener claro
el objetivo del proyecto, hacer una investigación profunda acerca del tema que se
llevara a cabo, construir la metodología del proyecto, una vez hecho esto ya
podemos planificar el proyecto e identificar los recursos, después de esto tenemos
que tener un plan de comunicación tras la primera reunión de arranque, vamos
creando una estrategia y calendario de comunicación y después evaluaremos al
instante el proyecto realizado, una vez terminado podemos volver a reutilizar el
proyecto, porque se puede dar la necesidad de reutilizar proyectos ya finalizados,
esto ocurre cuando solemos hacer el mismo trabajo o similar.

23
 Bibliografía

Sommerville I... (2012-04-26). Ingeniería de Software. Naucalpan de Juárez, Estado

de México: Pearson Educación de México, S.A. de C.V...(pp.596- 602).

Sapag, N. & Sapag C... (2008). Preparación y evaluación de proyectos. Bogotá,

Colombia: McGraw-Hill Interamericana S.A...(p.118).

Bedini, A... (2000). Gestión de Proyectos de Software. Buenos Aires: SYNSPACE.

(pp.54- 70)

Angulo, L... (Noviembre de 2013). Gestión de Proyectos con Project, Excel y Visio.
Av. Paseo de la República N. °5613, Miraflores, Lima, Perú: Macro EIRL… (pp.119-
121)

Lock, D... (25 - 28015). Gestión de Proyectos. Madrid (España): Paraninfo, S.A…
(p.1)

Pressman, S. Roger. (2002). INGENIERIA DEL SOFTWARE: UN ENFOQUE

PRÁCTICO. México, D.F.: McGraw-Hill/Interamericana editores. S.A. DE C.V...

Miranda M. J... (2012). Gestión de Proyectos. Bogotá: Paraninfo… (p.25).

Ramón, J., García, J., & Lamarca, I.. (2007). Gestión de Proyectos informáticos:
métodos, herramientas y casos. Barcelona: UOC… (p.43)

Rodríguez, N. & Martínez, W.. (2006). Planificación y evaluación de proyectos

informáticos. San José, Costa Rica: EUNED…. (p.64)

24