TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE ACAPULCO

INGENIERÍA EN SISTEMAS COMPUTACIONALES

MATERIA: GESTIÓN DE SOFTWARE

PROFESORA: ASTUDILLO HERNÁNDEZ CAROLINA

UNIDAD 3
PLANIFICACIÓN DEL PROYECTO

EQUIPO:

NOMBRE NO. DE CONTROL

CRUZ MARTÍNEZ JAIME 15321037
RODRÍGUEZ MARTÍNEZ ADRIANA 15321177
SALADO DELGADO JUAN JOSÉ GABRIEL 15321185

HORA: 12:00 – 01:00 pm

CICLO ESCOLAR AGOSTO / DICIEMBRE 2018

Contenido
INTRODUCCIÓN ..............................................................................................................................................2
3.1 OBJETIVO DEL PROYECTO .................................................................................................................3
Definición del problema ............................................................................................................................4
Objetivos de la planificación de proyectos .........................................................................................5
3.2 ESTIMACIONES DE TIEMPO .................................................................................................................5
El plan del proyecto ...................................................................................................................................6
Calendarización del proyecto .................................................................................................................6
Gráficos de barras y redes de actividades ..........................................................................................8
3.3 ESTIMACIONES DE COSTOS ...............................................................................................................9
Técnicas para estimar los costos del software ..................................................................................9
Variables para medir costos en proyectos ....................................................................................... 11
Técnica Juicio experto ........................................................................................................................... 11
Estimación del costo por la técnica DELFI....................................................................................... 12
Modelo del costo de un proyecto........................................................................................................ 12
3.4 ESTIMACIONES DEL PERSONAL REQUERIDO ........................................................................... 13
Los participantes ..................................................................................................................................... 14
Roles del personal y características .................................................................................................. 14
Estilos de trabajo..................................................................................................................................... 16
3.5 ANÁLISIS DE RIESGOS....................................................................................................................... 16
3.5.1 TIPOS DE RIESGOS .......................................................................................................................... 18
3.5.2 IDENTIFICACIÓN, IMPACTO Y PROYECCIÓN DEL RIESGO.................................................. 19
Identificación de riesgos ....................................................................................................................... 19
Impacto de riesgo .................................................................................................................................... 20
Proyección del riesgo ............................................................................................................................ 20
3.5.3 EVALUACIÓN DEL RIESGO ............................................................................................................ 21
3.5.4 ESTRATEGIAS FRENTE AL RIESGO ........................................................................................... 21
3.6 ANÁLISIS DE LA VIABILIDAD DEL PROYECTO ........................................................................... 23
CONCLUSIONES .......................................................................................................................................... 24
Conclusión personal Cruz Martínez Jaime ....................................................................................... 24
Conclusión personal Rodríguez Martínez Adriana ............................. Error! Bookmark not defined.
Conclusión personal Salado Delgado Juan José Gabriel ............................................................ 25
BIBLIOGRAFÍA ............................................................................................................................................. 26

1
INTRODUCCIÓN

La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software,
porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de software
fructífero se debe comprender el ámbito del trabajo a realizar, los riesgos en los que se
puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a
consumir y el plan a seguir.
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.
Los administradores de proyecto son responsables de la planeación, estimación y
calendarización del desarrollo del proyecto, así como de la asignación de tareas a las
personas. Supervisan el trabajo para verificar que se realice de acuerdo con los estándares
requeridos y monitorizan el avance para comprobar que el desarrollo esté a tiempo y dentro
del presupuesto, tienen que valorar los riesgos que pueden afectar un proyecto, monitorizar
dichos riesgos y emprender acciones cuando surjan problemas
La primera etapa en un proyecto de software puede implicar escribir una propuesta para
obtener un contrato de trabajo. La propuesta describe los objetivos del proyecto y cómo se
realizará. Por lo general, incluye estimaciones de costo y calendarización, además de
justificar por qué el contrato del proyecto debería concederse a una organización o un
equipo particular. La escritura de propuestas es una tarea esencial, pues la supervivencia
de muchas compañías de software depende de contar con suficientes propuestas
aceptadas y concesiones de contratos. Es posible que no haya lineamientos establecidos
para esta tarea; la escritura de propuestas es una habilidad que se adquiere a través de
práctica y experiencia.
Es por eso que esta unidad se verá cómo es que se planifica un proyecto, ya que hay
muchos factores a tomar en cuenta a la hora de realizar un proyecto para que este tenga
éxito y se obtenga un resultado favorable
También veremos acerca del personal que es necesario para un desarrollar un proyecto y
el tipo de personal con el que nos podemos encontrar, uno de los temas más importantes
también son los costos, ya que el dinero es una parte fundamental para emprender un nuevo
proyecto.
En este documento se plasma información que ha sido investigada de diferentes libros y
diferentes autores.

2
3.1 OBJETIVO DEL PROYECTO
Un proyecto es, ni más ni menos, la búsqueda de una solución inteligente al planteamiento
de un problema tendiente a resolver, entre tantos, una necesidad humana. Cualquiera que
sea la idea que pretende implementar, la inversión, la metodología o la tecnología por
aplicar, ella conlleva necesariamente la búsqueda de proposiciones coherentes destinadas
a resolver las necesidades de la persona humana.

El proyecto surge como una respuesta a una “idea” que busca la solución de un problema
(reemplazo de tecnología obsoleta, abandono de una línea de productos) o la manera de
aprovechar una oportunidad de negocio. Ésta por lo general corresponde a la solución de
un problema de terceros.

Al identificar un problema que se va a solucionar con el proyecto, o una oportunidad de

negocios que se va a hacer viable con él, deberán prioritariamente, buscarse todas las
opciones que conduzcan al objetivo. Cada opción será un proyecto.

En una primera etapa se preparará el proyecto, es decir, se determinará la magnitud de sus

inversiones, costos y beneficios.

En una segunda etapa, se evaluará el proyecto, en otras palabras, se medirá la rentabilidad

de la inversión. Ambas etapas constituyen lo que se conoce como la preinversión.

En el éxito o fracaso de un proyecto influyen múltiples factores. En general se pueden

