TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE ACAPULCO

INGENIERÍA EN SISTEMAS COMPUTACIONALES

Gestión De Proyectos De Software

DOCENTE: Ing. Carolina Astudillo Hernández

Unidad 3
Planificación De Proyecto

ALUMNOS:

Orive Santander Gabriel Alfonso 15320149

Figueroa Fajardo Miguel Ángel 15320126
Jiménez Blanco Luis Giovanni 16320095

Periodo: Agosto - Diciembre 2018

Horario: 11:00 – 12:00
Contenido
3.1 OBJETIVO DEL PROYECTO.............................................................................................................. 2
3.2 ESTIMACION DE TIEMPO ............................................................................................................... 4
3.3 ESTIMACION DE COSTOS ............................................................................................................... 6
3.4 ESTIMACION DE PERSONAL REQUERIDO ...................................................................................... 8
3.5 ANALISIS DE RIESGOS .................................................................................................................. 10
3.5.1 TIPOS DE RIESGOS ................................................................................................................ 11
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIESGO ..................................................... 12
3.5.3 EVALUACIÓN DEL RIESGO .................................................................................................... 16
3.5.4 ESTRATEGIAS FRENTE AL RIESGO ......................................................................................... 17
3.6 ANALISIS DE LA VIABILIDAD DEL PROYECTO ............................................................................... 18
BIBLIOGRAFIA .................................................................................................................................... 20

1
3.1 OBJETIVO DEL PROYECTO

La clave para empezar con éxito un proyecto es que tengamos los términos de
referencia bien establecidos. Para ello, debemos conocer a los usuarios (autoridad
y el patrocinador), los objetivos, el ámbito, las restricciones, los costes y /o
presupuesto, los recursos, las entregas, las fases del proyecto, las estrategias,
riesgos, hipótesis, roles y responsabilidades.

Un aspecto muy importante para mantener el apoyo de la organización es que los

objetivos del proyecto estén en perfecta conexión con los de aquella y además que
se hagan explícitos. En síntesis, podemos decir que las principales razones para el
establecimiento de objetivos son:

 Objetivos de la Gestión de Proyectos.

 Definir el Proyecto y establecer la estructura organizativa de los equipos
 Definir claramente los objetivos y establecer una planificación del Proyecto
 Realizar estimaciones concretas y reales de tiempos, costes y recursos.
 Controlar y supervisar los trabajos, inversiones, consumo de recursos, costes
y tiempos de ejecución del proyecto.
 Establecer unos criterios de calidad sobre los resultados esperados, y
comprobar su cumplimiento.
 Prever los posibles riesgos que puedan surgir.
 Permitir la resolución inmediata de los problemas surgidos durante la
ejecución del Proyecto.
 Proporcionar una dirección.
 Enfocar los resultados.
 Permitir que se lleven a cabo los planes.
 Priorizar y organizar el trabajo.
 Motivar al personal.
 Comunicar el propósito del proyecto.
 Permitir que se reconozca el éxito.

La administración efectiva de un proyecto de software depende de planear

completamente el progreso del proyecto. Las metas globales del negocio son un
factor importante que debe considerarse cuando se formula el plan del proyecto. El
proceso de planeación del proyecto inicia con una valoración de las restricciones

2
que afectan el proyecto (fecha de entrega requerida, personal disponible,
presupuesto global, etc.). Ésta se lleva a cabo con una estimación de los parámetros
del proyecto como su estructura, tamaño y distribución de funciones. Después de
algún tiempo (por lo general 2 o 3 semanas), se revisa el proyecto y señalan las
discrepancias. Debido a que las estimaciones iniciales de los parámetros del
proyecto son tentativas, el plan siempre deberá actualizarse.

Las estimaciones están asociadas con el esfuerzo y el tiempo con las actividades
identificadas del proyecto. Los administradores del proyecto deben estimar las
respuestas a las siguientes preguntas:

 ¿Cuánto esfuerzo (personal necesario) se requiere para completar una

actividad?
 ¿Cuánto tiempo se necesita para completar una actividad?
 ¿Cuál es el costo total de una actividad?

La estimación y la realización del cronograma del proyecto se llevan a cabo de forma

