Guia A Distancia de Gestion de Proyectos

NDICE
PRELIMINARES
BIMESTRE
PRIMER
Informtica
SEGUNDO
BIMESTRE
SOLUCIONARIO
Modalidad Abierta y a Distancia
BIBLIOGRFICAS
REFERENCIAS
Gestin de Proyectos Informticos
Texto Gua
4 crditos
Ciclo Titulacin
6 Informtica
La Universidad Catlica de Loja
rea Tcnica
NDICE
PRELIMINARES
MODALIDAD ABIERTA Y A DISTANCIA
Departamento de Ciencias de la Computacin y Electrnica

Seccin Ingeniera del Software y Gestin de Tecnologas de la
Informacin
BIMESTRE
PRIMER
Texto-Gua
4 crditos
SEGUNDO
BIMESTRE
SOLUCIONARIO
Titulacin Ciclo
VI
BIBLIOGRFICAS
REFERENCIAS
Informtica
Autora:
Karla Romero Gonzalez
Asesora virtual:
La Universidad Catlica de Loja
www.utpl.edu.ec
NDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
Texto-Gua
REFERENCIAS
Karla Romero Gonzalez
UNIVERSIDAD TCNICA PARTICULAR DE LOJA
CC 4.0, CC BY-NY-SA
Diagramacin, diseo e impresin:
EDILOJA Ca. Ltda.

Telefax: 593-7-2611418
San Cayetano Alto s/n
www.ediloja.com.ec
edilojainfo@ediloja.com.ec
Loja-Ecuador
Primera Edicin
ISBN digital - 978-9942-25-245-6
La versin digital ha sido acreditada bajo la licencia Creative Commons 4.0, CC BY-NY-SA: Reconocimiento-No comercial-Compartir igual; la
cual permite: copiar, distribuir y comunicar pblicamente la obra, mientras se reconozca la autora original, no se utilice con fines comerciales
y se permiten obras derivadas, siempre que mantenga la misma licencia al ser divulgada. https://creativecommons.org/licenses/by-nc-
sa/4.0/deed.es
Octubre, 2017
2. ndice
NDICE
PRELIMINARES
2. ndice......................................................................................................................................................... 4
3. Introduccin......................................................................................................................................... 6
4. Bibliografa........................................................................................................................................... 7
BIMESTRE
PRIMER
4.1. Bsica............................................................................................................................................................... 7
4.2. Complementaria........................................................................................................................................ 7
5. Orientaciones generales para el estudio.......................................................................... 10
5.1. Materiales...................................................................................................................................................... 10
SEGUNDO
BIMESTRE
5.2. Cmo estudiar?......................................................................................................................................... 10
5.3. Apoyo tecnolgico e interactividad................................................................................................... 11
6. Proceso de enseanza-aprendizaje para el logro de competencias............. 13
PRIMER BIMESTRE
SOLUCIONARIO
UNIDAD 1. INTRODUCCIN A LA GESTIN DE PROYECTOS ASPECTOS
FUNDAMENTALES.............................................................................................................................. 13
1.1. Atributos de un proyecto........................................................................................................................ 14
BIBLIOGRFICAS
1.2. Conceptos bsicos y comunes de un proyecto.............................................................................. 15
REFERENCIAS
1.3. Restricciones en la Gestin de Proyectos......................................................................................... 16
1.4. Ciclo de vida del proyecto....................................................................................................................... 17
1.5. Factores crticos de xito de un proyecto......................................................................................... 20
1.6. Otros aspectos claves en la gestin de proyectos........................................................................ 21
1.7. Ejemplos de proyectos informticos................................................................................................. 25
Autoevaluacin 1 ...................................................................................................................................................... 27
UNIDAD 2. LINEAMIENTOS PARA FORMULACIN DE PROYECTOS ASPECTOS

FINANCIEROS...................................................................................................................................... 29
2.1. Identificacin de ideas para proyectos............................................................................................. 29
2.2. Componentes de un proyecto: viabilidad - factibilidad............................................................ 33
2.3. Componentes de un proyecto informtico estructura de costes de un proyecto..... 34
2.4. Ejemplo de estudio financiero sitio de venta online.............................................................. 37
Autoevaluacin 2 ...................................................................................................................................................... 38
NDICE
UNIDAD 3. LA ESTIMACIN DE RIESGO EN UN PROYECTO........................................................ 40
3.1. Los Tres Ejes................................................................................................................................................... 40
3.2. El modelo de desarrollo........................................................................................................................... 41
PRELIMINARES
3.3. El modelo de anlisis................................................................................................................................ 42
3.4. El modelo de control................................................................................................................................. 43
3.5. La estimacin de riesgos......................................................................................................................... 45
3.6. Caso de estudio Estudio de riesgos para el proyecto de CRM............................................ 48
Autoevaluacin 3 ...................................................................................................................................................... 49
BIMESTRE
PRIMER
SEGUNDO BIMESTRE
UNIDAD 4. INICIAR Y ANALIZAR UN PROYECTO.......................................................................... 51

4.1. Iniciar un proyecto..................................................................................................................................... 51
SEGUNDO
BIMESTRE
4.2. Primeras decisiones o actividades...................................................................................................... 52
4.3. La estructuracin del proyecto............................................................................................................. 54
4.4. Caso de estudio Arrancar el proyecto de control de actividad........................................... 58
4.5. El anlisis de la solucin.......................................................................................................................... 58
4.6. Modelo de desarrollo Merise................................................................................................................ 59
SOLUCIONARIO
4.7. Modelo UML (Unified Modeling Language).................................................................................. 60
4.8. Caso de estudio: Anlisis del proyecto de control de calidad.................................................. 61
Autoevaluacin 4 ...................................................................................................................................................... 62
UNIDAD 5. EL DESARROLLO DEL PROYECTO LA PLANIFICACIN Y LA ESTIMACIN........ 64
BIBLIOGRFICAS
REFERENCIAS
5.1. Ejecucin de un proyecto generalidades.................................................................................... 64
5.2. Gestin del proyecto en el da a da................................................................................................... 65
5.3. Desarrollo de un proyecto de software............................................................................................ 66
5.4. Caso de estudio: El desarrollo del proyecto de control de actividad.................................... 70
5.5. La planificacin del proyecto................................................................................................................. 70
5.6. Caso de estudio: La planificacin del proyecto de control de actividad............................. 78
Autoevaluacin 5 ...................................................................................................................................................... 79
UNIDAD 6. EL SEGUIMIENTO Y CONTROL...................................................................................... 81

6.1. Seguimiento y control del proyecto................................................................................................... 81
6.2. Cierre del proyecto..................................................................................................................................... 88
6.3. Caso de estudio: Seguimiento del control de calidad................................................................ 90
Autoevaluacin 6 ...................................................................................................................................................... 92
7. Solucionario.......................................................................................................................................... 94
8. Referencias Bibliogrficas.......................................................................................................... 100
Texto-Gua: Gestin de Proyectos Informticos PRELIMINARES
3. Introduccin
NDICE
El componente acadmico de Gestin de Proyectos Informticos consta de 4 crditos y es parte del
grupo de componentes genricos de la titulacin de Informtica en la modalidad de estudios Abierta y
a Distancia.
PRELIMINARES
Este componente se imparte con el objetivo de incorporar en el profesional en formacin los conocimientos
bsicos necesarios que se necesitan para una correcta gestin de proyectos informticos. La gestin de
proyectos, en forma general, es una disciplina de gestin que se est usando muy frecuentemente hoy
en da en el entorno empresarial y consiste en la aplicacin de conocimientos, metodologas, tcnicas y
herramientas para la definicin, planificacin y realizacin de actividades con el objeto de transformar
BIMESTRE
PRIMER
objetivos o ideas en realidades, en el caso de este componente, se aplica el mismo concepto de gestin
de proyectos, pero orientado a la generacin de productos o servicios informticos.
Como lo cita HORINE (2009) las empresas tienen que adaptarse a un mercado ms global, competitivo
y demandante, mucho ms si hablamos de empresas de desarrollo de software o de cualquier tipo de
proyecto informtico, el avance de las TI, genera an ms el sentido competitivo, por lo que se debe
SEGUNDO
BIMESTRE
innovar, se debe responder rpidamente a los cambios y aqu es donde interviene una correcta gestin
de proyectos.
La gestin de proyectos puede ser aplicada a un proyecto de cualquier naturaleza, pero nuestro estudio
est orientado, exclusivamente a conocer cmo se desarrolla una correcta gestin de proyectos en el
SOLUCIONARIO
entorno de la informtica.
Sin embargo, es de nuestro inters despertar en el profesional en formacin la necesidad de conocer ms

por desarrollar a fondo este tema, e incluso que pueda ser parte de la formacin complementaria que
como profesionales tenemos, a travs de una de las certificaciones ms reconocidas a nivel mundial como
es la otorgada por el Project Management Institute - PMI, el PMP o Project Management Professional.
BIBLIOGRFICAS
REFERENCIAS
La gua est comprendida por 6 unidades que sern abordados de la siguiente manera:
Primer Bimestre - centrado en las siguientes temticas:
Introduccin a la gestin de proyectos Aspectos fundamentales

Lineamientos para formulacin de proyectos Aspectos financieros
La estimacin de riesgo en un proyecto
Segundo bimestre centrado en las siguientes temticas:
Iniciar y analizar un proyecto

El desarrollo del proyecto La planificacin y la estimacin
El seguimiento y control
Por tanto, estimado estudiante le motivo y le invito a seguir la gua como material de apoyo a su proceso
de estudio, junto con el estudio del texto bsico, as como el desarrollo de las actividades propuestas
tanto en la gua como en el EVA, pues los conocimientos adquiridos en el desarrollo de la materia
ayudarn al desarrollo de competencias que le sern de gran valor en su vida profesional.
6 MODALIDAD ABIERTA Y A DISTANCIA

4. Bibliografa
NDICE
4.1. Bsica
PRELIMINARES
Gurin, B.A. (2015). Gestin de proyectos informticos - Desarrollo, anlisis y control. Madrid: ENI.
En este texto bsico se presentan todas las etapas de un proyecto, desde un ngulo prctico,
relacionando las reglas prcticas con ejemplos reales. Se analizan las explicaciones de principio
a fin y los paradigmas listos para utilizar, para permitir a los jefes de proyecto tomar sus
propias decisiones, con todo conocimiento de causa. Los informticos y profesionales que estn
BIMESTRE
PRIMER
implicados en un proyecto informtico, encontrarn respuesta a las preguntas ms habituales
y que les afectan diariamente (gestin de peligros, recursos, estimacin, planificacin, riesgos,
aspectos funcionales...). El libro aborda los aspectos financieros (presupuestos, business cases y
control de gestin) y la asuncin del riesgo (anlisis y plan de gestin), para el control del proyecto.
Romero, K. (2017). Guia de Proyectos Informticos. Ecuador: EdiLoja.
SEGUNDO
BIMESTRE
Esta gua pretende ser una herramienta de acompaamiento al estudiante durante todo el ciclo
de estudio, dando pautas de estudio y recursos educativos para contextualizar de mejor manera
los temas estudiados en el componente de Gestin de Proyectos Informticos.
SOLUCIONARIO
4.2. Complementaria
Ramn, J., Garca, J., y Lamarca, I. (2007). Gestin de proyectos informticos: mtodos, herramientas
y casos. Barcelona: UOC.
BIBLIOGRFICAS
REFERENCIAS
Este texto presenta los conceptos bsicos de la gestin de proyectos y los adapta a los proyectos
informticos, lo cual permite a los estudiantes de Informtica entender de mejor manera la
metodologa planteada.
Mendez, R. (2014). Formulacin y Evaluacin de Proyectos. Bogot: ICONTEC INTERNACIONAL.

Este texto es una gua metodolgica para estructurar proyectos desde la formulacin del proyecto
en base a ideas, identificar las etapas de desarrollo de un proyecto, las herramientas que utilizan,
hasta comprender los conceptos bsicos de la Gerencia de Proyectos.
Prez, A., y Salazar, N. (2006). Metodologas para el desarrollo de sistemas. Caso de estudio: Mtrica II
y MERISE. Universidad Autnoma del Estado de Hidalgo, Instituto de ciencias bsicas e ingeniera.
Estado de Hidalgo: SN.
Este texto comprende la explicacin de las etapas que la metodologa MERISE requiere para su
desarrollo.
Project Management Institute, Inc. (2013). Fundamentos para la direcccin de proyectos (Gua
PMBOK): Pensilvania.
El PMI es el organismo lder en temas de gestin de proyectos. Propone la metodologa de PMBOK

ampliamente utilizada especialmente en Latinoamrica. Gran parte de la gua se ha desarrollado
en funcin de los lineamientos citados en PMBOK.

Recursos Educativos Abiertos (OCW):
DE LOS ROS, I., & CAZORLA, A. (n.d.). OCW UPM. Retrieved Noviembre 2011, from Proyectos de
NDICE
Desarrollo Rural I: http://ocw.upm.es/proyectos-de-ingenieria/proyectos-de-desarrollo-rural-i/
material-de-clase
Presenta un ejemplo claro del manejo de indicadores de evaluacin de proyectos.
PRELIMINARES
Nathaniel, O. (2004). OCW MIT. Retrieved Noviembre 2011, from http://ocw.mit.edu/courses/
civil-and-environmental-engineering/1-040-project-management-spring-2004/lecture-notes/
l18riskmgtreview.pdf
Presenta el alcance de la gestin de riesgos y el estudio detallado de este proceso.
BIMESTRE
PRIMER
SNCHEZ BARREIRO, P. (2011). Gestin de riesgos en proyectos de Software, Universidad de
Cantabria. Retrieved Noviembre 2011 from http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-
del-software-ii/materiales/tema7-gestionRiesgos.pdf
Proceso completo de gestin de riesgos con ejemplos claros del anlisis cuantitativo y cualitativo.
SEGUNDO
BIMESTRE
FRANC, J. (2010). Risk Management. Retrieved Noviembre 23, 2011, from http://www.slideshare.
net/francjohn/project-risk-management-3948403
Presentacin que ejemplifica la gestin de riesgos de un proyecto.
SOLUCIONARIO
Guarna, P., & Bernardo, O. (2010). Facultad de Ingeniera - Universidad de Buenos Aires. Recuperado
de Facultad de Ingeniera - Universidad de Buenos Aires: http://web.fi.uba.ar/~bortega/apunte_
calidad_codigo.pdf
Es un documento donde se describen los conceptos bsicos para la calidad de cdigo.
BIBLIOGRFICAS
Direcciones Electrnicas:
REFERENCIAS
Mulcahy, R. (2017). RMC Learning Solutions. Minnesota, USA: RMC. Recuperado de http://www.
rmcproject.com/index.aspx
Material de estudio sobre el tema y preparacin para la certificacin de PMPMI, Inc. (2017). Project
Management Institute. Pennsylvania, USA: PMI. Recuperado de http://www.pmi.org/
A. Se presenta la metodologa del PMBOK
Lider de Proyecto (2016). reas de Conocimiento. Mxico. DF. Recuperado de http://www.

liderdeproyecto.com/
Material de estudio de diversas metodologas giles de gestin de proyectos.
The PMI Agile Agile Community of Practice. (2009). Welcome to the old PMI Agile Community of
Practice Wiki. Recuperado de http://agile-pm.pbworks.com/w/page/1526573/FrontPage
Presentacin de comunidad, foros y discusin de la metodologa gil de gestin de proyectos.
Critical Tools, Inc. (2016). About Critical Tools Project Plannig Software. Recuperado de Critical
Tools Project Plannig Software: http://www.criticaltools.com/about.html

Sitio web que ofrece varias herramientas para la gestin de proyectos. Principalmente WBS Chart
Pro y PERT chart Expert.
NDICE
Salido, M. J. (2009). Gestin de Proyectos Reunin de Kickoff. Recuperado de Slideshare: https://
www.slideshare.net/Odilas/gestin-de-proyectos-reunin-de-kickoff-1270236
En la presentacin se incluyen los objetivos claves para realizar exitosamente la reunin de
PRELIMINARES
lanzamiento del proyecto.
Martn, Q. (2002). Departamento de Informtica: UV. Recuperado de Universidad de Valencia:

http://informatica.uv.es/iiguia/2000/IPI/material/tema8.pdf
Documento que desarrolla el proceso de cierre de un proyecto informtico y sugiere plantillas de

uso.
BIMESTRE
PRIMER
Advenio strategy&business design. (2016). Estructura de costes de tu empresa. Recuperado de
http://advenio.es/la-estructura-de-costes-de-tu-empresa/
Sitio web donde se encuentra de manera explicativa la estructura de costes de una empresa.
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS

5. Orientaciones generales para el estudio
NDICE
Estudiar a distancia es un reto que requiere esfuerzo, dedicacin y sobre todo organizacin, es por ello
que debe hacer de esta actividad un trabajo continuo y sistemtico, organice su tiempo de manera que
pueda verdaderamente aprovechar y participar en cada una de las actividades que se estn proponiendo,
PRELIMINARES
tanto actividades sncronas (VideoColaboracin, Chat, Video conferencia) y de actividades asncronas
(Foro, cuestionarios), desarrollo de temticas de ensayo, etc.
Como estrategia de estudio de este componente acadmico se hace referencia en esta gua didctica
algunos casos de estudio que se encuentran detallados en el texto bsico. Algunos casos prcticos son
con valores supuestos, pero no muy lejanos de la realidad, con el fin de dar a usted un conocimiento
BIMESTRE
PRIMER
terico-prctico y aplicativo.
No olvide que en este proceso de estudio no est solo y que cuenta con horas de tutora destinadas
para que usted pueda resolver dudas o dar sus comentarios respectivos al componente. Los medios de
comunicacin a estas tutoras son por medios accesibles: telfono, Skype, correo electrnico.
SEGUNDO
BIMESTRE
Tome en cuenta estas orientaciones que le servirn en su proceso de aprendizaje:
5.1. Materiales
SOLUCIONARIO
Para su estudio usted dispondr del texto bsico, mencionado en la bibliografa y la gua didctica.
La gua didctica ser un instrumento de orientacin para estudiar los temas del texto bsico y
especificar algunos puntos donde se necesita mejor comprensin y apoyo.
Es importante que adems del texto bsico complemente su estudio con el material
complementario sugerido en el apartado de bibliografa y con recursos disponibles en Internet
BIBLIOGRFICAS
REFERENCIAS
as como los Recursos Educativos Abiertos.
Las actividades para evaluacin continua como las actividades sincrnicas o asincrnicas,
cuestionarios y ensayos, deben desarrollarse de manera obligatoria, puesto que esto garantizar
que usted est preparado para el examen presencial y evitar esfuerzos de ltimo instante.
Para reforzar el proceso de aprendizaje usted tiene un profesor-tutor que le guiar en el ciclo
acadmico; al cual podr hacer las consultas que requiera en un horario que oportunamente se
estar publicando. Las tutoras las puede hacer mediante el EVA, correo electrnico o directamente
a travs de la lnea telefnica, as que aproveche esta alternativa que la UTPL pone a su disposicin.
5.2. Cmo estudiar?
Este proceso de estudio requiere de su parte una dedicacin constante al mismo, por lo cual le sugerimos:
Programe un horario de estudio diario; para esta asignatura es necesario que dedique al menos
una hora diaria de autoestudio.
Para ayudarse en el proceso de aprendizaje utilice las tcnicas de estudio que ms se adapten a su
manera de aprender: subrayado, resmenes, cuadros sinpticos y trate, en lo posible, de estudiar
en un horario y ambiente adecuado.

Como una estrategia de aprendizaje le sugiero realice todas las autoevaluaciones y ejercicios que
se plantean en la presente gua as como algunos planteamientos del texto bsico, ya que esto le
NDICE
permitir poner en prctica los conocimientos tericos de la asignatura. No olvide que si surge
alguna inquietud con respecto a estos ejercicios, puede pedir asesora al profesor-tutor.
Es importante que revise el Plan Docente de este componente acadmico que estar compartido
en la respectiva aula virtual. En este documento es donde se especifica el tiempo que debe
PRELIMINARES
dedicar al estudio del componente por unidad, as como las competencias que va adquirir y los
indicadores de aprendizaje que se evaluarn.
5.3. Apoyo tecnolgico e interactividad
Para usted ya es familiar que cuenta con el apoyo tecnolgico de una plataforma o entorno virtual de
BIMESTRE
PRIMER
aprendizaje EVA: www.utpl.edu.ec/eva3, este entorno, accesible nicamente para los estudiantes de la
UTPL, le permite interactuar con docentes y compaeros. Adems se dispone de la biblioteca virtual UTPL,
repositorio de documentos (OCW), entre otros que se citan en la gua o que sern publicados a travs
del EVConsulte con frecuencia el espacio ANUNCIOS donde encontrar informacin y orientaciones
sobre el desarrollo semanal de este componente, as como recursos que sern subidos en las respectivas
SEGUNDO
BIMESTRE
unidades de estudio, Revise por favor los microvideos, donde el profesor indica lineamientos bsicos
para comprender el tema de estudio.
Para orientar su estudio, a lo largo de la gua hemos utilizado los siguientes smbolos:
SOLUCIONARIO
Smbolo Significado
Recomendaciones de lectura dirigidas al texto bsico.
BIBLIOGRFICAS
REFERENCIAS
Analoga al mundo real respecto al tema de estudio.
Preguntas que surgen del estudio previo de un tema.
Enfatizar temas importantes que debe recordar en el

transcurso del estudio de este componente.
Referencia a una conceptualizacin importante.

Smbolo Significado
NDICE
Actividades sugeridas a realizar por los estudiantes,
para afianzar conocimientos.
PRELIMINARES
Interactividad en el EVA.
Fin de la unidad de estudio.
BIMESTRE
PRIMER
Autoevaluacin.
SEGUNDO
BIMESTRE
Verificacin de solucionario de las autoevaluaciones.
SOLUCIONARIO
Demuestre su esfuerzo.
BIBLIOGRFICAS
REFERENCIAS

Texto-Gua: Gestin de Proyectos Informticos PRIMER BIMESTRE
6. Proceso de enseanza-aprendizaje para el logro de competencias.
NDICE
PRELIMINARES
PRIMER BIMESTRE
BIMESTRE
PRIMER
UNIDAD 1. INTRODUCCIN A LA GESTIN DE PROYECTOS ASPECTOS
FUNDAMENTALES
SEGUNDO
BIMESTRE
Se recomienda la lectura del Captulo 1. Un proyecto informtico del texto bsico. As
como las lecturas de apoyo sugeridas a lo largo del estudio de esta unidad.
SOLUCIONARIO
Estimado estudiante, vamos a dar inicio al estudio de esta primera unidad donde abordaremos los
aspectos fundamentales de la Gestin de Proyectos, la misma que le permitir obtener los conocimientos
bsicos para entender con mayor amplitud la gestin de proyectos informticos.
Qu es un Proyecto? Gestin de proyectos informticos
BIBLIOGRFICAS
REFERENCIAS
En nuestra vida cotidiana, por lo general, aunque no nos demos cuenta, desarrollamos
proyectos, como por ejemplo: Construir una casa nueva o abrir un nuevo negocio.
Podemos decir que estos ejemplos de proyectos inician y terminan en un determinado
tiempo, usando recursos (humanos, financieros, materia prima, etc) y alcanzando un
objetivo propuesto.
Empecemos conociendo el concepto de proyecto segn varios autores:
Proyecto es el conjunto de actividades planificadas, ejecutadas y supervisadas que, con recursos

finitos, tiene como objeto crear un producto o servicio nico. (Domingo, 2000)
Un proyecto es un esfuerzo para lograr un objetivo especfico por medio de una serie particular de
tareas interrelacionadas y la utilizacin eficaz de recursos. (Gido y James, 2007)
Un proyecto es un conjunto o una secuencia de actividades que desarrolla durante un tiempo un
equipo de personas para obtener un resultado. (Ramn, Garca y Lamarca, 2007)
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o
resultado nico. (PMI, 2013)

Con esta lista de conceptos, con sus propias palabras puede definir Qu es un proyecto?
Qu tienen en comn todos los conceptos dados por estos autores?
NDICE
Las definiciones de lo que es un proyecto nos ayuda a enfocarnos a la definicin de UN PROYECTO
INFORMTICO como tal, el mismo que es el punto principal de nuestro estudio, y a continuacin veremos
una explicacin de lo que es:
PRELIMINARES
UN PROYECTO INFORMTICO no difiere mucho de los proyectos generales, tiene la
particularidad de parecerse sobre todo en los productos finales, en especial los proyectos
de desarrollo de software que siguen una metodologa particular. Los que participan
en ellos son profesionales en su mayora informticos y estos proyectos tratan por lo
general de automatizar un proceso.
Revisemos el texto bsico Captulo 1. Un proyecto informtico 1. Los aspectos
BIMESTRE
PRIMER
fundamentales 1. Los objetivos de un proyecto. En donde explica que una empresa es
una organizacin gobernada por procesos y que un proyecto es un proceso profesional
limitado en el tiempo y que rene las contribuciones de sus miembros para alcanzar un
objetivo (Gurin, 2015). Los siguientes son ejemplo de proyectos informticos:
Construccin de un software de gestin financiero.
SEGUNDO
BIMESTRE
Ejecucin de una auditora.
Levantar un negocio de e-commerce.
Implementar o restructurar un proceso en una empresa.
Construir un edificio o una infraestructura.
SOLUCIONARIO
Revisemos el texto bsico en el tema Un proyecto informtico: Los aspectos
fundamentales 3. Ejemplo de proyectos informticos.
Una vez que hemos analizado el concepto de proyecto, entenderemos de mejor manera lo que es
BIBLIOGRFICAS
REFERENCIAS
la Gestin de Proyectos y la Gestin de Proyectos Informticos. Es as que, Horine (2009), define la
gestin de proyectos como: Aplicacin de la ciencia y arte para planificar, organizar, implementar, liderar
y controlar el trabajo de un proyecto para alcanzar las metas y objetivos de la organizacin.
La definicin antes descrita podemos aplicarla a la gestin de proyectos informticos pues podemos
hacer todas esas actividades para controlar el trabajo de un proyecto informtico el cual tambin debe
estar alineado y propuesto para alcanzar las metas y objetivos de la organizacin o empresa.
1.1. Atributos de un proyecto