señalar que, si el bien ofrecido o el servicio es rechazado por la comunidad, eso significa
que la asignación de recursos adoleció de los defectos de diagnóstico o de análisis que lo
hicieron inadecuado para las expectativas de satisfacción de las necesidades del
conglomerado humano.

Las causas del fracaso o éxito pueden ser múltiples y de diversa naturaleza. Un cambio
tecnológico importante puede transformar un proyecto rentable en uno fallido. Cuando más
acentuado sea el cambio que produzca, mayor será el efecto sobre el proyecto.

Con la preparación y evaluación será posible reducir la incertidumbre inicial respecto de la

conveniencia de llevar a cabo una inversión. La decisión que se tome con más información
siempre será mejor, salvo al azar, que aquella que se tome con poca información. No es
posible calificar de malo a un proyecto por el solo hecho de no haber tenido éxito práctico.
Tampoco puede ser catalogado de bueno un proyecto que, teniendo éxito, ha estado
sostenido mediante expedientes casuísticos.

“Un proyecto es como un viaje por carretera. Algunos proyectos son simples y rutinarios,
como conducir hacia la tienda en plena luz del día. Pero la mayoría de los proyectos que
vale la pena realizar son más parecidos a conducir un camión, en la montaña, de noche”

Cem Kaner, James Bach y Bret Pettichord.

3
Definición del problema

Todo elemento desarrollado por el hombre primero es una idea en su mente. Los sistemas
computacionales, como otros productos de la tecnología, se desarrollan en respuesta a
requerimientos detectados. Las fuentes que producen las ideas de productos de
programación incluyen las necesidades del cliente generadas externamente, las
necesidades internas de la organización, planes de mercadotecnia, y los planes o misiones
organizacionales. La mayor parte de las organizaciones que desarrollan productos de
programación son muy selectivas al decidir qué productos desarrollarán; no explotan todas
las oportunidades. La decisión de llevar a cabo el proyecto se basa, generalmente en el
resultado de un estudio de factibilidad.

El primer paso en la planeación de un proyecto de programación es preparar, en la

terminología del cliente, un enunciado breve del problema que se solucionará y de las
restricciones que existen en su resolución. El enunciado definitivo del problema debe incluir
una descripción de la situación actual y de las metas que debe lograr el nuevo sistema.

Hay que tomar en cuenta que el problema del cliente, desde su punto de vista, tal vez sea
un problema de nómina, de inventario, o de control del tráfico aéreo, y no problemas de
algoritmos de clasificación, o bases de datos relacionales.

La definición del problema requiere de un entendimiento cabal del dominio del problema y
del entorno de éste, Las técnicas para obtener este conocimiento, por parte del planeador
son entrevistas con el cliente, observación de las tareas problemáticas, y desarrollo de las
reales. El planeador debe ser muy hábil en las técnicas de definición del problema, ya que
distintos representantes del cliente tendrán diferentes puntos de vista, sesgos, y prejuicios
que influirán en su percepción del área del problema.

El segundo paso en la planeación de un proyecto de programación es determinar lo

apropiado de una solución computacional. Además de ser eficaz en términos de costo, un
sistema computacional debe aceptarse social y políticamente. Para ser eficiente en costo,
un nuevo producto de programación debe proporcionar los mismos servicios e información
que el sistema antiguo, usando menos tiempo y personal, o proporcionar servicios e
información que antes eran inaccesibles. Un sistema que desplace muchos trabajadores
puede ser económica y técnicamente posible, pero inaceptable social o políticamente para
el usuario.

4
Objetivos de la planificación de proyectos

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo

que permita al gestor hacer estimaciones razonables de recursos, coste y planificación
temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo
de un proyecto de software, y deberían actualizarse regularmente a medida que progresa
el proyecto. Además, las estimaciones deberían definir los escenarios del <<mejor caso>>
y <<peor caso>> de forma que los resultados el proyecto pueden limitarse.

El objetivo de la planificación se logra mediante un proceso de descubrimiento de la

información que lleve a estimaciones razonables.

3.2 ESTIMACIONES DE TIEMPO

La gestión del proyecto de software comienza con un conjunto de actividades que en grupo
se denominan planificación del proyecto. Antes de que el proyecto comience el gestor del
proyecto y el equipo de software deben estimar el trabajo que habrá de realizarse, los
recursos que se requerirán y el tiempo que transcurrirá desde el principio hasta el final. Una
vez que se completen estas actividades, el equipo de software debe establecer un plan del
proyecto que defina las tareas y fechas clave de la ingeniería del software, que identifique
quien es responsable de dirigir cada tarea y especifique las dependencias entre tareas que
pueden ser determinantes en el progreso.

Muchos trabajadores técnicos preferirán realizar el trabajo técnico en lugar de pasar el

tiempo en la planificación. Muchos gestores técnicos no tienen suficiente entrenamiento en
la gestión técnica para sentirse seguros de que su planificación mejorará el resultado de un
proyecto. Puesto que ninguna parte requiere hacer la planificación, con frecuencia no se
realiza.

Pero las fallas para planificar es uno de los mayores errores que un proyecto puede cometer,
se necesita la planificación eficaz para resolver los problemas corriente arriba (temprano en
el proyecto) a bajo costo, más que corriente abajo (tarde en el proyecto) a alto costo. El
proyecto promedio gasta el 80 por ciento de su tiempo en reelaboración: corrigiendo errores
que se cometieron en etapas tempranas del proyecto.

McConell argumenta que cualquier proyecto puede encontrar el tiempo para planificar (y
adaptar el plan a lo largo del proyecto) simplemente tomando un pequeño porcentaje del
tiempo que se habría gastado en la reelaboración que ocurre debido a que no se planificó.

5
El plan del proyecto

