sistemas informaticos

2. Tabla de contenido
1. Introducción a la Gestión de Proyectos....................................................... 4
1.1. ¿Cómo empieza un proyecto? .............................................................. 4
1.2. La idea o necesidad inicial de un Proyecto Software puede partir de: .. 5
2. Proyectos de Software ................................................................................ 5
2.1. Elementos de un Proyecto .................................................................... 6
2.2. Acta de Constitución del Proyecto ........................................................ 7
2.3. La Gestión de Proyectos....................................................................... 8
2.4. Jerarquía de Planificaciones ................................................................. 9
Nivel Estratégico: ........................................................................................ 9
Nivel Táctico:............................................................................................... 9
Nivel Operativo:......................................................................................... 10
2.5. Actividades de Gestión........................................................................ 10
3. Planificación de Proyectos ........................................................................ 12
4. Plan de Proyecto....................................................................................... 13
4.1. Definición del Problema ...................................................................... 15
4.2. Problema en terminología del cliente: ................................................. 17
4.3. Descripción de la situación actual: ...................................................... 18
4.4. Metas del sistema ............................................................................... 18
4.5. Restricciones....................................................................................... 18
5. Desarrollo de una Estrategia de Solución ................................................. 19
5.1. Estrategias de Solución....................................................................... 20
6. Usos del Plan del Proyecto ....................................................................... 22
6.1. Fallas en la Planificación..................................................................... 23
6.2. Hitos y Entregas.................................................................................. 24

3. 7. Calendarización del Proyecto.................................................................... 25
8. Análisis de Riesgo..................................................................................... 27
9. Bibliografía ................................................................................................ 29
Índice de figuras
Figura 1 Inicio de un Proyecto............................................................................ 4
Figura 2 Planeación de un Proyecto de Software ............................................ 15
Figura 3 Hitos del Proceso de especificación de requerimientos ..................... 25
Figura 4 - Ejemplos de Calendario de Actividades........................................... 27
Índice de Tablas
Tabla 1 - Participantes del Desarrollo de Software .......................................... 22

4. 4
La gestión de proyectos, constituye parte esencial de la Ingeniería de software y
de todos los desarrollos profesionales de proyectos.
La gestión de proyectos nos ayuda a reconocer los desafíos que nos presenta el
cliente al momento de desarrollar un proyecto de software desde su comienzo
hasta la culminación del mismo.
La gestión de proyectos permite tener un mejor control de los recursos con los
que se cuenta para el desarrollo del proyecto, esto ayuda a poder alcanzar los
objetivos planteados por la organización.
En este capítulo hablaremos sobre el estudio preliminar, gestión de proyectos,
planificación de proyectos, calendarización, plan de proyectos, etc. En si los
temas más relevantes que abarca la gestión de un proyecto de software.
Figura 1 Inicio de un Proyecto

5. 5
o La comprobación de que el software existente ha quedado desfasado,
es decir, no cumple nuevos requisitos.
o Una petición específica de un cliente o usuario.
o Una propuesta generada dentro de la propia organización de
desarrollo.
o Una necesidad detectada por el departamento de ventas
o El personal de mantenimiento de las aplicaciones existentes, que
realiza una recomendación específica.
o Una conclusión a partir de la información obtenida de los usuarios.
Un proyecto es una asociación de esfuerzos, limitado en el tiempo, con un
objetivo definido, que requiere del acuerdo de un conjunto de especialidades y
recursos. También puede definirse como una organización temporal con el fin de
lograr un propósito específico. Cuando los objetivos de un proyecto son
alcanzados se entiende que el proyecto está completo.
Los proyectos informáticos obedecen a esta definición, pero además se
caracterizan por el impacto directo e indirecto que provocan en toda la
organización, la casi inevitable existencia de relaciones con otros proyectos
informáticos, el estar altamente propensos a sufrir de obsolescencia,
especialmente tecnológica y la intensa participación de recurso humano de
distintas áreas durante su desarrollo. (González, 2003)