conjunta. Sin embargo, en las primeras etapas del proyecto se requieren algunas
estimaciones de costos, antes que se tenga el cronograma detallado. Estas
estimaciones son necesarias para establecer un presupuesto para el proyecto o
para asignar un precio para el software de un cliente.

Una vez que el proyecto se comienza a ejecutar, las estimaciones se actualizan de

forma regular. Éstas pueden ser: solicitar recursos adicionales para el proyecto o
modificar el trabajo a realizar.

Existen tres parámetros involucrados en el cálculo del costo total de un proyecto de

desarrollo de software:

 Los costos de hardware y software, incluyendo el mantenimiento;

 Los costos de viajes y capacitación;
 Los costos de esfuerzo (los costos de pago a los ingenieros de software).

Para muchos proyectos, el costo dominante es el costo del esfuerzo. Las

computadoras que son suficientemente poderosas como para desarrollar el
software son relativamente baratas. Aunque los costos de viajes pueden ser
importantes si un proyecto se desarrolla en sitios distintos, son relativamente bajos
para muchos proyectos. Los costos del esfuerzo no son simplemente los
relacionados a los salarios de los ingenieros de software involucrados en el

3
proyecto. Las organizaciones calculan los costos de esfuerzo en función de los
costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la
organización y dividen éste entre el número de personas productivas. Por lo tanto,
los siguientes costos son parte de los costos de esfuerzo totales:

 Los costos de proveer, calentar e iluminar las oficinas

 Los costos del personal de apoyo como los contadores, secretarias,
limpiadores y técnicos
 Los costos de las redes y comunicaciones
 Los costos de los recursos centralizados como las bibliotecas, los recursos
recreativos, etc.

Debido a las consideraciones organizacionales involucradas, asignar precio del

proyecto por lo general le concierne al administrador principal de la organización,
así como a los administradores del proyecto de software.

3.2 ESTIMACION DE TIEMPO

Uno de los aspectos más importantes de tomar en cuenta es la estimación de los

tiempos de ejecución para cada una de las actividades que conforman a un
proyecto, ya que una mala estimación hace que el proyecto no sea finalizado a
tiempo, además del consabido incremento de los costos.

Dentro de la información que es necesario analizar para poder hacer una buena
estimación del tiempo se deben tomar en cuenta los siguientes aspectos:

1. Lista de actividades. La lista de actividades debe incluir todas las actividades que
serán ejecutadas en el proyecto. Deberá ser organizada como una extensión de la
estructura de la división de trabajo para ayudar a asegurar que está completo y que
no incluye actividades que no son requeridas como parte del alcance del proyecto.
Así como con la estructura de la división de trabajo; la lista de actividades debe
incluir descripciones de cada actividad para asegurar que los miembros del equipo
del proyecto entenderán como se deberá de ejecutar el trabajo.

2. Restricciones. Las restricciones son todos aquellos factores que van a limitar las
opciones del equipo del proyecto.

3. Suposiciones. Las suposiciones son factores que, para los procesos de

planeación, serán consideradas como verdaderas, reales, o ciertas. Las

4
suposiciones generalmente involucran algún grado de riesgo y serán
normalmente una salida del proceso de identificación de riesgos.

4. Requerimientos de recursos. La duración de la mayoría de las actividades se

verá influenciada significativamente por los recursos asignada a ella. Por ejemplo,
dos personas trabajando juntas serán capaces de completar una actividad de diseño
en la mitad del tiempo que le tomaría a cada uno individualmente realizar la tarea,
mientras que una persona trabajando medio tiempo en la actividad tomará
generalmente el doble del tiempo que la misma persona trabajando tiempo
completo.

5. Capacidades de recursos. La evaluación de la mayoría de las actividades se verá

influenciada significativamente por las capacidades de los recursos humanos y
materiales asignados a ella. Por ejemplo, si dos miembros del staff son asignados
tiempo completo, se podrá esperar que el miembro con mayor experiencia complete
la tarea en menos tiempo, que le tomará al miembro con menor experiencia terminar
la tarea.

6. Información histórica. La información histórica de la duración más probable de

muchas categorías de actividades, está muchas veces disponible de una o de más
de las siguientes fuentes:

 Archivos de proyecto. - una o más de las organizaciones involucradas en el