El plan del proyecto fija los recursos disponibles, divide el trabajo y crea un calendario de
trabajo. En algunas organizaciones, el plan de proyecto es un único documento que incluye
todos los diferentes tipos de planes. En otros casos, este plan sólo se refiere al proceso de
desarrollo. Otros pueden estar referenciados, pero son proporcionados por separado.
Los detalles de este plan varían dependiendo del tipo de proyecto y de la organización. Sin
embargo, muchos planes incluyen las siguientes secciones:
1. Introducción: Describe brevemente los objetivos del proyecto y expone las
restricciones (por ejemplo, presupuesto, tiempo, etcétera) que afectan a la gestión
del proyecto.
2. Organización del proyecto: Describe la forma en que el equipo de desarrollo está
organizado, la gente involucrada y sus roles en el equipo.
3. Análisis de riesgo: Describe los posibles riesgos del proyecto, la probabilidad de que
surjan estos riesgos y las estrategias de reducción de riesgos propuestas.
4. Requerimientos de recursos de hardware y software: Describe el hardware y el
software de ayuda requeridos para llevar a cabo el desarrollo. Si es necesario
comprar hardware, se deben incluir las estimaciones de los precios y las fechas de
la entrega.
5. División del trabajo: Describe la división del proyecto en actividades e identifica los
hitos y productos a entregar asociados con cada actividad.
6. Programa del proyecto: Describe las dependencias entre actividades, el tiempo
estimado requerido para alcanzar cada hito y la asignación de la gente a las
actividades.
7. Mecanismo de supervisión e informe: Describe la gestión de informes y cuándo
deben producirse, así como los mecanismos de supervisión del proyecto a utilizar.
El plan del proyecto debe revisarse regularmente durante el proyecto. Algunas partes, como
el calendario del proyecto, cambiarán frecuentemente; otras serán más estables. Para
simplificar las revisiones, se debe organizar el documento en secciones separadas que
permitan su reemplazo de forma individual conforme evoluciona el plan.

Calendarización del proyecto

Esta es una de las tareas más difíciles para los gestores de proyectos. Los gestores estiman
el tiempo y los recursos requeridos para completar las actividades y organizarlas en una
sucesión coherente. A menos que el proyecto a calendarizar sea similar a otro anterior, las
estimaciones previas son una base incierta para la calendarización del nuevo proyecto. La
estimación del calendario se complica más por el hecho de que proyectos diferentes pueden
utilizar métodos de diseño y lenguajes de implementación diferentes.
Si el proyecto es técnicamente complejo, las estimaciones iniciales casi siempre son
optimistas aun cuando los gestores traten de considerar las eventualidades. A este respecto,
la calendarización del tiempo para la creación del software no es diferente a la de cualquier
otro tipo de proyecto grande y complejo. Los nuevos aeroplanos, los puentes e incluso los
6
nuevos modelos de automóviles se retrasan debido a los problemas no anticipados. Por lo
tanto, los calendarios se deben actualizar continuamente en la medida que se disponga de
mejor información acerca del progreso.
La calendarización del proyecto (véase la Figura 1) implica separar todo el trabajo de un
proyecto en actividades complementarias y considerar el tiempo requerido para completar
dichas actividades. Por lo general, algunas de éstas se llevan a cabo en paralelo. Debemos
coordinar estas actividades paralelas y organizar el trabajo para que la mano de obra se
utilice de forma óptima. Deben evitarse situaciones que el proyecto entero se retrase debido
a que no se ha determinado una actividad crítica.
Normalmente, las actividades del proyecto deben durar por lo menos una semana. Hacer
subdivisiones más finas significa invertir una cantidad desproporcionada de tiempo en la
estimación y revisión de tablas. También es útil asignar una cantidad de tiempo máxima de
8 a 10 semanas para realizar cualquier actividad. Si lleva más tiempo, se deben hacer
subdivisiones.
Al estimar la calendarización, los gestores no deben suponer que cada etapa del proyecto
estará libre de problemas. Las personas que trabajan en él pueden enfermarse o renunciar,
el hardware puede fallar y el software o hardware de soporte puede llegar tarde. Si el
proyecto es nuevo técnicamente complejo, ciertas partes podrían ser más complicadas y
llevarían más tiempo del que se estimó originalmente.
Como en los calendarios, los gestores deben estimar los recursos necesarios para
completar cada tarea. El recurso principal es el esfuerzo humano que se requiere. Otros
recursos pueden ser el espacio en disco requerido en un servidor, el tiempo requerido de
hardware especializado, un simulador o el presupuesto para viajes del personal del
proyecto.
Una buena regla práctica es estimar como si nada fuera a salir mal, y entonces incrementar
la estimación para abarcar los problemas previstos. Con este mismo fin, a la estimación se
le debe agregar un factor de contingencia adicional. Este factor extra de contingencia
depende del tipo de proyecto, de los parámetros del proceso (fecha de entrega, estándares,
etcétera) y de la calidad y experiencia de los ingenieros de software que trabajen en el
proyecto. Como regla, para los problemas previstos siempre deben agregarse un 30% a la
estimación original y otro 20% para cubrir algunas cosas no previstas.
Por lo general, el calendario del proyecto se representa como un conjunto de gráficos que
muestran la división del trabajo, las dependencias de las actividades y la asignación del
personal.

7
Gráficos de barras y redes de actividades

Los gráficos de barras y las redes de actividades son notaciones gráficas que se utilizan
para ilustrar la calendarización del proyecto. Los gráficos de barras muestran quién es
responsable de cada actividad y cuándo debe comenzar y finalizar ésta. Las redes de
actividades muestran las dependencias entre las diferentes actividades que conforman un
proyecto. Los gráficos de barras y las redes de actividades se generan automáticamente a
partir de una base de datos de la información del proyecto utilizando una herramienta de
gestión de proyectos.
Considere el conjunto de actividades que se muestra en la Figura 2. Esta tabla recoge las
tareas, la duración e interdependencias de éstas. En ella se observa que la tarea T3
depende de la tarea T1. Esto significa que T1 debe completarse antes de que comience T3.
Por ejemplo, T1 podría ser la preparación de un diseño de un componente y T3 la
implementación de ese diseño. Antes de que se inicie la implementación, el diseño debe
estar terminado.
Las actividades de proyecto son el elemento de planeación básico. Cada actividad cuenta
con:
1. Una duración en días o meses calendario.
2. Una estimación del esfuerzo, la cual refleja el número de días-hombre o meses-
hombre para completar el trabajo.
3. Un plazo dentro del cual debe completarse la actividad.
4. Un punto final definido. Éste representa el resultado tangible de completar la
actividad. También podría ser un documento, la realización de una junta de
revisión, una ejecución exitosa de todas las pruebas, etcétera.

Figura 2. Tareas, duraciones y dependencias.