6. Al definir un proyecto es necesario tener claridad sobre los puntos que se definen
6
a continuación:
→ Cliente: Persona a quien va dirigido el resultado del proyecto,
generalmente ellos presentan un problema que requiere solución.
→ Usuarios: Persona que utilizará el sistema o parte de él.
→ Inicio: Momento en que es expresada la necesidad específica en el cliente.
→ Término: Momento en que se cumple el resultado definido tanto en costo,
oportunidad, calidad o desempeño técnico.
→ Costo: Recurso o insumo entrante al proyecto, expresado generalmente
en dinero.
→ Tiempo: Recurso que origina una secuencia y luego un programa, es
transformable en costo. Se incorpora al proyecto en dos dimensiones: la
duración del esfuerzo y el momento en que éste se realiza.
→ Desempeño Técnico: Característica de los resultados expresados a
través de un prototipo, gráfico, índices y funcionamiento fiable en términos
de los objetivos intermedios y del objetivo final.
→ Jefe del Proyecto: Persona responsable del proyecto. Encargado de la
dirección del proyecto, su planificación y el control de todos los costos,
recursos, programas y de la satisfacción del cliente. (González, 2003)

7. 7
El acta de constitución es el documento que autoriza formalmente un proyecto.
Este documento es emitido por un iniciador o patrocinador, a un nivel apropiado
para la financiación del proyecto.
El director del proyecto debe ser identificado y nombrado lo antes posible, antes
del inicio de la planificación y, preferentemente, mientras se desarrolla el acta de
constitución del proyecto. Confiere al director del proyecto la autoridad para
asignar recursos de la organización a las actividades del proyecto.
En algunas organizaciones, un proyecto no se constituye e inicia formalmente
hasta no haber completado:
a) Una evaluación de las necesidades,
b) Un estudio de viabilidad,
c) Un plan preliminar o alguna otra forma equivalente de análisis que se haya
iniciado por separado.
d) De forma directa o mediante referencia a otros documentos, debe incluir:
a. Requisitos que satisfacen las necesidades, deseos y expectativas
del cliente, el patrocinador y demás interesados.
b. Necesidades de negocio, descripción a alto nivel del proyecto o
requisitos del producto que el proyecto debe abordar.
c. Finalidad o justificación del proyecto.
d. Director del Proyecto nombrado, y nivel de autoridad.
e. Resumen del cronograma de hitos.
f. Influencias de los interesados.

8. g. Organizaciones funcionales y su participación.
8
h. Asunciones de la organización, ambientales y externas.
i. Restricciones de la organización, ambientales y externas.
j. Oportunidades de negocio que justifican el proyecto, incluido el
retorno de la inversión (ROI).
k. Presupuesto resumido. (SOMMERVILLE, 2005)
La gestión de proyectos es la capacidad de identificar los desafíos que
proporciona el cliente o la organización, y así lograr encontrar, y evaluar las
múltiples posibles soluciones que tiene el problema, seleccionando la que más
se adapta a las necesidades del proyecto, consiguiendo eficacia y calidad para
luego realizarlo. Desarrollar un software implica la solución de problemas.
(Rolando, Honores Tapia, & Zea Ordóñez, 2015)
En la ingeniería de software es esencial contar con una buena gestión de
proyectos. Por lo que una mala gestión puede llevar al fracaso del proyecto. La
gestión de proyecto ayuda a realizar el seguimiento de los trabajos realizados
durante el proceso de desarrollo del software.
Se trata de un proceso continuo, el cual requiere de toda la herramienta necesaria
para poderla desarrollar de la mejor manera posible, es una tarea muy importante,
ya que esta comienza con un conjunto de actividades que se inician en la fase
de planificación del proyecto y continúa durante la fase de desarrollo del mismo.
El propósito de planificar y controlar es proveer una propuesta uniforme para el
desarrollo y la administración de los proyectos. Los planes deben apoyar los