Los proyectos informticos necesitan cumplir con algunos atributos que son iguales a los atributos que
cualquier proyecto debe cumplir. Gido y Clements (2007) explican que los siguientes atributos ayudan
a definir un proyecto:
Tiene un objetivo bien definido, un resultado o producto esperado.

Se realiza por medio de una serie de tareas interdependientes1.
Utiliza varios recursos para realizar las tareas.
Tiene una duracin finita.
1 Un nmero de tareas no repetitivas que deben realizarse en cierta frecuencia para lograr el objetivo del proyecto (Gido y
James, 2007).

Puede ser una tarea nica o que se realiza una sola vez.
Tiene un cliente.
NDICE
Involucra un cierto grado de incertidumbre.
1.2. Conceptos bsicos y comunes de un proyecto.
PRELIMINARES
Revisemos el texto bsico Captulo 1: Un proyecto informtico 1. Los aspectos
fundamentales - 1.2. Los protagonistas de un proyecto.
Todo proyecto sea informtico o no, maneja los mismos trminos por lo que pedimos se revise la Tabla
1, en donde se han recopilado los trminos ms relevantes:
BIMESTRE
PRIMER
Tabla 1. Conceptos bsicos de un proyecto.
Trminos Significado
Personas que activamente participan en el proyecto y/o cuyos intereses
Interesados (Stakeholders) podran verse afectados positiva o negativamente por la ejecucin o
SEGUNDO
BIMESTRE
terminacin del proyecto.
Es la persona o grupo de personas que proporcionan los recursos
Patrocinador financieros que pueden ser en efectivo o en especie para el proyecto, es
decir, es quien defiende al proyecto.
Persona o grupos de personas que utilizarn el producto, servicio o
SOLUCIONARIO
resultado del proyecto, por ello es importante definir inicialmente
Cliente Usuario
quien podr utilizar efectivamente o se beneficiar con los resultados
entregados por un proyecto.
Cualquier producto, resultado o capacidad nicos para ejecutar un
Entregable
servicio requerido para completar un proceso, fase o proyecto.
Son las personas designadas por la organizacin ejecutante para
BIBLIOGRFICAS
alcanzar los objetivos del proyecto. PMI (2008) lo define como un rol
REFERENCIAS
Directores o gerentes del proyecto
prestigioso, lleno de desafos, con una responsabilidad significativa y
prioridades cambiantes.
Est conformado por el director del proyecto, el equipo de direccin del
Equipo del proyecto proyecto y otros miembros del equipo que desarrollan el trabajo, pero
que no necesariamente participan en la direccin del proyecto.
Personas claves que desempean el rol de gestores dentro de un rea
Gerentes funcionales administrativa o funcional de una empresa, tal como recursos humanos,
finanzas, contabilidad o adquisiciones.
Se refiere a un conjunto de proyectos o programas y otros trabajos que
Portafolio de proyectos se agrupan para facilitar la direccin eficaz de ese trabajo para cumplir
con los objetivos estratgicos del negocio.
Se define como un grupo de proyectos relacionados administrados
Programa de forma coordinada para obtener beneficios y control, que no se
obtendran si se gestionaran en forma individual.
Adaptado de Espinosa y Crdova (2015).
Con la finalidad de afianzar los conocimientos adquiridos hasta ahora en este estudio, se propone que
desarrolle la siguiente actividad:

Tome como ejemplo de proyecto, la construccin de un edificio e

identifique lo siguiente: interesados, clientes, entregables, patrocinadores.
NDICE
Busque en el internet cmo se lleva a cabo la construccin de una represa elctrica y
haga lo mismo que en el ejercicio anterior.
En el texto bsico Captulo 1: Un proyecto informtico 1. Los aspectos fundamentales - 1.2. Los
protagonistas de un proyecto, se explica generalmente quines son las personas o Stakeholders que
PRELIMINARES
participan en un proyecto informtico, como: el responsable de evaluar el mercado, los arquitectos
del servicio informtico, los que disean el proyecto y los que lo desarrollan, solamente que son roles
especficos en un proyecto y cualquiera de ellos puede ser el jefe del proyecto.
Todos deben procurar cumplir los objetivos del proyecto como un equipo y evitar a toda costa formar
fuerzas opuestas en el proyecto.
BIMESTRE
PRIMER
1.3. Restricciones en la Gestin de Proyectos
Segn la OCIO (Office of the Chief Information Officer Washington State), las restricciones son aquellos
elementos que restringen, limitan o regulan el proyecto y, al igual que los supuestos, no estn en control
del equipo del proyecto. Todos los proyectos tienen innumerables restricciones y algunas de estas son
SEGUNDO
BIMESTRE
comunes independientemente de la clase de proyecto que sea, sin embargo, hay tres muy importantes
que se las toma en cuenta y se denominan TRIPLE RESTRICCIN, las ms conocidas son:
1. Tiempo: siempre hay una fecha que cumplir.

2. Coste: todos los recursos (no solo financieros) que se necesitan para llevar a cabo el proyecto.
SOLUCIONARIO
3. Alcance: todo proyecto produce un producto, sea bien o servicio.
Segn las ltimas ediciones del PMI consideran que son 6: alcance, calidad, cronograma, presupuesto,
recursos y riesgos.
Esta triple restriccin est representada por un grfico de un tringulo equiltero - es decir todos sus
BIBLIOGRFICAS
REFERENCIAS
lados son iguales, en caso de que alguna de las restricciones (tiempo, coste o alcance) es modificada
en su dimensin la forma de este tringulo cambiara y lo que se debe buscar (el jefe del proyecto) es
siempre mantener el equilibrio. Ver figura 1.
Figura 1. Triple Restriccin

Fuente: El Autor.
En el texto bsico Captulo 1: Un proyecto informtico 3. Las restricciones, que son en

general algunos puntos que se deben tomar en cuenta en proyectos informticos. Ver
tabla 2.
En la Tabla 2 se encuentra un resumen de las restricciones que seala el texto bsico.

Tabla 2. Restricciones en un proyecto informtico.
Restricciones Qu son?
NDICE
Es un documento donde se consideran especificaciones funcionales y
Documento de especificaciones
tcnicas que forman parte del marco del trabajo del proyecto.
Como lo antes estudiado, se refieren a los gastos que se atribuyen al
proyecto. Verificar a ciencia cierta cul es el tipo de financiamiento
PRELIMINARES
del proyecto (se contar con todo el dinero, ser dado en fases o por
Control de costes
asignacin de fondos).
Gurin (2015) determina que un control eficaz de costes depende de la
calidad de la planificacin y de su seguimiento.
La calidad es un proceso transversal de la empresa que implica al conjunto
de sus servicios. La misma contextualizacin servira para un proyecto,
Control de calidad la calidad deber ser controlada desde el inicio del mismo. Gurin (2015)
BIMESTRE
PRIMER
determina que la calidad depender de una buena aplicacin de normas
de desarrollo y de pruebas.
Se basa en la gestin de riesgos y los retrasos. Tomando en cuenta que
Control de plazos algunos riesgos impactarn en algunas tareas que retrasarn el proyecto.
Deber existir una correcta planificacin de carga de trabajo.
Matriz de ajustes Es una herramienta que nos ayuda a equilibrar el proyecto.
SEGUNDO
BIMESTRE
Fuente: El Autor
1.4. Ciclo de vida del proyecto

Para entender de mejor manera cul es el proceso de llevar a cabo un proyecto, tenemos que hacer
SOLUCIONARIO
referencia al ciclo de vida del mismo, que no son ms que un nmero de fases secuenciales por las que
debe pasar el proceso, cada fase est determinada a alcanzar ciertos objetivos y a dar resultados. Por
ejemplo: los hitos de un proyecto no son ms que fechas especficas donde se determinan entregables.
El ciclo de vida de los proyectos varan de tamao y complejidad, pero el proceso que se realiza dentro
de cada fase del ciclo de vida es similar en todos, es decir, se adaptan dependiendo de la complejidad
BIBLIOGRFICAS
REFERENCIAS
del proyecto, en nuestro estudio tomaremos la estructura propuesta por PMBOK2, as mismo en la Tabla
3 se analizarn algunas fases y cmo se las conoce por otras metodologas o autores:
Tabla 3. Ciclo de Vida de un proyecto.
# Grupo de Proceso Descripcin Trminos Comunes

Planeacin preliminar
1 Iniciacin Autorizacin del proyecto o fase.
kicking off
Definicin y redefinicin de los objetivos del proyecto definiendo
2 Planificacin y seleccionar el mejor curso de accin para alcanzar desarrollando el plan
esos objetivos. definiendo el escenario
makingithappen
Coordinando al personal y a los recursos para ejecutar
3 Ejecucin gettingit done
el plan.
coordinando
Asegurar que los objetivos del proyecto son
alcanzados, monitoreando y midiendo regularmente tracking progress
4 Monitoreo y Control
el progreso para identificar variaciones al plan para keeping in course
que acciones correctivas puedan ser tomadas.
2 Gua de fundamentos para la gestin de proyectos creado por el Project Management Institute (PMI).

# Grupo de Proceso Descripcin Trminos Comunes

aceptacin del cliente
Aceptacin formal del proyecto o fase, poniendo fin
NDICE
5 Cierre transicin
de manera ordenada.
cierre
Fuente: El Autor
Por otro lado (Ramn et al., 2007), indica las actividades consideradas dentro de las fases de un ciclo de
PRELIMINARES
vida de un proyecto, las mismas se denotan en la figura 2:
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
Figura 2. Ciclo de vida de un proyecto
Fuente: El autor.
BIBLIOGRFICAS
REFERENCIAS
De acuerdo a Horine (2009) cada una de las fases identificadas en el ciclo de vida de un proyecto tiene
ciertas caractersticas con respecto al desarrollo del proyecto. Estas caractersticas varan de acuerdo
a la fase en la que nos encontremos desarrollando el proyecto, por ejemplo: en la etapa de cierre, el
costo y dotacin de personal en el proyecto es muy bajo puesto que ya se alcanzaron los objetivos
propuestos y no se requiere de todo el equipo para hacer el cierre del mismo. En la tabla 4 resumimos
estas caractersticas:
Tabla 4. Caractersticas de las fases
Fases
Inicio Planificacin Ejecucin Cierre
Caractersticas
Costo y dotacin del personal Bajos Medios Altos Bajos
Influencia de los interesados Mayores Medios Bajos Bajos
Capacidad de influir en las caractersticas finales

Alto Medio Bajo Bajo
del producto sin afectar el costo.
Fuente: El autor.

En la figura 3 el PMI (2013) representa grficamente las caractersticas asociadas al ciclo de vida de un
proyecto, junto con los entregables en cada una de sus fases:
NDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 3. Niveles Tpicos de Costo y Dotacin de Personal en una Estructura Genrica del Ciclo de Vida
del Proyecto.
Fuente: Project Management Institute, Inc (2013)
SEGUNDO
BIMESTRE
Algunas variables a tomar en cuenta durante todo el proceso de desarrollo son: el riesgo e incertidumbre
y el costo de cambio, el mismo que a medida que transcurre el desarrollo del proyecto en el tiempo, estos
tienden a minimizar o maximizar su impacto en el mismo. Por ejemplo: En la etapa inicial del proyecto el
riesgo y la incertidumbre son altos puesto que aunque se tiene una expectativa y objetivos que cumplir,
SOLUCIONARIO
al inicio an no se han tomado ciertas decisiones o han influido ciertos factores que solo con el tiempo
se dan, a medida que se avanza en el proyecto las siguientes etapas llegando al cierre del proyecto los
riesgos ya fueron: mitigados, investigados o monitorizados y la incertidumbre ya no existe.
Algo similar ocurre con la variable costo de cambios, al inicio del proyecto si tenemos un cambio el
costo o la variacin en el costo del proyecto es mnima, algo que no sucede si tenemos un cambio casi al
BIBLIOGRFICAS
REFERENCIAS
finalizar el proyecto, muchas veces esos cambios por ms pequeos que sean sus costos son excesivos
e incluso pueden atentar contra el cumplimiento del proyecto y no se podra terminarlo de manera
exitosa, esta variable de costo de cambios, debe estar incluida dentro del proceso de gestin de cambios
del mismo proyecto.
En la figura 4 , el PMI (2013) muestra el impacto de estas variables en funcin del tiempo del proyecto.
Figura 4. Impacto de las variables en funcin del tiempo.


1.5. Factores crticos de xito de un proyecto

Antes de introducirnos a este tema le invito que realice la siguiente actividad:
NDICE
Hacer una lectura comprensiva del tema Gestin de proyectos la clave para la
organizacin que se encuentra en el siguiente enlace: https://goo.gl/dgF9Vb Conteste
con sus propias palabras la siguiente interrogante: Por qu es importante la gestin de
PRELIMINARES
proyectos hoy en da en una organizacin?
Actualmente las organizaciones o empresas estn expuestas a un alto nivel de competividad y exigencia,
dado tanto por los clientes en relacin a los tiempos de entrega, costos y calidad; como por empresas que
ofrecen los mismos servicios. Para afrontar estos desafos de manera efectiva y eficiente, es importante
sobre manera que haya una gestin de proyectos que agregue valor real a la organizacin, ms an en
el caso de que usen tecnologa y que estos proyectos sean informticos.
BIMESTRE
PRIMER
Es muy comn escuchar que los procesos fracasan y como lo menciona Ramn et al. (2007) este concepto
de fracaso est ntimamente relacionado al incumplimiento de la triple restriccin: costo, alcance,
tiempo y calidad (lo estudiamos en el punto 1.4 de esta unidad), es decir, estos exceden el presupuesto,
expectativas o lneas de tiempo.
SEGUNDO
BIMESTRE
Algunos puntos ms comunes que nos indican que un proyecto ha fracasado o est por fracasar, son:
El proyecto se ha desviado del mbito para el que fue planteado. Revise por favor el texto bsico
Captulo 1: Un proyecto informtico 4. El mbito del proyecto.
No se han logrado cumplir con los objetivos que fueron planteados.
SOLUCIONARIO
Los tiempos asignados no se cumplieron o sobrepasaron la planificacin.
Los recursos y costes se sobrepasaron.
No se alcanzaron los resultados deseados (tomando en cuenta la calidad del servicio y producto).
Existe un sin nmero de factores que inciden a que un proyecto fracase con mucha frecuencia. Ramn
BIBLIOGRFICAS
REFERENCIAS
et al., (2007) enlistan los ms comunes:
Falta de compromiso de la direccin.

Los usuarios no se involucran.
Falta de conocimiento tcnico por parte del equipo (ms an si es un proyecto informtico).
Falta de madurez o estabilidad en la tecnologa.

Malas relaciones entre compaeros o el equipo de trabajo.
Mala gestin administrativa y econmica.
Mala planificacin.
Mala recopilacin y anlisis de requerimientos.
Pasos de ejecucin no realistas.
Falta de documentacin y de seguimiento.
Mala comunicacin.
No se toman en cuenta riesgos en el proyecto.
Tiene que tener claro y conocer que as como hay factores que inciden a que un proyecto fracase tambin
existen otros factores que nos ayudan a determinar que el proyecto sea un xito. Para que tenga una
mejor perspectiva por favor desarrolle la siguiente actividad.

Hacer una lectura comprensiva del tema Los 4 factores que ms influyen en el xito de
un proyecto que se encuentra en el siguiente enlace: https://goo.gl/WoYH0u. Usted cree
NDICE
que tener los objetivos bien claros del proyecto desde el inicio del mismo, tiene mucho
que ver con el xito del mismo. Si? No? Por qu?
El estudio de estos factores de xito es muy amplio, pero en el que la mayora de autores e investigaciones
coinciden es que depende mucho de una buena direccin del proyecto, sobre todo si es del tipo
PRELIMINARES
informtico, para que tenga ms claro este tema por favor revise el texto bsico Captulo1 Un proyecto
informtico: 5. Los objetivos de la direccin de un proyecto.
1.6. Otros aspectos claves en la gestin de proyectos.

Existen aspectos claves en la gestin de proyectos en general, es decir, sean proyectos informticos
o no, estos aspectos influyen mucho en lo que tiene que ver el desarrollo de un proyecto, sobre todo
BIMESTRE
PRIMER
en su ciclo de vida. En el texto bsico no tenemos una explicacin clara al respecto, por lo que se ha
considerado tomar en cuenta los aspectos claves que el PMI considera.
1.6.1. Cultura de los proyectos dentro de las organizaciones
La cultura, estilo y estructura de una organizacin influyen en la forma en que se llevan a cabo sus
SEGUNDO
BIMESTRE
proyectos. Cuando en el proyecto participan entidades externas, como las que forman parte de una
unin temporal de empresas o de un convenio de colaboracin, el proyecto ser influenciado por ms
de una organizacin. (PMI, 2013).
No es lo mismo que a un proyecto informtico lo lleve a cabo una organizacin orientada al desarrollo
SOLUCIONARIO
de proyectos informticos, qu una organizacin que solo tiene parte de su tiempo y recursos dedicados
a un proyecto informtico. Por ejemplo: Apple es una empresa donde se desarrollan grandes proyectos
tecnolgicos para s mismo, creacin de software y hardware, es por eso que los nuevos modelos
propuestos de iPhone como proyectos informticos o tecnolgicos fluyen ms rpido teniendo un xito
total en la culminacin o cierre de los mismos. Pero una organizacin que no est destinada al desarrollo
BIBLIOGRFICAS
de proyectos tecnolgicos o informticos, le cuesta primero armar el equipo que va a llevar a cabo el
REFERENCIAS
proyecto, debe unir personas expertas, cada cual en su diferente mbito. Para seguir con el ejemplo
anterior, podra ser una empresa que antes desarrollaba solo software y que ahora quiere lanzarse al
mercado con un nuevo modelo de telfono mvil. Esta empresa podra hacer dos cosas, la antes descrita,
que es conformar ella el grupo de personas tomadas de su propia empresa, o contratar a otra empresa
que le pueda desarrollar el producto que necesita (esto se conoce como Outsourcing), por lo general la
empresa que contrat es la experta y puede llevar a cabo este proyecto, sin embargo los recursos sobre
todo financieros se vern altamente afectados.
Con esta explicacin y para reforzar sus conocimientos, por favor desarrolle la siguiente actividad:
Nokia es una empresa tecnolgica, busque en el Internet sobre esta empresa Qu

haca? Qu servicios o productos tecnolgicos ofrecan? Y en base a esta informacin
conteste: Tiene una cultura de gestin de proyectos? Cree que est conformada de
manera adecuada? Siempre generan buenos resultados?
La cultura organizacional de la empresa que no es ms que el patrn general de conductas, creencias y

valores compartidos por sus miembros (Lemus, 2011). Las experiencias comunes de los miembros de la
organizacin son las que forman esta cultura. El PMI (2013) enlista algunas experiencias comunes:
Visin, misin, valores, creencias y expectativas compartidas;

Normas, polticas, mtodos y procedimientos;

Sistemas de motivacin e incentivos;
NDICE
Tolerancia al riesgo;
Percepcin del liderazgo, jerarqua y relaciones de autoridad;
Cdigo de conducta, tica laboral y horario de trabajo; y
Entornos operativos.
PRELIMINARES
La cultura organizacional es directamente influenciada no solo por estas experiencias comunes sino
tambin por algunos factores organizacionales los mismos que (PMI, 2013) considera que son la
Estructura de la organizacin y Activos de los procesos de la organizacin:
A. Estructura de la organizacin
BIMESTRE
PRIMER
Litwin y Stinguer (1978) afirman que una estructura hace referencia a la forma en que se dividen, agrupan
y coordinan las actividades de las organizaciones en cuanto a las relaciones entre los diferentes niveles
jerrquicos, indistintamente de la posicin en el nivel. Para que se comprenda mejor, por ejemplo, se
refiere al organigrama de una empresa, segn como est estructurado influye en la disponibilidad de
recursos y en el desarrollo de un proyecto.
SEGUNDO
BIMESTRE
Segn PMI (2013) existen tres tipos de estructuras organizacionales, en la Tabla 5 se especifican estos
tipos con sus diferencias:
Tabla 5. Tipo de estructuras organizacionales
SOLUCIONARIO
Tipos de estructuras
Diferencias
organizacionales
Consiste en una jerarqua donde cada empleado tiene un superior
claramente definido. Lara (2011) da una definicin ms clara: Consiste
en dividir el trabajo y establecer la especializacin de manera que cada
Funcional
hombre, desde el gerente hasta el obrero, ejecute el menor nmero
BIBLIOGRFICAS
REFERENCIAS
posible de funciones. Los departamentos de la organizacin desarrollan las
actividades del proyecto que les toc de manera independiente.
Mantienen muchas de las caractersticas de una organizacin funcional,
y el rol del director del proyecto es ms bien el de un coordinador o
Dbil
facilitador. Tiene ms caractersticas de una estructura funcional que la de
Matricial (Es una estructura orientada a proyectos.
una fusin
Reconoce la necesidad de contar con un director del proyecto pero no
entre la
le confiere autoridad plena sobre el proyecto ni sobre su financiamiento.
estructura Equilibrada
Tiene caractersticas por igual de una estructura funcional y de la orientada
funcional y la
a proyectos.
orientada a
proyectos) Tienen directores de proyecto con dedicacin plena y con una autoridad
considerable, as como personal administrativo dedicado a tiempo
Fuerte
completo. Tienen muchas ms caractersticas de una estructura orientada a
proyectos que de la estructura funcional.
Los miembros del equipo a menudo estn ubicados en un mismo lugar.
La mayor parte de los recursos de la organizacin estn involucrados en
Orientada a proyectos
el trabajo de los proyectos y los directores de proyecto tienen bastante
independencia y autoridad.
Fuente: El autor
La Figura 5 muestra las caractersticas claves de los principales tipos de estructuras de una organizacin
en relacin con los proyectos, establecida por PMI (2013).

NDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 5. Influencia de la Estructura de la Organizacin en los Proyectos.
B. Activos de los procesos de la organizacin
SEGUNDO
BIMESTRE
Las empresas difieren una de otras por lo antes estudiado (factores, estructura, etc.) pero tambin por
sus normativas, por sus polticas, por sus procedimientos, por sus procesos, etc. Toda empresa posee
bases de datos de toda la informacin necesaria para su normal funcionamiento, as como los registros
de los proyectos realizados y lo almacenan en un repositorio llamado Activos de los procesos de la
Organizacin, que ayudan a especificar los tipos de contratos en cada proyecto y bajo qu trminos y
SOLUCIONARIO
condiciones se desarrollarn. Estos activos son:
1. Procesos y procedimientos
Procesos, estndares de la organizacin.
BIBLIOGRFICAS
Lineamientos, instrucciones de trabajo y criterios de medicin de desempeo.
REFERENCIAS
Plantillas.
Requisitos de comunicacin de la organizacin.
Procedimientos de gestin de problemas.
Procedimientos de control financiero, entre otros.
2. Base corporativa de conocimiento
Bases de datos financieras.

Bases de conocimiento de la gestin de configuracin.
Informacin histrica y base de lecciones aprendidas.
Archivos de proyectos, etc.

1.6.2. Habilidades directivas en el desarrollo del proyecto
Con la finalidad de comprender mejor este tema, se sugiere que realice la siguiente actividad:
NDICE
Lea comprensivamente la informacin de este sitio web: https://goo.gl/rBlrBr. Conteste
las siguientes preguntas: Ser necesario ser un buen lder para dirigir un proyecto? Ser
importante que un gerente de proyectos tenga un buen trato con el resto del equipo?
PRELIMINARES
Por qu?
Un gerente de proyectos tiene que ser un planeador, organizador, hombre orquesta, un facilitador, un
coach, alguien que resuelve problemas, etc. Y tambin debe cumplir con algunos skills o habilidades
necesarias como:
Tener fundamentos en gestin de proyectos.
BIMESTRE
PRIMER
Poseer habilidades en gestin de negocios.
Tener conocimiento tcnico.
Poseer habilidades de comunicacin.
Liderazgo.
SEGUNDO
BIMESTRE
Revisemos el texto bsico Captulo 1: Un proyecto informtico 1. Los aspectos
fundamentales 5. Los objetivos de la direccin de proyectos.
SOLUCIONARIO
Sin embargo, Horine (2009) enlista especficamente errores ms comunes que cometen los gerentes de
proyectos:
No se tiene un entendimiento claro sobre cmo alinear los proyectos a la organizacin.

No hay una gestin apropiada de las expectativas con los interesados.
BIBLIOGRFICAS
REFERENCIAS
No se obtiene el acuerdo y compromiso de los interesados sobre las metas del proyecto y
criterios de xito.
No se desarrolla un cronograma realista que incluye todos los esfuerzos de trabajo,
dependencias de tareas, estimaciones y asignacin nivelada de recursos.
No se obtiene la aceptacin del cronograma del proyecto.
No hay una clara definicin y comunicacin de quin es el responsable de qu.
No se utilizan procedimientos de control de cambio para gestionar el alcance del proyecto.
No hay comunicacin consistente y efectiva con todos los stakeholders o interesados.
No se ejecuta el plan del proyecto.
No se acta a tiempo en contra de los riesgos claves.
No identifican de manera proactiva riesgos y se establecen planes de contingencia o
respuesta para esos riesgos.
No se obtienen los recursos correctos con los skills o habilidades necesarias y en el tiempo
adecuado.
Inadecuada definicin y gestin de requerimientos.
Insuficiente gestin y liderazgo del equipo de proyecto.