proyecto puede mantener registros de resultados de proyectos previos que
sean lo suficientemente detallados para ayudar en el desarrollo de los
estimativos de duración. En algunas áreas de aplicación, individuos del
equipo de trabajo pueden mantener tales registros.

 Bases de datos de estimación comerciales. - mucha información histórica

está disponible comercialmente. Estas bases de datos tienden a ser
especialmente útiles cuando las duraciones no son función del contenido de
trabajo real (por ejemplo, cuánto tiempo se demora el concreto para curar;

5
 cuánto se demora un agente gubernamental para responder a ciertas
requisiciones).

 Conocimiento del equipo de proyecto. - Los miembros individuales del equipo

del proyecto pueden recordar estimativos actuales o previos, los cuales
pueden ser útiles, pero son generalmente menos confiables que resultados
documentados.

3.3 ESTIMACION DE COSTOS

La administración de los proyectos de software comienza con un conjunto de

actividades que de manera colectiva se llaman planificación de proyecto. Antes de
que el proyecto pueda comenzar, el equipo de software debe estimar el trabajo que
se va a realizar, los recursos que se requerirán y el tiempo que transcurrirá de
principio a fin. Una vez completadas dichas actividades, el equipo de software debe
establecer un calendario del proyecto que defina las tareas e hitos de la ingeniería
de software, que identifique quién es responsable de realizar cada tarea y
especifique las dependencias entre tareas que puedan imponer una fuerte demora
sobre el avance.

En una excelente guía para “sobrevivir al proyecto de software”, Steve McConnell

[McC98] presenta una visión del mundo real de la planificación del proyecto:

Muchos trabajadores técnicos preferirían realizar trabajo técnico en lugar de pasar

tiempo planificando. Muchos gerentes técnicos no tienen suficiente capacitación en
administración técnica como para sentirse seguros de que su planificación mejorará
el resultado de un proyecto. Dado que ninguna parte quiere hacer planes, con
frecuencia nunca se hacen.

Pero fallar en la planificación es uno de los errores más cruciales que un proyecto
puede tener... la planificación efectiva es necesaria para resolver problemas
corrientes arriba [tempranamente en el proyecto] a bajo costo, en lugar de corriente
abajo [tardíamente en el proyecto] a alto costo. El proyecto promedio emplea 80 por
ciento de su tiempo en “poner al día”: corregir errores que se cometieron
anteriormente en el proyecto.

La estimación de costo y esfuerzo del software nunca será una ciencia exacta.
Demasiadas variables (humanas, técnicas, ambientales, políticas) pueden afectar

6
el costo final del software y el esfuerzo aplicado para su desarrollo. Sin embargo, la
estimación del proyecto de software puede transformarse de un arte oscuro a una
serie de pasos sistemáticos que proporcionen estimaciones con riesgo aceptable.
Para lograr estimaciones confiables de costo y esfuerzo, surgen algunas opciones:

1. Retrase la estimación hasta avanzado el proyecto (obviamente,

¡puede lograr estimaciones 100 por ciento precisas después de que el
proyecto esté completo!).
2. Base las estimaciones en proyectos similares que ya estén completos.
3. Use técnicas de descomposición relativamente simples para generar
estimaciones de costo y esfuerzo de proyecto. 4. Use uno o más
modelos empíricos para estimación de costo y esfuerzo de software.

¿Qué es? Se establece una necesidad real para el software; los participantes están
a bordo, los ingenieros de software están listos para comenzar y el proyecto está a
punto de iniciar. Pero, ¿cómo se procede? La planificación de proyectos de software
abarca cinco grandes actividades: estimación, calendarización, análisis de riesgos,
planificación de gestión de la calidad y planificación de gestión del cambio. En el
contexto de este capítulo, sólo se considera la estimación, el intento por determinar
cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto
específico basado en software.

¿Quién lo hace? Los gerentes de proyecto de software, con la información

solicitada a los participantes del proyecto y datos de métricas de software
recopiladas de proyectos anteriores.

¿Por qué es importante? ¿Construiría una casa sin saber más o menos cuánto
gastará, las tareas que necesita realizar y el cronograma para el trabajo que se va
a realizar? Desde luego que no y, dado que la mayoría de los sistemas y productos
basados en computadora cuestan considerablemente más que construir una gran
casa, parece razonable realizar una estimación antes de comenzar a crear el
software.