9. niveles estratégicos, tácticos y operacionales de las organizaciones con el fin de
9
alcanzar las metas corporativas de largo, mediano y corto plazo.
El ciclo de vida involucrado en la gestión de proyectos, se conforma de dos
actividades a realizar: actividades de gestión y las actividades de desarrollo del
sistema.
Las actividades de gestión están enfocadas a la administración de las
organizaciones, personas, sistemas y procedimientos comprendidos en el
proceso de planificación y construcción del sistema.
Las tareas involucradas en el desarrollo del sistema se orientan al desarrollo
mismo. Las metodologías de desarrollo están constituidas en diferentes etapas,
agrupadas por áreas funcionales de estudio, diseño y construcción, basadas en
una estructura de partición del trabajo.
La administración y planificación de proyectos requiere de la integración de dos
modelos implícitos de trabajo, usualmente no reconocidos: el modelo de
administración y el modelo de desarrollo. (Rolando, Honores Tapia, & Zea
Ordóñez, 2015)
→ Propuestas a largo plazo (3-8 años), realizadas por la alta dirección y su
equipo de apoyo.
→ Los planes se centran en lo que debe hacerse para satisfacer las metas
de la organización. (Gómez, 2015)
→ Propuestas a medio plazo (1-3 años), realizadas por mandos intermedios.

10. → Planes dirigidos a desarrollar las capacidades necesarias para
10
implementar las estrategias de negocio. (Gómez, 2015)
→ Propuestas a corto plazo realizadas por supervisores y responsables
de áreas.
→ Planes dirigidos a establecer metas y estructuras productivas para los
equipos. Suelen estar basados en tareas y orientados a los resultados.
(Pressman, 2010)
El trabajo difiere enormemente dependiendo de la organización y del producto de
software a desarrollar. Sin embargo, en algún momento, muchos gestores son
responsables de algunas o de la totalidad de las siguientes actividades:
a. Redacción de la propuesta
b. Planificación y calendarización del proyecto
c. Estimación de costos del proyecto
d. Supervisión y revisión del proyecto
e. Selección y evaluación del personal
f. Redacción y presentación de informes.
La gestión de proyectos de software comprende una gran cantidad de
actividades, que contienen la planificación del proyecto, incluyendo el alcance del
mismo, estimando costes respecto a la asignación de tareas y gestión de
recursos durante el desarrollo del proyecto del software. (Rolando, Honores
Tapia, & Zea Ordóñez, 2015)

11. La ingeniería de software incluye actividades que van desde la recolección de
11
los requisitos del proyecto, análisis, gestión de procesos, calidad y riesgos, hasta
la puesta en marcha del proyecto de software. Dentro de las cuales la más
relevante es la de gestionar el proyecto de software.
Las actividades de la gestión de proyectos nos ayudan a cumplir con los objetivos
definidos en un tiempo establecido, utilizando recursos tanto humanos como
técnicos. (Rolando, Honores Tapia, & Zea Ordóñez, 2015)
La principales actividades son la de planificar, coordinar, seguimiento y controlar
todas las actividades que permitan el alcance del proyecto. Una de las principales
etapas es la de redactar la propuesta del proyecto ya que esto permite describir
los objetivos del mismo y como se llevaría a cabo para lograr cumplirlos. Lo que
incluye la estimación de costes, tiempo y alcance del proyecto.
La planificación del proyecto es una actividad que se realiza antes de la
producción del software. Determinando la hitos, entregas y orientación general
del responsable del proyecto para conseguir los objetivos establecidos por la
organización.
La supervisión del proyecto de software es el seguimiento que se hace del
mismo, el cual debe ser continuo. Comparando el progreso de las actividades
realizadas para el desarrollo del proyecto.
Durante un proyecto, es normal tener varias revisiones formales de su gestión.
Se hace la revisión completa del progreso y de los desarrollos técnicos del
proyecto, y se tiene en cuenta el estado del proyecto junto con los propósitos de
la organización que ha encargado el software.
El resultado de una revisión puede dar lugar a la cancelación del proyecto. El
tiempo de desarrollo para un proyecto grande de software puede ser de varios
años. Durante ese tiempo los objetivos organizacionales tienden obviamente a
cambiar, estos cambios pueden significar que el software ya no se necesita o que
los requerimientos originales del proyecto son inapropiados. La gestión