La mayora de proyectos sean informticos o no, fracasan, cuando no existe un buen plan de comunicacin
a lo largo del desarrollo del ciclo de vida del proyecto.
NDICE
1.7. Ejemplos de proyectos informticos.
Comprender lo que es un proyecto informtico conceptualmente es mucho ms tedioso que
comprenderlo en base a ejemplos reales sobre todo basados en desarrollos reales. Con esto se solicita
PRELIMINARES
realizar la siguiente actividad:
Revisar el texto bsico en el Captulo 1: Un proyecto informtico 6. Tres ejemplos de

proyectos. 1 Implementacin de un CRM; 2. Desarrollo de una aplicacin de control de
calidad; 3. Creacin de un sitio de venta online.
Para entender mejor estos ejemplos debe recordar algunos trminos que seguramente durante su
BIMESTRE
PRIMER
carrera universitarias los escuche e incluso ya puede conocer y manejarlos.
En el ejemplo 1 Implementacin de un CRM
Un CRM (Customer Relationship Management) es un trmino de la industria de la informacin

que se aplica a metodologas, software y, en general, a las capacidades de Internet que ayudan a
SEGUNDO
BIMESTRE
una empresa a gestionar las relaciones con sus clientes de una manera organizada. Por ejemplo,
una empresa podra crear una base de datos de clientes que describiese las relaciones con
suficiente detalle para que la direccin, los agentes de ventas, las trabajadores de servicio y, tal
vez, los clientes, puedan acceder directamente a dicha informacin, responder a las necesidades
de los clientes con planes de productos y ofertas, recordar a los clientes distintas necesidades de
SOLUCIONARIO
servicio, saber qu otros productos ha adquirido un cliente, y as sucesivamente. (Rouse, 2006,
pg. 1)
En el ejemplo 2 Desarrollo de una aplicacin de control de calidad
Un sistema ERP es un conjunto de sistemas de informacin que permite la integracin de ciertas
BIBLIOGRFICAS
REFERENCIAS
operaciones de una empresa, especialmente las que tienen que ver con la produccin, la logstica,
el inventario, los envos y la contabilidad.
En el ejemplo 3 Creacin de un sitio de venta online
En este ejemplo debe centrarse en los literales a, b y c, donde se especifican los pasos para la
creacin de un sitio de venta online. Los Servicios de I+D, significan aquellos servicios de
Investigacin y Desarrollo.
Es muy importante la lectura y comprensin de estos 3 ejemplos de proyectos informticos, pues en el