¿Cuáles son los pasos? La estimación comienza con una descripción del ámbito
del problema. Luego éste se descompone en un conjunto de problemas más
pequeños y cada uno de éstos se estima, usando como guías datos históricos y
experiencia. La complejidad y el riesgo del problema se consideran antes de realizar
una estimación final.

7
¿Cuál es el producto final? La generación de una tabla simple que delinea las
tareas que se van a realizar, las funciones por implementar y el costo, esfuerzo y
tiempo involucrados para cada tarea.

¿Cómo me aseguro de que lo hice bien? Eso es difícil, porque en realidad no se

sabe hasta que el proyecto se completa. Sin embargo, si se tiene experiencia y se
sigue un enfoque sistemático, si genera estimaciones usando datos históricos
sólidos, si crea puntos de datos de estimación con al menos dos métodos diferentes,
si establece un calendario realista y continuamente lo adapta conforme el proyecto
avanza, puede estar seguro de que está haciendo su mejor esfuerzo.

3.4 ESTIMACION DE PERSONAL REQUERIDO

El planificador comienza por evaluar el ámbito del software y seleccionando las

habilidades requeridas para completar el desarrollo. Se especifican tanto la posición
organizacional (por ejemplo, gerente, ingeniero de software ejecutivo) como la
especialidad (por ejemplo, telecomunicaciones, base de datos, cliente-servidor).
Para proyectos relativamente pequeños (algunos persona-meses), un solo individuo
puede realizar todas las tareas de ingeniería de software y consultar especialistas
según lo requiera. Para proyectos más grandes, el equipo de software puede
dispersarse geográficamente a través de algunas ubicaciones diferentes. Por tanto,
se debe especificar la ubicación de cada recurso humano.

8
El número de personas requeridas para un proyecto de software puede
determinarse sólo después de hacer una estimación del esfuerzo de desarrollo (por
ejemplo, persona-meses). Véase Figura 1 recursos del proyecto.

Figura 1 Recursos del proyecto.

9
3.5 ANALISIS DE RIESGOS

En su libro acerca de administración y análisis de riesgos, Robert Charette [Cha89]

presenta una definición conceptual de riesgo: Primero, el riesgo se preocupa por los
acontecimientos futuros. Ayer y hoy están más allá de la preocupación activa, pues
ya cosechamos lo que previamente se sembró por nuestras acciones pasadas. La
cuestión tiene que ver, por tanto, con si podemos, al cambiar nuestras acciones de
hoy, crear una oportunidad para una situación diferente y esperanzadoramente
mejor para nosotros en el mañana. Esto significa, segundo, que el riesgo involucra
cambio, como en los cambios de mentalidad, de opinión, de acciones o de lugares
[...] [Tercero,] el riesgo involucra elección y la incertidumbre que ella conlleva. En
consecuencia, paradójicamente, el riesgo, como la muerte y los impuestos, es una
de las pocas certezas de la vida.

Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres

fundamentos conceptuales de Charette siempre están presentes. El futuro es su
preocupación: ¿qué riesgos pueden hacer que el proyecto de software salga
defectuoso? El cambio es lo que preocupa: ¿cómo afectan en los cronogramas y en
el éxito global los cambios que puede haber en los requisitos del cliente, en las
tecnologías de desarrollo, en los entornos meta y en todas las otras entidades
conectadas con el proyecto? Por último, se debe lidiar con las opciones: ¿qué
métodos y herramientas deben usarse, cuántas personas deben involucrarse,
cuánto énfasis es “suficiente” poner en la calidad? Peter Drucker [Dru75] dijo alguna
vez: “aunque sea fútil intentar eliminar el riesgo, y cuestionable intentar minimizarlo,
es esencial que los riesgos tomados sean los riesgos correctos”.

¿Qué es? El análisis y la administración del riesgo son acciones que ayudan al
equipo de software a entender y manejar la incertidumbre. Muchos problemas
pueden plagar un proyecto de software. Un riesgo es un problema potencial: puede
ocurrir, puede no ocurrir. Pero, sin importar el resultado, realmente es una buena
idea identificarlo, valorar su probabilidad de ocurrencia, estimar su impacto y
establecer un plan de contingencia para el caso de que el problema realmente
ocurra.