12. puede decidir parar el desarrollo del software o cambiar el proyecto para
12
adecuarlo a los cambios de los objetivos de la organización. (Rolando, Honores
Tapia, & Zea Ordóñez, 2015)
La gestión efectiva de un proyecto de software depende de planificar
completamente el progreso del proyecto. La planificación generalmente
comienza con el objetivo, en esta fase cada tarea y sub-tarea recibe un tiempo
razonable para su realización.
En esta fase se define el alcance del proyecto de software, por tanto, la
planificación debe ser clara y precisa, se determina los recursos, tiempo y
alcance esperados para la ejecución de cada una de las tareas y funciones
propuestas.
El proceso de planificación se inicia con una valoración de las restricciones que
afectan al proyecto (fecha de entrega requerida, personal disponible,
presupuesto global, etc.). Ésta se llevará a cabo en conjunto con una estimación
de los parámetros del proyecto, como su estructura, tamaño y distribución de
funciones. Entonces se definen los hitos de progreso y productos a entregar. En
ese momento, el proceso entra en un ciclo, se prepara un calendario para el
proyecto y las actividades definidas en el calendario se inician o se continúan.
(SOMMERVILLE, 2005)
Si el proyecto se retrasa, se tiene que renegociar con el cliente las restricciones
del mismo y las entregas. Si esta renegociación no tiene éxito y no se puede
cumplir con el calendario, se debe llevar a cabo una revisión técnica, cuyo
objetivo es encontrar un enfoque alternativo que se ajuste a las restricciones del
proyecto y se cumpla con las metas previstas en el calendario.

13. Durante el proyecto siempre surgen problemas, las suposiciones iniciales y el
13
calendario deben ser más bien pesimistas que optimistas. Debe haber suficiente
holgura para que las contingencias en el plan, las restricciones del proyecto y los
hitos no se tengan que negociar cada vez que se efectúa un ciclo en el plan.
El plan de proyecto es un documento formal aprobado y que define cómo debe
ser ejecutado, monitoreado y controlado el proyecto. Debe resumir los planes
subsidiarios, es decir, los planes específicos de manejo del tiempo, del
presupuesto y de la calidad del producto.
El plan de proyecto engloba la información relativa a la gestión del proyecto, es
decir, nuestro documento definirá y logrará comunicar el ámbito y recursos al
personal de desarrollo y a los clientes. Definiremos y sugeriremos técnicas de
control de riesgos, también definiremos los costes y planificación para la revisión
de la gestión.
Como parte principal, les proporcionaremos un enfoque general, para todo el
personal relacionado a este proyecto. Y por último describiremos como se
garantizará la calidad y se gestionarán los cambios en el mismo. (Rolando,
Honores Tapia, & Zea Ordóñez, 2015)
Los detalles del 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 (presupuesto, tiempo, etc.) que afectan a la gestión del
proyecto.
2. Organización del proyecto: describe la forma en que el equipo de desarrollo
está organizado, le gente involucrada y sus roles en el equipo.

14. 3. Análisis de riesgo: describe los posibles riesgos del proyecto, la
14
probabilidad que surjan estos riesgos y las estrategias de reducción de
riesgos propuestos.
4. Requerimientos de recursos de hardware y software: describe el hardware
y software de ayuda requeridos para llevar a cabo el desarrollo. Si es
necesario comprar el hardware, se deben incluir las estimaciones de los
precios y las fechas de entrega.
5. División del trabajo: describe la división del proyecto en actividades e
identifica los hitos y productos a entregar asociados a 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. Mecanismos 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.
En conclusión, el plan de proyecto es un documento clave a la hora de organizar
el trabajo en un desarrollo de software. Porque básicamente plasma sobre el
papel todos los recursos disponibles para realizar el desarrollo, y asigna tareas
específicas, con fechas precisas y mecanismos concretos de control y
seguimiento. (Rolando, Honores Tapia, & Zea Ordóñez, 2015)