8
3.3 ESTIMACIONES DE COSTOS

La estimación de costos de un producto de programación es una de las más difíciles y

erráticas tareas de la ingeniería de software; es difícil haces estimaciones exactas durante
la fase de planeación de un desarrollo debido a la gran cantidad de factores desconocidos
en ese momento. Sin embargo, la práctica normal en los contratos implica un firme
compromiso monetario como parte del estudio de factibilidad. Lo anterior, aunado a la
naturaleza competitiva de este negocio, es un factor que contribuye a los retrasos de entrega
y sobregiro en presupuesto tan comunes en los proyectos de programación.
Reconociendo este problema, algunas organizaciones utilizan una serie de estimadores de
costos; se prepara un estudio preliminar durante la fase de planeación y se presenta en la
revisión de la factibilidad del proyecto. La estimación mejorada se muestra en las revisiones
de los requisitos de programación y la estimación final se presenta durante la revisión
preliminar del diseño. Cada estimación es un refinamiento obtenido como resultado de las
actividades de trabajo desarrolladas adicionalmente; algunas veces, varias opciones del
producto, con sus respectivos costos, se exhiben en las revisiones; lo anterior permite que
el cliente escoja una solución adecuada dentro de las posibles soluciones.
En ocasiones los clientes financian las fases de análisis y de diseño preliminar en contratos
separados para poder alcanzar estimaciones exactas en cuanto a costo y tiempo de entrega.
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 iteració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:
1. Hardware.
2. Entrenamiento.
3. Esfuerzo.
Técnicas para estimar los costos del software

Existen siete técnicas posibles para estimar los costos del Software
1. 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.
2. 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.
3. Estimación por analogía. Se basa en el desarrollo previo de proyectos similares.
4. Ley de Parkinson. El trabajo se expande hasta llenar todo el tiempo disponible.

9
 5. Precio para ganar. El costo se estima según el presupuesto disponible.
6. 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.
7. 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:
1. La complejidad del proyecto
2. 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 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.

10
Variables para medir costos en proyectos

Costos de elaboración:
 Costos de consulta.
 Costos de alquiler o de compra de los equipos.
 Costos de modificación del emplazamiento de los equipos (aire acondicionado,
seguridad, etc.).
 Costos del capital Costos de gestión y de personal.
Costos de puesta en marcha:
 Costos del software del sistema operativo.
 Costos de la instalación de los equipos de comunicaciones (líneas telefónicas y de
datos).
 Costos del personal para la puesta en marcha.
 Costos de contratación de personal y alquileres.
 Costos de interrupción en el resto de la organización.
 Costos de gestión necesarios para dirigir la actividad inicial.
Costos relacionados con el proyecto:
 Costos de adquisición del software de aplicación.
 Costos de las modificaciones del software para que encajen con los sistemas locales.
 Costos de personal, gastos generales, etc. del desarrollo de aplicaciones internas.
 Costos de entrenamiento del personal en el uso de las aplicaciones.
 Costos de recogida de información y procedimiento de instalación.
 Costos de preparación de la documentación.
 Costos de la supervisión del desarrollo.
Costos del proceso:
 Costos de mantenimiento del sistema (hardware, software e instalaciones).
 Costos de suministros (electricidad, teléfono, etc.).
 Costos de depreciación del hardware.
 Costos del personal involucrado en la gestión de los sistemas de información,
operación y actividades de planificación.

Técnica Juicio experto

La técnica más utilizada para la estimación de costos es el uso del juicio experto, que
además es una técnica de tipo jerárquica hacia abajo. El juicio experto se basa en la
experiencia, en el conocimiento anterior y en el sentido comercial de uno o más individuos
dentro de la organización.
La mayor ventaja del juicio experto, que es la experiencia, puede llegar a ser su debilidad;
el experto puede confiarse de que el proyecto sea similar al anterior; pero bien puede
suceder que haya olvidado algunos factores que ocasionan que el sistema nuevo sea
11
significativamente diferente; o quizás, el experto que realiza la estimación no tenga
experiencia en este tipo de proyecto.
Para compensar tales factores, los grupos de expertos algunas veces tratan de llegar a un
consenso en el estimado; lo anterior tiende a minimizar las fallas individuales y la falta de
familiaridad en proyectos particulares neutralizando las tendencias personales y el
(posiblemente inconsciente) deseo ganar un contrato a través de una estimación optimista.
La mayor desventaja de la estimación en grupo es el efecto que la dinámica interpersonal
del grupo pueda tener en cada uno de los individuos; los miembros de un grupo pueden ser
inocentes con respecto a factores de tipo político, a la presencia de alguna autoridad dentro
del grupo, o al dominio de un miembro del grupo con una fuerte personalidad.

Estimación del costo por la técnica DELFI

La técnica DELFI fue desarrollada en la corporación Rand en 1984, con el fin de obtener el
consenso de un grupo de expertos. La técnica puede adaptarse a la estimación de costos
de la siguiente manera:
1. Un coordinador proporciona a cada experto la documentación con la definición del
sistema y una papeleta para que escriba su estimación.
2. Cada experto estudia la definición y determina su estimación en forma anónima; los
expertos pueden consultar con el coordinador, pero no entre ellos.
3. El coordinador, prepara y distribuye un resumen de las estimaciones efectuadas,
incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.
4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente,
utilizando los resultados de la estimación anterior. En los casos que una estimación
difiriera mucho de las demás, se podrá solicitar que también en forma anónima el
experto justifique su estimación.
5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una
discusión grupal durante el proceso.

Modelo del costo de un proyecto