¿Quién lo hace? Todos los involucrados en el proceso de software (gerentes,

ingenieros de software y otros interesados) participan en el análisis y la
administración del riesgo.

10
¿Por qué es importante? Piense en la consigna de los boy scouts: “estar
preparados”. El software es una empresa difícil. Muchas cosas pueden salir mal y,
francamente, muchas con frecuencia lo hacen. Por esta razón es que estar
preparado, comprender los riesgos y tomar medidas proactivas para evitarlos o
manejarlos son elementos clave de una buena administración de proyecto de
software.

¿Cuáles son los pasos? Reconocer qué puede salir mal es el primer paso, llamado
“identificación de riesgos”. A continuación, cada riesgo se analiza para determinar
la probabilidad de que ocurra y el daño que causará si ocurre. Una vez establecida
esta información se clasifican los riesgos, por probabilidad e impacto. Finalmente,
se desarrolla un plan para manejar aquellos que tengan alta probabilidad y alto
impacto.

¿Cuál es el producto final? Se produce un plan para mitigar, monitorear y manejar

el riesgo (MMMR) o un conjunto de hojas de información de riesgo. ¿Cómo me
aseguro de que lo hice bien? Los riesgos que se analizan y manejan deben inferirse
a partir de un estudio del personal, el producto, el proceso y el proyecto. El MMMR
debe revisarse conforme avance el proyecto para asegurarse de que los riesgos se
mantienen actualizados. Los planes de contingencia para administración del riesgo
deben ser realistas.

3.5.1 TIPOS DE RIESGOS

Aunque hay un considerable debate acerca de la definición adecuada de riesgo de
software, existe un acuerdo general en que los riesgos siempre involucran dos
características: incertidumbre (el riesgo puede o no ocurrir; es decir, no hay riesgos
100 por ciento probables1) y pérdida (si el riesgo se vuelve una realidad, ocurrirán
consecuencias o pérdidas no deseadas [Hig95]). Cuando se analizan los riesgos es
importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociados
con cada riesgo. Para lograr esto, se consideran diferentes categorías de riesgos.
Los riesgos del proyecto amenazan el plan del proyecto, es decir, si los riesgos del
proyecto se vuelven reales, es probable que el calendario del proyecto se deslice y
que los costos aumenten. Los riesgos del proyecto identifican potenciales
problemas de presupuesto, calendario, personal (tanto técnico como en la
organización), recursos, participantes y requisitos, así como su impacto sobre un
proyecto de software. En el capítulo 26, la complejidad, el tamaño y el grado de
incertidumbre estructural del proyecto también se definieron como factores de
riesgos para el proyecto (y la estimación). Los riesgos técnicos amenazan la calidad
y temporalidad del software que se va a producir. Si un riesgo técnico se vuelve una

11
realidad, la implementación puede volverse difícil o imposible. Los riesgos técnicos
identifican potenciales problemas de diseño, implementación, interfaz, verificación
y mantenimiento. Además, la ambigüedad en la especificación, la incertidumbre
técnica, la obsolescencia técnica y la tecnología “de punta” también son factores de
riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver
de lo que se creía. Los riesgos empresariales amenazan la viabilidad del software
que se va a construir y con frecuencia ponen en peligro el proyecto o el producto.
Los candidatos para los cinco principales riesgos empresariales son: 1) construir un
producto o sistema excelente que realmente no se quiere (riesgo de mercado), 2)
construir un producto que ya no encaje en la estrategia empresarial global de la
compañía (riesgo estratégico), 3) construir un producto que el equipo de ventas no
sabe cómo vender (riesgo de ventas), 4) perder el apoyo de los administradores
debido a un cambio en el enfoque o en el personal (riesgo administrativo) y 5) perder
apoyo presupuestal o de personal (riesgos presupuestales). Es extremadamente
importante observar que la categorización simple de riesgos no siempre funciona.
Algunos de ellos son simplemente impredecibles por adelantado. Otra
categorización general de los riesgos es la propuesta por Charette [Cha89]. Los
riesgos conocidos son aquellos que pueden descubrirse después de una evaluación
cuidadosa del plan del proyecto, del entorno empresarial o técnico donde se
desarrolla el proyecto y de otras fuentes de información confiables (por ejemplo,
fecha de entrega irreal, falta de requisitos documentados o ámbito de software,
pobre entorno de desarrollo). Los riesgos predecibles se extrapolan de la
experiencia en proyectos anteriores (por ejemplo, rotación de personal, pobre
comunicación con el cliente, disolución del esfuerzo del personal conforme se
atienden las solicitudes de mantenimiento). Los riesgos impredecibles son el
comodín en la baraja. Pueden ocurrir y lo hacen, pero son extremadamente difíciles
de identificar por adelantado.