15. 15
Figura 2 Planeación de un Proyecto de Software
Antes de poder planificar un proyecto se deberían establecer sus objetivos y su
ámbito, considerar soluciones alternativas e identificar las dificultades técnicas y
de gestión. Sin esta información es imposible definir estimaciones razonables de
costo, riesgo, esfuerzo, entre otros aspectos que conformen un proyecto.
(PINACHO, 2014)
El primer paso en la planeación del proyecto es Definir el Problema, para tal fin
el cliente o usuario y el desarrollador se reúnen para definir los objetivos del
proyecto y su ámbito. Las técnicas usuales que pueden aplicarse para definir el
problema son:
a) Las entrevistas con el cliente y las personas involucradas en el proceso.
b) La observación del proceso actual.
c) La identificación de tareas problemáticas.

16. d) En la entrevista el desarrollador puede iniciar preguntando:
16
e) ¿Qué problema resolverá la solución?
f) ¿De quién ha surgido la petición de este trabajo?
g) ¿Quién va a utilizar la solución?
h) ¿Puede mostrarme o describirme el entorno en el que se utilizará la
solución?
i) ¿Hay alguna limitación especial de rendimiento que vaya a afectar la
forma en que se enfoque la solución?
j) ¿La información que me proporciona es “oficial”?
k) ¿Hay alguien más que pueda proporcionar información adicional?
Esta serie de preguntas puede ayudar para que el cliente defina su problema,
exponga sus ideas y la percepción que tiene de la solución en software.
Para documentar la definición del problema se recomienda que primero se
prepare brevemente, en la terminología del cliente (PINACHO, 2014)
a) Un enunciado del problema que se solucionará
b) Una descripción de la situación actual
c) Las metas que debe lograr el sistema nuevo
d) Las restricciones impuestas en la solución, las cuales pueden ser de tipo:
1) Técnicas (un software para un sistema operativo determinado, o que deba
usarse un lenguaje especifico)
2) Tiempo (cuando el cliente impone una fecha para la entrega del software)
3) Económicas (presupuesto limitado)

17. 4) Equipo (limitantes en las que el software debe interactuar con un equipo
17
de características específicas)
5) Operativas (limitantes acerca del ambiente en que va a operar, tal como
el tipo de usuario, etc.)
Aquí le presento un ejemplo simplificado de
Definición del Problema
Hay un problema en el área de producto terminado, concretamente con la forma
en que se acomodan las cajas de producto para su almacenamiento. Hay tres
personas trabajando todo el día acomodando cajas en su correspondiente
compartimiento. Las cajas se las van aventando hasta que le llega al
acomodador, maltratando el producto. A veces cuando se termina su turno no
han acomodado ni la mitad de las cajas. Se necesita dar un mejor manejo a las
cajas, porque si se empiezan a maltratar desde antes de salir de la fábrica, hay
que imaginar cómo llegarán al consumidor final después de todo el manejo que
deben pasar.
Se piensa que instalando una cinta transportadora las cajas pueden viajar hasta
una estación de clasificación donde sean identificadas y ordenadas en uno de
los compartimentos al final de la cinta. Las cajas pueden llevar una etiqueta con
el código de barras del producto para que puedan ser identificadas rápidamente.
(PINACHO, 2014)

18. 18
En el área de producto terminado de la empresa X las cajas de producto salen
de la línea de producción y llegan aquí para almacenarlas. Las cajas se deben
acomodar en un compartimento específico que depende de su código de
producto. Como es una bodega donde la distancia del punto donde llegan las
cajas a los compartimentos es de unos 15 metros están tres personas, una en el
punto donde llegan las cajas, otro a la mitad del camino y el último en los
compartimentos. El primero toma una caja lee el código de producto, se lo
comunica al segundo al mismo tiempo en que se la avienta; el segundo recibe la
caja, busca en una lista el código y le comunica al tercero en cuál compartimento
debe ir al tiempo que le avienta la caja. El tercero recibe la caja y la acomoda en
el compartimento que le indicaron. (PINACHO, 2014)
1) Prescindir del elemento humano en este proceso.
2) Las cajas no deberán recibir maltrato al acomodarlas.
3) Las cajas deben estar acomodadas el mismo día en que llegaron.
a) Operativa: Llevar a cabo el proceso sin emplear personal.
b) Tiempo: Se requiere el nuevo sistema a lo más en 10 meses, cuando la
época pre-navideña empiece.

