Académique Documents
Professionnel Documents
Culture Documents
Alumna: N° de control:
Serrano Cruz Genesis Alexa 15321248
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
1
3.1 Objetivo del proyecto
2
3.2 Estimaciones de tiempo
3
3.3 Estimaciones de costos
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.
6
3.4 Estimaciones de personal requerido
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].
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.
10
3.5 Análisis de riesgos
11
Figura 22.4 Tipos de riesgos y ejemplos:
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.
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.
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.
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
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.
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.
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.
21
3.6 Análisis de la viabilidad del proyecto
22
Conclusión
23
Bibliografía
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)
Ramón, J., García, J., & Lamarca, I.. (2007). Gestión de Proyectos informáticos:
métodos, herramientas y casos. Barcelona: UOC… (p.43)
24