3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIESGO

La identificación de riesgos es un intento sistemático por especificar amenazas al
plan del proyecto (estimaciones, calendario, carga de recursos, etc.). Al identificar
los riesgos conocidos y predecibles, el gerente de proyecto da un primer paso para
evitarlos cuando es posible y para controlarlos cuando es necesario. Existen dos
tipos distintos de riesgos para cada una de las categorías que se presentaron en la
sección 28.2: riesgos genéricos y riesgos específicos del producto. Los riesgos
genéricos son una amenaza potencial a todo proyecto de software. Los riesgos

12
específicos del producto pueden identificarse solamente por quienes tienen clara
comprensión de la tecnología, el personal y el entorno específico del software que
se construye. Para identificar los riesgos específicos del producto, examine el plan
del proyecto y el enunciado de ámbito del software, y desarrolle una respuesta a la
siguiente pregunta: ¿qué características especiales de este producto pueden
amenazar el plan del proyecto? Un método para identificar riesgos es crear una lista
de verificación de ítem de riesgo. La lista de verificación puede usarse para
identificación del riesgo y así enfocarse sobre algún subconjunto de riesgos
conocidos y predecibles en las siguientes subcategorías genéricas:

1. Tamaño del producto: riesgos asociados con el tamaño global del software
que se va a construir o a modificar.
2. Impacto empresarial: riesgos asociados con restricciones impuestas por la
administración o por el mercado.
3. Características de los participantes: riesgos asociados con la sofisticación de
los participantes y con la habilidad de los desarrolladores para comunicarse
con los participantes en forma oportuna.
4. Definición del proceso: riesgos asociados con el grado en el que se definió el
proceso de software y la manera como se sigue por parte de la organización
desarrolladora.
5. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de
las herramientas por usar para construir el producto.
6. Tecnología por construir: riesgos asociados con la complejidad del sistema
que se va a construir y con lo “novedoso” de la tecnología que se incluye en el
sistema.
7. Tamaño y experiencia del personal: riesgos asociados con la experiencia
técnica y de proyecto global de los ingenieros de software que harán el trabajo.

La lista de verificación de ítem de riesgo puede organizarse en diferentes formas.

Las preguntas relevantes en cada uno de los temas pueden responderse para cada
proyecto de software. Las respuestas a dichas preguntas permiten estimar el
impacto del riesgo. Un formato diferente de lista de verificación de ítem de riesgo
simplemente menciona las características que son relevantes en cada subcategoría
genérica. Finalmente, se menciona un conjunto de “componentes y promotores de
riesgo” [AFC88] junto con sus probabilidades de ocurrencia. Los promotores de
desempeño, apoyo, costo y calendario se analizan en respuesta a las preguntas
anteriores. Algunas listas de verificación exhaustivas para riesgo de proyecto de
software están disponibles en la red (por ejemplo, [Baa07], [NAS07], [Wor04]).

13
Puede usar dichas listas de verificación para comprender los riesgos genéricos para
proyectos de software.

La proyección del riesgo, también llamada estimación del riesgo, intenta calificar
cada riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real
y 2) las consecuencias de los problemas asociados con el riesgo, en caso de que
ocurra. Usted trabaja junto con otros gerentes y personal técnico para realizar cuatro
pasos de proyección de riesgo:

1. Establecer una escala que refleje la probabilidad percibida de un

riesgo.
2. Delinear las consecuencias del riesgo.
3. Estimar el impacto del riesgo sobre el proyecto y el producto.
4. Valorar la precisión global de la proyección del riesgo de modo que no
habrá malos entendidos.

Véase figura 2 valoración de impacto.