19. 19
El siguiente paso en la planeación de un proyecto de programación es determinar
lo apropiado de una solución computacional.
Un sistema que se acepta en costo, pero desplaza a muchos trabajadores puede
no ser aceptada política y socialmente por el usuario (por ejemplo: por problemas
sindicales, rechazo al cambio, etc.).
Algunas veces los sistemas computacionales se construyen para aliviar un
síntoma y no la causa primaria del problema. Esto ocurre cuando:
a) El problema se entiende, pero no puede resolverse debido a
circunstancias económicas, políticas o sociales.
b) Cuando el cliente no es capaz de comunicar el problema real.
c) Cuando el desarrollador no entiende la explicación del cliente sobre el
problema. (Gómez, 2015)

20. 20
Las estrategias de solución no se formulan describiendo detalladamente en que
consiste la solución, sino en describir las características generales que deberán
tener la posible solución.
Para formular una estrategia de solución debemos partir del hecho de que todos
los sistemas basados en computadora hacen uso de varios elementos del
sistema:
Software - Programas de computadora, estructuras de datos y su
documentación que sirven para hacer efectivo el método, procedimiento o control
que se requiera.
Hardware - Dispositivos electrónicos que proporcionan capacidad de cálculo y
dispositivos electromecánicos (ej. Sensores, motores, bombas) que proporcionan
una función externa.
Personas - Usuarios y operadores del hardware y el software.
Base de datos - Información organizada a la que se accede mediante el
software.
Documentación - Manuales, formularios y otra información descriptiva que
indica el uso y/o operación del sistema.
El ingeniero de sistemas puede obtener diversas estrategias de solución al hacer
asignaciones diferentes de las funciones del sistema a cada uno de los
elementos de un sistema basado en computadora. Es decir, se organizan las
funciones del sistema de tal manera que unas se asignan al software, otras al
hardware, otras a las personas, etc. De forma que se pueda obtener la función y
comportamiento esperados.

21. Cada asignación diferente representa una estrategia de solución. Al documentar
21
cada estrategia de solución se debe incluir:
a) Una descripción general de las características del producto
b) Las prioridades de cada una de las características.
c) Qué nuevas capacidades proporcionará el sistema.
d) Qué procesos se van a preservar y cuales se van a mejorar.
e) Qué aspectos de seguridad se manejarán.
f) Cuánto personal se requerirá para operar el sistema.
g) Ampliaciones posteriormente factibles.
Aquí le presento un ejemplo
simplificado de las estrategias de
solución formuladas para el problema
del almacén de producto terminado
Estrategia 1: Un operador estará situado en la estación de clasificación. El lee
las cajas y las coloca en el compartimento apropiado.
Observe que esta es una solución puramente manual pero efectiva. Aquí las
asignaciones de las funciones del sistema se han hecho a las Personas. Puede
ser necesaria alguna Documentación que relacione el número de identificación
con el compartimento.
Estrategia 2: Se coloca un lector de código de barras y un controlador
automático en la estación de clasificación. El código de barras se pasa al
controlador programable que controla un mecanismo de separación. El
separador desplaza la caja al compartimento apropiado.

22. Observe que esta es una solución totalmente automática, en la que se han
22
asignado las funciones del sistema al Hardware (lector de código de barras,
control programable, mecanismo de separación), al Software (para decodificar el
código de barras y el control programable) y a una Base de Datos (una tabla que
relaciona los códigos de identificación con los compartimentos). Es probable que
cada uno de ellos deba llevar sus propios instructivos como Documentación.
Estrategia 3: Se coloca un lector de código de barras y un controlador
programable en la estación de clasificación. La salida del código de barras se
pasa a un brazo de robot que toma la caja y la lleva al compartimento
correspondiente.
Observe que esta también es una solución totalmente automática, en la que se
han asignado las funciones del sistema al Hardware, al Software, a Base de
Datos y a la Documentación.
Los proyectos de Desarrollo de Software involucran a diversos participantes y
cada uno de ellos da un uso distinto al plan del proyecto. Tal como se resume en
la siguiente tabla:
Tabla 1 - Participantes del Desarrollo de Software