El costo de un proyecto es la suma de los costos incurridos en cada fase, y éstos, a su vez,
incluyen los costos de la realización de las distintas actividades del proyecto. El costo de un
proyecto es la suma de los costos de verificación de la consistencia de estos productos con
los de las fases previas.
El costo de producción de la definición del sistema y del plan del proyecto es el mismo de
realizar las planeación y preparación de los documentos, más el costo de la verificación de
que la definición del sistema establece precisamente las necesidades del cliente y el costo
de verificación de que el plan del proyecto es factible.
El costo de preparación de la especificación de requisitos para la producción de software
incluye el costo de definir requisitos y preparar documentos, más el costo de modificar y
corregir la definición del sistema y el plan del proyecto, más el costo de verificación de que
12
la especificación esté completa y sea consistente con respecto a la definición del sistema y
las necesidades del cliente.
El costo de diseño, es el costo de las actividades propias y la generación de los documentos,
más el costo de modificar y corregir la definición del sistema, el plan de proyecto, y la
especificación de requisitos para la producción de software, más el costo de verificación del
diseño contra los requisitos, la definición del sistema y plan del proyecto.
El costo de la instrumentación del producto es el costo dela conversión, documentación,
depuración y pruebas del código fuente, más el costo de la terminación del manual del
usuario, el plan de verificación, los procedimientos de mantenimiento, y las instrucciones de
instalación y entrenamiento, más el costo de modificar y corregir la definición del sistema,
el plan del proyecto, la especificación de requisitos para la producción del software, la
especificación del diseño, y el plan de verificación; más el costo de verificación de que la
instrumentación esté completa y sea consistente con respecto a la definición del sistema, la
especificación de requisitos para la producción de software y los documentos del diseño.
El costo de las pruebas del sistema incluye el costo de planear y llevar a cabo las pruebas,
más el costo de las modificaciones al código fuente y a los documentos externos durante
ellas, más el costo de verificación de que las pruebas validan adecuadamente al producto.
Por último, el costo del mantenimiento es la suma de los costos de llevar a cabo mejoras al
sistema, hacer adaptaciones para nuevas condiciones de operación, y encontrar fallas.

3.4 ESTIMACIONES DEL PERSONAL REQUERIDO

Las personas que trabajan en una organización de software son los activos más
importantes. Cuesta mucho dinero reclutar y retener al buen personal, así que depende de
los administradores de software garantizar que la organización obtenga el mejor
aprovechamiento posible por su inversión. En las compañías y economías exitosas, esto se
logra cuando la organización respeta a las personas y les asigna responsabilidades que
reflejan sus habilidades y experiencia. Es importante que los administradores de proyecto
de software comprendan los conflictos técnicos que influyen en el trabajo del desarrollo de
software. Sin embargo, por desgracia, los buenos ingenieros de software no
necesariamente son buenos administradores de personal. Los ingenieros de software con
frecuencia tienen grandes habilidades técnicas, pero pueden carecer de habilidades más
sutiles que les permitan motivar y dirigir a un equipo de desarrollo de proyecto. Como
administrador de proyecto, usted deberá estar al tanto de los problemas potenciales de
administrar personal y debe tratar de desarrollar habilidades de gestión de recursos
humanos.
Para determinar el cronograma del proyecto y estimar el esfuerzo y los costos asociados,
se necesita conocer aproximadamente cuánta gente estará trabajando en el proyecto, qué
tareas ejecutarán y qué habilidades y experiencia deben tener para que puedan realizar sus
trabajos de manera eficaz.

13
Los participantes

El proceso de software (y todo proyecto de software) está poblado de participantes, quienes

pueden organizarse en alguna de las siguientes áreas:
 Gerentes ejecutivos, quienes definen los temas empresariales que con frecuencia
tienen una influencia significativa sobre el proyecto.
 Gerentes de proyecto (técnicos), quienes deben planificar, motivar, organizar y
controlar a los profesionales que hacen el trabajo de software.
 Profesionales que aportan las habilidades técnicas que se necesitan para someter a
ingeniería un producto o aplicación.
 Clientes que especifican los requerimientos para el software que se va a fabricar, así
como otros participantes que tienen un interés periférico en el resultado.
 Usuarios finales, quienes interactúan con el software una vez que se libera para su
uso productivo.
Todo proyecto de software está poblado con personas que están dentro de esta taxonomía.2
Para ser efectivo, el equipo de software debe organizarse de manera que maximice las
habilidades y capacidades de cada persona. Y ésta es labor del líder del equipo.

Roles del personal y características

Siempre hay actividades que son necesarias para cualquier proyecto de software. Por
ejemplo, todo proyecto requiere de gente que interactúe con los clientes, para determinar
qué es lo que ellos quieren y para cuando lo quieren. Otras personas diseñan el sistema y
otros escriben y prueban los programas. Las actividades claves de un proyecto
probablemente incluyan las de:
1. Análisis delos requerimientos.
2. Diseño del sistema.
3. Diseño del programa.
4. Implementación del programa.
5. Prueba.
6. Entrenamiento.
7. Mantenimiento.
8. Aseguramiento de calidad.
Sin embargo, no todas las tareas son ejecutadas por la misma persona o el mismo grupo.
Las asignaciones del personal a las tareas dependen de la dimensión del proyecto, de la
pericia del personal y de su experiencia. Hay una gran ventaja de asignar responsabilidades
diferentes a diferentes grupos de personas, de tal modo que se pueden identificar fallas al
principio del desarrollo del proceso.
Una vez que se ha decidido acerca de los roles de los miembros del grupo del proyecto, se
debe decidir qué tipo de gente se necesita para cada rol. El personal del proyecto puede
diferenciarse en muchas formas y no es suficiente decir que un proyecto necesita un
14
analista, dos diseñadores y cinco programadores, por ejemplo. Dos personas con la misma
profesión pueden diferir en al menos uno de los siguientes aspectos:
 Capacidad para desempeñar un trabajo.
 Interés en el trabajo.
 Experiencia con sistemas similares.
 Experiencias con herramientas o lenguajes similares.
 Experiencia con técnicas similares.
 Experiencia con ambiente de desarrollo similar.
 Habilidad de comunicación.
 Habilidad para compartir responsabilidades con otros.
 Capacidad de gerenciamiento.