14
Figura 2 valoración de impacto

Nota:

1) La consecuencia potencial de errores o fallos de software no detectados.

2) La consecuencia potencial si el resultado deseado no se alcanza.

La intención de estos pasos es considerar los riesgos de manera que conduzcan a

una priorización. Ningún equipo de software tiene los recursos para abordar todo
riesgo posible con el mismo grado de rigor. Al priorizar los riesgos es posible asignar
recursos donde tendrán más impacto.

15
3.5.3 EVALUACIÓN DEL RIESGO
El proceso de evaluación de los riesgos considera cada uno de los riesgos clave
que han sido identificados, así como las estrategias para gestionarlos. Otra vez, no
existe un proceso sencillo que nos permita establecer las evaluaciones de gestión
de riesgos. Depende del juicio y de la experiencia del gestor del proyecto

El proceso de análisis y evaluaciones de los riesgos trata principalmente de

comprender la probabilidad de que surja un riesgo y las consecuencias potenciales
que tendrían lugar si se produce un accidente o incidente asociado a ese riesgo.
Necesitamos realizar este análisis para comprender si un riesgo es una amenaza
seria para el sistema o el entorno y proporcionar una base para decidir los recursos
que se deberían usar para gestionar el riesgo.

La figura que se mostrara a continuación (Brazendale y Bell, 1994), desarrollada

para sistemas de seguridad críticos, muestra estas tres regiones. La parte
sombreada del diagrama refleja los costes para asegurar que los riesgos no
provocan accidentes o incidentes. El coste de diseño del sistema para tener en
cuenta el riesgo es una función de la anchura del triángulo. Los costes más altos se
dan con los riesgos de la parte superior del diagrama; los más bajos. Con los riesgos
de la cima del triángulo.

Figura 3 triangulo de riesgo.

Los límites entre las regiones de la Figura 3 triangulo de riesgo tienden a moverse
a lo largo del tiempo, debido a expectativas públicas de seguridad y a
consideraciones políticas. Si bien los costes financieros de aceptar los riesgos y de
pagar cualquier accidente que pueda tener lugar pueden ser menores que los costes
de prevención de accidentes. La opinión pública puede demandar que dichos costes

16
adicionales sean aceptados. Por ejemplo, puede ser más barato para una empresa
tratar el problema de la polución en las raras ocasiones en las que ocurra, que
instalar sistemas para prevenir la polución. Esto hubiera sido aceptable en los años
60 y 70, pero probablemente hoy en día no es aceptable pública o políticamente.
En este caso. El límite entre la región intolerable y la región ALARP se ha movido
hacia abajo para que los riesgos que hubieran sido aceptados en el pasado sean
ahora intolerables. La valoración del riesgo comprende la estimación de la
probabilidad y severidad del riesgo. Normalmente éste es muy difícil de llevar a cabo
de forma exacta y generalmente depende de valoraciones de ingeniería. Las
probabilidades y severidades de los riesgos se asignan utilizando términos relativos
tales como probable. Improbable, y raro y alto, medio y bajo. La experiencia previa
en el sistema puede permitir asociar algún valor numérico a estos términos. Sin
embargo, debido a que los accidentes son relativamente poco comunes, es muy
difícil validar la exactitud de este valor

3.5.4 ESTRATEGIAS FRENTE AL RIESGO