23. 23
Los problemas más comunes que enfrentan hoy en día los proyectos de
desarrollo de software, tales como: retrasos en la entrega del producto final,
aumento de los costos de desarrollo y mantenimiento y escasa calidad del
software, se deben principalmente a una mala o escasa planificación. (Gómez,
2015)
Las principales causas de las fallas en la planificación de proyectos de Desarrollo
de Software son las siguientes:
a) Inadecuada definición del proyecto.
b) Comprensión errónea del problema.
c) Desconocimiento o inexperiencia de cómo planificar.
d) Incumplimiento del ciclo de planificación.
e) Escasa negociación de compromisos con el usuario al inicio del proyecto
f) Definición incompleta de los requerimientos.
g) Estimaciones optimistas.
h) Supuestos y restricciones del proyecto inválidos o no verificados.
i) Aplicación errónea o no-utilización de la información histórica de la
organización.
j) Mala administración del proyecto.
k) Fallas en el uso de los planes.
l) Carencia de control de cambios.
m) Escasa motivación.

24. n) Estilo erróneo de liderazgo.
24
o) Carencia de control y gestión.
p) Organización errónea del grupo de trabajo. (Gómez, 2015)
Cuando se planifica un proyecto, se debe establecer una serie de hitos que son
puntos finales de una actividad del proceso del software. Los gestores necesitan
información para hacer su trabajo, como el software es intangible, esta
información sólo se puede proveer como documentos que describen el estado
del software que se está desarrollando.
Cuando se planifica un proyecto, se debe establecer una serie de hitos – puntos
finales de una actividad del proceso del software – en cada uno, debe existir una
salida formal como un informe, documentos cortos acerca de los logros en una
actividad del proyecto.
Una entrega es el resultado del proyecto que se entrega al cliente. De forma
general, se entrega al final de una fase principal del proyecto como la
especificación, el diseño, etc. En las entregas podemos encontrar la visión,
alcance y sus definiciones. Es muy importante que el documento de visión y
alcances no sea una imposición, debemos esforzarnos para que la visión la
compartan todos, la definición del problema, una revisión del proceso existente,
una definición general de los requerimientos de usuarios, como está estructurado
el proyecto, descripción de cada uno de los roles y una lista de los miembros que
lo conforman, las estructuras y los procesos estándar que debe seguir el equipo.
(Gómez, 2015)

25. Como regla general, las entregas son hitos, pero éstos no son necesariamente
25
entregas. Dichos hitos pueden ser resultados internos del proyecto que son
utilizados por el gestor para verificar el progreso del mismo pero que no se
entregan al cliente.
Para establecer los hitos, el proceso del software debe dividirse en actividades
básicas con sus salidas básicas. Por ejemplo, la siguiente figura muestra las
actividades involucradas en la especificación de requerimientos cuando se utiliza
la construcción de prototipos para ayudar a validar dichos requerimientos.
Figura 3 Hitos del Proceso de especificación de requerimientos
La calendarización del proyecto 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.
Alguna vez se le preguntó a Fred Brooks cómo es que los proyectos de software
se atrasan en su calendario. Su respuesta fue tan simple como profunda: “un día
a la vez”.