aula virtual de este componente se desarrollarn actividades en torno a estos ejemplos.
Interactividad a travs del CAMPUS Virtual.
Ingrese peridicamente al campus virtual EVA ( http://utpl.edu.ec/ ) para familiarizarse

con los temas de esta unidad y para participar en el Foro expuesto, as como en la
realizacin en lnea de la Autoevaluacin de esta unidad y en la participacin de
otras actividades (Cuestionarios, CHAT, tutoras) que son muy importantes para el
desarrollo de las competencias de este componente acadmico.

Hemos finalizado el estudio de esta unidad. Para evaluar los conocimientos adquiridos en esta unidad es
importante que desarrolle la siguiente AUTOEVALUACIN:
NDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 1
NDICE
1. Construir una casa nueva o abrir un nuevo negocio son ejemplos de:
PRELIMINARES
a. Operaciones
b. Proyectos
c. Procesos
2. Es un esfuerzo temporal para crear un producto, servicio o resultado nico:
BIMESTRE
a. Ejecucin
PRIMER
b. Implementacin
c. Proyecto
3. Es la aplicacin de la ciencia y arte para planificar, organizar, implementar y controlar el trabajo de

un proyecto, para que una organizacin alcance sus objetivos:
SEGUNDO
BIMESTRE
a. Gestin de proyectos
b. Desarrollo de operaciones
c. Ejecucin de procesos
SOLUCIONARIO
4. Son aquellos que activamente participan en un proyecto y el desarrollo del mismo les afecta
positivamente o negativamente.
a. Entregables
b. Stakeholders
BIBLIOGRFICAS
REFERENCIAS
c. Directores
5. Son aquellos que cumplen un rol de gestores dentro del rea administrativa de la empresa.
a. Patrocinador
b. Cliente
c. Gerente funcional
6. El elemento de la triple restriccin de un proyecto que se refiere a todos los recursos que se
necesitan en un proyecto es:
a. Tiempo
b. Coste
c. Alcance
7. Es un proceso transversal de la empresa que implica al conjunto de sus servicios.
a. Control de costes
b. Control de servicios
c. Control de calidad

8. La etapa del ciclo de vida del proyecto donde se definen los objetivos del proyecto y se selecciona
el mejor curso de accin para alcanzar los objetivos de denomina:
NDICE
a. Iniciacin
b. Planificacin
c. Ejecucin
PRELIMINARES
9. Un punto muy comn para el fracaso de un proyecto es:
a. Los recursos y costes cubrieron al 100% todo el proyecto.

b. Se alcanzaron los resultados deseados.
c. No se toman en cuenta los riesgos del proyecto.
BIMESTRE
PRIMER
10. Uno de los errores ms comunes que comete el gerente del proyecto es:
a. No se utilizan procedimientos de control de cambios

b. Su sueldo es demasiado corto para lo que debe ganar.
c. Sobrecarga de trabajo.
SEGUNDO
BIMESTRE
Por favor, verifique sus respuestas con el solucionario de la autoevaluacin ubicado al
final de la gua.
SOLUCIONARIO
Ir a solucionario
BIBLIOGRFICAS
REFERENCIAS
No coincidieron algunas respuestas! No se desanime! Vuelva a intentarlo!
Le invito a que se esfuerce un poco ms y busque apoyo en las tutoras o se comunique con su profesor tutor
para as lograr el desarrollo de competencias.

UNIDAD 2. LINEAMIENTOS PARA FORMULACIN DE PROYECTOS ASPECTOS

FINANCIEROS
NDICE
Se recomienda la lectura del texto bsico - Captulo 2. Los aspectos financieros. As como
las lecturas de apoyo sugeridas al final del estudio de esta unidad.
PRELIMINARES
Estimado estudiante, vamos a dar inicio al estudio de la segunda Unidad, para ello se requiere que tenga
ya los conocimientos bsicos de la gestin de proyectos adquiridos en la Unidad 1 de esta gua. En esta
unidad abordaremos los lineamientos que se consideran para la formulacin de proyectos, la misma
que le ayudar a tener un enfoque ms especfico para formular proyectos, as como para conocer la
evaluacin de la factibilidad del mismo.
BIMESTRE
PRIMER
2.1. Identificacin de ideas para proyectos
Cuntos productos y servicios en el mundo que ahora son un xito se iniciaron slo como
una simple idea. Desde el boom de la creacin de la Computadora y todos sus derivados;
la creacin del satlite ecuatoriano PEGAZO, el Internet, entre otros. Empezaron como
SEGUNDO
BIMESTRE
una simple idea, una ideologa, una ilusin o un sueo por cumplir.
No toda idea que se nos viene a la cabeza podemos convertirla en proyecto, pero si es una idea
convincente puede convertirse en todo un exitoso proyecto empresarial. Para que tenga xito una
idea es imprescindible que la analicemos, demostrar de forma clara y concisa, qu ventajas va a aportar
SOLUCIONARIO
nuestra idea a nuestros clientes y en qu mercados, y cmo generara ingresos a la organizacin.
Las ideas ms originales y de mayor xito son desarrolladas por personas que tienen ya varios aos
de experiencia. Desarrollar una Idea para un proyecto con el necesario grado de madurez exige una
profunda comprensin de la tecnologa que puede ser aplicada, adems de un buen conocimiento
de la conducta de los clientes o, simplemente, de la organizacin en que trabaja. Por ejemplo, Steve
BIBLIOGRFICAS
REFERENCIAS
Jobs y Bill Gates ya tenan experiencia, incluso laborando juntos, antes que fundaran Apple y Microsoft
respectivamente.
Una idea que resulta en la propuesta de un proyecto puede surgir, por ejemplo, desde iniciativas
emprendedoras. Mendez (2014) clasifica estas iniciativas en dos tipos:
Las que surgen como respuesta a necesidades: se desarrollan ideas o actividades comerciales
relativamente sencillas y fciles de imitar. Por lo que con el tiempo la competencia surge lo
que disminuye rpidamente su participacin en el mercado.
Las que surgen a partir de la identificacin de oportunidades: se puede generar riqueza
con valores agregados, los mismos que son: el conocimiento, la investigacin y la tecnologa,
por lo general son proyectos o emprendimientos con base tecnolgica.
Una idea es ms atractiva si rene las siguientes condiciones, segn (Mendez, 2014):
Es el resultado de un trabajo de investigacin y de la aplicacin de conocimiento.

Es la respuesta a una necesidad.
Es innovadora.
Es aceptada en gran parte en el mercado o la poblacin.
Aprovecha de manera adecuada los recursos de una localidad, regin o pas.

Al ser desarrollada trae beneficios a la organizacin y a la sociedad.
En la tabla 6, podemos diferenciar dos tipos de proyectos (para no seguir hablando de ideas o
NDICE
emprendimientos) con los que diariamente las organizaciones se enfrentan:
Tabla 6. Diferencias de proyectos planos y de proyectos innovadores.
PRELIMINARES
Variables Proyectos planos Proyectos innovadores
Tipo de Idea Plana Innovadora
Nivel de complejidad Bajo Medio y alto
BIMESTRE
Mercados Locales Internacionales
PRIMER
Posibilidad de crecimiento Baja Alta
Relacin con la investigacin Baja o nula Alta
SEGUNDO
BIMESTRE
Visin del negocio A corto plazo A mediano y largo plazo
Capacidad para atraer

Baja Alta
inversiones
Rentabilidad Baja Alta
SOLUCIONARIO
Posibilidad de imitar Alta Baja
Relacin con tecnologa Baja Alta
BIBLIOGRFICAS
Posibilidad de inversin Baja Alta
REFERENCIAS
Horizonte del proyecto Corto Largo
Integracin con otras disciplinas Monodisciplinaria o personal Interdisciplinaria
Fuente de Idea Necesidad Oportunidad
Calidad de empleos generados Bajo nivel de competencias Personal altamente competente

Fuente: Mendez, (2014)
En nuestro diario vivir y con las experiencias cotidianas las personas se vuelven
expertas en resolver ciertos conflictos o en ver oportunidades simplemente usando
sentido comn, el mismo que no es muy comn valga la redundancia, ya que este se
desarrolla como lo menciona con la lectura, observacin, la capacidad de escuchar y
el supuesto de una actitud investigativa. Mendez, (2014)

Las siguientes son fuentes de donde se pueden obtener ideas, la mayora estn tomadas de (Mendez,
2014):
NDICE
Planes de desarrollo.
Estudios de mercado.
Diagnstico sobre problemas municipales.
PRELIMINARES
Ferias regionales, nacionales e internacionales.
Cambios de leyes o normas.
Proyectos fracasados.
Experiencias familiares.
Innovaciones tecnolgicas.
Misiones internacionales.
BIMESTRE
PRIMER
Bancos de ideas.
Contactos con clientes, proveedores y empresarios.
Reconocimiento de gustos y preferencias.
Nuevas tecnologas.
SEGUNDO
BIMESTRE
Cambios de percepciones.
Este ejemplo ayudar a comprender ms este tema: Hoy en da se pueden pagar

los servicios bsicos en lnea, a travs de las entidades bancarias que tengan banca
electrnica, estos servicios tienen un costo, pero ya se evita de las largas colas, filas y
SOLUCIONARIO
puede pagar todos los servicios en menos de 3 clics.
Del ejemplo anterior, se puede argumentar que, seguramente surgi una idea porque se identific una
necesidad, quiz fue un banco el pionero en desarrollar este sistema, porque quera dar un servicio de
calidad a sus clientes y con el auge de la tecnologa, el Internet, etc. Esta idea se convirti en un proyecto
exitoso.
BIBLIOGRFICAS
REFERENCIAS
2.1.1. Clasificacin de proyectos
En la figura 6 el Instituto Latinoamericano de Poltica Econmica y Social (ILPES) clasifica de la siguiente

manera a los proyectos:
Figura 6. Clasificacin de los proyectos segn ILPE

Clasificar cada proyecto depende de la identificacin de las necesidades de los mismos, quienes hacen
esta identificacin son las instituciones o dueos de los proyectos.

No podemos dejar desapercibido lo visto en el punto 2.1 de esta unidad, los proyectos que surgen como
una idea dentro de una organizacin o empresa por lo general se conoce como idea de negocio3. En la
Tabla 7 tenemos algunos puntos principales de una idea de negocio segn el concurso Ventures4.
NDICE
Tabla 7. Puntos de una idea de negocio.
Puntos Preguntas a responder
PRELIMINARES
1. Concepto de negocio Qu hace su negocio?
2. Propuesta de valor Cul es el aporte que su producto o servicio le brinda al cliente?
Qu pasos sigue su negocio desde la elaboracin o consecucin de un

3. Modelo de negocio
producto o servicio hasta su entrega final al cliente?
BIMESTRE
Qu ventajas tiene sobre negocios similares? Qu habilidades
PRIMER
4. Ventajas competitivas tiene que aseguren su xito en el mercado? Qu le protege contra la
imitacin?
Cmo crea valor su negocio? Cmo generar utilidades con la
5. Fuentes de ingresos
operacin de su negocio? Cules son sus diferentes fuentes de ingreso?
Cul es su mercado objetivo? Quines son sus clientes objetivo? Cul
6. Clientes y mercado
SEGUNDO
BIMESTRE
es el plan para que los clientes conozcan su producto?
Cunto dinero necesita para que su idea se haga realidad? Cunto
7. Financiacin
capital de riesgo necesita?
Nivel de formacin, conocimientos de negocio, expertos en funciones
8. Experticia del equipo
especficas.
SOLUCIONARIO
Estos puntos pueden ser discutidos entre el equipo que quiere proponer un proyecto, pueden salir
algunos borradores antes de obtener la idea clara de lo que se quiere hacer. Todo lo que se conteste
a estas interrogantes, tiene que ser claro y preciso y se debe usar todo el material y las herramientas
necesarias para sustentar la idea, como: tecnologa, informacin, etc.
BIBLIOGRFICAS
REFERENCIAS
Por ejemplo, hoy en da es muy comn que en las empresas o una persona particular quiera emprender en
algo innovador, lo ms innovador en el mundo de los SMARTPHONES es el desarrollo de aplicaciones. La
idea inicia con el hecho quiz de cubrir una necesidad. La aplicacin KTAXI es un sistema integral, robusto
y confiable, creado con la intencin de satisfacer la necesidad diaria de solicitar taxi, favoreciendo al
cliente, taxista y a la colectividad. Esta aplicacin ayuda a pedir un taxi sin necesidad de hacer una llamada
telefnica, lo que necesita es conexin a Internet y llenar un formulario especificando a que direccin
se enva el taxi. A tomado mucha popularidad sobre todo en la localidad de Loja Ecuador donde fue
que se desarroll la aplicacin, seguramente los desarrolladores de esta aplicacin no realizaron el tipo
test de la Tabla 7, sin embargo tericamente ms no empricamente vieron la necesidad, la enfocaron y
la desarrollaron.
Con base al ejemplo descrito anteriormente, por favor, desarrolle la siguiente actividad:
Conteste las siguientes preguntas: Qu ventajas tiene esta aplicacin sobre el pedir un
taxi con el proceso tradicional? Cul es el mercado objetivo?Cunto dinero cree que
se necesit para el desarrollo de esa idea, tomando en cuenta todos los recursos? Es
sumamente sencillo contestar estas preguntas?
3 Es el producto o servicio que una empresa u organizacin ofrece en el mercado.

4 Este concurso identifica propuestas que tengan opcin de convertirse en un modelo de negocio sostenible, escalable y de
alto impacto en las dimensiones econmica, social y ambiental.

Esta actividad ayuda a darnos cuenta que aunque las preguntas parecen sencillas de responder, no es
como se ven a simple vista.
NDICE
2.2. Componentes de un proyecto: viabilidad - factibilidad
La decisin de emprender en un proyecto se determina en base a algunos factores, desde el anlisis
del entorno donde se sita la empresa u organizacin, hasta el entorno tecnolgico que necesitar el
PRELIMINARES
proyecto para desarrollarse. Los estudios de estos entornos permitiran tener una perspectiva ms clara
del camino que tomar el proyecto como tal. Segn Sapag (2007) existen tres estudios del entorno que
ayudan a definir las mejores opciones estratgicas para definir la viabilidad del proyecto:
1. Estudio del entorno demogrfico: estudio estadstico de la poblacin humana y su distribucin.

Involucra todos los clientes de un mercado.
2. Estudio del entorno cultural: estudio de actitudes, formas de ser, expectativas, educacin,
BIMESTRE
PRIMER
creencias y valores sobre todo de los clientes potenciales de un mercado.
3. Estudio del entorno tecnolgico: estudio de la suma total del conocimiento que se tiene de las
formas de hacer las cosas. Identificacin de tcnicas de innovacin tecnolgica en los procesos de
produccin y apoyo a los procesos administrativos.
SEGUNDO
BIMESTRE
Junto al estudio de estos entornos y la viabilidad tcnica, la legal y la econmica condicionan el xito o
fracaso de un proyecto. Veamos a que se refiere cada una de estas viabilidades:
1. Viabilidad tcnica: busca determinar si es posible, fsica o materialmente, hacer un proyecto

(Sapag, 2007). Evaluar la capacidad tcnica y el nivel de motivacin del equipo del proyecto. Los
SOLUCIONARIO
aspectos tcnicos a evaluar son el tamao, la localizacin y el proceso tecnolgico que utilizar el
proyecto.
a. Tamao: tiene que ver con la magnitud del proyecto y puede expresarse de diferente
manera, por ejemplo, segn el monto de inversin o el nmero de empleos generados, etc.
Mendez, (2014)
BIBLIOGRFICAS
REFERENCIAS
b. Localizacin: hace referencia al lugar donde se ubicar el proyecto. El estudio de localizacin
en caso de ser un proyecto de construccin, por ejemplo, de una carretera en un lugar
especfico es mucho ms sencillo, que el estudio de localizacin de un proyecto para cumplir
con la demanda de un bien o servicio.
c. Proceso tecnolgico: se refiere a la ingeniera en s del proyecto, se relaciona con la parte
tcnica del proyecto, es muy importante contar con la ayuda de expertos en temas de
tecnologa y que sean afines a los objetivos que el proyecto quiere lograr. En la figura 7
encontramos las tres bases tcnicas sobre las cuales se llevar a cabo el proyecto.
Figura 7. Bases tcnicas de la ingeniera del proyecto

Adaptado de Mendez,(2014)
Hasta ahora se preguntar cuando empezaremos a dar un vistazo ya sobre la viabilidad de proyectos
informticos, y aunque ese es el estudio de este componente acadmico, primero se debe conocer las
bases tericas para poder estudiar el tema ms especfico.

2. Viabilidad legal: se refiere a determinar la inexistencia de trabas legales para la instalacin y

operacin normal del proyecto Sapag, N. (2007). Por ejemplo, aqu se analizan un poco las normas
NDICE
y polticas internas de la empresa, las cuales no deben ser un impedimento para el desarrollo del
proyecto en ninguna de las partes del ciclo de vida del mismo.
3. Viabilidad econmica: por medio de una comparacin coste-beneficio del proyecto se define si
es rentable o no la inversin que se har en ese proyecto. Algunos autores como Mendez (2014)
lo denominan anlisis de inversiones para cuantificar en trminos econmicos las necesidades
PRELIMINARES
del proyecto
a. Inversiones fijas: son las que se adquieren para el funcionamiento del proyecto sobre todo
en la parte operativa, por ejemplo, maquinaria, equipos, muebles, etc.
b. Inversiones diferidas: gastos hechos por anticipado, por ejemplo, el pago por el estudio de
viabilidad del proyecto.
BIMESTRE
PRIMER
c. Capital de trabajo: constituye el capital que es necesario para el normal funcionamiento del
proyecto, se lo obtiene en base al estudio de necesidades de materia prima, productos en
proceso y de productos terminados.
Hemos estudiado muy brevemente los componentes que participan pasa saber si un proyecto es viable
o no, pero a nivel de costos-beneficios estos proyectos tambin deben ser evaluados, Sapag (2007) da
SEGUNDO
BIMESTRE
los principales criterios de evaluacin en proyectos:
1. El valor actual neto (VAN): consiste en actualizar los cobros y pagos de un proyecto o inversin y
calcular su diferencia.
SOLUCIONARIO
2. Tasa interna de retorno (TIR): es la tasa que iguala el valor presente neto a cero, mide la rentabilidad
de un proyecto como un porcentaje.
3. Periodo de recuperacin de inversin (PRI): nos da el tiempo en que se recupera la inversin,
incluido la recuperacin del capital involucrado en el proyecto.
4. Rentabilidad inmediata (RI): determina el momento ptimo para hacer la inversin.
BIBLIOGRFICAS
REFERENCIAS
Para afianzar los conocimientos en esta rea, se recomienda revisar:
En el texto bsico Captulo 2. Los aspectos financieros 2. Los presupuestos y 3. La

cuenta de resultados.
Aunque estos conceptos estn fuera del entorno informtico y bsico, no son difciles de entender,
sin embargo debemos tomar en cuenta que hay expertos en temas de evaluaciones de proyectos en
rentabilidad y que no se debe prescindir de ellos, la no participacin de un evaluador en un proyecto,
determina, incluso el fracaso del mismo, al igual que la mala prediccin de su viabilidad y el que el
evaluador no conozca a ciencia cierta el enfoque y objetivos que se quiere lograr con ese proyecto, ya
que l puede guiar la evaluacin por otras opciones segn su entendimiento.
2.3. Componentes de un proyecto informtico estructura de costes de un proyecto

Revisar el texto bsico Captulo 2. Los aspectos financieros 1. La estructura de costes
de un proyecto.

En un proyecto informtico como tal, por ejemplo el desarrollo de un software especfico para
determinada empresa, las condiciones econmicas y financieras estn presentes a lo largo de todo su
ciclo de vida.
NDICE
En un proyecto la estructura de costes ayuda a estimar los costes fijos y recurrentes de este. Para entender
un poco ms esta estructura, vamos a aprender trminos bsicos dado por Macas, (2011).
PRELIMINARES
a. Coste es el total de gastos incorporados a la produccin hasta un momento dado.
b. Coste es la suma de valores que hay que sacrificar para producir algo.
c. El coste, desde un punto de vista econmico, puede considerarse como:
La suma de bienes y servicios que se utilizan para llevar a cabo un determinado acto
productivo.
BIMESTRE
El consumo, valorado en dinero, de bienes y servicios utilizados en la produccin que
PRIMER
constituye el objeto de la empresa.
Para el jefe del proyecto es obvia la necesidad de conocer el precio de coste de un producto o servicio
(proyecto) no slo para decidir si debe o no fabricarlo, o si este es viable o no, sino tambin para poder
fijar su precio de venta, en caso de que sea un proyecto cuyo resultado final sea un producto dado a un
SEGUNDO
BIMESTRE
mercado especfico, porque tambin puede ser un proyecto desarrollado con fines internos, el cual su
precio de venta variara pero tambin se requiere saber para constatar finalmente la inversin final de la
organizacin en este producto.
En la estructura de costes de un proyecto informtico es un conjunto de costes, valga la redundancia, que
SOLUCIONARIO
determina el costo total de un proyecto, algunos de estos costes y herramientas usadas en la estructura
de costes estn descritas seguidamente, pero con ms detalle revsela en el texto bsico.
1. Salarios y prestaciones de realizacin.- Frecuentemente representan el 75% desde costes

de un proyecto durante el primer ao y hasta que est ya el producto o servicio en la fase de
mantenimiento. En este punto se construyen las tablas de costes, se negocian los costes diarios
BIBLIOGRFICAS
REFERENCIAS
en rgimen del coste de duracin, negociar las prestaciones en rgimen de coste fijo y se hace el
plan de carga financiera.
2. Las prestaciones de alojamiento: Para que las aplicaciones informticas de alto rendimiento,
funcionen, necesitan de hardware que est a su mismo nivel. Hoy en da externamente hay muchas
empresas que brindan estos servicios y que se debe tomar en cuenta sus costes ya que varan de
acuerdo al tipo de alojamiento y el plan de carga financiero.
Revisar el texto bsico Captulo 2. Los aspectos financieros - 1. La estructura de costes de

un proyecto 1.1.4. el plan de carga financiero y cmo o por quines est condicionado
este plan de carga.
3. Las prestaciones de explotacin y mantenimiento: Cuando se desarrollan soluciones existen

algunas operaciones para su explotacin y mantenimiento que pueden ser externalizadas, es
decir, pueden ser derivadas a terceros u otros expertos.
4. Las prestaciones de soporte a los usuarios: Se externaliza cuando estas actividades no son la
razn de ser de la organizacin o negocio. Por ejemplo, IBM presta servicios de soporte tcnico a
grandes empresas que tienen un robusto Sistema de Informacin.
5. Los costes refacturados: Se trata de operaciones puntuales como la asistencia mientras dura la
fase de aprendizaje de la solucin, procesos de formacin, etc.
6. Costes no relacionados con la informtica: Costes de comercializacin, marketing, recursos
generales y costes varios, etc.

2.3.1. Los presupuestos
Gurin (2015) indica que los presupuestos sintetizan lo planes de carga financiera as como contabilizan
NDICE
un conjunto de cargas necesarias en base a una escala de tiempo determinado para que el proyecto se
ponga en marcha, contine en el tiempo y llegue a trmino. Este presupuesto ayuda al jefe de proyecto
a controlar que los gastos se estn haciendo conforme lo acordado, de la misma manera si se est
excediendo del mismo o si en caso se podra ahorrar en algunos gastos.
PRELIMINARES
Revisar el texto bsico Captulo 2. Los aspectos financieros: 2. Los presupuestos, existe aqu dos tablas
de ejemplos de presupuesto. Cul es la diferencia a su criterio personal de ambos presupuestos? Cules
son los beneficios de cualquiera de ellos?
Es cierto que entre ambos presupuestos hay diferencias, pero en si los presupuestos
sea los costos y tiempo que abarquen son una base fundamental de seguimiento de un
BIMESTRE
PRIMER
proyecto.
2.3.2. La cuenta de resultados
Los ingresos del negocio deben ser comparados con los gastos generados por el proyecto, con la cuenta
de resultados Profit And Loss5 podemos hacer esta comparacin, en donde se ven inmersas algunas
SEGUNDO
BIMESTRE
variables que se describirn brevemente y que en el texto bsico los pueden profundizar.
1. El modelo econmico: Es una representacin simplificada de la economa real de una organizacin,

y se ponen aqu en manifiesto las interrelaciones entre las variables relevantes. En soluciones de
software hay algunas variables relevantes, conocidos como business models.
SOLUCIONARIO
a. Licencia y mantenimiento.
b. La suscripcin.
c. El modelo transaccional.
BIBLIOGRFICAS
2. La proyeccin financiera: Es una tabla en donde se proyectan los costes e ingresos que sirven
REFERENCIAS
para el anlisis financiero (beneficios y prdidas de un proyecto). Aqu se colocan los flujos de
tesorera, en el texto bsico en el Captulo2: Los aspectos financieros 3. La cuenta de resultados.
2. Proyeccin financiera, puede encontrar un ejemplo de flujo de tesorera para un supuesto
proyecto A.
En esta proyeccin se obtienen los indicadores claves VAN, TIR, Breakeven6, que ayudan a evaluar
la rentabilidad de la operacin. Break Even es el punto de equilibrio entre prdidas y ganancias.
(Gurin, 2015)
2.3.3. El Business case
Es un estudio de caso que resume los principales aspectos de una accin comercial que necesita un
producto o servicio para entrar en el mercado y se lo utiliza para justificar la inversin de un proyecto y
como lo dice en el texto bsico, su esperanza econmica. Gurin (2015) describe estos aspectos as:
1. La propuesta de valor: expresa el valor percibido por los futuros clientes de la solucin presentando
las principales caractersticas de la misma, como: funcionalidades, modelo econmico, tipos de
acceso, mercado de destino, etc.
5 Estado de Prdidas y Ganancias.

6 Es el punto en el cual no se obtienen ni prdidas ni ganancias en la bolsa de valores o empresa.

2. El top line financiero: Es un conjunto de indicadores financieros con los que ya se estudiaron
anteriormente, como: VAN, TIR, Break Even, etc.
NDICE
3. El exclusive summary: es un corto anlisis de los aspectos ms importantes del proyecto, en pocas
palabras se describe el producto, el servicio, el mercado, los factores de xito de los mismos, los
resultados esperados, las necesidades de financiamiento y las conclusiones generales.
El seguimiento financiero de los proyectos
PRELIMINARES
Se lo hace en base a dos componentes importantes, que son: los informes de
actividad se recopila informacin acerca de las actividades realizadas o por realizar
de un proyecto - y los ingresos de explotacin son ingresos de menor importancia
pero de manera ms o menos regular.
2.4. Ejemplo de estudio financiero sitio de venta online
BIMESTRE
PRIMER
En el texto bsico tenemos un ejemplo, aunque no abarcan costos reales ni todas las variables especficas
que participan en un proyecto, nos aclarar mejor lo estudiado en esta unidad. Le invito a desarrollar la
siguiente actividad:
Lea comprensivamente el ejemplo del texto bsico Captulo 2: Los aspectos financieros:
SEGUNDO
BIMESTRE
Estudio financiero del sitio web On-line. Asuma que usted es Mara la dirigente de la
empresa a la que se refieren en el ejemplo. Procedera igual que Mara para determinar
la estructura de costes de la empresa? Con todas las actividades que se realizan Puede
hacer el anlisis financiero de la misma o faltan algunas variables a estudiar o analizar?
SOLUCIONARIO
Ingrese peridicamente al campus virtual EVA (http://utpl.edu.ec/) para familiarizarse

BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 2
NDICE
1. La idea de propuesta de un proyecto que surge como respuesta a necesidades:
PRELIMINARES
a. Genera riqueza con valores agregados.
b. Es sencilla y fcil de imitar.
c. Resulta de un trabajo de investigacin.
2. De las siguientes cul no es una fuente para obtener ideas de proyectos:
BIMESTRE
a. Innovaciones tecnolgicas.
PRIMER
b. Proyectos fracasados.
c. Bibliografa de direccin de proyectos.
3. En la viabilidad de un proyecto est el estudio del entorno cultural que se refiere a:
SEGUNDO
BIMESTRE
a. Estudio de actitudes de los clientes potenciales del mercado
b. Estudio estadstico de la poblacin humana y su distribucin.
c. Estudio de la suma total del conocimiento.
4. La viabilidad tcnica de un proyecto se refiere a:
SOLUCIONARIO
a. Determinar la existencia de trabas legales.
b. Determinar si el proyecto es rentable o no.
c. Determinar si el proyecto es posible fsica o materialmente.
BIBLIOGRFICAS
5. Las siglas VAN significan:
REFERENCIAS
a. Periodo de recuperacin de inversin.
b. Tasa interna de retorno.
c. El valor neto actual.
6. Consiste en actualizar los cobros y pagos de un proyecto o inversin y calcular su diferencia.

7. Nos da el tiempo en que se recupera la inversin, incluido el capital:


8. Es la suma de los valores que hay que sacrificar para producir algo:
a. Tasa interna.
NDICE
b. Valor agregado.
c. Coste.
9. La suma de bienes y servicios que se utilizan para llevar a cabo un determinado acto productivo,
PRELIMINARES
se llama:
a. Tasa interna.
b. Valor agregado.
c. Coste.
BIMESTRE
PRIMER
10. Sintetizan lo planes de carga financiera as como contabilizan un conjunto de cargas necesarias
en base a una escala de tiempo:
a. Los presupuestos.
b. La cuenta de resultados.
SEGUNDO
c. Plan inicial del proyecto.
BIMESTRE
final de la gua.
SOLUCIONARIO
Ir a solucionario
BIBLIOGRFICAS
REFERENCIAS
Le invito que se esfuerce un poco ms y busque apoyo en las tutoras o se comunique con su profesor tutor
para as lograr el desarrollo de sus competencias.

UNIDAD 3. LA ESTIMACIN DE RIESGO EN UN PROYECTO
NDICE
Se recomienda la lectura del texto bsico Captulo 3. La estimacin del riesgo. As como
las lecturas de apoyo sugeridas a lo largo de esta unidad.
PRELIMINARES
Estimado estudiante, vamos a dar inicio al estudio de la tercera unidad, para ello se requiere que tenga
ya los conocimientos bsicos de la gestin de proyectos adquiridos en las Unidades 1 y 2 de esta gua.
En esta unidad abordaremos los lineamientos que se consideran para la estimacin de riesgos de un
proyecto.
En la vida diaria muchas empresas fracasan en sus proyectos, a pesar que todo los pasos
BIMESTRE
PRIMER
previos a los mismos fueron tomados en cuenta con cautela, como puede ser definicin
de requisitos, creacin de un plan de comunicacin paralelo al ciclo de vida del proyecto,
sin embargo, la no estimacin de los riesgos de un proyecto puede convertirse en el
ms grande error cometido, pues no se lograra abstraer de mejor manera las mejores
opciones para el desarrollo del proyecto, en sentido por ejemplo de saber cul es el
SEGUNDO
BIMESTRE
mejor modelo de desarrollo o la aplicacin de un modelo de anlisis donde nos ayudara
a crear de mejor manera lo que el usuario final o cliente solicita.
Cuando el jefe del proyecto no sabe cmo o por dnde empezar el proyecto, que ya
est plasmado en una idea y que ya se tiene por lo menos generalmente visualizados
SOLUCIONARIO
los requerimientos que necesitar debe tener presente el estudio de los tres ejes
que en el texto bsico tenemos.
3.1. Los Tres Ejes

Para entender estos tres ejes Gurin (2015) menciona que a un proyecto se lo debe tomar como si fuera
BIBLIOGRFICAS
REFERENCIAS
un proceso, el mismo que ser un espacio estructurado tridimensional compuesto por: Tiempo que ser
el ciclo de vida del proyecto, anlisis y control. En la figura 8 estos tres ejes estn representados.
Figura 8. Los tres ejes

Fuente: Gurin, (2015)
Tiempo (ciclo de vida del proyecto): Suponiendo que el proyecto es un proyecto estndar,
comienza en la expresin de las necesidades y termina en el mantenimiento, en algunos modelos
de desarrollo, terminan el proyecto en una etapa que estar luego de mantenimiento, denominada
Finalizacin.

Anlisis (abstraccin): La abstraccin lo que hace es sacar en trminos entendibles, o dividir

por partes el proyecto, para obtener de manera ms especfica, por ejemplo, los requerimientos
funcionales o no funcionales, justo en las especificaciones y empezando el desarrollo de los
NDICE
mismos es donde se hace ms un proceso de abstraccin.
Control (ciclo de decisin): Est representado por los riesgos, puntos de control y tomas de
decisiones en el proyecto. Conforme avanza el proyecto algunos mtodos van forjando este ciclo
PRELIMINARES
de decisin de manera metdica y eficaz. (Gurin, 2015)
Por favor lea comprensivamente y trate de analizar la tabla que se encuentra en el texto
bsico Captulo 3: La estimacin de riesgo 1. Los tres Ejes. Por qu no es bueno
aplicar mtodos aislados en los diferentes ejes?
3.2. El modelo de desarrollo
BIMESTRE
PRIMER
Una de las cosas que debe hacer el jefe del proyecto es elegir el mejor modelo de desarrollo que se
adapte a las necesidades del proyecto a emprender.
Gurin (2015) menciona que no hay ni buenos ni malos modelos, pero hay algunos que se utilizan ms
o que son ms adaptables dependiendo del tipo de proyecto que se quiera desarrollar.
SEGUNDO
BIMESTRE
En el texto bsico se hace referencia de algunos modelos con su respectiva explicacin
aunque no est totalmente descrito su estudio, s es de su particular inters uno de ellos,
le invito a que haga un estudio ms profundo del mismo.
SOLUCIONARIO
En la tabla 8 se resumen los modelos de desarrollo.
Tabla 8. Modelos de desarrollo.78
Modelo Enfoque
Modelo lineal (no se puede desarrollar una etapa paralela a otra) o nominal (cada uno
BIBLIOGRFICAS
REFERENCIAS
1. Modelo en es libre de aadirle otras etapas o de revisarlo), cada etapa sigue a la anterior. En el
cascada texto bsico en el apartado de este modelo, tenemos una tabla con la definicin de
cada etapa.
Anticipa las pruebas funcionales externalizndolas, se hacen en paralelo y luego se
2. Modelo en V aplican. Este modelo pretende anticipar el error de cobertura funcional para ahorrar
trabajo y tiempo.
Anticipa las pruebas de integracin, se enfoca en disminuir los riesgos tcnicos, se
3. Modelo iterativo
comienza por las partes ms difciles para eliminar el riesgo de abandono.
Predomina la maquetacin grfica y exploracin funcional, el cliente participa
activamente en el alcance. Utiliza tecnologa robusta y madura y es usado para las
3.1. Modelo RAD8
herramientas de desarrollo integradas que residen en los servidores de aplicacin
ligeros.
3.2. Modelo de Hace nfasis en el tipo de dilogo con el cliente. Funciona con ciclos de produccin
Extreme intermedios (versiones) muy cortos. Es ideal si se desea un modelo de integracin
Programming continua que obligue a cumplir el catlogo de buenas prcticas de programacin y
- XP ciclos de desarrollo cortos.
Proceso de desarrollo basado en UML. Es de un nivel conceptual bastante alto y no se
3.3. Modelo RUP9
puede aplicar tal cual.
Fuente: Gurin, (2015)
7 RAD significa Desarrollo rpido de aplicaciones.

8 RUP significa Proceso Racional Unificado.

3.3. El modelo de anlisis

Es el siguiente modelo que debe tomar en cuenta el jefe del proyecto, con el que administra el estudio
NDICE
del futuro sistema. Existen dos mtodos ms utilizados, Merise y UMTambin existe un principio de
modelizacin de anlisis que debemos tomar en cuenta y nos dejar claro como es este proceso.
3.3.1. Principio de modelizacin de anlisis
PRELIMINARES
Debemos suponer que vamos a describir una situcin de un sistema o de lo que debera hacer una
aplicacin en un documento, esto se llama abstraccin, la tcnica de la modelizacin ayuda a definir
prioridades en un proyecto informtico, es decir, desechar detalles que no tienen ningn valor ni
importancia dentro del proyecto.
La modelizacin se lleva a cabo en tres fases, tal como se presenta en la figura 9:
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 9. Fases de modelizacin
SOLUCIONARIO
Adaptado de Gurin, (2015)
Abstraccin: es la etapa ms delicada, donde se extrae lo fundamental y de donde se crean los

modelos que son una representacin formalizada y subjetiva de la realidad.
Instanciacin: se crean instancias a partir de los modelos obtenidos con la abstraccin.
Verificacin: siempre es necesario regresar atrs para poder verificar si se hizo una abstraccin
BIBLIOGRFICAS
REFERENCIAS
correcta, a medida que la abstraccin est bien, la instanciacin est bien.
Con la finalidad de que comprenda mejor este tema, lo invito a resolver las siguientes actividades:
Por favor estudie detenidamente los dos casos que est en el texto bsico Captulo 3: La
estimacin de riesgos 3. Modelo de anlisis 3.1. El principio de modelizacin del anlisis
a. El ejemplo del diccionario de trminos y b. El ejemplo de las figuras geomtricas. En
el Ejemplo a. Antes de llegar a la verificacin Detecta alguna incoherencia en la etapa de
modelado o modelo? En el Ejemplo b. Es posible construir una figura que no pertenezca
al inventario de figuras propuesto?
En el texto bsico en el apartado sugerido anteriormente puede encontrar una detallada explicacin de
la resolucin de los dos ejemplos y con ello podemos llegar a la siguiente conclusin:
La modelizacin es una actividad muy delicada y que debe siempre estar ajustada a la
realidad que queremos representar. La mayora de proyectos fracasan porque en las
especificaciones de requisitos se toman en cuenta, requisitos intiles que al final slo
harn perder tiempo y recursos.

3.3.2. Modelo Merise
El principio de modelizacin de anlisis se convierte en la base para algunos modelos de anlisis ms
NDICE
estructurados y normalizados como es el modelo Merise, que con sus fases ayuda a ser ms rigurosos al
momento de generar los diferentes modelos sugeridos segn Gurin (2015):
Se reunen todos los documentos relacionados con el proyecto, desde regulaciones y
PRELIMINARES
contratos hasta planes.
Se habla con cada uno de los usuarios o participantes o stakeholders del proyecto para
tener ms amplia la idea del proyecto o proceso. El punto anterior y este punto, es con la
finalidad de delimitar el sistema o proyecto.
Se pasa al nivel de abstraccin ms alto construyendo los modelos conceptuales y la
semntica del sistema, concentrndose en el QUIN.
BIMESTRE
PRIMER
Con el resultado anterior se pasa a la creacin de modelos organizativos que nos ayudarn
a crear o entender la lgica del sistema, se genera una base de datos, obviamente luego de
seleccionar el motor SQL.
Finalmente se obtiene un modelo fsico, que es un script de creacin de base de datos.
SEGUNDO
BIMESTRE
En el texto bsico Captulo 3: La estimacin de riesgo 3. EL modelo de anlisis. 3.2 El
modelo Merise, puede profundizar ms respecto a este tema.
SOLUCIONARIO
3.3.3. Modelo UML
UML - Unified Modeling Language ayuda a visualizar, especificar, construir y documentar un sistema,
especificando los procesos o mtodos del mismo. Con el uso de diagramas de casos de uso, diagramas
de actividad y diagrama de carril se puede entender de mejor manera la interaccin entre los usuarios
o stakeholders y el proyecto. Brevemente se explican los pasos que se siguen en un modelado con UML
BIBLIOGRFICAS
REFERENCIAS
para el anlisis (Gurin, 2015):
Se delimita el sistema identificando actores y construyendo casos de uso.

Se construyen flujos del trabajo mediante secuencias de sistema (escenarios) y tambin se
desarrollan los modelos del dominio con los datos del sistema.
Se construyen los diagramas de clase creando el modelo conceptual del sistema.
Finalmente se construye la arquitectura lgica y tcnica del sistema.
En el texto bsico puede encontrar con ms detalle la explicacin respecto al modelado

UML, se recomienda leer este apartado, as como leer el siguiente artculo: https://goo.
gl/0ZVm8D, en donde con un ejemplo podr recordar qu es un caso de uso, un diagrama
de actividad y de carril.
3.4. El modelo de control

El objetivo de todo jefe de proyecto es llevar el proyecto a su fin con el alcance, costo y tiempos definidos,
esto conlleva a que haya un arduo control, pudiendo ser un sistema o un modelo empleado para poder
encontrar peligros, riesgos o amenazas y as anticipar los cambios o contramedidas necesarias para que
el proyecto no se vea interrumpido de ninguna manera.

El control comprueba el proceso con una visin exterior, pero un proyecto se lo desarrolla como si fuera
un proceso, esta actividad va arraigada mucho con la empresa por lo que los controles tambin deben
NDICE
cubrir la parte interior.
Hoy en da el desarrollo de grandes proyectos basados en desarrollo de software se han puesto en

marcha, por ejemplo la automatizacin de un proceso vital de la empresa o la automatizacin de un
servicio, algunos han alcanzado los objetivos propuestos en estos proyectos, otros se han visto en
PRELIMINARES
algunos escenarios como culminar el proyecto pero con el presupuesto sobrevalorado, o no cumplir
con lo que el cliente o empresa esperaba que cumpla o haga este software, es por ello que las empresas
han visto la necesidad de incluir un modelo de control que les ayude a lograr los objetivos propuestos
en cierto.
Necesitamos conocer ciertas definiciones para tratar de entender lo que hace un modelo de control,
estas definiciones las hemos tomado del modelo COSO (Committee of Sponsoring Organizations of the
BIMESTRE
PRIMER
Treadway Commission):
Control: Cualquier medida que tome la direccin, el Consejo y otros, para mejorar la gestin
de riesgos y aumentar la probabilidad de alcanzar los objetivos y metas establecidos.
La direccin planifica, organiza y dirige la realizacin de las acciones suficientes para
SEGUNDO
BIMESTRE
proporcionar una seguridad razonable de que se alcanzarn los objetivos y metas.
Control interno: Proceso llevado a cabo por el Consejo de Administracin, la Gerencia y otro
personal de la Organizacin, diseado para proporcionar una seguridad razonable sobre el
logro de los objetivos de la organizacin clasificados en:
SOLUCIONARIO
Efectividad y eficiencia de las operaciones
Confiabilidad de la informacin financiera
Cumplimiento con las leyes, reglamentos, normas y polticas
Caractersticas del control interno:
BIBLIOGRFICAS
REFERENCIAS
Medio para alcanzar un fin, no un fin en s mismo.
No es un evento o circunstancia sino una serie de acciones que influyen en las
actividades de la organizacin.
Forma parte de los procesos bsicos de la administracin: planeacin, ejecucin y
monitoreo y se encuentra integrado en ellos.
Los controles deben construirse Dentro de la infraestructura de la organizacin y no
Sobre ella.
Es efectuado por personas. No es solamente un conjunto de manuales de polticas y
procedimientos, sino son personas en cada nivel de la organizacin.
Es ejecutado por la gente de una organizacin a travs de lo que hace y dice. La gente
disea los objetivos de la Entidad y establece los mecanismos de control.
Afecta las acciones del personal, sealndole sus responsabilidades y lmites de
autoridad, as como la vinculacin entre sus deberes y la forma en que los desempean.
La alta direccin es responsable de la existencia de un eficiente sistema de control.
Los Directores tienen la obligacin de la vigilancia del control adems de que
proporcionan directrices y aprueban ciertas transacciones y polticas.
Cada individuo dentro de la organizacin tiene algn rol respecto al control interno.

No existe sistema infalible. Ningn sistema har por siempre lo que se espera que
haga.
NDICE
No importa lo bien diseado y operado que sea un sistema de control; lo ms que
puede esperarse es que proporcione seguridad razonable.
El efecto acumulado de controles y su naturaleza diversa, reducen el riesgo de que no
puedan alcanzarse los objetivos.
PRELIMINARES
Con el tema un poco ms claro de lo que es un control y cules son las caractersticas del mismo, debemos
tener en cuenta que para llevarlo a cabo se necesitan indicadores de rendimiento clave (KPI), con estos
indicadores el comit de direccin aporta orientaciones nuevas y modifica prioridades, este comit es
quin en el futuro decidir sobre el resultado del proyecto si hay riesgos significativos y si hay peligros
con consecuencias negativas. Gurin, (2015)
BIMESTRE
PRIMER
El comit de control utiliza los KPI para dar un informe si el jefe de proyecto lo requiri, y en base a esa
respuesta se toman decisiones en la planificacin, aplazarla, adelantarla, suspenderla, tambin puede
que el tiempo que se necesita es menos del que se planific anteriormente. Con esto podemos llamarlo
mini-proceso de lo que hace el comit de control y quedara enmarcado en la figura 10:
SEGUNDO
BIMESTRE
SOLUCIONARIO
Figura 10. Funcin del Comit de control
BIBLIOGRFICAS
Adaptado de Guern, (2015)
REFERENCIAS
En el texto bsico puede encontrar con ms detalle la explicacin respecto al modelo
de control, se recomienda reforzar con la lectura de marcos de referencia que ayudan a
llevar a cabo la aplicacin de control o control interno dentro del proceso de proyecto,
puede ser una norma ISO.
3.5. La estimacin de riesgos

3.5.1. El anlisis de riesgos
El objetivo de todo gerente de proyectos es llevar el mismo a su fin con el alcance, costo y tiempos
definidos y, cumpliendo los estndares de calidad necesarios. Por ello, se hace indispensable una efectiva
gestin de riesgos.
Qu es un riesgo? Es un evento o suceso que de efectivizarse puede afectar positivamente

o negativamente a un proyecto, es decir, puede ocurrir o no y, si su afectacin es negativa
el gerente del proyecto debe planificar actividades, tareas o estrategias para minimizar
o evitar esos efectos. Si este genera un resultado positivo, el gerente debe crear las
acciones necesarias para aprovecharlo. El resultado de la gestin de riesgos es la esencia
de la gestin de proyectos.

El anlisis de los riesgos es una actividad crucial en la gestin del proyecto cuyo objetivo principal es
encontrar, mitigar, controlar o eliminar las advertencias, crticas, objeciones que hay durante todo el
NDICE
ciclo de vida del proyecto, a raz de esto se toman las acciones necesarias para lograr el desarrollo del
proyecto y alcanzar los objetivos del mismo, en lineamiento con su alcance.
En el texto bsico Captulo 3: La estimacin de riesgos 5. Estimacin de riesgos 5.1. El

anlisis de los riesgos, encuentra una tabla con una lista de clases y tipos de riesgos que
PRELIMINARES
es importante que usted sepa identificar para que los tenga claro a la hora de especificar
los riesgos en un proyecto.
Gurin, (2015) refiere que la persona encargada del anlisis o gestin de riesgos debe confrontar cuan
pertinentes son las decisiones tomadas durante la fase de diseo con las realidades del proyecto.
3.5.2. Identificacin, caracterizacin y plan de riesgos
BIMESTRE
PRIMER
Ramn et al. (2007) sealan que el riesgo es por definicin incierto, nadie puede asegurar qu ocurrir o
qu no ocurrir. Hay un espectro de posibilidades que normalmente est en relacin con la informacin
disponible del proyecto.
Algunos autores coninciden que cuando se define el proyecto es el momento ms adecuado para
SEGUNDO
BIMESTRE
la identificacin (cules), cuantificacin (con que probabilidad de ocurrencia, con qu impacto en el
proyecto) y calificacin (de que tipo, el alcance que tendr).
Otro punto importante en la identificacin de riesgos es definir quin (Stakeholders)

asume estos riesgos y cuales son todas las consecuencias de su ocurrencia.
SOLUCIONARIO
En todo proyecto siempre existen riesgos, por lo que se trata de establecer mecanismos de observacin
y prevencin, planes para mitigar o reducir los riesgos y planes de contingencia para el caso en el que
el evento no deseado pueda ocurrir (Ramn et al. , 2007). Para establecer estos mecanismos el jefe de
proyecto o la persona encargada de la gestin de riesgos del proyecto, hace o establece en la mayora de
BIBLIOGRFICAS
REFERENCIAS
proyectos una matriz de valoracin de riesgos o matriz de impacto probabilidad, un ejemplo se ilustra
en la figura 11.
La matriz de impacto y probabilidad para la valoracin de riesgos utiliza dos componentes claves:
a. Probabilidad de ocurrencia.
b. Nivel de impacto.
Figura 11. Matriz de Impacto y Probabilidad

Adaptado de Franc (2010)

Ramn et al. (2007) nos proporciona un modelo de monitorizacin de riesgos descrito en la tabla 9, que
nos puede ayudar a gestionar o encontrar riesgos durante todo el ciclo de vida del proyecto.
NDICE
Tabla 9. Modelo de monitorizacin de riesgos
Identificacin
Estatus del riesgo: potencial, actual, problema
PRELIMINARES
Proceso de Gestin de riesgos Anlisis de impacto
Preparacin de contramedida
Responsabilidad
La presentacin de la propuesta u oferta
La firma del contrato
El lanzamiento del proyecto
Momentos clave del proceso
Los hitos de entrega de productos
BIMESTRE
Las reuniones de seguimiento
PRIMER
El cierre
Resultado comparado con el plan
Calendario real comparado con el plan
reas clave de seguimiento
Nuevos riesgos o temas parecidos
Cambios en el alcance o impacto
SEGUNDO
BIMESTRE
Fuente: El Autor
En el texto bsico La estimacin de riesgo La estimacin de riesgos 2. El plan de riesgos.

Tenemos una tabla que es un resumen de los riesgos identificados y peso (valores), con
lo que en algunos proyectos se evala el bloqueo o fracaso del mismo, este apartado le
SOLUCIONARIO
ayudar a reforzar los conocimientos en este tema.
En la gestin de riesgos se debe conocer qu se puede hacer con un riesgo cuando este es identificado,
y hay 4 maneras de tratarlo:
Evitar: que consiste en tomar las acciones necesarias para saltarse o evitar las actividades que
BIBLIOGRFICAS
llevan a efectivizar el riesgo.
REFERENCIAS
Transferir: Ha escuchado usted qu se logra con las aseguradoras? precisamente eso, transferir
los riesgos asociados a los activos que se aseguran.
Mitigar: implementar las acciones necesarias para disminuir la posibilidad de que el riesgo se
efectivice.
Aceptar: esta respuesta se aplica cuando el riesgo no es categorizado como crtico y el gerente del
proyecto considera que se puede avanzar a pesar de su existencia, sin embargo, este riesgo debe
ser monitoreado constantemente para reaccionar a tiempo si este cambia su nivel de criticidad.
Es importante evaluar los riesgos durante todo el ciclo de vida del proyecto, pero
mucho ms importante es evaluar los posibles riesgos antes que empiece el proyecto.
Los miembros del comit evaluador, revisan los riesgos identificados y buscan una
posible solucin, puntualizando si repercute en el alcance y presupuesto del proyecto.
Hacer una correcta gestin de riesgos, permitir al jefe de proyecto elegir el modelo de desarrollo y el
modelo de anlisis del proyecto. No hay que olvidar que el jefe del proyecto debe procurar la finalizacin
del proyecto, manteniendo siempre el equilibrio y la planificacin tal como est prevista.

En el texto bsico Captulo 3: La estimacin de riesgos 5. Estimacin de riesgos 5.2.

El plan de riesgos. B - Elegir el modelo de proyecto en funcin del riesgo. Hay una tabla
NDICE
comparativa de las partes del proyecto donde se evalan riesgos y las restricciones de
tres modelos. Depende del jefe del proyecto elegir el que se asemeje a su proyecto.
3.6. Caso de estudio Estudio de riesgos para el proyecto de CRM
PRELIMINARES
En el texto bsico tenemos un caso de estudio sobre un proyecto donde se deben identificar los riesgos
aplicables a un proyecto de implantacin de un CRM (Administracin basada en relacin con los clientes).
Por favor realice la siguiente actividad.
Lea comprensivamente el caso de estudio, el anlisis de riesgos y el plan de riesgos.

Asuma que usted es Ana y que realiz un anlisis cruzado de tipo de riesgo y que los
riesgos predominantes son con la organizacin. Qu metodologa de desarrollo y
BIMESTRE
PRIMER
anlisis propondra al cliente para este proyecto? Para un riesgo funcional qu tipo de
modelo se adatara mejor segn su criterio?
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 3
NDICE
1. El eje de anlisis en un proyecto:
PRELIMINARES
a. Est representado por los riesgos en el proyecto.
b. Divide el proyecto en partes para entender mejor los requerimientos.
c. Tambin se llama ciclo de vida del proyecto.
2. El eje de control en un proyecto:
BIMESTRE
a. Est representado por los riesgos en el proyecto.
PRIMER
b. Divide el proyecto en partes para entender mejor los requerimientos.
c. Tambin se llama ciclo de vida del proyecto.
3. El modelo de desarrollo iterativo:
SEGUNDO
BIMESTRE
a. Cada etapa sigue a la anterior
b. Hace pruebas funcionales en paralelo.
c. Se enfoca en disminuir los riesgos tcnicos.
4. El modelo de desarrollo en V:
SOLUCIONARIO
a. Cada etapa sigue a la anterior
b. Hace pruebas funcionales en paralelo.
c. Se enfoca en disminuir los riesgos tcnicos.
BIBLIOGRFICAS
5. La abstraccin en la modelizacin de anlisis es la etapa en donde:
REFERENCIAS
a. Se crean instancias a partir de los modelos obtenidos.
b. Se extrae lo fundamental y a partir de aqu se crean los modelos.
c. Se verifican las etapas de modelizacin.
6. Encontrar peligros, riesgos o amenazas y as anticipar los cambios o contramedidas necesarias

para que el proyecto no se vea interrumpido de ninguna manera, es la tarea del modelo de:
a. UML
b. Merise
c. Control
7. De los siguientes cual concepto NO corresponde al control interno:
a. Medio para alcanzar un fin.

b. Serie de acciones.
c. Es un evento o circunstancia.

8. Cuando se toman las acciones necesarias para saltarse las actividades que llevan a efectivizar el
riesgo, es cuando al riesgo lo estamos:
NDICE
a. Evitando
b. Transfiriendo
c. Mitigando
PRELIMINARES
9. Si una organizacin contrata los servicios de una Aseguradora privada (de vida, de salud), es
cuando al riesgo se lo est:
a. Evitando
b. Transfiriendo
c. Mitigando
BIMESTRE
PRIMER
10. Cuando el riesgo no est categorizado como crtico entonces se lo:
a. Transfiere
b. Mitiga
c. Acepta
SEGUNDO
BIMESTRE
final de la gua.
SOLUCIONARIO
Ir a solucionario
BIBLIOGRFICAS
REFERENCIAS

Texto-Gua: Gestin de Proyectos Informticos SEGUNDO BIMESTRE
SEGUNDO BIMESTRE
NDICE
UNIDAD 4. INICIAR Y ANALIZAR UN PROYECTO
PRELIMINARES
Para el estudio de esta unidad se recomienda la lectura de los captulos 4. Iniciar un
proyecto y 5. El anlisis, del texto bsico. As como las lecturas de apoyo sugeridas a lo
largo del estudio de esta unidad.
BIMESTRE
PRIMER
Estimado estudiante, vamos a dar inicio al estudio de esta cuarta unidad, que se convierte en el primer
tema de estudio del segundo bimestre de este componente. Abordaremos las pautas que se necesitan
para iniciar un proyecto as como para analizar el mismo, previo al desarrollo.
En la unidad 2 de esta gua vimos algunos lineamientos de donde puede surgir un proyecto, puede
ser una idea o necesidad de alguna empresa, pero tambin hay otros puntos a tomar en cuenta y los
SEGUNDO
BIMESTRE
estudiaremos dentro de la etapa de inicio del proyecto, desde la perspectiva de que por lo general en el
entorno de proyectos informticos el inicio de un proyecto se da tambin desde otros puntos. Vamos a
analizar cada punto:
4.1. Iniciar un proyecto
SOLUCIONARIO
4.1.1. Punto de inicio de un proyecto - La convocatoria de licitacin
La empresa u organizacin tiene una lista de requerimientos de un proyecto y esta lista es entregada
a algunos proveedores, a los que se les solicita que hagan una oferta. Estos proveedores son elegidos
conforme el patrocinador o el jefe de la empresa los vea necesarios y dependiendo del proyecto a
BIBLIOGRFICAS
REFERENCIAS
desarrollar. Tendrn siempre un tiempo estimado para que los proveedores presenten sus ofertas, en
base a criterios el patrocinador o el jefe de la empresa escoge la mejor opcin. Estos criterios pueden
estar en torno a calidad, costo, tiempo, etc. Cuando se haya elegido, se notifica al proveedor con una
orden de ejecucin. Hay que tener en cuenta que estamos hablando de proyectos de empresas privadas,
ya que las empresas pblicas manejan de diferente manera la parte de orden de ejecucin.
Puede ser que ahora mismo usted est prestando sus servicios en alguna empresa pblica
o privada. Sera importante a medida de lo posibl, que pregunte. Cmo empiezan un
proyecto?Quin los solicita?Quin los aprueba?Hay concursos para ganar el desarrollo
de un proyecto interna o externamente?
En esta convocatoria existen algunos documentos que se deben tomar en cuenta:
a. Documentos que conforman una licitacin: Son Marcos de Referencia9 donde se agrupan
las especificaciones y se las contextualiza, as como tambin se indican los objetivos que el
patrocinador o jefe de empresa quiere alcanzar. Por lo general se agrupan un conjunto de
preguntas y las respuestas por escrito o codificadas, como podemos ver en el ejemplo en
el texto bsico Captulo 4: Iniciar un proyecto 1. El punto de inicio 1.1 La convocatoria
de licitacin a. Documentos que forman una licitacin (Gurin, 2015). Existen algunos
9 Un conjunto de acciones que nos indican cmo deberan hacerse las cosas, basadas en valores, leyes o reglas

marcos de referencia que los vamos a enlistar brevemente, pero que en el texto bsico est
detallado el estudio de cada uno.
NDICE
Marco de referencia de la respuesta funcional: agrupa las preguntas referentes a los procesos
de la empresa con el software.
Marco de referencia de la respuesta tcnica: agrupa las preguntas referentes a la plataforma
tcnica a ser usada, teniendo en cuenta temas de integracin de la aplicacin, administracin
y versionamiento de la misma.
PRELIMINARES
Marco de referencia de la respuesta sobre la organizacin: no solo agrupa preguntas
sino reglas que se deben cumplir obligatoriamente, en torno a la forma de entrega y de
aceptacin de la aplicacin.
Marco de referencia de la respuesta presupuestaria: se refiere a la naturaleza del contrato
que se va a establecer entre el patrocinador y el proveedor, donde estn especificados
temas de coste, tiempo e incluso calidad del proyecto.
BIMESTRE
PRIMER
b. La peticin directa Como su nombre lo indica se empieza el proyecto con una peticin
que hace el cliente o por un servicio de marketing de un producto que est ofreciendo una
empresa. En proyectos de software los proyectos que empiezan con peticiones directas son:
Integracin de un paquete de software.
SEGUNDO
BIMESTRE
Desarrollo a medida de una solucin operativa.
Creacin de un nuevo paquete de software.
Incluir ms funcionalidades a un paquete de software que ya existe.
SOLUCIONARIO
4.2. Primeras decisiones o actividades
4.2.1. Definicin del mbito del proyecto
La definicin consiste en reformular lo que el cliente espera con miras a la evolucin que ste proyecto
tendr en el futuro.
BIBLIOGRFICAS
REFERENCIAS
Sea la metodologa que usemos o en que gua nos basemos para desarrollar un proyecto siguiendo su
ciclo de vida, la definicin del mbito del proyecto en general es la etapa donde se maneja una relacin
directa con el cliente a nivel directivo, sin embargo, resulta indispensable para el xito del proyecto que
sta fase se lleve con la prolijidad necesaria para que finalmente los objetivos que ha conseguido la
ejecucin del proyecto sean los que el cliente esperaba.
Esta actividad de definicin del mbito tiene el objetivo de la creacin de un documento que tiene varias
partes:
a. El contexto: se describe brevemente lo que el cliente tiene, y lo que quiere o desea obtener.
b. EL objetivo: se clarifica en qu va a participar el patrocinador y qu reas cubrir durante el

proyecto.
En el texto bsico Captulo 4: Iniciar un proyecto 2. Las primeras decisiones 1.

Definicin del mbito del proyecto Ejemplo de definicin del mbito de un proyecto.
Revise este ejemplo de definicin de proyecto que le va a servir para realizar algunas
actividades propuestas en el EVA de este componente acadmico.

Para contextualizar una peticin de cliente se debe hacerlo con un enfoque muy
parecido al proceso de modelizacin: es conveniente generalizar. Olvidando los
NDICE
detalles sin importancia (Gurin, 2015).
En este punto es importante tambin saber sobre temas de definicin de requerimientos.
La definicin de requerimientos consiste en identificar y documentar las necesidades de los interesados
PRELIMINARES
o stakeholders a fin de cumplir con los objetivos del proyecto. Como usted conocer, el xito del proyecto
depender directamente del cuidado que se tenga en obtener y gestionar los requisitos del proyecto
y del producto. Estos incluyen necesidades, deseos y expectativas cuantificadas del patrocinador, del
cliente y de otros interesados. Estos requisitos deben recopilarse, analizarse y registrarse con un nivel de
detalle suficiente, que permita medirlos una vez que se inicia el proyecto.
Un requerimiento es una condicin que un producto, servicio o software debe hacer por
BIMESTRE
PRIMER
sus usuarios. Puede ser una funcin especfica, caracterstica, principio o nivel de calidad
que el producto o servicio debe proveer para que merezca su existencia.
Los requerimientos constituyen parte del alcance del desarrollo de un proyecto. Sin los requerimientos,
no hay forma de validar el diseo de un sistema, no hay forma de conectar el producto con las necesidades
del proyecto (PMI, 2008).
SEGUNDO
BIMESTRE
La figura 12 hace una analoga de lo que una mala gestin de expectativas y requerimientos en la fase
inicial del proyecto puede generar. Esta situacin es muy parecida a la realidad. Usted ha visto un caso
similar? Por qu ocurre?
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS
Figura 12. Analoga de la gestin de requerimientos

Fuente: Garca et al. (2008)
4.2.2. El anlisis previo
Aunque ya en este paso es muy probable que el proyecto se realice porque ya empezamos la etapa
de inicio, es muy importante de dimensionarlo de manera muy precisa. Por ejemplo la rentabilidad
del proyecto depender de la precisin de las previsiones, es decir, de tener todos los recursos que se
necesiten para desarrollarlo (Gurin, 2015).
En este anlisis previo existen algunos puntos a tomar en cuenta:

a. La recopilacin de la informacin disponible: reunir toda la informacin que se necesite

para empezar el proyecto. En el texto bsico donde se trata de este apartado, se explica en
NDICE
una tabla claramente cules son los documentos a reunir y una breve descripcin de cada
uno.
b. Diseo de la solucin: la solucin que se busca y que se convierte en el objetivo de un
proyecto de software se la forma en base a los documentos reunidos y lo hacen los
stakeholders encargados de prever esta solucin.
PRELIMINARES
c. La restitucin: se trata de hacer las pruebas necesarias con la solucin propuesta para ver si
funciona y hacer los cambios necesarios en caso de que lo amerite, se empieza a construir
el plan global.
4.2.3. El organigrama de tareas
BIMESTRE
Es la estimacin de hombres-das necesarios para la realizacin del proyecto. Se puede construir una
PRIMER
tabla con las fases del proyecto y para cada fase distinguir el stakeholder que participa y cuantos das le
tomar desarrollar esa actividad.
Imagine que va a construir un portal web, cada una de las fases necesita un diferente
participante por ejemplo para la parte de diseo grfico que se trata de la forma del
SEGUNDO
BIMESTRE
portal, debe intervenir un diseador grfico, para la parte de codificacin debe intervenir
el programador web, para la parte de gestin de contenidos puede ser un experto en
comunicacin y marketing, y as sucesivamente.
En el texto bsico Captulo 4: Iniciar un proyecto 2. Las primeras decisiones 2.3 El
SOLUCIONARIO
organigrama de tareas. Existen unidades de trabajo de acuerdo al tipo de modelo de
desarrollo que se utilice para hacer una solucin de software, debe revisar este apartado
para poder fortalecer los conocimientos en esta rea.
4.3. La estructuracin del proyecto
BIBLIOGRFICAS
REFERENCIAS
4.3.1. El dimensionamiento del proyecto
Gurin (2015) indica que en esta parte del dimensionamiento del proyecto se contestan algunas
interrogantes como: Cul va a ser su duracin? Cuntos recursos estn afectados?Cul va a ser
la inversin necesaria?Cul es el precio a ofrecer al cliente por la realizacin de este proyecto? Para
responder estas preguntas se aplican mtodos empricos que han mostrado siempre buenos resultados.
a. La carga total en das/hombre.

El organigrama de tareas, se divide los das totales que se necesitar para cumplir con los
objetivos del proyecto para el nmero de perfiles o stakeholders que participarn en el
mismo, tomando en cuenta que en el desarrollo del proyecto se debe aumentar un poco
ms de das. Seguidamente vemos un ejemplo:
Tabla 10. Ejemplo de carga de das por perfiles.
Perfil 1 Perfil 2 Perfil 3

Perfiles
(Stakeholder 1) (Stakeholder 2) (Stakeholder 2)
Carga 30 25 15
Carga total (suma de carga) 70

Perfil 1 Perfil 2 Perfil 3

Perfiles
(Stakeholder 1) (Stakeholder 2) (Stakeholder 2)
NDICE
Gestin o desarrollo del proyecto
14
(20%+)
Carga del proyecto en das/
84
hombre
PRELIMINARES
Fuente: Gurin,(2015)
b. El personal que participa en el proyecto.
Cada proyecto es diferente uno a otro y la correcta asignacin de recursos y la contribucin

de cada miembro del equipo ayudar a que este se ejecute de la forma esperada, para lo
cual se hace indispensable la matriz de roles y responsabilidades, lo cual se integra con los
BIMESTRE
dems elementos de la planificacin a nivel de hitos y responsabilidades.
PRIMER
En la mayora de proyectos se utiliza la matriz de roles y responsabilidades, que para su
desarrollo se debe basar en dos aspectos:
Establecer una organizacin sencilla, donde la contribucin de cada uno sea nica,
SEGUNDO
BIMESTRE
distinta y observable, cada quien informe a una sola persona y las decisiones sean
ntidas e individuales.
Alinear lo ms posible la organizacin del proyecto con las reglas y costumbres de la
empresa, su propia estructura de lnea y sus rganos colegiados.
SOLUCIONARIO
En la tabla 11 se muestra la estructura de la matriz tpica de roles y responsabilidades, la
misma que se conoce tambin con el nombre de matriz RACI (Responsable, Aprobado,
Consultado, Informado).
Tabla 11. Matriz tpica de roles y responsabilidades.
BIBLIOGRFICAS
REFERENCIAS
RESPONSABLES (Stakeholders)
HITOS A (perfil 1) B (perfil 2) C
1 Especificacin de requisitos (documento) X d d
2 Plan de diseo e implementacin S X d
3 Plan de mantenimiento I P I
Fuente: Espinosa y Crdova (2015)
A, B, C, etctera, son los nombres o perfiles de los stakeholders que participarn en el

proyecto y en la parte de HITOS, van los hitos o entregables que se desarrollarn como
resultado final en cada fase del proyecto.
Los hitos del proyecto, que son los puntos clave de control de un proyecto, se
utilizarn para controlar el adecuado avance, pagos requeridos, informes a presentar,
etc.
En la tabla 12 est la descripcin de los smbolos que se utilizan para especificar que hace
(actividad o tarea) cada stakehorder dentro del proyecto.

Tabla 12. Roles ms comunes para la matriz de roles y responsabilidades.
NDICE
SMBOLO SIGNIFICADO
X Ejecuta el trabajo
D Toma decisiones en solitario o en ltimo lugar
PRELIMINARES
d Toma decisiones conjuntamente o parcialmente
P Gestiona el trabajo y controla el progreso
S Proporciona soporte y apoyo
C Debe ser Consultado
I Debe estar informado
BIMESTRE
PRIMER
A Est disponible para dar opinin y consejo
Una vez realizada la matriz debe evaluarse horizontal y verticalmente: horizontal para revisar
si cada hito tiene asignado los recursos necesarios en tiempo y calidad y verticalmente
SEGUNDO
BIMESTRE
asegura que cada miembro acte en la parte y momento adecuado.
Es importante resaltar que la matriz puede completarse con unas reglas de trabajo comunes
para todo el equipo.
SOLUCIONARIO
Gurin (2015) especifica que es posible que en proyectos informticos y sobre todo de
desarrollo de software, eliminar algunas configuraciones de personal que conducen de
manera evidente al fracaso. Si se asignan pocas personas, el proyecto durar ms tiempo,
incluso puede decaer en alguna fase de su ciclo de vida.
En el texto bsico Captulo 4: Iniciar un proyecto 3. La estructuracin del proyecto
BIBLIOGRFICAS
REFERENCIAS
3.1 El dimensionamiento del proyecto literal b. Se enumeran algunos aspectos que
pueden ayudar al jefe de proyecto a integrar bien la carga de das a los stakeholders del
proyecto.
c. Puntos a tomar en cuenta en la estimacin (errores ms habituales).
Aqu vamos a detallar algunos puntos que el jefe de proyecto debe tomar en cuenta para
hacer conocer a su equipo de trabajo. Se enlistan los siguientes puntos y en el texto bsico
podemos encontrar explicados con ms detalle:
Explicar correcta y detalladamente la evaluacin de todas las unidades de trabajo,

explicitando su complejidad y los riesgos que conllevan cada una de las tareas.
Insistir que se entienda la diferencia entre estimacin y planificacin. La planificacin es
un proceso que se define a la lo largo de todo el proyecto e involucra a todas sus reas
de conocimiento (Alcance, Cronograma, Costos, Recursos, Riesgos, Calidad, Proveedores,
Comunicacin), buscando el equilibrio y el balance entre estas. La estimacin es un
proceso analtico que da valor o predice la duracin de una actividad. La estimacin y la
planificacin deben ir de la mano, siempre que estimemos se debe planificar, por ejemplo
los recursos. Supongamos que tenemos un grupo de tareas a estimar y el resultado de esa
estimacin nos devuelve 80 horas (2 semanas). Suponiendo que algunos recursos para esas
tareas son part-time, unos ms caros, otros ms baratos, otros parecidos a lo que se necesita

y compatibles. En este caso la estimacin debe ir junto con la planificacin de asignacin de

tareas, para que el resultado de la estimacin sea ms real.
NDICE
Analizar qu est causando que la estimacin est sobrepasando el presupuesto fijado, o
el mbito del proyecto no est correctamente establecido o el diseo de la solucin ha
sobrepasado los lmites planificados inicialmente.
Identificar correctamente los riesgos que conlleva la estimacin del proyecto, y clarificar al
PRELIMINARES
cliente qu riesgos asumen quin.
4.3.2. El director del programa (Program Manager)
El Program Manager, conocido as por algunos expertos en direccin de proyectos, es la persona quin
solicita el desarrollo del proyecto, puede ser el mismo cliente o quin lo represente. En la figura 13
tenemos detalladamente las tareas y operaciones que hace el Program Manager.
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
Figura 13. Tareas y operaciones del Program manager
BIBLIOGRFICAS
Adaptado de Gurin,(2015).
REFERENCIAS
4.3.3. El jefe del proyecto
Tambin lo denominan Product Manager, es el responsable del desarrollo tcnico de la solucin. Gurin
(2015) especifica algunas de sus actividades:
Valida las condiciones de desarrollo del proyecto confiado por el director de programa.
Proporciona una propuesta al director del programa.
Gestiona el proyecto.
Participa en los comits de control.

3.3 El jefe del producto, en la tabla descrita all se especifican las tcnicas que utiliza para
hacer sus actividades en las diferentes reas en torno al desarrollo del proyecto.
4.3.4. La constitucin del equipo
El jefe del proyecto forma su equipo, y por lo general asigna las tareas segn su criterio o experiencia, a
cada uno de los perfiles identificados que participarn en el proyecto.


3.4 La constitucin del equipo, literal a, se puede encontrar una tabla con las actividades,
NDICE
funciones y perfiles que por lo general participan en un proyecto de desarrollo de
software.
4.3.5. La externalizacin de recursos
PRELIMINARES
Algunas empresas, segn el proyecto que desarrollen, en este caso un proyecto de desarrollo de
software, se ven en la necesidad de externalizar algunos recursos que en el momento del desarrollo del
proyecto son escasas.
Para lograr cumplir con los objetivos del proyecto, las empresas tienen dos opciones de externalizar y
son segn Gurin (2015):
BIMESTRE
PRIMER
Outsourcing: Se asigna personal temporal a un proyecto. Se externaliza el problema, en
nuestro caso el proyecto, dejando la solucin de este en manos de la empresa de outsourcing.
Subcontratacin: Las empresas subcontratan algunos elementos del proyecto. En la
subcontratacin, en concreto, comparecen tres partes: la empresa contratante, la empresa
de servicios y los trabajadores, siendo la relacin entre estas solamente de carcter comercial.
SEGUNDO
BIMESTRE
Revise en el texto bsico Captulo 4: Iniciar un proyecto 3. La estructuracin del
proyecto, los puntos 3.6, 3.7 .3.8 y 3.9 para que clarifiqu de mejor manera qu ms se
debe tener en cuenta a la hora de iniciar un proyecto. Participe en el EVA en las actividades
propuestas para fortalecer estos temas.
SOLUCIONARIO
4.4. Caso de estudio Arrancar el proyecto de control de actividad
En el texto bsico tenemos un caso de estudio sobre un proyecto donde un jefe de proyecto debe
diferenciar la peticin de la proposicin del cliente, precisando el planning general del equipo, conocido
como el inicio del proyecto o Kick-Off.
BIBLIOGRFICAS
REFERENCIAS
Lea comprensivamente el caso de estudio, sobre todo, comprenda cmo realiz el ajuste
del proyecto, la estructuracin del mismo, el anlisis de los riesgos, cmo se llev a cabo
la eleccin de los modelos y la iniciacin del mismo. Participe en el foro propuesto en el
EVA, con sus puntos de vista sobre cmo hubiera trabajado usted como jefe de proyecto,
en qu puntos est de acuerdo y en cuales no con el jefe de proyecto designado en este
caso.
4.5. El anlisis de la solucin

Para hacer el anlisis de la solucin, se tiene que recordar que la solucin de un problema, puede estar
implementada en trminos de proyecto, puede ser un proyecto de desarrollo de software.
Existen varios mecanismos para el anlisis de la solucin, estos son implementados por desarrolladores
de software especficamente y que el jefe de proyecto debe tambin conocer, es por esto que en este
apartado 5 de esta unidad, vamos a estudiar brevemente estos mecanismos.
4.5.1. El rea de negocio
Esta rea se centra en la estructuracin de datos que se considere para empezar el anlisis para la
construccin de la solucin. Se volvern a mencionar los modelos MERISE y UML que ya los vimos
brevemente en el captulo 3 de esta gua.

Veremos algunos conceptos que en nuestra carrera son muy comunes y que seguramente ustedes ya
conocen un poco de lo que se trata.
NDICE
A. Las bases de datos relacionales
Conocemos que una base de datos es un conjunto de tablas que guardan informacin, tambin nos
permite realizar diferentes operaciones como seleccionar, insertar, actualizar, borrar entre las ms
PRELIMINARES
conocidas. Las tablas por lo general tienen relacin unas con otras, estas bases de datos tienen elementos
que se deben conocer.
Por favor debe revisar en el texto bsico Captulo 5: El anlisis 1. Las bases de datos
relacionales donde est ms ampliamente explicado cada uno de los atributos de las
bases de datos relacionales. Seguramente ya ha trabajado con ellas en el transcurso del
estudio de esta carrera, pero es un tema que se debe tener muy presente a la hora de
BIMESTRE
PRIMER
desarrollar una solucin de software.
a. Las tablas
b. Las claves y las relaciones
c. Las vistas y las consultas
SEGUNDO
BIMESTRE
d. Los tratamientos y los procedimientos almacenados
Existen algunos tipos de bases de datos que fueron creados con la finalidad de trabajar con datos
relacionales como es SQL (Structured Query Language) y es el ms comn de utilizar.
SOLUCIONARIO
Con el avance de tecnologa y de plataformas de desarrollo de software donde se estudia ya la
Programacin Orientada a Objetos (POO), tambin las bases de datos han cambiado y se han creado
para que soporten datos de objetos, Gurin (2015) indica que existen dos maneras de hacer esto:
1. La base de datos relacional se asocia al framework por medio de un dispositivo que hace
corresponder los registros SQL con los objetos (mapeo de objetos relacional).
BIBLIOGRFICAS
REFERENCIAS
2. La base de datos integra mecanismos orientados a objetos que permiten el acceso a las
instancias de manera ms sencilla y los tratamientos son ms rpidos.
Tambin hay bases de datos semiestructuradas basados en modelos de datos semiestructutrados. Para
entender mejor este modelo de datos, por favor realizar la siguiente actividad.
Ingrese a la siguiente direccin https://goo.gl/KwLpv0. Aqu se explica claramente el

modelo de datos semiestructural, por favor lea comprensivamente y participe en la
actividad propuesta en el EVA respecto a este tema.
4.6. Modelo de desarrollo Merise

En el trabajo desarrollado por Prez y Salazar (2006) se describe que MERISE es un mtodo de
concepcin, de desarrollo y de realizacin de proyectos informticos. La meta de este mtodo es llegar a
realizar un sistema de informacin. El mtodo MERISE est basado en la separacin de los datos y de los
procedimientos a efectuarse en ms modelos conceptuales y fsicos.
La separacin de los datos y de los procedimientos asegura una vida ms larga del modelo. De este
modelo la parte ms importante a tomar en cuenta es la parte de anlisis en donde hace lo siguiente
(Prez y Salazar, 2006):

Identificar las necesidades del cliente. Evaluar qu conceptos tiene el cliente sobre el sistema
para establecer su viabilidad.
NDICE
Realizar un estudio tcnico y econmico. Asignar funciones a los recursos (hardware,
software, personas, bases de datos, etc.).
Establecer restricciones de presupuesto y planificacin temporal.
Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del hardware y software
PRELIMINARES
as como la administracin de personal y/o la administracin de base de datos.
Gurin (2015) menciona que MERISE de basa en diagramas de flujo para hacer este anlisis y cumplir con
estos objetivos por lo que se basa en varios modelos. La primera etapa del ciclo de anlisis de MERISE
delimita la realidad, es decir, identifica las necesidades del cliente antes que disearlas. Aqu se utilizan
algunos modelos:
BIMESTRE
PRIMER
a. MCD Modelo Conceptual de datos: es una lista de trminos conocida como diccionario de
datos, que no es nada ms que el resultado de muestras documentales, actividades y flujos,
previamente obtenidos.
b. MLD Modelo Lgico de datos: utiliza el MCD y realiza el rea relacional muy parecida a
SQL, con este modelo se determinan las representaciones de entidades y atributos, etc., que
SEGUNDO
BIMESTRE
servirn para la creacin del MFc.
c. MFD Modelo Fsico de datos: es la descripcin en cdigo SQL de la base de datos a utilizar,
por ejemplo, la creacin de tablas, identificadores nicos, etc.
En el texto bsico Captulo 5: EL anlisis 2. El modelo de anlisis, explica de mejor
SOLUCIONARIO
manera y con ms detalle cada uno de los modelos anteriores. Se recomienda leer lo
indicado para afianzar sus conocimientos en este tema.
4.7. Modelo UML (Unified Modeling Language)

Es el lenguaje de modelado de software ms utilizado en la actualidad en todos los proyectos de
BIBLIOGRFICAS
REFERENCIAS
desarrollo de software, ya que es un conjunto de notaciones destinadas a la descripcin de un sistema de
software y que cualquier Stakeholder puede comprender, sin necesidad de tener arduos conocimientos
de este modelo.
UML utiliza algunos diagramas con la finalidad de tener un nivel de abstraccin alto del sistema que se
va a desarrollar. En la siguiente lista estn los diagramas que se utilizan con mayor frecuencia.
a. Modelo de casos de uso: representan los objetivos funcionales de los usuarios que utilizarn
el sistema, la funcionalidad del Stakehorder.
b. Diagrama de clases: representan las clases que se han identificado en el sistema luego de
un arduo anlisis, y las relaciones que tienen unas con otras.
c. Diagrama de secuencia: aporta un nivel de detalle adicional distinguiendo los objetos del
sistema que estn implicados en un proceso o escenario.
d. Diagrama de actividades: donde se denota la responsabilidad o actividades que tienen en
sus manos los actores o Stakeholders previamente identificados.
e. Diagrama de estado-transicin: con este diagrama se extraen los datos ms importantes
de los atributos o campos que hay en el sistema, y trabaja colocando un estado en estos
atributos, las transiciones son las que cambian ese estado.

En el texto bsico Captulo 5: EL anlisis 3. El modelo de anlisis UML, explica de mejor

manera y con ms detalle cada uno de los diagramas anteriores. Se recomienda leer para
NDICE
afianzar sus conocimientos en este tema.
4.8. Caso de estudio: Anlisis del proyecto de control de calidad

Al final del Captulo 5 del texto bsico, puede encontrar un caso de estudio donde se aplican todos los
PRELIMINARES
conceptos revisados en esta unidad.
Lea comprensivamente el caso de estudio Anlisis del Proyecto de control de calidad

que est al final del Captulo 5: EL anlisis del texto bsico. Debe entender cada uno
de los pasos que los analistas llevaron a cabo para poder describir lo que el sistema de
software finalmente hace.
BIMESTRE
PRIMER

SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 4
NDICE
1. Un marco de referencias es:
PRELIMINARES
a. Integracin de un paquete de software.
b. Reformular lo que el cliente quiere.
c. Conjunto de acciones que nos indican cmo se hacen las cosas.
2. El marco de referencia funcional agrupa las preguntas referentes a:
BIMESTRE
a. La plataforma tcnica a ser usada.
PRIMER
b. Los procesos de la empresa con el software.
c. Tambin agrupa reglas que se deben cumplir.
3. El marco de referencia de la respuesta tcnica agrupa las preguntas referentes a:
SEGUNDO
BIMESTRE
a. La plataforma tcnica a ser usada.
b. Los procesos de la empresa con el software.
c. Tambin agrupa reglas que se deben cumplir.
4. La peticin directa de un proyecto se refiere a:
SOLUCIONARIO
a. Una idea que se le ocurre al jefe de proyecto
b. El cliente hace la peticin de un producto
c. Surge imprevistamente por una situacin.
BIBLIOGRFICAS
5. La definicin consiste en:
REFERENCIAS
a. Una metodologa aplicada para desarrollar un proyecto.
b. El plan de ejecucin del proyecto.
c. Reformular lo que el cliente ha solicitado.
6. El contexto de la definicin del proyecto es:
a. Descripcin breve de lo que el cliente tiene, quiere y desea obtener

b. Clasificacin de las reas en que el patrocinador participar.
c. Ninguna de las anteriores.
7. Consiste en identificar y documentar las necesidades de los stakeholders:
a. Ejecucin de proyecto.
b. Mantenimiento del proyecto.
c. Definicin de requisitos.

8. Es una condicin que un producto, servicio o software debe hacer por los usuarios:
a. Objetivos.
NDICE
b. Alcance.
c. Requerimientos.
9. Son puntos clave de control de un proyecto.
PRELIMINARES
a. Requisitos.
b. Hitos.
c. Contratos.
10. Es quin solicita el desarrollo del proyecto, puede ser el cliente mismo.
BIMESTRE
PRIMER
a. Program Manager.
b. Jefe de proyecto.
c. Patrocinador.
SEGUNDO
BIMESTRE
final de la gua.
SOLUCIONARIO
Ir a solucionario
BIBLIOGRFICAS
REFERENCIAS

UNIDAD 5. EL DESARROLLO DEL PROYECTO LA PLANIFICACIN Y LA ESTIMACIN
NDICE
Se recomienda las lecturas de los captulos 7. El desarrollo del proyecto y 8. La planificacin
y la estimacin, del texto bsico. As como las lecturas de apoyo sugeridas a lo largo del
PRELIMINARES
estudio de esta unidad.
Estimado estudiante, vamos a dar inicio al estudio de esta quinta unidad, donde tratamos ya cmo se
desarrolla el proyecto de desarrollo de software, pero antes de centrarnos especficamente a un proyecto
de software como tal, veremos cmo se lleva la ejecucin de un proyecto de manera general.
BIMESTRE
5.1. Ejecucin de un proyecto generalidades.
PRIMER
En la fase de ejecucin debemos velar porque las cosas se hagan, de tal forma que podamos controlar
el avance conociendo el estatus del mismo en cualquier instante y tomar acciones correctivas segn se
vayan presentando los incidentes o problemas.
SEGUNDO
BIMESTRE
Ramn et al. (2007) mencionan que la fase de ejecucin est sustentada en 4 pilares, como se muestra
en la figura 14.
SOLUCIONARIO
BIBLIOGRFICAS
Fuente: Ramn et al. (2007)
REFERENCIAS
En esta etapa del ciclo de vida del proyecto es donde se trabaja en torno a la calidad del producto o
resultado final que vamos a desarrollar, tener un producto de calidad es directamente proporcional a
la calidad puesta en el proyecto de software. Garca (2008) define la calidad en un proyecto como: el
nivel en el que un conjunto de caractersticas propias satisfacen los requisitos, estos requisitos pueden ser
tanto de un producto particular o de un servicio nico. La gestin de la calidad trata tanto la calidad del
proyecto como del producto. La calidad, gestin del proyecto y satisfaccin del cliente forman parte
del control general del proyecto. En la figura 15 se muestran los puntos ms relevantes de los fallos ms
habituales en la prctica de ejecucin de proyectos:

NDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Fuente: Ramn et al. (2007)
5.2. Gestin del proyecto en el da a da
SOLUCIONARIO
Llevar a cabo el desarrollo de un proyecto es una tarea continua o del da a da, para entenderlo mejor
haremos una analoga.
La construccin de un edificio se debe revisar diariamente para verificar su evolucin

con la finalidad de saber el estado del mismo y ver que los recursos estn siendo bien
BIBLIOGRFICAS
utilizados y que se cumplir el hito planificado, Est de acuerdo con esta analoga?
REFERENCIAS
La gestin del proyecto del da a da se conoce como el nombre de hands-on mediante el cual se mide
la salud del proyecto en el cual se deben resolver todas las incidencias o impedimentos que puedan
ocasionar retrasos en la ejecucin, las incidencias e impedimentos no se limitan a aspectos tcnicos o de
requerimientos sino que tambin contemplan las relaciones laborales, motivacin del equipo del trabajo
del cliente, en s todos los factores que puedan incidir directa o indirectamente sobre la ejecucin.
Dependiendo del tamao del proyecto, el gerente debe velar por todos los aspectos como el control de
calidad junto con la documentacin, as como las posibles implicaciones sobre la gestin del cambio y
riesgos del proyecto, adems de revisar y presentar los informes de control de avance. Estos controles
son especificados dentro del plan del da a da. Dentro del plan del da a da es necesario realizarnos las
siguientes interrogantes:

El da a da de un proyecto se basa en la planificacin que se ha realizado, el mismo que puede estar

descompuesto en entregables menores controlados por horas de entrega, esto dependiendo de la
NDICE
metodologa de gestin que se lleve, pasando desde entregables de una semana, quince das, etc.,
dependiendo de la naturaleza del proyecto y segn el previo estudio del mismo, se puede tomar el que
ms se adapte, as como las metodologas de desarrollo que se estudi en el Captulo 3: La estimacin de
riesgo, como metodologas giles, a continuacin listamos algunas o las ms utilizadas:
PRELIMINARES
Adaptive Software Development (ASD).
Agile Unified Process (AUP).
Essential Unified Process (EssUP).
Feature Driven Development (FDD).
Lean Software Development (LSD).
BIMESTRE
Kanban.
PRIMER
Open Unified Process (OpenUP).
Programacin Extrema (XP).
Mtodo de desarrollo de sistemas dinmicos (DSDM).
Scrum.
SEGUNDO
BIMESTRE
Las reuniones de trabajo con el equipo dependern de la metodologa y criticidad de la ejecucin
pudiendo ser diarias o semanales.
5.3. Desarrollo de un proyecto de software
SOLUCIONARIO
El desarrollo de los proyectos de software se llevan a cabo en torno al marco de la ejecucin de un proyecto
normal. Tienen ciertas caractersticas como: El control de calidad del cdigo con el que se desarroll la
solucin de software, la documentacin (manuales de desarrollo y de usuario, etc) , versionamiento, etc.
El apartado 5.2 Desarrollo de un proyecto de software estar basado en el texto bsico
BIBLIOGRFICAS
Captulo 7: El desarrollo del proyecto. Se recomienda leer para profundizar sus
REFERENCIAS
conocimientos en este tema.
5.3.1. La calidad de software
Podemos pensar que la calidad de software solo puede medirse basados en que el software como tal
hace lo que debera hacer, resolver ciertos problemas y se entrega al cliente lo que pidi. Guarna y
Bernardo (2010) indican otros factores para definir bien la calidad de software y no solo debe cumplir lo
antes mencionado, como:
Confiabilidad
Facilidad de uso
Seguridad
Funcionalidad
Oportunidad
Costo
Eficiencia en el desempeo
Interoperabilidad
Extensibilidad
Reutilizacin

Portabilidad
Escalabilidad
NDICE
Gurin (2015) dice que la construccin de cdigo como tal, es el soporte y la base fundamental para que
el problema identificado sea resuelto, por lo que es importante que este cdigo tenga un control de
calidad, siguiendo algunos lineamientos especficos, cmo:
PRELIMINARES
A. Las normas de codificacin
I. La indentacin: No es nada ms que llevar un orden en las instrucciones del cdigo, las mismas
que son dependientes una de otras. Es decir la codificacin debe ser legible, para facilitar la
bsqueda de errores e incluso hacer una mejora de cdigo. Se tiene que saber qu estructura es
la principal y cuales estn contenidas en est, la apertura y cierre de llaves, los espacios y saltos de
lnea necesarios.
BIMESTRE
PRIMER
II. Los nombres en los programas (variables): Los nombres de las variables tienen que ser claros y
entendibles, ya que los mismos son utilizados para realizar infinitas operaciones. Y deben respetar
las reglas de cada uno de los lenguajes de programacin que se utilice. Guarna y Bernardo (2010)
nos explican que Los nombres de las funciones/procedimientos son muy importantes, ya que el
SEGUNDO
BIMESTRE
mismo siempre describe que es lo que hace dicha funcin/procedimiento, pero de una forma tal,
que slo expresa la intencin (o el qu) y no detalles de implementacin (el cmo). Otro buen
punto es no mezclar idiomas en los nombres de las funciones/procedimientos, es decir, mezclar el
ingls con el espaol.
SOLUCIONARIO
III. La modularidad: Se trata de dividir la codificacin y ms concretamente el cdigo en partes,
funcionales y que tienen un alto grado de cohesin entre las partes que se relacionan. Hagamos
una analoga con la Programacin Orientada a Objetos que es basada en cumplir esta caracterstica.
B. La gestin de la documentacin
BIBLIOGRFICAS
I. Los comentarios: Guarna y Bernardo (2010) indican que los comentarios en el cdigo son de vital
REFERENCIAS
importancia, al momento de explicar ciertas partes del cdigo que creemos que es necesario
explicar. Pero tenemos que tener cuidado el rato de comentar, ya que la exageracin incluso
generar ms confusin.
II. La documentacin generada: Algunos programas de compilacin generan automticamente

la documentacin porque poseen etiquetas de descripcin de las clases, mtodos, atributos y
paquetes.
C. Las revisiones de cdigo
I. Reglas de codificacin: deben ser revisadas por el jefe de proyecto y basadas en un estndar,
normas o buenas prcticas y los desarrolladores deben conocerlas.
II. Herramientas de control durante el desarrollo: son listas de control que los desarrolladores deben
conocer y tener a la mano mientras codifican. Una serie de instrucciones por ejemplo de cmo
comentar las clases, etc.
III. Revisin de cdigo: se debe realizar antes de la entrega y el jefe de proyecto lo hace junto con los
desarrolladores con la finalidad de encontrar errores, si el software es muy grande se revisa un
mdulo al azar.

D. Herramientas de anlisis y de cobertura.
Gurin (2015) explica que son herramientas que detectan el rendimiento del cdigo cuando se
NDICE
lo ejecuta, algunas ya vienen en los IDEs11 10o en los compiladores, mientras que otras se instalan
independientemente. Lo que stas herramientas hacen es indicar:
Las variables locales declaradas y no utilizadas.
PRELIMINARES
Los atributos privados no utilizados.
Los mtodos no accesibles.
Bucles indefinidos, etc.
E. Repositorios de cdigo fuente.
BIMESTRE
Son necesarios ya que un proyecto de desarrollo de software por lo general es grande y se
PRIMER
necesita de un equipo de desarrolladores, no solo de un desarrollador, por lo tanto se requiere de
un repositorio, que no es nada ms que un programa instalado en un servidor donde se guarda
el software desarrollado y se puede registrar tambin archivos necesarios para que este cdigo
funcione, y control de versiones.
SEGUNDO
BIMESTRE
Revise el texto bsico Captulo 7: El desarrollo del proyecto. 1. Control de la calidad de
cdigo 5. Los repositorios de cdigo fuente. Encontraremos una tabla donde se enlistan
algunas herramientas que son repositorios y tambin hay la explicacin precisa de la
instalacin de un repositorio. Puede hacer la prueba de la instalacin de un repositorio
utilizando su mquina como servidor local.
SOLUCIONARIO
F. La gestin de versiones.
Existen herramientas que gestionan versiones del software que se est desarrollando y guardan
incluso historiales, que precisan la fecha y la hora exacta de los cambios del software que genera el
versionamiento. Una de las herramientas ms utilizadas es GitHub que funciona tambin como un
BIBLIOGRFICAS
REFERENCIAS
repositorio pero en la computadora local y se comparten los archivos. El sistema para compartir
los archivos es muy similar a Dropbox.
El nmero de versiones es como lo quiera utilizar el desarrollador de software, a veces usa el nombre
de la aplicacin junto con el ao que fue creado, ejemplo. Oficce 2017, o a su vez por el nmero
de etapas por las que ha pasado el software hasta llegar a estar listo para pasar a produccin y al
mercado, por ejemplo, Dotproject 10.5.4. En el texto bsico en el apartado de Gestin de versiones
puede entender de mejor manera como es utilizado el versionamiento.
G. La pruebas del software.
El cdigo o software una vez desarrollado debe ser sometido a diferentes categoras de pruebas.
Gurin (2015) las enlista de esta manera:
I. Pruebas unitarias: validan el funcionamiento de los mdulos de software de manera independiente

unos con otros.
II. Pruebas de integracin: Se unen todos los componentes que forman parte del software y se
prueba que funcionen en cohesin.
10 Entorno de desarrollo integral, ejemplo: Eclipse, Visual Basic, etc.

III. Pruebas funcionales: Verifican el correcto funcionamiento de los procesos implementados en el

software. Hay dos clases de estas pruebas, de caja negra y de caja blanca.
NDICE
a. Caja negra: se hace la prueba en donde el usuario no tienen ninguna idea de la manera en
que se ha implementado el software.
b. Caja blanca: el usuario conoce el funcionamiento interno del funcionamiento del software.
PRELIMINARES
IV. Benchmarking: Estas pruebas controlan el software en condiciones reales, variando el nmero de
datos de ingreso y el nmero de usuarios que la utilizan, para verificar si funciona correctamente.
a. Pruebas de carga y rendimiento: Las pruebas de carga verifican el comportamiento del

sistema cuando alcanza un nmero de usuarios establecido, as como las pruebas de
rendimiento, cuantifican la rapidez con la que el sistema responde a una peticin.
b. Pruebas de estrs y escalabilidad: Monitorea el sistema en una situacin de estrs, donde
BIMESTRE
PRIMER
se trata de hacer que ejecute un sin nmero de transacciones.
c. Pruebas de resistencia: Se trata de controlar el sistema en situaciones de carga y tratar de
provocar un colapso del mismo, con la finalidad de verificar cmo responde.
d. Pruebas de lmites: El sistema es sometido a soportar un nmero de usuarios y transacciones
superior a las que soporta, con la finalidad de conocer el lmite antes de colapsar.
SEGUNDO
BIMESTRE
H. Las metodologas de pruebas.
En el apartado anterior estudiamos las diferentes pruebas en las que el sistema o software es
sometido con la finalidad de alcanzar el nivel ms alto de calidad, pero estas pruebas deben estar
SOLUCIONARIO
dentro de una metodologa de prueba, donde se identifican el ciclo de prueba y se determina el
plan de pruebas
I. Ciclo de prueba: en la figura 16 podemos verificar el ciclo comn de prueba de un proyecto de

desarrollo, es un proceso con un conjunto de pasos:
BIBLIOGRFICAS
REFERENCIAS
Figura 16. Ciclo de prueba de un sistema

Adaptado de Gurin, B.(2015)
II. Plan de pruebas: Ayuda a planificar minuciosamente las funciones a probar, cmo sern ejecutadas
esas pruebas, quines sern los responsables y el cronograma para su ejecucin. El Plan de Pruebas
de Software puede aplicarse a todo el Proyecto de Desarrollo de Software, o puede acotarse a una
iteracin o conjunto de casos. Adems, puede definir jerarquas de casos de pruebas a considerar.

El proyecto organiza sus ciclos de pruebas en funcin de los errores sucesivos y la

disponibilidad cambiante del equipo de proyecto. (Gurin, 2015)
NDICE
5.4. Caso de estudio: El desarrollo del proyecto de control de actividad
Al final del Captulo 7 del texto bsico, puede encontrar un caso de estudio donde se aplican todos
PRELIMINARES
los conceptos revisados en esta unidad. Lea comprensivamente el caso de estudio con el afn de
comprender cada una de las modalidades expuestas.
Caso de estudio El desarrollo del proyecto de control de actividad que est al final
del Captulo 7: El desarrollo del proyecto del texto bsico. Se organiza el desarrollo
de software de control de actividad y se establecen las modalidades de codificacin,
BIMESTRE
pruebas y despliegue.
PRIMER
5.5. La planificacin del proyecto
Antes de explicar la planificacin y estimacin del software como tal, vamos a estudiar como se lleva la
etapa de planificacin de un proyecto de manera general.
SEGUNDO
BIMESTRE
Una parte importante del proceso de planificacin es el desarrollo del plan del proyecto o plan de
direccin/gestin del proyecto, as como toda la documentacin requerida para llevar a cabo dicho plan.
La elaboracin de este documento es tambin repetitiva en el tiempo debido a cambios importantes
que se pueden presentar a lo largo del ciclo de vida.
SOLUCIONARIO
Como lo seala el PMBOK (2013, pg. 90),
Desarrollar el plan para la direccin del proyecto es el proceso que consiste en documentar
las acciones necesarias para definir, preparar, integrar y coordinar todos los planes
subsidiarios. El plan para la direccin del proyecto se convierte en la fuente primaria de
BIBLIOGRFICAS
informacin para determinar la manera en que se planificar, ejecutar, supervisar y
REFERENCIAS
controlar, y cerrar el proyecto.
Es decir, una vez desarrollado el plan del proyecto tendremos el mapa de ruta del mismo y esto nos
guiar durante su ejecucin.
5.5.1. Revisin de objetivos del proyecto, hitos y responsables
Gido y James (2007) explican que previo a la planificacin es fundamental entender claramente los
objetivos del proyecto con el nivel de detalle suficiente para establecer el alcance del proyecto y la calidad
requerida por parte de los clientes. Los mecanismos presentados permitirn delimitar este alcance, los
supuestos, restricciones e identificar los hitos intermedios establecidos. Una vez logrado esto, se puede
pasar a un proceso de descomposicin para llegar al detalle de actividades del proyecto.
Es importante hacer nfasis en los objetivos del proyecto. Estos objetivos deben ser
de tipo SMART: Specific (especfico), Measurable (medible), Achievable (realizable),
Realistic (realista) y Time-Bound (limitado en tiempo).
Es decir, si contamos con objetivos que cumplan con estas caractersticas ser mucho ms sencillo
plantear caminos claros hacia ellos.

Otro trmino que se debe citar en esta seccin son los hitos del proyecto, que son los puntos claves de
control de un proyecto, se utilizarn para controlar el adecuado avance, pagos requeridos, informes a
NDICE
presentar, etc.
La definicin de hitos permitir medir el avance intermedio del proyecto y, al igual que los objetivos, los
hitos deben tener algunas caractersticas importantes en especial mantener la caracterstica SMAR
PRELIMINARES
5.5.2. EDT Estructura de desglose de trabajo
Un aspecto de vital importancia en la definicin del alcance es la identificacin de los entregables. A

partir de esos entregables se podrn identificar las actividades de bajo nivel que deben ser ejecutadas
durante el Proyecto para la consecucin de los objetivos.
Una tcnica muy empleada hoy en da y sugerida por las mejores prcticas de gestin de proyectos es el
BIMESTRE
PRIMER
desarrollo de la estructura de desglose de trabajo o EDT (WBS por sus siglas en ingls).
Qu es un EDT? - Es una descomposicin jerrquica del trabajo que va a ser ejecutado

por el equipo del proyecto para alcanzar los objetivos del proyecto y as conseguir los
entregables requeridos.
SEGUNDO
BIMESTRE
La estructura de desglose de trabajo (EDT) est compuesta bsicamente por una serie de cajas que
representan entregables de un proyecto, la premisa clave para la realizacin de un EDT es que este
pueda representar a esos entregables dependiendo de la localizacin de los mismos dentro del esquema
grfico. A continuacin se incluye la figura 17 ejemplificando su funcionamiento.
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS
Figura 17. Ejemplo de EDT - Desarrollo de un software especfico
El primer nivel del EDT es el nombre del proyecto.

El segundo nivel puede representar las fases del proyecto.
El tercer nivel puede indicar grupos de entregables.
El nivel ms bajo del EDT debe indicar paquetes de trabajo.

No existe una normativa clara en relacin a la cantidad de niveles que pudiera tener un EDT, en el contexto
prctico se va determinando si es demasiado general o especfico, como regla a tomar en cuenta se
NDICE
puede indicar que el ltimo nivel del EDT debera representar paquetes de trabajo no superiores a 8
horas de dedicacin, cuando se haya llegado a ese nivel dentro de un EDT es importante definir la tareas
que representan ese paquete de trabajo dentro de Microsoft Project.
Cules son los beneficios si se usa EDT? Facilitar los procesos de gestin tales como:
PRELIMINARES
estimacin, cronograma, recursos, anlisis de riesgos y medicin del alcance. Presentar
una descripcin clara de los entregables del proyecto y del alcance. Representar la forma
incremental en la cual se desarrollan las tareas del proyecto.
5.5.3. Especificaciones del proyecto: Actividades y Tareas
Durante el desarrollo del EDT debemos definir actividades de acuerdo a lo siguiente:
BIMESTRE
PRIMER
La creacin especfica de las actividades que permitirn generar los entregables del proyecto.
La identificacin de los entregables del proyecto, realizado a travs de la creacin de la EDT,
en la cual el componente mnimo se denomina Paquete de trabajo.
La descomposicin de los paquetes de trabajo en elementos ms pequeos denominados
SEGUNDO
BIMESTRE
actividades, las cuales puedan ser fcilmente controlables, auditables y cuantificables
(tiempo y recursos).
Las actividades proporcionan la base para la estimacin, planificacin, seguimiento, y control del trabajo
del proyecto.
SOLUCIONARIO
Para cada paquete de trabajo se define lo siguiente:
Responsables.
Lista de actividades para completar el paquete de trabajo.
BIBLIOGRFICAS
Para cada actividad se define:
REFERENCIAS
Estimado de la duracin.
Responsables.
Luego se trabaja en el Diagrama de Red11, considerando:
Representa la secuenciacin de actividades del proyecto.

En el mismo se pueden calcular los tiempos sobrantes de las rutas del proyecto, as como
tambin la (s) ruta(s) crtica(s)12.
Es muy comn que la generacin de actividades no involucre de manera adecuada

a todos los interesados del proyecto, lo cual produce resultados no satisfactorios
dentro del mismo; como sugerencia de xito, se debe involucrar desde el primer
momento del proyecto a los interesados del mismo, logrando su comprometimiento,
apoyo y principalmente, la generacin de una visin compartida sobre las actividades
necesarias para lograr el objetivo del proyecto.
11 Un diagrama de red es una forma grfica de ver tareas, dependencias y la ruta crtica del proyecto.
12 Es un algoritmo utilizado para el clculo de tiempos y plazos en la planificacin de proyectos.

5.5.4. Secuenciar actividades
La secuenciacin de actividades se hace necesaria, dado que existen relaciones entre las mismas que
NDICE
es necesario identificar y documentar; las actividades son secuenciadas utilizando relaciones lgicas;
cada actividad exceptuando la primera y la ltima son conectadas al menos a un predecesor y a un
sucesor. Esta tarea ser muy importante al momento de contar con un cronograma real de cumplimiento.
Este proceso de secuenciacin puede realizarse a travs de un software de computadora o de manera
PRELIMINARES
manual.
Una de las tcnicas de secuenciacin ms utilizadas es:
Mtodo de diagramas de precedencia (PDM)
Este mtodo es utilizado para la determinacin de la ruta crtica, en la cual se utilizan
BIMESTRE
PRIMER
cuadrados o rectngulos definidos como nodos los cuales representan las actividades, se
las conecta con flechas que muestran la relacin lgica que existe entre ellas. El diagrama
representado en la figura 18 ejemplifica el mtodo:
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS
Figura 18. Ejemplo de Diagrama de precedencia
Fuente: El autor
Esta tcnica comprende los siguientes tipos de dependencias entre actividades:
Fin a Inicio: El inicio de la actividad sucesora depende de la finalizacin de la actividad

predecesora. Ej. Se debe finalizar con el cavado de un hueco para luego comenzar a plantar
un rbol.
Fin a Fin: La finalizacin de la actividad sucesora depende de la finalizacin de la actividad
predecesora. Ej. Se debe primero terminar de testear para terminar la documentacin.
Inicio a Inicio: El inicio de la actividad sucesora depende del inicio de la actividad predecesora.
Ej. Comenzar el diseo y luego de al menos un par de semanas de diseo puede comenzar
a desarrollar o codificar.
Inicio a Fin: Una actividad debe empezar antes de que la sucesora pueda finalizar (raramente
utilizada).
El estudio ms a fondo de la construccin del EDT, queda a su libre decisin, es importante

recordar que el EDT es necesario para poder saber especficamente qu actividades se
realizan y quines las realizan. En algunos textos de gestin de proyectos se especifican
claramente los pasos a seguir para determinarlo.

A. Las unidades de trabajo y las tareas
El mtodo de diagrama de precedencia ayuda a determinar precisamente las actividades o tareas a
NDICE
realizar.
El jefe de proyecto puede dividir una tarea en relacin con los recursos y usar las relaciones de precedencia
que las identificamos claramente en el diagrama de precedencia, para sincronizar su ejecucin (Gurin,
PRELIMINARES
2015).
Tomemos en cuenta los siguientes puntos para manejar las tareas efectivamente:
Manejar coherentemente las tareas en relacin a otras tareas que conforman el conjunto de
la planificacin.
Las tareas se deben etiquetar para garantizar un seguimiento eficaz.
BIMESTRE
PRIMER
Las relaciones de las tareas son elementos caractersticos, que indican qu tareas deben
terminar antes que empiece otra.
Se definen por sus objetivos y sus criterios de finalizacin.
Se debe evaluar el riesgo relacionado con la realizacin de una tarea para decidir si forma
parte de la ruta crtica.
SEGUNDO
BIMESTRE
B. Los recursos
Los recursos son las personas que conforman el equipo que desarrolla el proyecto y tambin los medios
logsticos que se necesitan para desarrollar las operaciones, recursos y materiales. Por ejemplo.
SOLUCIONARIO
El jefe del proyecto divide los recursos lo mejor posible y como lo vea necesario, de acuerdo a la figura
19:
BIBLIOGRFICAS
REFERENCIAS
Figura 19. Tipos de recursos

Fuente: El autor
5.5.5. Estimar esfuerzos
Una vez identificadas las actividades y la relacin entre estas, se puede estimar los recursos necesarios
por cada actividad teniendo en cuenta el tipo y cantidades de: materiales, personas, equipos, y ms
recursos requeridos. Este proceso afecta directamente al presupuesto del proyecto. Se puede decir que
el EDT y el proceso de estimacin constituyen el pilar fundamental en el proceso de planeacin. Existen
algunas tcnicas y mtodos de estimacin usados por algunos jefes de proyecto, como por ejemplo:

Tcnicas de estimacin
Top-down
NDICE
Bottom up
Distribucin de esfuerzo, etc.
Rutas del camino crtico.
PRELIMINARES
Mtodo de estimacin
Juicio de experto
Informacin histrica
Factores de riesgo

BIMESTRE
Metodo de cadena crtica, etc
PRIMER
Aplicadas las tcnicas y mtodos de estimaciones, se tendr el tiempo, recursos y costo requerido por
cada actividad a fin de poder completar el cronograma del proyecto. El resultado es el cronograma
detallado como muestra la figura 20:
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS
Figura 20. Ejemplo de Cronograma de proyecto
Fuente: Escuela de Organizacin Industrial (2013)
Estimar carga en un proyecto de software
La estimacin de carga en un proyecto de desarrollo de software debe darse primero con la evaluacin
a los responsables de las actividades identificadas, preguntndoles el tiempo que se tomarn en
desarrollar la tarea, pues por experiencia este tiempo se puede dar en promedio.
Gurin (2015) dice que el jefe del proyecto debe, en primer lugar, convencer a su equipo de la necesidad
de dar una opinin, y no tiene por qu ser la definitiva. Recuerde que:
Un proyecto es un compromiso de recursos para alcanzar un objetivo. Por lo tanto

todas las tareas que nos van a ayudar a alcanzar ese objetivo deben ser evaluadas.

A. Las cargas y los plazos
La carga es expresada en trminos de das/hombre (d/h) y representa la cantidad de trabajo que tiene
NDICE
que hacer la persona para realizar una tarea, a su diferencia con el plazo, que es el nmero de das
mximo en que la persona puede concluir esta tarea.
Desarrollar el cdigo de un software puede tener para un desarrollador una carga de 10
PRELIMINARES
d/h en un plazo de 10 das, es decir en 10 das el desarrollara el cdigo usando todos
los recursos necesarios, pero si hay dos desarrolladores y trabajan de manera paralela el
plazo se puede reducir a 5 das para cumplir la misma tarea.
El mtodo ms utilizado para estimar la carga y los plazos en un proyecto de desarrollo de software es el
de estimacin mediante baco.
BIMESTRE
PRIMER
Este mtodo consiste en identificar las tareas que tenemos que estimar en tablas de proyectos parecidos
y anteriores, se lo utiliza mucho para cifrar un proyecto y generar su organigrama de tareas (Gurin,
2015).
Se pueden utilizar otros mtodos de estimacin como los antes mencionados en el punto 5.4.6 de este
apartado, pero no debemos descartar que la estimacin impuesta es cuando el presupuesto y la fecha
SEGUNDO
BIMESTRE
de entrega se imponen, convirtindose este tipo de estimacin en un problema para el jefe de proyecto,
ya que debe buscar las mejores estrategias de desarrollo que se adapten al producto que se quiere
conseguir como resultado de un proyecto.
Revise el texto bsico Captulo 8: La planificacin y la estimacin. 1. La estimacin
SOLUCIONARIO
de carga, haga una lectura comprensiva de este punto para que fundamente los
conocimientos base del tema de estimacin en un proyecto de software y participe en
las actividades propuestas en el EVA
5.5.6. Distribucin del trabajo y recursos necesarios
BIBLIOGRFICAS
REFERENCIAS
Tanto la distribucin del trabajo como la estimacin de recursos se hace en funciones del EDT desarrollado
para el proyecto.
La distribucin del trabajo se desarrollar en funcin de los roles y el porcentaje de horas que se ha
estimado van a participar, as como una estimacin de costos, la misma que se puede realizar en funcin
de las mismas tcnicas y mtodos de estimacin mencionados anteriormente.
Dado que las estadsticas indican que la mayora de proyectos no terminan conforme
a lo presupuestado se recomienda utilizar las mejores prcticas con el fin de realizar
una estimacin adecuada del costo en el que se incurrir al realizar las tareas de un
proyecto.
Los costos deben ser refinados conforme avanza la ejecucin del proyecto con el fin de reflejar detalles
adicionales tan pronto como stos estn disponibles. La asertividad en la estimacin de costos se
incrementar conforme al avance y desarrollo del proyecto.
Con la realizacin de estas actividades y cambios que se hayan expuestos, se presenta al cliente ya el
PLAN DEFINITIVO con la finalidad de que tenga la certeza de cmo se va a desarrollar su producto.
La distribucin del trabajo y de los recursos necesarios es una responsabilidad del jefe de proyecto y
con esto hace el seguimiento de las operaciones del proyecto, debe explicar aquello que espera de cada

miembro del equipo, fijar los objetivos de desarrollo y controlar el resultado de los mismos. (Gurin,
2015). Este proceso se denomina Elaboracin. En la figura 21 se describen las actividades del jefe de
NDICE
proyecto en este proceso:
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 21. Proceso de Elaboracin jefe jefe de proyecto
Adaptado de Gurin, B.(2015).
A. Las tareas de la organizacin
SOLUCIONARIO
Quin asegura el nmero de tareas relacionadas con la organizacin es el jefe de proyecto. En la figura 22
se detallan las actividades para Organizar un proyecto, siendo el jefe de proyecto quien debe procurar
que se cumplan.
BIBLIOGRFICAS
REFERENCIAS
Figura 22. Actividades para organizar un proyecto

Autor: Adaptado de Gurin, B.(2015).

5.6. Caso de estudio: La planificacin del proyecto de control de actividad

Lea comprensivamente el caso de estudio La planificacin del proyecto de control de
NDICE
actividad, que est al final del Captulo 8: La planificacin y la estimacin. Con este caso
de estudio se definen y se distinguen de mejor manera las estimaciones que se hacen
en una planificacin. Con lo estudiado participe en las actividades propuestas en el EVA
respecto a este tema.
PRELIMINARES

BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 5
NDICE
1. Cul de los siguientes NO es un fallo habitual en la prctica de ejecucin de proyectos:
PRELIMINARES
a. Involucramiento de usuarios en cantidad, calidad y tiempo.
b. Una buena gestin de cambios.
c. Desequilibrio entre los objetivos de tiempo, coste y calidad.
2. La indentacin es:
BIMESTRE
a. Colocar nombres a las variables claras y entendibles
PRIMER
b. Llevar un orden en las instrucciones del cdigo.
c. Dividir la codificacin en partes funcionales.
3. La modularidad es:
SEGUNDO
BIMESTRE
c. Dividir la codificacin en partes funcionales.
4. Los comentarios en el cdigo nos sirven para:
SOLUCIONARIO
c. Explicar ciertas partes del cdigo.
BIBLIOGRFICAS
5. Las reglas de codificacin deben estar basadas en:
REFERENCIAS
a. Un estndar o buena prctica.
b. Una metodologa de desarrollo.
c. En la experiencia del programador.
6. Las pruebas unitarias de software:
a. Se unen todos los componentes que conforman el software

b. Verifican el correcto funcionamiento de los procesos implementados.
c. Validan el funcionamiento de los mdulos del software.
7. En las pruebas de integracin de software:
a. Se unen todos los componentes que conforman el software

b. Verifican el correcto funcionamiento de los procesos implementados.
c. Validan el funcionamiento de los mdulos del software.

8. En las pruebas funcionales de software:
a. Se unen todos los componentes que conforman el software.
NDICE
b. Se verifica el correcto funcionamiento de los procesos implementados.
c. Se valida el funcionamiento de los mdulos del software.
9. Quienes verifican el comportamiento del sistema cuando alcanza un nmero de usuarios establecido,
PRELIMINARES
son las pruebas de:
a. Carga y rendimiento
b. Escalabilidad
c. Resistencia
BIMESTRE
PRIMER
10. Quienes monitorean el sistema en una situacin de estrs, son las pruebas de:
a. Carga y rendimiento
b. Escalabilidad
c. Resistencia
SEGUNDO
BIMESTRE
Por favor, verifique sus respuestas con el solucionario de la autoevaluacin ubicado al final
de la gua.
SOLUCIONARIO
Ir a solucionario
BIBLIOGRFICAS
REFERENCIAS
Le invito que se esfuerce un poco ms y busque apoyo en las tutoras o se comunique con su profesor tutor para
as lograr el desarrollo de sus competencias.

UNIDAD 6. EL SEGUIMIENTO Y CONTROL
NDICE
Se recomienda la lectura del Captulo 8. El seguimiento y el control, del texto bsico. As
como las lecturas de apoyo sugeridas en el transcurso del estudio de esta unidad.
PRELIMINARES
Estimado estudiante, vamos a dar inicio al estudio de esta sexta y ltima unidad de este componente
acadmico, la misma que est estructurada para analizar los temas de seguimiento y control de un
proyecto, as como la etapa de cierre o terminacin del mismo.
6.1. Seguimiento y control del proyecto
BIMESTRE
En esta etapa revisaremos el estado del proyecto desde sus varios frentes: tiempo, recursos y presupuesto;
PRIMER
el jefe del proyecto puede apoyarse de un equipo de seguimiento que realice el mapeo de los hitos
contra el avance de cada tarea asignada, contra los parmetros de tiempo, recursos y presupuesto, y
observar posibles riesgos para tomar las acciones de control necesarias, este equipo de seguimiento
generalmente est asignado a un equipo PMO (Project Management Office).
SEGUNDO
BIMESTRE
El reporting y seguimiento son los elementos claves para el control. Control quiere decir anlisis y
evaluacin, previsin del futuro, comunicacin y correccin, adems hace referencia a un plan.
El objetivo de gestin de un proyecto es controlar el proyecto para que como mnimo:
SOLUCIONARIO
vaya segn lo esperado (plan) y,
si no es as (seguimiento),
tomar las decisiones adecuadas (control)
... que permitan finalizar el proyecto con xito (que se cumplan los objetivos)
Recordemos los instrumentos que nos sirven para dar seguimiento al proyecto:
BIBLIOGRFICAS
REFERENCIAS
Definicin del proyecto
Plan de hitos
Plan de actividades (cronograma)
Matriz de responsabilidades
Plan de gestin de riesgos
Plan de control de cambios, etc.

Los contenidos del seguimiento y control de proyecto presentados en la figura 23:
NDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 23. Organizar el Proyecto
Adaptado de Ramn et al. (2007)
Los cambios en el alcance del proyecto y sus mecanismos de ajuste, pueden ser.
SOLUCIONARIO
La gestin de riesgos del proyecto.
El cumplimiento de hitos y entregables conforme el plan del proyecto.
El seguimiento, los resultados y la calidad de las tareas planificadas.
La revisin de los recursos, y esfuerzo dedicado y los costes contabilizados hasta la fecha.
BIBLIOGRFICAS
El seguimiento de la actuacin del equipo y de sus miembros.
REFERENCIAS
Cada punto anterior debe someterse al siguiente anlisis:
Contrastar el estado actual de proyecto y los logros conseguidos.

Previsin de situaciones futuras del proyecto (por ejemplo, los riesgos del proyecto) basadas
en el conocimiento y las tendencias observables en el momento.
La toma de acciones correctivas respecto a la planificacin del proyecto existente hasta
aquel momento.
Para realizar el seguimiento, el jefe de proyecto puede valerse de algunos artefactos que cumplan con
las siguientes caractersticas:
Fcil de utilizar (para m y para mi equipo de trabajo)

til (para m y para mi equipo de trabajo)
Barata (en dinero y en tiempo)
A. El informe de actividad (IA) y grado de avance de las tareas
Los IA son documentos, informes en s, desarrollados por los miembros del equipo, segn las tareas
o actividades asignados, estos informes son un seguimiento del trabajo realizado y de las posibles

dificultades que hayan surgido. Es mucho ms fcil que este informe se lo realice en una hoja de clculo
para en el futuro hacer un anlisis de avance y cuantificar el seguimiento.
NDICE
A partir de este informe el jefe de proyecto determina el grado de avance de las tareas. Este avance est
dado por:
Tiempo consumido: trabajo invertido en una tarea.
PRELIMINARES
Carga de trabajo inicial: tiempo estimado para cumplir esta tarea.
Tiempo restante: nmero de das para terminar la tarea o actividad.
A continuacin en la figura 24, se muestran algunos tipos de reportes grficos que se pueden utilizar en
base al IA:
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 24. Diagrama de barras del progreso del proyecto
SOLUCIONARIO
La figura anterior muestra un diagrama de barras en la cual se ve el trabajo realizado versus el trabajo
estimado.
BIBLIOGRFICAS
REFERENCIAS
Figura 25. Modelo de informe de progreso de un proyecto

En la figura 25 se muestra un porcentaje de avances por tareas, responsables, fechas y el estado de la

tarea.
Al momento de realizar una comparacin es aconsejable medir el porcentaje global del proyecto vs el
esperado, a continuacin en la figura 26 se observa otro modelo de presentacin.

NDICE
PRELIMINARES
Figura 26. Modelo de informe de progreso de un proyecto
BIMESTRE
PRIMER
B. Seguimiento del cumplimiento de hitos y entregables del plan del proyecto
Durante el seguimiento es importante que el jefe de proyecto analice el avance del proyecto contra el
plan establecido y proponer acciones correctivas en caso de un desvo en las actividades, es importante
SEGUNDO
BIMESTRE
mantener el control del proyecto ya que los costes asociados a la resolucin de impedimentos o errores
en los proyectos pueden ser muy costosos.
A nivel del equipo, el reporte debe realizarse con mucho ms detalle o hasta un segundo nivel de
descomposicin de las tareas, de tal forma que permita identificar los factores que estn impidiendo el
SOLUCIONARIO
avance de las tareas en el caso que amerite; las herramientas y tcnicas van a depender de la metodologa
empleada en el proyecto.
BIBLIOGRFICAS
REFERENCIAS
Figura 27. WBS con porcentaje de avance de las tareas


En la figura 27 se muestra un modelo de reporte de avance con enfoque en detalle de tareas, en el cual
se puede apreciar tambin el porcentaje global de avance del proyecto.
NDICE
Si en los reportes de avances se presentaran problemas o impedimentos, se puede realizar las siguientes
actividades para su mitigacin, dependiendo de la evaluacin del problema:
La adicin o eliminacin de tareas al plan.
PRELIMINARES
Cambios en la estimacin de recursos requeridos para una determinada tarea.
Adicin o sustraccin de recursos asignados.
Cambios en los recursos asignados.
Cambios en los presupuestos disponibles que a efectos prcticos suelen ser la deduccin o
traduccin de los anteriores.
BIMESTRE
PRIMER
C. Seguimiento del inicio y finalizacin de las tareas
Continuando con el desarrollo del conocimiento de gestin de proyectos, en el seguimiento a detalle de

las tareas se deben incluir por lo menos los siguientes items:
Si las tareas se iniciaron en las fechas acordadas y si no es as, qu impacto pueden tener
SEGUNDO
BIMESTRE
sobre las dems.
Si las tareas se han completado conforme al calendario.
Si la calidad de los resultados est conforme a lo esperado.
Si la matriz de roles y responsabilidades se ha respetado.
SOLUCIONARIO
Si existen cambios sobre el alcance de las tareas.
Si existen cuestiones externas que afecten al desarrollo del plan.
D. Seguimiento presupuestario
El seguimiento presupuestario es el proceso que consiste en primera instancia en desarrollar una
BIBLIOGRFICAS
REFERENCIAS
aproximacin de los recursos monetarios necesarios para completar las actividades del proyecto.
Tambin se puede decir que es el proceso que consiste en monitorear la situacin del proyecto para
actualizar el presupuesto del mismo y gestionar cambios a la lnea base de costo.
Consiste en actualizar el presupuesto del mismo y gestionar cambios a la lnea base de costo. El
seguimiento del presupuesto implica registrar los costos reales en los que se ha incurrido a la fecha.
Cualquier incremento con respecto al presupuesto autorizado solo puede aprobarse mediante el
proceso de control de cambios, ya que gran parte del esfuerzo del control de costos implica analizar la
relacin entre el uso de los fondos del proyecto y el trabajo real efectuado a cambio de tales gastos. La
clave para un control de costos efectivo es la gestin de la lnea base aprobada de desempeo de costos
y de los cambios a esa lnea base.
El control de costos del proyecto incluye:
Influir en los factores que producen cambios en la lnea base de costo.

Asegurarse de que todas las solicitudes de cambio se lleven a cabo de manera oportuna.
Gestionar los cambios reales cuando y conforme suceden.
Asegurarse de que los gastos no excedan el financiamiento autorizado para el proyecto,
tanto por periodo como total.

Monitorear el desempeo de los costos para detectar y comprender las variaciones con
respecto a la lnea base aprobada de costo.
NDICE
Monitorear el desempeo del trabajo con relacin a los fondos en los que se ha incurrido.
Evitar que se incluyan cambios no aprobados en los informes sobre costos o utilizacin de
recursos.
Informar a los interesados pertinentes acerca de todos los cambios aprobados y costos
PRELIMINARES
asociados.
Realizar acciones para mantener los sobrecostos previstos dentro de lmites aceptables.
E. Seguimiento de la actuacin y resultados del equipo
La gestin de los recursos humanos del proyecto incluye los procesos que organizan, gestionan y
conducen el equipo del proyecto. El equipo del proyecto est conformado por aquellas personas a las
BIMESTRE
PRIMER
que se les han asignado roles y responsabilidades para completar el proyecto. Si bien se asignan roles y
responsabilidades especficos a cada miembro del equipo del proyecto, cada miembro puede aportar
con su experiencia profesional durante el proceso de planificacin y fortalecer su compromiso con el
proyecto.
Durante la ejecucin del proyecto el gerente debe asegurarse de:
SEGUNDO
BIMESTRE
Que todos los miembros del equipo entiendan los objetivos del proyecto.
Que cada miembro del equipo entienda su rol.
Cada miembro del equipo dispone de la infraestructura para su trabajo.
SOLUCIONARIO
Cada miembro del equipo tiene las capacidades y habilidades para las tareas encomendadas.
Cada miembro sabe cmo relacionarse con el resto.
F. Las reuniones del proyecto
La manera ms directa para hacer un seguimiento efectivo al equipo que participa en el desarrollo del
BIBLIOGRFICAS
REFERENCIAS
proyecto es mediante las reuniones, ya que stas son un canal de comunicacin directo. Gurin (2015)
menciona que en el transcurso del proyecto existen algunos tipos de reuniones como:
Reuniones de trabajo: Sirven para especificar y decidir sobre las acciones a tomar en
el desarrollo del proyecto por parte de todos los involucrados. El jefe del proyecto debe
aprovechar estas reuniones para poder comunicar claramente lo que desea y tratar de
obtener el mayor aporte posible de parte del equipo.
Sesiones de especificacin y anlisis: Aqu se tratan los puntos que hay que analizar con
profundidad del proyecto.
Sesiones Debriefing13 y formacin: Estn dirigidas por expertos con la finalidad de capacitar
a los miembros del equipo en algn mbito que se necesite dentro del proyecto.
Kicks-offs (el inicio): Son las reuniones que se hacen frecuentemente al iniciar el proyecto,
para socializar el mismo.
14 El debriefing, es la reunin posterior a una accin armada o a una misin en la que se extraen conclusiones de la misma. En
ella se analiza el cumplimiento o no de los objetivos de la misin y se extraen conclusiones acerca de la actuacin de todos
sus participantes.

G. La Gestin de imprevistos
Hay algunos riesgos potenciales a tomar en cuenta cuando se desarrolla un proyecto de software, los
NDICE
mismos que se los denomina imprevistos, (Gurin, 2015) aborda los siguientes:
A. Las complicaciones tcnicas
PRELIMINARES
Las complicaciones tcnicas son muy comunes en un proyecto de desarrollo de software y muchas
veces superarlas o enfrentarlas es un desafo para el jefe de proyecto y el equipo. Las complicaciones
normalmente ests previstas y se anticipan mucho ms de lo esperado, siguiendo el proceso de la figura
28:
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
Figura 28. Proceso de diagnstico de complicaciones tcnicas
Fuente: Gurin (2015)
BIBLIOGRFICAS
REFERENCIAS
Revise el texto bsico Captulo 9: El seguimiento y control Gestin de imprevistos 1.
Las complicaciones tcnicas. En este apartado estn detalladas con ms precisin las
actividades que hacen el equipo y el jefe de proyecto para detectar imprevistos.
B. Los conflictos
En el desarrollo de todo proyecto existe infinidad de conflictos que el jefe de proyecto debe tratar de
resolver, si es posible, incluso antes de que el proyecto inicie. Un conflicto puede provocar un bajo
rendimiento en el desarrollo de las tareas y actividades por parte de los miembros de equipo. Algunos
puntos por los que se puede generar un conflicto son:
Desacuerdos funcionales, tcnicos, comerciales u organizativos.

Malos entendidos entre los miembros del equipo.
Falta de comunicacin entre el equipo de desarrollo de proyecto.
Rivalidades por jerarquas o por experiencia y conocimiento.
Estimaciones mal realizadas sobre todo en la carga de trabajo, etc.
Existen algunas tcnicas de resolucin de conflictos que el jefe de proyecto puede utilizar y que en el
texto bsico podemos estudiarlas de manera ms detallada.

C. Los peligros organizativos
Estos peligros vienen directamente desde los altos mandos o desde la direccin de la organizacin,
NDICE
Gurin (2015) detalla algunos de estos peligros organizativos:
Retrasos: Pueden aparecer retrasos en la planificacin y/o presupuesto ya que siempre

estn sometidos a variaciones. El jefe de proyecto debe enviar alertas si los retrasos son
PRELIMINARES
muchos y largo tiempo y as mismo debe tener un sistema de control interno que le permita
hacer el seguimiento y obligar el cumplimiento de las tareas o actividades retrasadas.
Mala calidad de las entregas: Los entregables, sean documentos o quiz otra clase de
entregables, que estn mal desarrollados o que sean de psima calidad, afecta directamente
al correcto desarrollo de operaciones del proyecto. Ya que algunas actividades esperan el
entregable de una actividad predecesora, por lo que se hara una cadena sin terminar de
BIMESTRE
entregables mal hechos.
PRIMER
Comunicacin defectuosa: No existe un correcto plan de comunicacin, no se ha elegido el
nmero de canales ni los canales correctos para la comunicacin.
Lea comprensivamente el apartado del texto bsico Captulo 9: El seguimiento y

control El comit de control. Conteste las siguientes interrogantes. En qu consiste un
SEGUNDO
BIMESTRE
control? Qu entiende por indicadores de control? Con sus respuestas fundamentadas
interacte en el EVA en la actividad propuesta para este apartado.
6.2. Cierre del proyecto
SOLUCIONARIO
En la mayora de las veces la etapa de cierre se da al final de los objetivos cumplidos pero no necesariamente
es la regla, un proyecto puede cerrarse mucho antes de haber cumplido sus hitos principales y esto
debido a varias circunstancias del medio como pueden ser estrategias de negocios, imposibilidad de
ejecucin, etc.
En el proceso de cierre se van a revisar todos los procesos y/o actividades a travs de todos los grupos de
BIBLIOGRFICAS
REFERENCIAS
procesos de la direccin de proyectos, a fin de completar formalmente el proyecto, una fase del mismo
u otras obligaciones contractuales.
Para realizar el proceso de cierre de un proyecto lo vamos a dividir en tres etapas principales que se
visualizan en la figura 29:
Figura 29. Etapas de cierre del proyecto

Fuente: Ramn, Garca, y Lamarca (2007)
Existen algunos escenarios sobre los cuales puede suceder un cierre de proyecto:
A. Cierre Abrupto14
Los proyectos se pueden cerrar cuando hayan alcanzado todos sus hitos, o hayan sobrepasado algunas
de las tres restricciones principales en cuanto a tiempo, costo y alcance, sea cual fuere el motivo a
continuacin se muestran algunas de las razones por las cuales suele terminarse un proyecto:
14 Que sucede sbitamente, puede referirse a una interrupcin. Inesperado. Fuente: https://goo.gl/5M4RjW

Sobrepaso de objetivos de costo y tiempo

El proyecto no est alineado a la estrategia de negocio
NDICE
Prdida del sponsor o patrocinador principal
El producto del proyecto ya no es rentable, etc.
Durante toda la ejecucin del proyecto es imprescindible revisar que los objetivos sigan alineados a
PRELIMINARES
las estrategias de negocio de la organizacin, de tal forma que la cartera de proyectos que se manejen
cumpla con los objetivos para los cuales fueron creados. La siguiente lista muestra algunos consejos
para evitar situaciones de cierre forzosas:
Un buen equipo tiene una sabia combinacin de entusiasta, realista y pesimista (escpticos),
de tal forma que permitan identificar pronto una emergencia.
Establecer un mecanismo de alarma anticipada, la implementacin de un equipo de
BIMESTRE
PRIMER
seguimiento de los hitos, en donde en cada fase de trabajo se puede mostrar tempranamente
las desviaciones del trabajo de tal forma que permita mitigar los riesgos existentes.
Establecer un plan de salida: recogiendo evidencia de alerta para presentar ante los
directivos.
Incluir un responsable del plan de salida quien puede ser un ejecutivo que pueda cerrar un
SEGUNDO
BIMESTRE
proyecto fallido.
B. Cierre Ordinario
Un proyecto termina cuando se han alcanzado los objetivos del mismo, en el tiempo y presupuesto
SOLUCIONARIO
establecidos, aunque puede suceder que el proyecto pueda terminar antes de tiempo y con un
presupuesto mayor al establecido inicialmente, esto es admisible siempre y cuando el tiempo o recursos
extras no sobrepasen la valoracin del producto del proyecto.
Cuando se cierra una fase o el proyecto, se debe proveer de toda la documentacin y capacitacin
requerida por parte del cliente ya que al logar una aceptacin del mismo estaremos cerrando
BIBLIOGRFICAS
REFERENCIAS
exitosamente el proyecto.
Los principales elementos de cierre se muestran en la figura 30:
Figura 30. Elementos principales del cierre ordinario

Adaptado de Fuente: Ramn, Garca, y Lamarca (2007) y Gurin, (2015)
Finalizar el trabajo: Para cerrar adecuadamente un trabajo se debe establecer un mecanismo de

aceptacin final de usuario, esto generalmente con las pruebas de aceptacin y en el caso de estar
integrado con otros componentes se debe entregar un informe de pruebas de integracin de tal
forma que la documentacin quede formalizada. Ver Anexo 2 Acta de cierre del proyecto.
Entrega y documentacin del proyecto: Los entregables son las piezas que forman el resultado del
proyecto por lo tanto la documentacin es algo que debe generarse a lo largo de toda la ejecucin
del proyecto, para ello nos podemos valer de un equipo de documentadores que se apoyen en
alguna herramienta tecnolgica de tal forma que se deje evidencia de todo al cliente final.

La documentacin de cierre debe incluir una presentacin hacia el comit gerencial, as como
toda la documentacin tcnica y de soporte para los usuarios y administradores del producto final
NDICE
del proyecto.
Entre la documentacin relevante a entregar tenemos:
Documentacin del diseo del sistema (especificaciones tcnicas, diagramas de red,
PRELIMINARES
flujogramas, procedimientos, etc.).
Documentacin de operaciones (parametrizaciones y procesos de informacin y resultados).
Documentacin de usuarios (manuales, errores conocidos, procedimientos, etc.).
Apoyo al cliente recepcin y verificacin: En la fase post-implementacin debe existir un apoyo

hacia el cliente de tal forma que podamos garantizar la correcta operatividad del producto, el
BIMESTRE
soporte debe formar parte integral de la parte contractual del proyecto, generalmente el soporte
PRIMER
que se brinda al cliente se enfoca en:
Mantenimiento del sistema

Mantenimiento de la aplicacin
Hardering del hardware y comunicaciones
SEGUNDO
BIMESTRE
Se comprueba que todos los entregables que se han proporcionado cumplen las condiciones
previstas en el contrato y la verificacin es el anlisis cuantitativo de lo que se ha entregado
(Gurin, 2015). Con estas dos actividades se puede proceder al pago de parte del cliente por el
proyecto que recibi y el pago es condicionado de acuerdo a como est entregado el producto
SOLUCIONARIO
final del proyecto.
Gestin de cambio: El producto entregado puede generar un cambio en la organizacin, ya que

puede ser un nuevo software o una nueva versin de software que ya exista. Existen diferentes
maneras de gestionar este cambio:
BIBLIOGRFICAS
REFERENCIAS
Con un proyecto piloto previo a hacer el cambio definitivo.
Se forma a todos los involucrados con el nuevo sistema, dando a conocer el funcionamiento
del software y los manuales necesarios del mismo.
Cuando ya se pone el nuevo software en la fase de explotacin por los usuarios, se debe
hacer un soporte por el tiempo especfico y necesario. Hay diferentes maneras de llevar
a cabo este soporte, en el texto bsico podemos afianzar este tema en el Captulo 9: El
seguimiento y control. 4. Terminar un proyecto. 4.3. La gestin de cambio.
Mantenimiento: Cuando el proyecto se ha puesto en produccin inicia esta fase, y el soporte se

puede dar desde procesos de alta de errores hasta sugerencias de mejoras al sistema por parte
de los usuarios. El tipo de mantenimiento del proyecto es una variable que en el contrato del
proyecto se debe especificar. No todos los mantenimientos son indefinidos.
6.3. Caso de estudio: Seguimiento del control de calidad.

Lea comprensivamente el caso de estudio Seguimiento del proyecto de control de
calidad que est al final del Captulo 9: El seguimiento y el control. Este caso de estudio
est enmarcado a enfatizar de manera prctica cmo se lleva a cabo los temas expuestos
en esta unidad 6. Participe en las actividades propuestas en el EVA respecto a este caso
de estudio.

NDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 6
NDICE
1. Uno de los documentos que me sirven para dar seguimiento al proyecto es:
PRELIMINARES
a. Informe de decisiones.
b. Plan de Hitos.
c. Informe final.
2. Son documentos desarrollados por los miembros de equipo, segn las tareas asignadas:
BIMESTRE
a. Plan de cambios.
PRIMER
b. Informe de Hitos.
c. Informe de actividad.
3. El trabajo invertido en una tarea, dentro del avance se lo conoce como:
SEGUNDO
BIMESTRE
a. Tiempo restante.
b. Carga de trabajo.
c. Tiempo consumido.
4. El nmero de das para terminar una actividad est dado por:
SOLUCIONARIO
a. Tiempo restante.
b. Carga de trabajo.
c. Tiempo consumido.
BIBLIOGRFICAS
5. Durante el seguimiento es importante que el jefe de proyecto analice el avance del proyecto en
REFERENCIAS
contra del:
a. Contrato con el cliente.

b. Plan establecido.
c. No es importante que analice.
6. El control de costos del proyecto incluye:
a. Gestionar los cambios reales.

b. Ver que las tareas se hayan cumplido.
c. Ninguna de las anteriores.
7. La manera ms directa de hacer un seguimiento efectivo al equipo, es:
a. Que cada miembro lleve una libreta de apuntes.

b. Hacer reuniones del proyecto.
c. Hacer pruebas funcionales de software.

8. Aqu se tratan los puntos que hay que analizar con profundidad del proyecto:
a. Kicks-off.
NDICE
b. Sesiones de formacin.
c. Sesiones de anlisis.
9. Estn dirigidas por expertos con la finalidad de capacitar:
PRELIMINARES
a. Kicks-off.
10. Son las reuniones que se hacen frecuentemente al iniciar el proyecto, para socializar el mismo:
BIMESTRE
PRIMER
a. Kicks-off.
SEGUNDO
BIMESTRE
final de la gua.
SOLUCIONARIO
Ir a solucionario
BIBLIOGRFICAS
REFERENCIAS

Texto-Gua: Gestin de Proyectos Informticos SOLUCIONARIO
7. Solucionario
NDICE
Verifique la respuesta correcta segn la Autoevaluacin que corresponda.
____________________________________________________________
PRELIMINARES
Autoevaluacin 1
Pregunta Respuesta
BIMESTRE
b
PRIMER
1.
2. c
3. a
SEGUNDO
b
BIMESTRE
4.
5. c
6. c
SOLUCIONARIO
7. c
8. b
9. c
BIBLIOGRFICAS
REFERENCIAS
10. a
Ir a autoevaluacin

Autoevaluacin 2
NDICE
Pregunta Respuesta
1. b
2. c
PRELIMINARES
3. a
4. c
5. c
BIMESTRE
PRIMER
6. c
7. a
8. c
SEGUNDO
BIMESTRE
9. c
10. a
SOLUCIONARIO
Ir a autoevaluacin
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 3
NDICE
Pregunta Respuesta
1. b
2. a
PRELIMINARES
3. c
4. a
5. b
BIMESTRE
PRIMER
6. c
7. c
8. a
SEGUNDO
BIMESTRE
9. b
10. c
SOLUCIONARIO
Ir a autoevaluacin
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 4
NDICE
Pregunta Respuesta
1. c
2. b
PRELIMINARES
3. a
4. b
5. c
BIMESTRE
PRIMER
6. a
7. c
8. c
SEGUNDO
BIMESTRE
9. b
10. a
SOLUCIONARIO
Ir a autoevaluacin
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 5
NDICE
Pregunta Respuesta
1. c
2. b
PRELIMINARES
3. c
4. c
5. a
BIMESTRE
PRIMER
6. c
7. a
8. b
SEGUNDO
BIMESTRE
9. a
10. b
SOLUCIONARIO
Ir a autoevaluacin
BIBLIOGRFICAS
REFERENCIAS

Autoevaluacin 6
NDICE
Pregunta Respuesta
1. b
2. c
PRELIMINARES
3. c
4. a
5. b
BIMESTRE
PRIMER
6. a
7. b
8. c
SEGUNDO
BIMESTRE
9. b
10. a
SOLUCIONARIO
Ir a autoevaluacin
BIBLIOGRFICAS
REFERENCIAS

Texto-Gua: Gestin de Proyectos Informticos REFERENCIAS BIBLIOGRFICAS
8. Referencias Bibliogrficas
DI CTI ONARY
TH ESA UR US
NDICE
Domingo Ajenjo, A. (2000). Direccin y gestin de proyectos: un enfoque prctico. Madrid: RAMA.
Espinosa, M., & Crdova, C. (2015). Gua Didactica - GESTIN DE PROYECTOS INFORMTICOS. Loja:
PRELIMINARES
EdiLoja.
Gido, J., & James, C. (2007). Administracin exitosa de proyectos. Mxico: Cengage Learning Editores,
S.S.
Guarna, P., & Bernardo, O. (2010). Facultad de Ingeniera - Universidad de Buenos Aires. Obtenido
BIMESTRE
de Facultad de Ingeniera - Universidad de Buenos Aires: http://web.fi.uba.ar/~bortega/apunte_
PRIMER
calidad_codigo.pdf
Gurin, B.-A. (2015). Gestin de proyectos informticos - Desarrollo, anlisis y control. Madrid: ENI.
Horine, G. (2009). Gestin de proyectos. Anaya Multimedia.
SEGUNDO
BIMESTRE
Lara, O. (04 de 10 de 2011). Tipos de estructura organizacional. Obtenido de Gestiopolis: http://
www.gestiopolis.com/tipos-de-estructura-organizacional/
Lemus, W. J. (04 de 06 de 2011). 9 factores que repercuten en el clima organizacional y los

objetivos empresariales. Obtenido de Gestiopolis: http://www.gestiopolis.com/9-factores-clima-
SOLUCIONARIO
organizacional-objetivos-empresariales/
Litwin, G., & Stinguer, H. (1978). Organizacional Climate. New York: Simon & Shuster.
Macas, M. (4 de Abril de 2011). La estructura de costes de tu empresa: Advenio. Obtenido de Advenio

strategy&business desing: http://advenio.es/la-estructura-de-costes-de-tu-empresa/
BIBLIOGRFICAS
REFERENCIAS
Mendez, R. (2014). Formulacin y Evaluacin de Proyectos. Bogot: ICONTEC INTERNACIONAL.
Prez, A., & Salazar, N. (2006). Metodologas para el desarrollo de sistemas. Caso de estudio: Mtrica II
y MERISE. Universidad Autnoma del Estado de Hidalgo, Instituto de ciencias bsicas e ingeniera.
Estado de Hidalgo: SN.
Project Management Institute, Inc. (2013). Fundamentos para la direcccin de proyectos (Gua
PMBOK). Pensilvania.
Ramn, J., Garca, J., & Lamarca, I. (2007). Gestin de proyectos informticos: mtodos, herramientas
y casos. Barcelona: UOC.
Rouse, M. (11 de Enero de 2006). CRM (Gestin de Relacin con Clientes). Obtenido de
SearchDataCenter: searchdatacenter
Sapag, N. (2007). Proyectos de inversin Formulacin y evaluacin. Mexico: Pearson.

Guia A Distancia de Gestion de Proyectos

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Guia A Distancia de Gestion de Proyectos

Diunggah oleh

Hak Cipta:

Format Tersedia

NDICE

La Universidad Catlica de Loja

Departamento de Ciencias de la Computacin y Electrnica

UNIVERSIDAD TCNICA PARTICULAR DE LOJA

EDILOJA Ca. Ltda.

ISBN digital - 978-9942-25-245-6

UNIDAD 2. LINEAMIENTOS PARA FORMULACIN DE PROYECTOS ASPECTOS

UNIDAD 4. INICIAR Y ANALIZAR UN PROYECTO.......................................................................... 51

UNIDAD 5. EL DESARROLLO DEL PROYECTO LA PLANIFICACIN Y LA ESTIMACIN........ 64

UNIDAD 6. EL SEGUIMIENTO Y CONTROL...................................................................................... 81

Sin embargo, es de nuestro inters despertar en el profesional en formacin la necesidad de conocer ms

Primer Bimestre - centrado en las siguientes temticas:

Introduccin a la gestin de proyectos Aspectos fundamentales

Segundo bimestre centrado en las siguientes temticas:

Iniciar y analizar un proyecto

6 MODALIDAD ABIERTA Y A DISTANCIA

Romero, K. (2017). Guia de Proyectos Informticos. Ecuador: EdiLoja.

Mendez, R. (2014). Formulacin y Evaluacin de Proyectos. Bogot: ICONTEC INTERNACIONAL.

El PMI es el organismo lder en temas de gestin de proyectos. Propone la metodologa de PMBOK

7 MODALIDAD ABIERTA Y A DISTANCIA

Recursos Educativos Abiertos (OCW):

Presenta un ejemplo claro del manejo de indicadores de evaluacin de proyectos.

Presenta el alcance de la gestin de riesgos y el estudio detallado de este proceso.

Presentacin que ejemplifica la gestin de riesgos de un proyecto.

Es un documento donde se describen los conceptos bsicos para la calidad de cdigo.

A. Se presenta la metodologa del PMBOK

Lider de Proyecto (2016). reas de Conocimiento. Mxico. DF. Recuperado de http://www.

Material de estudio de diversas metodologas giles de gestin de proyectos.

Presentacin de comunidad, foros y discusin de la metodologa gil de gestin de proyectos.

8 MODALIDAD ABIERTA Y A DISTANCIA

En la presentacin se incluyen los objetivos claves para realizar exitosamente la reunin de

Martn, Q. (2002). Departamento de Informtica: UV. Recuperado de Universidad de Valencia:

Documento que desarrolla el proceso de cierre de un proyecto informtico y sugiere plantillas de

9 MODALIDAD ABIERTA Y A DISTANCIA

5. Orientaciones generales para el estudio

5.2. Cmo estudiar?

10 MODALIDAD ABIERTA Y A DISTANCIA

5.3. Apoyo tecnolgico e interactividad

Recomendaciones de lectura dirigidas al texto bsico.

Preguntas que surgen del estudio previo de un tema.

Enfatizar temas importantes que debe recordar en el

Referencia a una conceptualizacin importante.

11 MODALIDAD ABIERTA Y A DISTANCIA

Fin de la unidad de estudio.

12 MODALIDAD ABIERTA Y A DISTANCIA

6. Proceso de enseanza-aprendizaje para el logro de competencias.

Qu es un Proyecto? Gestin de proyectos informticos

Empecemos conociendo el concepto de proyecto segn varios autores:

Proyecto es el conjunto de actividades planificadas, ejecutadas y supervisadas que, con recursos

13 MODALIDAD ABIERTA Y A DISTANCIA

Revisemos el texto bsico Captulo 1. Un proyecto informtico 1. Los aspectos

Construccin de un software de gestin financiero.

1.1. Atributos de un proyecto

Tiene un objetivo bien definido, un resultado o producto esperado.

14 MODALIDAD ABIERTA Y A DISTANCIA

1.2. Conceptos bsicos y comunes de un proyecto.

15 MODALIDAD ABIERTA Y A DISTANCIA

Tome como ejemplo de proyecto, la construccin de un edificio e

1. Tiempo: siempre hay una fecha que cumplir.

Figura 1. Triple Restriccin

En el texto bsico Captulo 1: Un proyecto informtico 3. Las restricciones, que son en

En la Tabla 2 se encuentra un resumen de las restricciones que seala el texto bsico.

16 MODALIDAD ABIERTA Y A DISTANCIA