Las estrategias reactivas de riesgo se han llamado irrisoriamente la “escuela de
gestión de riesgo de Indiana Jones” [Tho92]. En las películas que llevan su nombre,
Indiana Jones, cuando enfrenta una dificultad abrumadora, invariablemente dice:
“No te preocupes, ¡pensaré en algo!”. Al nunca preocuparse por los problemas hasta
que suceden, Indy reaccionará en alguna forma heroica. Tristemente, el gerente
promedio de proyectos de software no es Indiana Jones y los miembros del equipo
del proyecto de software no son sus fieles ayudantes. Sin embargo, la mayoría de
los equipos de software se apoyan exclusivamente en estrategias reactivas de
riesgo. Cuando mucho, una estrategia reactiva monitorea el proyecto para riesgos
probables. Los recursos se hacen a un lado para lidiar con los riesgos, hasta que
se convierten en problemas reales. De manera más común, el equipo de software
no hace nada acerca de los riesgos hasta que algo sale mal. Entonces el equipo se
apresura a entrar en acción con la intención de corregir el problema rápidamente.
Con frecuencia esto se llama modo bombero. Cuando falla, la “administración de
crisis” [Cha92] toma el control y el proyecto está en un peligro real. Una estrategia
considerablemente más inteligente para la administración del riesgo es ser
proactivo. Una estrategia proactiva comienza mucho antes de iniciar el trabajo
técnico. Los riesgos potenciales se identifican, su probabilidad e impacto se valoran
y se clasifican por importancia. Luego, el equipo de software establece un plan para
gestionar el riesgo. El objetivo principal es evitarlo, pero, dado que no todos los
riesgos son evitables, el equipo trabaja para desarrollar un plan de contingencia que
17
le permitirá responder en forma controlada y efectiva. A lo largo del resto de este
capítulo se estudia una estrategia proactiva de gestión del riesgo.

3.6 ANALISIS DE LA VIABILIDAD DEL PROYECTO

La gestión de proyectos de software es una parte esencial de la ingeniería del

software. La buena gestión no puede garantizar el éxito del proyecto. Sin embargo,
la mala gestión usualmente lleva al fracaso del proyecto. El software es entregado
tarde, los costes son mayores que los estimados y los requerimientos no se
cumplen.

Los gestores de software son responsables de la planificación y temporalización del

desarrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo
conforme a los estándares requeridos y supervisan el progreso para comprobar que
el desarrollo se ajusta al tiempo previsto y al presupuesto. La administración de
proyectos de software es necesaria debido a que la ingeniería de software
profesional siempre está sujeta a restricciones organizacionales de tiempo y
presupuesto. El trabajo del gestor de proyectos de software es asegurar que éstos
cumplan dichas restricciones y entregar software que contribuya a las metas de la
compañía de desarrollo software.

En la viabilidad del proyecto se analiza lo siguiente:

1. El producto es intangible. El gestor de un proyecto de construcción de un

embarcadero o de uno de ingeniería civil puede ver el producto mientras
se está desarrollando. Si hay un desfase en calendario, el efecto en el
producto es visible de forma obvia: partes de la estructura no están
completas. El software es intangible. No se puede ver ni tocar. Los
gestores de proyectos de software no pueden ver el progreso. Confían en
otros para elaborar la documentación necesaria para revisar el progreso.

18
 2. No existen procesos del software estándar. En las disciplinas de ingeniería
con larga historia, el proceso se prueba y verifica. Para tipos particulares
de sistemas, como puentes o edificios, el proceso de ingeniería se
comprende bien. Sin embargo, los procesos de software varían
notablemente de una organización a otra. A pesar de que la comprensión
del proceso del software se ha desarrollado de forma significativa en los
últimos años, aún no se puede predecir con certeza cuándo un proceso
particular tiende a desarrollar problemas. Esto es especialmente cierto
cuando el proyecto software es parte un proyecto de ingeniería de un
sistema grande.

3. A menudo los proyectos grandes son únicos. Por lo general, los

proyectos grandes de software son diferentes de proyectos previos. En
consecuencia, los gestores, aun cuando cuenten con una amplia
experiencia, ésta no es suficiente para anticipar los problemas. Más aún,
los rápidos cambios tecnológicos en las computadoras y las
comunicaciones hacen parecer obsoleta la experiencia previa. Las
lecciones aprendidas en esas experiencias pueden no ser transferibles a
los nuevos proyectos.

La gestión efectiva de un análisis de validación depende de planificar

completamente el progreso del proyecto. El gestor del proyecto debe anticiparse a
los problemas que puedan surgir. Así como preparar soluciones a esos problemas.
Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para
el proyecto. Este plan inicial debe ser el mejor posible de acuerdo con la información
disponible. Éste evolucionará conforme el proyecto progrese y la información sea
mejor.

19
BIBLIOGRAFIA
Pressman, R. (2011). Ingeniería del sofware. Un Enfoque Práctico. 7th ed. Mexico: McGRAW-HILL
INTERAMERICANA EDITORES, S.A. DE C.V.

Sommerville, I. (2011). Ingeniería de Software. 9th ed. México: PEARSON EDUCACIÓN.

20