Cada una de estas características puede afectar la capacidad del individuo para
desempeñarse de una forma productiva. Estas variaciones ayudan a explicar por qué un
programador puede escribir una rutina particular en un día, mientras que otro necesita una
semana. Las diferencias pueden ser críticas, no sólo en la estimación del plan, sino en el
éxito del proyecto.
Para entender el desempeño de cada trabajador se debe conocer su capacidad para
ejecutar el trabajo en cuestión. Algunas veces, la capacidad está relacionada con la
comodidad. En los proyectos, se puede haber trabajado con personas que si sienten más
cómodas programando en un lenguaje que en otro.
Esta percepción de la comodidad es importante: la gente generalmente es más productiva
cuando tiene confianza en su capacidad para desempeñarse.
El interés en el trabajo también puede determinar el éxito de alguien en el proyecto. Es
importante que quien haya sido elegido para una tarea se sienta estimulado por su
desempeño, sin importar la razón por la cual fue elegido.
La selección del personal del proyecto involucra no solamente la capacidad individual, sino
también la experiencia y el entrenamiento.
Muchos proyectos involucran varias personas quienes deben compartir la responsabilidad
de completar una o más actividades. Aquellos que trabajan en un aspecto del desarrollo del
proyecto deben confiar en que los otros miembros del grupo realizarán su parte. Esto no
solo requiere de la comunicación verbal de ideas y de resultados, sino que también requiere
documentación escrita de lo que se planea hacer y de lo que se ha hecho. Se deben aceptar
los resultados sin rehacer su trabajo. Mucha gente tiene dificultad para compartir el control
de esta manera.
El control también es tema de discusión en la gestión de proyecto. Algunas personas son
buenas dirigiendo el trabajo de otras. Este aspecto de interacción personal también está
relacionado con la comodidad que siente la gente con el trabajo que tiene. Quienes no se
sientes cómodos con la idea de alentar a sus colegas para cumplir el cronograma, para que
documenten sus codificaciones o para reunirse con el cliente, no son buenos candidatos
para trabajos de desarrollo que impliquen dirigir a otros trabajadores.
15
Existen varios aspectos de la formación de los trabajadores que pueden afectar la calidad
del grupo de proyecto. Un gerente de proyecto debe conocer los intereses de cada persona
y sus capacidades cuando se elige con quién se trabajará.

Estilos de trabajo

Personas diferentes tienen estilos preferidos diferentes para interactuar con otras personas
y para entender los problemas que surgen en el curso de su trabajo. Por ejemplo, algunos
pueden preferir hacer un análisis detallado de toda la posible información antes de tomar
una decisión, mientras que un colega puede confiar en su intuición para tomar la mayoría
de sus decisiones importantes.
Jung (1959) denomina cuatro estilos básicos:
Los extrovertidos racionales: Tienden a mantener sus ideas y no permitir que una intuición
afecte las decisiones a tomar. Les dicen a sus colegas lo que los colegas quieren saber,
pero raramente piden más información antes de hacerlo. Cuando razonan confían en la
lógica no en la emoción.
Los introvertidos racionales: También evitan decisiones emocionales, pero ellos están
dispuestos a tomarse tiempo para considerar todos los posibles cursos de acción. Son
acopiadores de información, no se sienten seguros de tomar una decisión a menos que
estén convencidos de tener todos los hechos a la mano.
Los extrovertidos intuitivos: Basan muchas decisiones en reacciones emocionales y tienden
a querer comentar a los demás sobre éstas, más que a pedir opiniones. Ellos usan su
intuición para ser creativos y a menudo sugieren aproximaciones no usuales para solucionar
un problema.
Los introvertidos intuitivos: Es creativo, pero aplica la creatividad sólo después de haber
reunido suficiente información sobre la cual se basa una decisión.
Comprender los estilos de trabajo puede ayudar a ser flexible en el acercamiento a otros
miembros del grupo de proyecto y a los clientes y usuarios. En particular, los estilos de
trabajo dan información acerca de las prioridades de los otros. Si las prioridades e intereses
de un colega son distintas de las de uno, se le puede presentar información en función de
lo que considere importante.

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:

16
 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.

Figura 3. Ejemplos de diferentes tipos de riesgos

Luego hay que tabular los resultados de este proceso de análisis mediante una tabla
clasificada de acuerdo con la gravedad del riesgo. La figura 4 ilustra esto para los riesgos
que se identificaron en la figura 3. 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.

17
 Figura 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.

3.5.1 TIPOS DE RIESGOS

Cada uno de nosotros asume riesgos en su vida diaria. No se sabe dónde vive usted; pero
en la ciudad, solo para llegar al trabajo cada mañana constituye un riesgo. Entre los que se
pasan la luz roja, los que se cambian de carril rápidamente y furiosos conductores que están
al volante, es un milagro que pueda llegar allí con seguridad. Riesgo por definición es
incertidumbre y no es posible tener un proyecto, sin tener riesgo.
Los tipos de riesgos y sus indicadores potenciales son los siguientes:
 Tecnológico: Entrega tardía del hardware o software de soporte; muchos problemas
tecnológicos reportados.
 Personal: Baja moral del personal; malas relaciones entre miembros del equipo; alta
rotación del personal.
 De organización: Chismes en la organización; falta de acción de altos ejecutivos.
18
  Herramientas: Renuencia de los miembros del equipo para usar herramientas; quejas
acerca de las herramientas CASE; demandas por estaciones de trabajo mejor
equipadas.
 Requerimientos: Muchas peticiones de cambio de requerimientos; quejas de los
clientes.
 Estimación: Falla para cumplir con el calendario acordado; falla para corregir los
defectos reportados.

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

Aunque hay un considerable debate en torno a la definición propia para el riesgo de

software, existe un acuerdo general en que el riesgo siempre involucra dos características:
 Incertidumbre: el riesgo puede o no recurrir; esto es, no existen riesgos 100%
probables.
 Pérdida: si el riesgo se convierte en realidad, ocurrirán consecuencias o pérdidas
indeseables.

Identificación de riesgos

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: riesgos genéricos y riesgos específicos del producto. Los
riesgos genéricos son una amenaza potencial a todo proyecto de software. Los riesgos
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:
Tamaño del producto: riesgos asociados con el tamaño global del software que se va a
construir o a modificar.
Impacto empresarial: riesgos asociados con restricciones impuestas por la administración o
por el mercado.
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.

19
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.
Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas
por usar para construir el producto.
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.
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.

Impacto de riesgo

Es la cantidad de dolor que un evento de riesgo negativo puede causar o la cantidad de