26. La realidad de un proyecto técnico es que cientos de pequeñas tareas deben
26
ocurrir para lograr una meta más grande. Algunas de esas tareas yacen fuera de
la corriente principal y pueden completarse sin preocuparse acerca de su impacto
sobre la fecha de conclusión del proyecto. Otras se encuentran en la “ruta crítica”.
Si las tareas “críticas” se retrasan en el calendario, la fecha de conclusión de todo
el proyecto se pone en riesgo. (Gómez, 2015)
La calendarización del proyecto de software es una acción que distribuye el
esfuerzo estimado a través de la duración planificada del proyecto, asignando el
esfuerzo a tareas específicas de ingeniería del software. Al estimar la
calendarización, los gestores no deben suponer que cada etapa del proyecto
estará libre de problemas, ciertas partes podrían ser más complicadas y llevarían
más tiempo del que se estimó originalmente.
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 depende del tipo de proyecto, de los parámetros del proceso, de la
calidad y experiencia de los ingenieros de software que trabajen en el proyecto.
Para aprender a crear tu diagrama de Gantt puede acceder al siguiente canal de
YouTube haz clic

27. 27
Figura 4 - Ejemplos de Calendario de Actividades
Una tarea importante es anticipar los riesgos que podrían afectar a la
programación del proyecto o a la calidad del software a desarrollar y emprender
acciones para evitar esos riesgos. Los resultados de este análisis de riesgos se
deben documentar a lo largo del plan del proyecto junto con el análisis de
consecuencias cuando el riesgo ocurra.
De forma simple, se puede concebir un riesgo como una probabilidad de que una
circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto,
para el software que se está desarrollando y para la organización.
Si un programador experto abandona el proyecto, esto es un riesgo para el
proyecto (debido a que la entrega del sistema se puede retrasar), para el
producto (debido a que un sustituto puede no ser tan experto y cometer muchos

28. errores) y para el negocio (debido a que esa experiencia puede no contribuir a
28
negocios futuros).
Es preciso anticiparse a los riesgos, comprender el impacto de éstos en el
proyecto, en el producto y en el negocio, considerar los pasos para evitarlos. En
el caso de que ocurran, se deben crear planes de contingencia para que sea
posible aplicar acciones de recuperación.
En primer lugar se debe identificar el posible riesgo del proyecto, que se puede
llevar a cabo a través de un proceso de grupo utilizando un enfoque de tormenta
de ideas o simplemente puede basarse en la experiencia. Para ayudar al
proceso, se utiliza una lista de posibles tipos de riesgo que pueden ser:
a) Riesgos de tecnología: se derivan de las tecnologías de software o de
hardware utilizadas en el sistema que se está desarrollando.
b) Riesgos de personal: riesgos asociados con las personas del equipo de
desarrollo.
c) Riesgos organizacionales.: se derivan del entorno organizacional donde
el software se está desarrollando.
d) Riesgos de herramientas: se deriva de herramientas y software de apoyo
utilizado para desarrollar el sistema.
e) Riesgos de requerimientos: se derivan de los cambios de los
requerimientos del cliente y el proceso de gestionar dicho cambio.
f) Riesgos de estimación: se derivan de los estimados administrativos de las
características del sistema y los recursos requeridos para construir dicho
sistema.
Se considera por separado cada riesgo identificado y se decide acerca de la
probabilidad y la seriedad del mismo. No existe una forma fácil de hacer esto, en
cuanto surja más información acerca de los riesgos, éstos deben analizarse
nuevamente y se deben establecer nuevas prioridades. La prevención de riesgos
y los planes de contingencia se deben modificar tan pronto como surja nueva
información de los riesgos.

29. 29
Gómez, V. (16 de Julio de 2015). Introducción a la Gestión de Proyectos.
Obtenido de https://instintobinario.com/introduccion-a-la-gestion-de-
proyectos/
González, A. B. (2003). Gestión de Proyectos de Software. Junio.
PINACHO, U. (29 de Noviembre de 2014). https://urielpinacho.wordpress.com/.
Obtenido de https://urielpinacho.wordpress.com/2014/11/29/definicion-
del-problema/
Pressman, R. S. (2010). Ingeniería del Software. Un enfoque prático. D.F.,
Colonia Desarrollo Santa Fe,, México: Mc Graw Hill.
Rolando, M. R., Honores Tapia, J. A., & Zea Ordóñez, M. P. (2015). Nociones de
Ingeniería de Software. MACHALA: UTMACH.
SOMMERVILLE, I. (2005). Ingeniería del software. Madrid: 7ma.