ganancia que un resultado positivo pueda tener. El impacto es generalmente dependiente
del riesgo. Si quisiese determinar el impacto de la pérdida de un recurso clave; podría
aproximar la cantidad de tiempo que podría retrasarse el cronograma, mientras busca a
alguien con determinadas habilidades (y luego darle tiempo para que se ponga al día con el
proyecto). También, podría aproximar el costo asociado de retrasar las tareas.
El impacto puede ser expresado como un número o un valor. Los números son siempre
expresados en porcentajes que van desde 0.0 (significa que no hay probabilidad de que un
evento de riesgo ocurra) hasta 1.0 (es decir, hay una posibilidad de 100% de que el riesgo
ocurra. Los valores son, por lo general, medidos por una escala alta-media-baja o alguna
variación. Estos son aplicables a los proyectos pequeños y medianos e incluso grandes
proyectos dónde hay un número mínimo de riesgos.

Proyección del riesgo

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.
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.
20
 4. Valorar la precisión global de la proyección del riesgo de modo que no habrá malos
entendidos.
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.

3.5.3 EVALUACIÓN DEL RIESGO

La evaluación del riesgo del proyecto es una actividad que busca valorar el riesgo y prever
o establecer medidas que permitan disminuirlo. 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.
Debemos, también, describir aquellas soluciones o cambios que se han encontrado que
disminuyen el riesgo del proyecto, como, por ejemplo: la modificación de tiempos, los
recursos, los costos, la división del proyecto en subproyectos, el refinamiento del prototipo
o maqueta, etcétera.
Además, el análisis del riesgo de un proyecto debe expresarse en términos de pérdida de
dinero, porque nos permite evaluar el impacto y la atención que merece.
Hay dos momentos en los que se pueden determinar los factores de riesgo de un proyecto:
al inicio y durante el proyecto. En ambas etapas es conveniente que el equipo del proyecto
se reúna para analizar la situación y determinar el área crítica, los síntomas y la forma en
que se podría mitigar el riesgo.
La elección de la metodología que se va a aplicar para analizar el riesgo del proyecto
dependerá indiscutiblemente de la naturaleza del proyecto y del estilo de administración. La
regla por utilizar es: a mayor presupuesto de recursos más detalle y conciencia en el
análisis.
Contribuirá a disminuir el riesgo del proyecto una comunicación oportuna, participación
activa, procedimientos de evaluación y validación, contar con los recursos en el momento
en que se necesitan.

3.5.4 ESTRATEGIAS FRENTE AL RIESGO

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

21
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.
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 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 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 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 5.

Figura 5. Estrategias para ayudar a gestionar el riesgo.

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
22
riesgo cuando éste surja. Tales estrategias deben reducir el efecto global de un riesgo en el
proyecto o el producto.

3.6 ANÁLISIS DE LA VIABILIDAD DEL PROYECTO

Para administrar un proyecto de software exitoso, se debe comprender qué puede salir mal,
de modo que los problemas puedan evitarse. En un excelente ensayo acerca de los
proyectos de software, John Reel [Ree99] define 10 señales que indican que un proyecto
de sistemas de información está en peligro:
1. El personal del software no entiende las necesidades del cliente.
2. El ámbito del producto está pobremente definido.
3. Los cambios se gestionan pobremente.
4. Cambia la tecnología elegida.
5. Las necesidades empresariales cambian [o están mal definidas].
6. Las fechas límite son irreales.
7. Los usuarios son resistentes.
8. Pérdida de patrocinio [o nunca obtenido adecuadamente].
9. El equipo del proyecto carece de personal con habilidades adecuadas.
10. Los gerentes [y profesionales] evitan mejores prácticas y lecciones aprendidas.
Los profesionales de la industria, hastiados, con frecuencia se refieren a la regla 90-90
cuando estudian proyectos de software particularmente difíciles: el primer 90 por ciento de
un sistema absorbe el 90 por ciento del esfuerzo y tiempo asignados. El último 10 por ciento
toma otro 90 por ciento del esfuerzo y tiempo asignados. Las semillas que conducen a la
regla 90-90 están contenidas en las señales anotadas en la lista anterior.
Se sugiere un enfoque de sentido común de cinco partes en los proyectos de software:
1. Comenzar con el pie derecho. Esto se logra al trabajar duro (muy duro) para entender
el problema que debe resolverse y luego establecer objetivos y expectativas realistas
para todos aquellos que estarán involucrados en el proyecto. Lo anterior se refuerza al
construir el equipo correcto y darle autonomía, autoridad y tecnología necesarias para
realizar el trabajo.
2. Mantener la cantidad de movimiento. Muchos proyectos parten hacia un buen comienzo
y luego lentamente se desintegran. A fin de mantener la cantidad de movimiento, el
gerente de proyecto debe proporcionar incentivos para mantener la rotación de personal
en un mínimo absoluto, el equipo debe enfatizar la calidad en cada tarea que realice y
el administrador ejecutivo debe hacer todo lo posible para permanecer fuera del camino
del equipo.
3. Siga la pista al progreso. Para un proyecto de software, el progreso se rastrea conforme
los productos operativos (por ejemplo, modelos, código fuente, conjuntos de casos de
prueba) se producen y aprueban (usando revisiones técnicas) como parte de una
actividad que asegure la calidad. Además, pueden recopilarse medidas de proceso de
software y proyecto y usarse para valorar el progreso contra promedios desarrollados
para la organización de desarrollo del software.
23
4. Tome decisiones inteligentes. En esencia, las decisiones del gerente del proyecto y del
equipo de software deben “mantenerse simples”. Siempre que sea posible, decida usar
software comercial de anaquel, o componentes o patrones de software existentes, así
como evitar interfaces a la medida cuando estén disponibles enfoques estándar; decida
también identificar y luego evitar los riesgos obvios, y asignar más tiempo del que se
considere necesario para tareas complejas y riesgosas (necesitará cada minuto).
5. Realice un análisis postmortem. Establezca un mecanismo consistente para extraer
lecciones aprendidas por cada proyecto. Evalúe los calendarios planeado y real,
recopile y analice métricas de proyecto de software, consiga retroalimentación de los
miembros del equipo y de los clientes, y registre los hallazgos en forma escrita.

CONCLUSIONES
Conclusión personal Cruz Martínez Jaime
La planificación en cualquier campo es importante ya que es la base de lograr algo de la
manera más óptima posible disminuyendo todos los posibles errores que se presenten.
Durante la planificación del proyecto es muy importante tener en cuenta muchos factores,
de las cuales son sus objetivos, debemos tener claro cuáles son los objetivos del proyecto
y como vamos a llevarlos a cabo, esto llevado de la mano con las estimaciones.
Si tienes una planificación importante estas tendrán una mayor precisión. ya sea un proyecto
dirigido una empresa o hacia los clientes la gestión del tiempo debe ser lo más reducido sin
tomar riesgos, además el costo ya que durante este en la parte que “mueve” y sea posible
el proyecto con la ayuda del personal, de pendiendo de las áreas en la que laboren cada
uno tiene un papel importante para desarrollar el proyecto, si se tiene exceso serán gastos
innecesarios y si es menor el desarrollo será lento y no concordara con las estimaciones de
costo y tiempo teniendo mayores problemas.
Sin embargo, tener claro sus objetivos e estimaciones no es todo, ya que como mencione
siempre hay riesgos y debemos saber qué tipos de riesgos hay para estar preparados y
tomar las mejores decisiones.
Ya que los riesgos abarcan un amplio margen como de negocio, ventas, presupuesto etc.,
estos deben de identificarse lo más pronto posible, ya que solo tendrán un impacto negativo.
Si se presentan, la empresa debe de estar preparada para un posible cambio de planeación,
dando a una fase de evaluación donde se determina si ese cambio es viable o no.
Enfrentarse a problemas no es sencillo, mucho menos para grandes empresas ya que no
se pueden permitir este tipo de errores, pero cuando estos se presentan deben de tener
ciertas estrategias frente al problema. Con ayuda de la evaluación de riesgos tomar la mejor
decisión de menor costo y de mayor conveniencia. Sin embargo, todos estos pasos no
aseguran que la planeación de un proyecto sea lo más eficiente, ya que en ocasiones este
puede que no sea viable por mejor solido que se vea, por ende, tener una idea clara tomando
en cuenta todos los factores es de gran importancia dando a la planeación y al proyecto el
mejor futuro posible, cumpliendo con las expectativas planeadas, con las menores perdidas
posibles y que el cliente o clientes estén satisfechos con el producto final.

24
Conclusión personal Rodríguez Martínez Adriana
Durante el desarrollo de este trabajo me di cuenta de lo importante que es la planeación de
un proyecto, no solo es querer llevar a cabo una serie de actividades para llegar a una meta,
sino que es necesario pasar por muchos procesos los cuales son de muchísima importancia
para la realización de un buen proyecto.
Puedo decir que la planeación de un proyecto no es una tarea fácil, se necesita de mucho
personal que tenga los suficientes conocimientos en cada una de las tareas que se
desarrollaran durante el proceso, el personal es la clave del éxito.
También sé que no todos los proyectos son viables a realizarse algunos tienen más riesgos
que otros es por eso que antes de poner en marcha un proyecto se debe de analizar
cuidadosamente todos los beneficios y los problemas que podría causar y que se pueden
llegar a tener a lo largo del desarrollo del mismo.
Otro punto muy importante son los costos, pareciera que un proyecto no es costoso, pero
en realidad si lo es, y todo depende también del tamaño del proyecto, ya que entre más
grande es pues es más difícil de realizar y por lo tanto necesita de más herramientas
(tecnológicas), más personal etcétera.
Es muy importante realizar una buena planeación y tener a alguien que sea buen líder de
equipo frente al proyecto, ya que de esta planeación se derivan todos los tiempos en los
que se harán las tareas, cuando se entregaran avances, las pruebas y la fecha límite para
ser entregado al cliente.

Conclusión personal Salado Delgado Juan José Gabriel

Cuando se quiere realizar un proyecto es necesario tomar todas las medidas

correspondientes para que este sea desarrollado de la mejor manera posible y se obtengan
los mejores resultados.
En esta unidad aprendí acerca de la planeación de los proyectos, en general pienso que la
planeación es el pilar de cualquier buen proyecto que se haya realizado o que se quiera
realizar, es muy importante.
Durante toda nuestra vida hemos ido realizando pequeños proyectos y en cada uno de ellos
utilizamos la planeación para que estos sean llevados a cabo tal y como queremos y den
un buen resultado, así funcionan los proyectos que se hacen profesionalmente, solo que
aquí se tienen que documentar cada tarea que se realice.
Dentro de esta unidad también aprendí que el personal es muy importante para un proyecto,
se necesita de personal bien capacitado y que pueda desempeñar las tareas que se le
asignen sin ningún tipo de problema.

25
BIBLIOGRAFÍA

RICHARD FAIRLEY. (1994). INGENIERÍA DE SOFTWARE. MÉXICO D.F: Mc-GRAW-HILL.

pp. 50-51-66-67
PRESSMAN R. (1982). INGENIERÍA DE SOFTWARE UN ENFOQUE PRÁCTICO. MÉXICO
D.F: Mc-GRAW-HILL INTERAMERICANA. pp. 750-751-748-644.
ANGULO, L. (2013). GESTIÓN DE PROYECTOS BAJO EL ENFOQUE PMBOK. AV.
PASEO DE LA REPÚBLICA N. 5613, MIRAFLORES, LIMA, PERÚ: EDITORIAL MACRO.
pp. 119-124.
LAWRENCE S. (2002). INGENIERÍA DE SOFTWARE TEORÍA Y PRÁCTICA. AV.
REGIMIENTO DE PATRICIOS, BUENOS AIRES, REP. DE ARGENTINA: PRENTICE
HALL. pp. 130-103-104-105-106-107-108-109.
RODRÍGUEZ N. & MARTÍNEZ W. (2006). PLANIFICACIÓN Y EVALUACIÓN DE
PROYECTOS INFORMÁTICOS. SAN JOSÉ, COSTA RICA: EDITORIAL UNIVERSIDAD
ESTATAL A DISTANCIA. p.64
SOMMERVILLE I. (2011). INGENIERÍA DE SOFTWARE. MÉXICO: PEARSON. pp. 598-
599-600-601.
PRESSMAN R. (2002). INGENIERÍA DEL SOFTWARE, UN ENFOQUE PRÁCTICO
Séptima edición. MÉXICO, D.F: Mc-GRAW-HILL. pp. 642-643-644.

26