TRABAJO COLABORATIVO 2 y 3
PROYECTO DE GRADO (ING. DE
SISTEMAS) GRUPO: 201014_7
TUTOR:
WILMAR LIBERTO COPETE
ESTUDIANTES
JOHN ALEXANDER REYES CAMPOS
- CÓDIGO: 79912231
JUAN CARLOS MONROY -
CÓDIGO: 79748543
EDISON AUGUSTO LADINO -
CÓDIGO: 79750997
ALEX EDUARDO MORENO
ECHAVARRIA
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA (UNAD)
INGENIERÍA DE SISTEMAS
CEAD JOSÉ ACEVEDO Y GÓMEZ
BOGOTÁ D.C. NOVIEMBRE 2016-II
Tabla de Contenido
ESTRUCTURA DEL PROYECTO:
Planteamiento del Problema
En la empresa
Salud Total se ha encontrado diversos procesos que generan inconvenientes de
tipo tecnológico con diversos re-procesos en la ejecución de sus aplicaciones
hallando que esta área no está totalmente estructurada para el desarrollo y
funcionamiento del software que sus clientes requieren, siendo muy
independientes en la ejecución de las tareas que estas áreas desarrollan.
En el
problema están involucrados tanto el hardware como el software, ya que,
dependiendo del hardware, su capacidad y administración, depende el software
base o herramientas para ejecutar las tareas de desarrollo, por consiguiente,
el software que se desarrolla.
El problema de investigación es la desarticulación de las áreas del
proceso de desarrollo causado por uso
de recursos de manera independiente en la labor de desarrollo, pruebas y
performance, que ocasionan la entrega de interfaces poco amigables y que pueden
ocasionar falta a la integridad de la información, siendo esta la situación a
investigar.
Por observación directa se confirma que el tiempo dedicado en cada área es
duplicado por el rendimiento de las herramientas, por lo cual el tiempo de
interacción entre las áreas de desarrollo es limitado.
Se evidencia que los tiempos de solicitud de cambios de software son
apropiados, pero el rendimiento en las tareas de desarrollo y las otras áreas
consume tiempo adicional por pasar de un ambiente con recursos apropiados a
otro con restricciones en cuanto a permisos en bases de datos, aplicaciones y
recursos compartidos.
Se invierte tiempo en apertura de casos de solicitud de permisos para
bases de datos, recursos compartidos y uso de aplicaciones en la herramienta”
HelpDesk CA”, para lo cual transcurre un tiempo prudencial de atención,
teniendo que esperar la solución para continuar la parte que implica la
solicitud.
Los servidores del ambiente de desarrollo tienen una configuración
diferente a los servidores de pruebas, así mismo para los servidores de performance,
así que las áreas tienen ambientes con configuraciones y privilegios diferentes
para sus labores en cuanto a la infraestructura.
Propósito de Investigación
Este proceso de investigación deberá retroalimentar a las aéreas
afectadas y quienes deberán
conocer los procedimientos que se deben realizar cuando se está
desarrollando software para una empresa con múltiples usuarios que requieren
del servicio que la compañía presta.
Es preciso evaluar por qué existen estas sub-aéreas y si es
indispensable requerirlas para diferentes desarrollos o aplicaciones que la
empresa necesita, de ahí debemos entender y analizar la infraestructura
tecnológica con el fin de no recargar el uso de esta.
Una vez evaluadas las sub-áreas, con este resultado se realizaría una guía con todas los posibles
interrogantes que se presenten por parte de los integrantes que se vayan a
beneficiar en donde se explique la parte de las labores de desarrollo de
software, pruebas y performance, para facilitar el servicio en cada área y así
puedan alcanzar los demás propósitos que se derivan.
Es fundamental que en la guía se incluya que los ambientes de pruebas y
desarrollo de software estén integrados en las aéreas y que su actualización
sea un concepto primordial para cada desarrollador en pro de conocer todos los
sistemas que maneja la empresa.
Con la aplicación de la guía, se espera disminuir espacio en
infraestructura que permita distribuir mejor los recursos entre las tres áreas,
lo que permitirá hacer entregas periódicas, dando oportunidad de correcciones
en el camino entre áreas.
También se espera que los ambientes de desarrollo de software, pruebas y
performance, puedan articular de manera pertinente, derivado del trabajo en
equipo, lo que permitirá dividir los problemas en tareas cortas.
Otro resultado esperado, a partir del uso de la guía por parte de los involucrados,
es que los integrantes de cada equipo puedan hacer seguimiento a los pasos en
que va el desarrollo de los productos.
El propósito más importante que se espera obtener es que el usuario
final pueda hacer uso del software oportunamente entre los tiempos requeridos,
con el fin de facilitar la visualización de mejoras.
Se espera que el costo en
diagnóstico de infraestructura sea de $2.000.000 mes, de la estructura de
procesos de desarrollo de software $2.000.000 mes, el costo por asesoría en
infraestructura $2.000.000 mes, asesoría en procesos de desarrollo de software
$2.000.000 mes y la implementación de la tecnología de Desarrollo Ágil
$6.000.000, con un total en cuanto diagnóstico integral, asesoría integral e
implementación: $14.000.000 de pesos, incluyendo la
capacitación.
Preguntas de Investigación
¿De qué manera se puede realizar una guía completa para que sea
aprovechada y que todos puedan entender y hacer un buen uso?
¿Existe capacitación y entrenamiento adecuado para el personal del área
de desarrollo de software?
¿De qué forma se puede adecuar la infraestructura para que pueda ser
aprovechada tanto por los ambientes de desarrollo de software, pruebas y performance?
¿De qué manera puede el usuario final, usar el software requerido o
cambios requeridos, de tal forma que se entregue dentro del tiempo solicitado y
con una experiencia en su uso sin contrapiés?
¿Cómo se podría evaluar los diferentes procesos que se ejecutan en el
área de desarrollo de software para que no afecten los tiempos de entrega en
sus aplicaciones?
¿Porque las pruebas no se están ejecutando de manera correcta cuando una
aplicación es necesaria para el usuario o el cliente?
¿Cuál es el costo y el tiempo de realizar la guía para los usuarios
finales?
Definir la terminología a utilizar
Aquí se definen
términos específicos que tienen que ver o que son propios de la investigación a
realizar.
Performance: Área de pruebas de rendimiento de software en una
infraestructura, hace parte del desarrollo del software.
Pruebas: Estado del desarrollo del software donde se prueban
las aplicaciones en desarrollo, donde se mide el nivel de comprensión,
aplicación y análisis.
Desarrollo: Es el ciclo de vida del software en cuanto a su
creación o modificación, a partir de unos requerimientos con el fin de
solucionar un problema y\o lograr un objetivo.
Infraestructura:
Todo lo que
involucra las herramientas tecnológicas y su despliegue en una red, de forma
organizada y jerarquizada, limitada por seguridad y administración.
Levantamiento
de requerimientos:
El cual fundamenta que proceso en estos momentos se ejecuta y que se puede
mejorar de este en pro del usuario.
Privilegios: Facultades de grupos o usuarios en una red para el
uso de recursos en un sistema o subsistemas.
Usuario: Totalmente involucrado en el proceso de desarrollo
para su fácil manejo.
Cronograma: Es el planeador con fechas, donde se consignan las
actividades, responsables, fechas de inicio y finalización, recursos necesarios
y resultado esperado.
Software
Base: Son las
herramientas base del host o servidor, con el fin de poder ser usado por
cualquier usuario, EJ: winrar, visor de imágenes, antivirus, compresor de
archivos, navegadores adicionales a Internet Explorer.
Software
No Base: Es el software
que se usado para la tarea de desarrollo en sí. Ej: SQL Server 2014, Visual
Studio 2012, entre otros.
Servidor
de desarrollo: Son los
servidores usados para adelantar la tarea de desarrollo de software, cuenta con
software base y no base para poder adelantar el desarrollo de software, además
de compartir con recursos compartidos y conexión LAN.
CREAR UN MAPA
CONCEPTUAL EN CMAPTOOLS QUE CONTEMPLE PARA EL TEMA CONSULTADO SOBRE LA TECNOLOGÍA
MODERNA LOS SIGUIENTES INTERROGANTES:
I.
¿Qué es?
II.
¿Para qué sirve?
III.
¿Cuáles son las características
principales?
IV.
¿Cuáles son las ventajas y
desventajas?
V.
¿Cuáles son las aplicaciones o
usos?
VI.
¿Por qué se puede aplicar en
determinado problema o en ciertos sistemas?
VII.
¿Por qué se considera una
tecnología de punta o moderna?
VIII.
¿Qué trabajos se han realizado por
diversos investigadores alrededor del tema? Pueden ser ponencias, artículos
científicos u otros.
Para solucionar el problema
planteado, lo primero que se debe tener es una herramienta para la
administración del ciclo de desarrollo del software basado en una metodología
ágil, la cual contemple actividades de desarrollo y de pruebas.
Adicionalmente contar con una
persona o grupo que realice las pruebas del software a desarrollar y de
cualquier cambio que se presente dentro del mismo, que a su vez realice la
retroalimentación al área de desarrollo, para así tener una interacción
constante y poder cumplir con los requerimientos solicitados por el cliente.
CREAR UN DOCUMENTO PDF QUE CONTENGA LA PLANEACIÓN DE
LA SOLUCIÓN: PARA REALIZAR ESTA ACTIVIDAD, SE SUGIERE UTILIZAR EL DECÁLOGO DE
BERNAL. SE DEBE DILIGENCIAR EL SIGUIENTE CUADRO PARA ADJUNTARLO A LA PRIMERA
ACTIVIDAD:
CONCEPTO
|
DESCRIPCIÓN
|
Cronología
(¿Cuándo?)
|
En la
empresa Salud Total se ha encontrado diversos procesos que generan
inconvenientes de tipo tecnológico con diversos re-procesos en la ejecución
de sus aplicaciones hallando que esta área no está totalmente estructurada
para el desarrollo y funcionamiento del software que sus clientes requieren,
siendo muy independientes en la ejecución de las tareas que estas áreas
desarrollan.
En el
momento de iniciar el levantamiento de información y durante el resto del
ciclo de vida del desarrollo del software.
Cada proceso
que necesite de articulación con otras sub-áreas de desarrollo.
Al momento
de optimizar los recursos para obtener un mejor rendimiento.
El
desarrollo de la solución se tendrá que dar durante el periodo de octubre a
diciembre 2016.
|
Axiomas
(¿Quién?)
|
Se cuenta
con la participación de los integrantes del pequeño grupo colaborativo
201014_7 del curso proyecto de grado (ingeniería de sistemas)
Estudiantes
John
Alexander Reyes Campos - código: 79912231
Juan Carlos
Monroy - código: 79748543
Edison Augusto
Ladino - código: 79750997
Alexander
Eduardo Moreno Echavarría
|
Método
(¿Cómo?)
|
Primero
plantear el problema, levantar información de procesos actuales y sistemas
usados junto con la forma de su uso, establecer exactamente los puntos de
conflicto, desarrollar el software requerido según las necesidades presentados
en los anteriores pasos, generar prácticas en un ambiente de desarrollo de
pruebas, retroalimentarse y mejorar el desarrollo con los comentarios de los
usuarios quienes probaron en el desarrollo de pruebas este mismo, capacitación
a los usuarios en este nuevo desarrollo, sacarlo a producción ya con las
mejoras.
|
Ontología
(¿Qué?)
|
Objetivo
final: integrar la información de las sub áreas considerando que sea un
verdadero alivio para el sistema manejado dentro de la empresa Salud Total.
|
Tecnología
(¿Con qué?)
|
Se
utilizará la tecnología de Desarrollo de Software Ágil como “XP (Programación
Extrema), SCRUMB y Kanban”
|
Teleología
(¿Para qué?)
|
Este
desarrollo se propuso para acabar con los cuellos de botellas, se compacten
todas las sub áreas y la información este accesible al usuario interno como
el final para que no se genere repetición de solicitud en la información.
|
Topografía
(¿Dónde?)
|
Este
desarrollo se hará en dos partes, el levantamiento de información y puesta en
marcha del desarrollo en pruebas, capacitación y producción dentro de la
Empresa Salud Total y el desarrollo como tal en diferentes partes de Bogotá
donde se encuentre el desarrollador (siendo claro dentro de Bogotá).
|
Ecología
(¿Contra qué?)
|
La sede de
Tecnología de Salud total se encuentra en la Av. 68 13-50, oficinas y centro
de datos en 3er piso, sector Industrial de Bogotá.
Con la
implementación de la tecnología propuesta para solucionar el problema
expuesto, busca minimizar tanto el consumo innecesario de energía, como el
consumo de recursos innecesarios después de poner en funcionamiento el
sistema.
|
Etiología
(¿Por qué?)
|
Porque por
observación directa y conversación con los usuarios afectados, se evidencian
tanto fallas de software como inconsistencia en la información. Además, se ha
observado el trabajo individual, dejando de lado el trabajo en equipo y los
beneficios que esto trae.
También
porque la empresa tiene los recursos para adoptar la tecnología propuesta,
con el fin de superar el problema planteado y dar satisfacción al cliente.
|
Experiencia
(¿Cuánto?)
|
La experiencia en cuanto a un buen funcionamiento,
desempeño y calidad del software se ha visto reflejada por el buen trabajo en
equipo que se ve en una empresa al equipo de pruebas que realiza los
diagnósticos necesarios en cuanto a errores que el mismo software pueda tener
y que dichos errores sean transmitidos al área de desarrollo para que ellos
hagan los ajustes necesarios antes de que el producto pueda salir a
producción o se entregado al usuario final, esto con el fin de entregar un
software de excelencia.
|
gerencia
de proyectos
ACTIVIDAD I
·
Gerencia
de Proyectos
La
gerencia de proyectos está determinada como la disciplina de administrar y
organizar múltiples recursos y procesos que de alguna forma deben cumplir
diferentes pasos para un proyecto, con el fin de que su terminación sea exitosa
cumpliendo los tiempos y costos planteados desde su comienzo, aplicando el
conocimiento de las habilidades y técnicas para que estos sean ejecutados de
manera efectiva y asertiva, y así emplear competencias estratégicas para las
compañías u organizaciones, permitiendo encontrar los resultados de las metas
propuestas para competir mejor en el mercado.
La
dirección o gerenciamiento de un proyecto incluye el identificar los requisitos
y condiciones, establecer objetivos claros y que se puedan realizar, un balance
entre el alcance y el costo, y las expectativas de los interesados en el
proyecto, todo esto con el fin de poder establecer un plan, poderlo poner en
práctica, estar al tanto de sus procesos y satisfacer las necesidades de los
clientes
Esta
disciplina se manejaba de manera bastante informal, pero viendo la necesidad de
un orden genérico y completo para este tema surge a mediados de los años 20
esta profesión más enfocada por el PMI estructurada en la librería de
estándares globales los cuales nos entregan herramientas de los fundamentos del
conocimiento en la dirección de proyectos determinado algunas aéreas del
conocimiento para la gerencia de proyectos.
Imagen tomada de:
http://es.slideshare.net/juanprada/gerencia-de-proyectos-12012592
También
existe una organización sin fines de lucro a escala mundial conocida como
Project Management Institute (PMO) que sirve como referencia de las buenas
prácticas y estándares para todos aquellos que practican esta disciplina.
El
uso de conocimientos, habilidades, herramientas y técnicas de gerencia de
proyectos se logra mediante la ejecución exacta de sus procesos, el cual se
fundamenta en el conjunto de actividades integradas que se llevan a cabo en un
conjunto especifico de productos, bienes y servicios para así poder conectar
las diversas entradas y salidas del ciclo de vida de un proyecto.
GESTION DEL ALCANCE
ALCANCE DEL PRODUCTO: (project scope)
El gerente de proyectos debe tener la
capacidad para tener una gestión en el alcance de forma clara y concisa y
además del conocimiento acerca de la metodología SCRUM que agiliza el proceso,
dividiendo el problema en pequeñas tareas en un tiempo que se ha definitivo con
anterioridad, Los clientes puede acceder en la utilización del producto.
Promueve el trabajo en equipo cuando alguna actividad genera algún problema,
(los desarrolladores se comunican entre sí y dan solución al inconveniente),
reduciendo la pérdida de tiempo. Al momento de realizar las nuevas mejoras al
software por parte del grupo de desarrollo ya habiendo pasado las pruebas
pertinentes y validando:
ü
La visualización de los datos.
ü
La respuesta y realización de las transacciones.
ü
Que los estados de las actividades y documentos generados en el
sistema se reflejen de acuerdo a la secuencia lógica requerida por el usuario.
ü
La secuencia lógica de las funcionalidades y transacciones.
ü
Cumplimiento de estándares de desarrollo y presentación.
ü
Pruebas funcionales.
ü
Pruebas no funcionales.
ü
Verificación de documentación entregada.
ü
Validación de la ejecución de pruebas por parte del grupo de
desarrollo.
ü
Solución / corrección de incidentes reportados en el proceso de
pruebas.
ü
Otros que sean pertinentes.
Por medio de estas opciones se mejorarán
las interacciones entre las áreas y sub-áreas de desarrollo con un mejor
rendimiento y optimización de los recursos para dar una mejor calidad y
satisfacción total en el servicio ofrecido.
1.
Recopilación de requisitos
Definición y funciones
del producto:
Con
el siguiente proyecto se busca satisfacer la necesidad de las sub-áreas de
desarrollo integrando la información. Por
medio de la técnica SCRUM que agiliza el proceso, dividiendo el problema en
pequeñas tareas y las cuales tienen un tiempo que determinado con anterioridad,
En donde el cliente puede comenzar a utilizar el producto rápidamente.
Promoviendo el trabajo en equipo cuando se presente un inconveniente en el
software (los desarrolladores se comunican entre sí y se ofrecerán la solución
en línea remota mete brindando solución al problema), reduciendo el tiempo
perdido y da facilidad para actualizar y mejorar el sistema
2.
Creación de la EDT. (WBS)
EDT: Alcance de los
objetivos del proyecto
•
El modelo de proceso de desarrollo para el software que se utilizaría
para el diseño y desarrollo en este caso es el método SCRUM que se encuentra
dentro de la metodología ágil, Dicha metodología está definida para la gestión
de proyectos, especialmente para proyectos de rápido cambio de requisitos,
proyectos a corto plazo y con grupo de desarrolladores pequeños.
•
Como la empresa Salud Total es una empresa prestadora de servicios de
salud se debe tener buena disponibilidad del software atención de los usuarios
ya que estas áreas son el eje central del negocio y el desarrollo del software
se dará para suplir una necesidad actual en el negocio para que los clientes
finales tengan un acceso rápido a la aplicación de la empresa en el momento que
lo deseen.
•
La metodología SCRUM agiliza el proceso, porque se divide el problema
en pequeñas tareas y las tareas tienen un tiempo que se ha determinado con
anterioridad, El cliente puede comenzar a utilizar el producto rápidamente.
Promueve el trabajo en equipo (los desarrolladores se comunican entre sí y se
ayudan cuando alguna actividad da problemas), se reduce el tiempo perdido y da
facilidad para añadir mejoras.
Entregables
Se le entregará a la
empresa en medio magnético CD el instalador del software, adjunto vendrá un
manual del usuario donde se explicará paso a paso la instalación del
aplicativo, tiene derecho a capacitación de 6 horas las cuales serán de forma
presencial establecidas con los usuarios en dividida en tres días.
3.
Control del alcance
Con
el software y su implementación en la empresa Salud Total pretendemos
contribuir al crecimiento de la empresa y a mejorar la calidad de vida de los
usuarios facilitando el acceso para satisfacer sus necesidades. Maximizando las
ganancias y permitiendo identificar la relación costo-beneficio y ayudando en
la toma de decisiones instaurando unos procedimientos e interpretando las
incidencias.
El
software se debe ocupar de cada uno de los temas creando una acción necesaria
cada vez que la empresa realice una interacción u ofreciendo un servicio. Para
la empresa Sald Total es de vital importancia conocer al cliente adaptando un
trato con diferentes opciones de estrategias de atención y Servicio, ofreciendo
sus diferentes opciones de servicio en el mundo, gracias a la implementación de
la aplicación todo se puede dar para tener mayor fluidez en el manejo de la
información y alcanzar el logro de objetivos de la empresa.
4.
Verificación del alcance
Al realizar la entrega de los entregables
por parte de los programadores a la empresa Salud Total, se aceptan los
términos y condiciones para el manejo de la información y asesoría incluida.
Un gerente de Proyectos debe tener una
buena gestión del Tiempo para que en el Proyecto se incluyan los procesos
necesarios para lograr la conclusión del mismo a tiempo.
DEFINICIÓN DE LAS ACTIVIDADES
Definir las actividades del cronograma
implica identificar y documentar el trabajo que se planifica realizar.
El proceso Definición de las Actividades
identificará los productos entregables al nivel más bajo de la estructura de
desglose del trabajo. Los paquetes de trabajo del proyecto están planificados
(descompuestos) en componentes más pequeños denominados actividades del
cronograma, para proporcionar una base con el fin de estimar, establecer el
cronograma, ejecutar, y supervisar y controlar el trabajo del proyecto. La
definición y planificación de las actividades del cronograma están implícitas
en este proceso, de tal modo que se cumplan los objetivos del proyecto.
-
Entradas
- Factores Ambientales de la Empresa Incluyen la disponibilidad de los sistemas de información de la gestión de proyectos y herramientas de software para la elaboración de cronogramas.
- Activos de los Procesos de la Organización Contienen las políticas formales e informales existentes relacionadas con la planificación de actividades, los procedimientos y las guías que se tienen en cuenta al desarrollar las definiciones de las actividades.
- Enunciado del Alcance del Proyecto Los productos entregables del proyecto, las restricciones y las asunciones documentadas en el enunciado del alcance del proyecto.
- Estructura de Desglose del Trabajo La estructura de desglose del trabajo es una entrada principal para la definición de las actividades del cronograma.
- Plan de Gestión del Proyecto El plan de gestión del proyecto contiene el plan de gestión del cronograma, que proporciona orientación sobre el desarrollo y la planificación de las actividades del cronograma y del plan de gestión del alcance del proyecto.
-
Herramientas y Técnicas
- Descomposición Implica subdividir los paquetes de trabajo del proyecto en componentes más pequeños y más fáciles de manejar, denominados actividades del cronograma
- Plantillas Puede incluir una lista de habilidades de los recursos y la cantidad de horas de esfuerzo necesarias, la identificación de riesgos, los productos entregables esperados y cualquier otra información descriptiva.
- Planificación Gradual Las actividades del cronograma pueden existir a distintos niveles de detalle en el ciclo de vida del proyecto. Durante los inicios de la planificación estratégica, cuando la información está menos definida, las actividades se pueden mantener al nivel de hito.
- Juicio de Expertos o de los miembros del equipo del proyecto
- Componente de Planificación Dos componentes de planificación son:
-
Cuenta de Control. Se puede ubicar un punto de control de gestión en
puntos de gestión seleccionados (componentes específicos en niveles
seleccionados) de la estructura de desglose del trabajo. Estos puntos de
control se utilizan como base para la planificación cuando todavía no se han
planificado los paquetes de trabajo relacionados. Todo el trabajo y el esfuerzo
realizado dentro de una cuenta .de control se documenta en un plan de la cuenta
de control.
-
Paquete de Planificación. Un paquete de planificación es un componente
ubicado por debajo de la cuenta de control, pero por encima del paquete de
trabajo. Este componente se utiliza para planificar el contenido del trabajo
conocido que no tiene actividades del cronograma detalladas.
-
Salidas
- Lista de Actividades
- Atributos de la Actividad Identifican los múltiples atributos relacionados con cada actividad del cronograma. Incluyen el identificador de la actividad, los códigos de la actividad, la descripción de la actividad, las actividades predecesoras, las actividades sucesoras, las relaciones lógicas, los adelantos y los retrasos, los requisitos de recursos, las fechas impuestas, las restricciones y las asunciones
- Lista de Hitos Identifica todos los hitos e indica si es obligatorio u opcional.
- Cambios Solicitados
-
ESTABLECIMIENTO DE LA SECUENCIA DE LAS
ACTIVIDADES
Implica identificar y documentar las
relaciones lógicas entre las actividades del cronograma. Las actividades del
cronograma pueden estar ordenadas de forma lógica con relaciones de precedencia
adecuadas, así como también adelantos y retrasos, para respaldar el desarrollo
posterior de un cronograma del proyecto realista y factible.
-
Entradas
- Enunciado del Alcance del Proyecto
- Lista de Actividades
- Atributos de la Actividad
- Lista de Hitos
- Solicitudes de Cambio Aprobadas
-
Herramientas y Técnicas
- Método de Diagramación por Precedencia (PDM)
Esta técnica también se denomina
actividad en el nodo (AON), y es el método utilizado por la mayoría de los paquetes
de software de gestión de proyectos. El PDM incluye cuatro tipos de
dependencias o relaciones de precedencia:
- Final a Inicio
- Final a Final
- Inicio a Inicio
- Inicio a Fin
En el PDM, final a inicio es el tipo de
relación de precedencia más comúnmente usado. Las relaciones inicio a fin
raramente se utilizan
- Método de Diagramación con Flechas (ADM) Es un método para crear un diagrama de red del cronograma del proyecto que utiliza flechas para representar las actividades, que se conectan en nodos para mostrar sus dependencias.
- Plantillas de Red del Cronograma Pueden utilizarse para acelerar la preparación de redes de actividades del cronograma del proyecto. Éstas pueden incluir un proyecto completo o solamente una parte de él.
- Determinación de Dependencias Se utilizan tres tipos de dependencias para definir la secuencia entre las actividades.
- Dependencias obligatorias Son aquellas inherentes a la naturaleza del trabajo que se está realizando.
- Dependencias discrecionales. Se encuentran totalmente documentadas, ya que pueden producir valores arbitrarios de holgura total y pueden limitar opciones posteriores de programación.
- Dependencias externas. Son las que implican una relación entre las actividades del proyecto y las actividades que no pertenecen al proyecto.
- Aplicación de Adelantos y Retrasos El equipo de dirección del proyecto determina las dependencias que pueden requerir un adelanto o un retraso para definir con exactitud la relación lógica.
-
Salidas
- Diagramas de Red del Cronograma del Proyecto
- Lista de Actividades (Actualizaciones)
- Atributos de la Actividad (Actualizaciones)
- Cambios Solicitados
-
ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES
Involucra determinar cuáles son los
recursos (personas, equipos, o material) y qué cantidad de cada recurso se utilizará,
y cuándo estará disponible cada recurso para realizar las actividades del
proyecto. El proceso Estimación de Recursos de las Actividades se coordina
estrechamente con el proceso Estimación de Costes
-
Entradas
1
Factores Ambientales de la Empresa
2
Activos de los Procesos de la Organización
3
Lista de Actividades
4
Atributos de la Actividad
5
Disponibilidad de Recursos
6
Plan de Gestión del Proyecto
-
Herramientas y Técnicas
- Juicio de Expertos
- Análisis de Alternativas
- Datos de Estimación Publicados Varias empresas publican periódicamente los índices de producción actualizados y los costes unitarios de los recursos para una extensa variedad de industrias, materiales y equipos, en diferentes países y en diferentes ubicaciones geográficas dentro de esos países.
- Software de Gestión de Proyectos Tiene la capacidad de ayudar a planificar, organizar y gestionar los conjuntos de recursos, y de desarrollar estimaciones de recursos.
- Estimación Ascendente Cuando no se puede estimar una actividad del cronograma con un grado razonable de confianza, el trabajo que aparece dentro de la actividad del cronograma se descompone con más detalle. Se estiman las necesidades de recursos de cada una de las partes inferiores y más detalladas del trabajo, y estas estimaciones se suman luego en una cantidad total para cada uno de los recursos de la actividad del cronograma.
-
Salidas
- Requisitos de Recursos de las Actividades Es una identificación y descripción de los tipos y las cantidades de recursos necesarios para cada actividad del cronograma de un paquete de trabajo. Estos requisitos pueden sumarse para determinar los recursos estimados para cada paquete de trabajo.
- Atributos de la Actividad (Actualizaciones) Los tipos y las cantidades de recursos necesarios para cada actividad del cronograma se incorporan a los atributos de la actividad.
- Estructura de Desglose de Recursos La estructura de desglose de recursos (RBS) es una estructura jerárquica de los recursos identificados por categoría y tipo de recurso.
- Calendario de Recursos (Actualizaciones) Documenta los días laborables y no laborables que determinan aquellas fechas en las que cada recurso específico, ya sea una persona o un material, puede estar activo u ocioso.
- Cambios Solicitados
-
DESARROLLO DEL CRONOGRAMA
Es un proceso interactivo, determina las
fechas de inicio y finalización planificadas para las actividades del proyecto. El desarrollo
del cronograma exige que se revisen y se corrijan las estimaciones de duración
y las estimaciones de los recursos para crear un cronograma del proyecto
aprobado que pueda servir como línea base con respecto a la cual poder medir el
avance.
-
Entradas
- Activos de los Procesos de la Organización Como un calendario del proyecto
- Enunciado del Alcance del Proyecto
Hay dos categorías principales de
restricciones de tiempo que se tienen en cuenta durante el desarrollo del
cronograma:
- Las fechas impuestas para el inicio o la finalización de las actividades pueden usarse para restringir el inicio o la finalización a que se produzca no antes de una fecha especificada o no después de una fecha especificada.
- El patrocinador del proyecto, el cliente del proyecto u otros interesados a menudo determinan eventos clave o hitos principales que afectan a la finalización de ciertos productos entregables para una fecha específica.
- Lista de Actividades
- Atributos de la Actividad
- Diagramas de Red del Cronograma del Proyecto
- Requisitos de Recursos de las Actividades
- Calendarios de Recursos
- Estimaciones de la Duración de la Actividad
- Plan de Gestión del Proyecto Contiene el plan de gestión del cronograma, el plan de gestión de costes, el plan de gestión del alcance del proyecto y el plan de gestión de riesgos. Estos planes guían el desarrollo del cronograma.
-
Herramientas y Técnicas
- Análisis de la Red del Cronograma Emplea un modelo de cronograma y diversas técnicas analíticas, para calcular las fechas de inicio y finalización tempranas y tardías, y las fechas de inicio y finalización planificadas para las partes no completadas de las actividades del cronograma del proyecto
- Método del Camino Crítico Es una técnica de análisis que calcula las fechas de inicio y finalización tempranas y tardías teóricas para todas las actividades del cronograma, sin considerar las limitaciones de recursos.
- Compresión del Cronograma Acorta el cronograma del proyecto sin modificar el alcance del proyecto, para cumplir con las restricciones del cronograma, las fechas impuestas u otros objetivos del cronograma. Las técnicas de compresión del cronograma incluyen: Intensificación y Ejecución rápida.
- Análisis “¿Qué pasa si...?” Un análisis de la red del cronograma se realiza usando el modelo de cronograma para calcular diferentes escenarios, tales como la demora en la entrega de uno de los principales componentes, la ampliación de la duración de un diseño específico o la aparición de factores externos, como una huelga o un cambio en el proceso de permisos.
- Nivelación de Recursos Se usa para abordar las actividades del cronograma que deben realizarse para cumplir con fechas de entrega determinadas, para abordar situaciones en las que se dispone de recursos compartidos o críticos necesarios sólo en ciertos momentos o en cantidades limitadas, o para mantener el uso de recursos seleccionados a un nivel constante durante períodos específicos del trabajo del proyecto.
- Método de Cadena Crítica Combina los enfoques determinístico y probabilístico. Agrega colchones de duración que son actividades del cronograma no laborables, para mantener el enfoque en las duraciones de las actividades planificadas.
- Software de Gestión de Proyectos El software de gestión de proyectos para la elaboración de cronogramas se utiliza ampliamente para ayudar en el desarrollo del cronograma. Otros software pueden ser capaces de interactuar de forma directa o indirecta con el software de gestión de proyectos para llevar a cabo los requisitos de otras Áreas de Conocimiento, como la estimación de costes por período y la simulación del cronograma en el análisis cuantitativo de riesgos.
- Calendarios Aplicables Los calendarios del proyecto y los calendarios de recursos identifican los períodos en que se autoriza el trabajo
- Ajuste de Adelantos y Retrasos Como el uso inadecuado de adelantos o retrasos puede distorsionar el cronograma del proyecto, los adelantos o retrasos se ajustan durante el análisis de la red del cronograma para desarrollar un cronograma del proyecto viable.
- Modelo de Cronograma Se utilizan con métodos manuales o con software de gestión de proyectos para realizar el análisis de la red del cronograma a fin de generar el cronograma del proyecto.
-
Salidas
1
Cronograma del Proyecto
o Diagramas de red del cronograma del
proyecto
o Diagramas de barras
o Diagramas de hitos
2
Datos del Modelo de Cronograma
3
Línea Base del Modelo
4
Requisitos de Recursos (Actualizaciones)
5
Atributos de la Actividad (Actualizaciones)
6
Calendario del Proyecto (Actualizaciones)
7
Cambios Solicitados
8
Plan de Gestión del Proyecto (Actualizaciones)
Es una de las tareas más importantes que
puede tener el gerente de proyectos ya que es lo que puede marcar la diferencia
entre tener más rentabilidad con el proyecto o incluso determinar si el
proyecto es realizable o no, para esto el gerente debe tener claro lo siguiente
y así definir el costo de proyecto de la empresa Salud Total.
- TÉCNICA
Debemos definir que técnica aplicamos
- Estimación por analogía (top-down): Se calcula el coste del proyecto a partir del coste de otro similar. Suele emplearse cuando no se dispone de información suficientemente detallada del proyecto. Para ser efectiva, los proyectos previos deben ser similares de verdad, no solo en apariencia, y deben realizarla expertos. Esta estimación es menos fiable que otras técnicas.
- Estimación ascendente (bottom-up): Se estima el coste de paquetes de trabajo individuales, para después mediante agregación estimar el coste total del proyecto. Cuantos más pequeños sean los paquetes, más dificultad, pero mayor exactitud.
- Estimación por tres valores: Esos tres valores son el pesimista, optimista y más probable. Es igual que la técnica utilizada para los tiempos, PERT. Para calcular el coste se suma el coste pesimista más cuatro veces el probable más el optimista y se divide entre 6.
- DETERMINAR PRESUPUESTO
Al determinar el presupuesto podemos ver
el reparto del dinero a lo largo del tiempo de duración del proyecto. Eso nos
sirve para medir y supervisar la evolución de los costes a lo largo de la
realización del proyecto. Se calcula con los datos de estimación de costes de
todos los paquetes de trabajo, con la estructura de desglose de trabajo y con
el calendario del proyecto. Además, hay que tener en cuenta las reservas para
contingencia para controlar la aparición de posibles riesgos.
- CONTROLAR LOS COSTES
Una vez que ha comenzado el proyecto
tenemos que controlar los costes ya que no siempre se va gastando el dinero tal
y como planificamos. Para ello se realizan las siguientes actividades:
o Asegurarse de que los cambios solicitados
sean acordados
o Gestionar los cambios reales cuando y a
medida que se produzcan
o Asegurar que los posibles sobrecostes no
excedan la financiación autorizada periódica y total para el proyecto
o Realizar el seguimiento del rendimiento
del coste para detectar y entender las variaciones con respecto a la línea base
de coste
o Registrar todos los cambios pertinentes
con precisión en la línea base de coste
o Evitar que se incluyan cambios no
aprobados en informes sobre costos o uso de recursos
o Informar a los interesados sobre los
cambios aprobados
o Actuar para mantener los sobrecostes
esperados dentro de límites aceptables.
La técnica más utilizada para controlar
los costes es la técnica del valor ganado (Earned Value Technique). Se basa en
comparar lo planificado con los resultados reales (lo realmente terminado).
Para ello tenemos tres indicadores:
- Valor planificado (PV): Valor que debería tener según la planificación
- Coste real (AC): Lo que hemos gastado
- Valor ganado (EV): Valor que tiene el trabajo realmente completado
Al aplicar la técnica obtenemos
resultados que nos indican desviaciones potenciales en el coste y en el
cronograma.
- Variación del cronograma (SV): SV = EV – PV
- Variación del coste (CV): CV = EV – AC
Además, esta técnica nos proporciona unos
índices que nos permiten ver la situación del proyecto, son el SPI = EV/PV y el
CPI = EV/AC
o Por debajo del presupuesto y por encima
del calendario (gasta más para avanzar). Esta situación se da cuando el CPI es
mayor que 1 y el SPI es menor que 1
o Por encima en presupuesto y por debajo en
calendario (reduce ritmo para ahorrar dinero). Esta situación se da cuando el CPI es
menor que 1 y el SPI es mayor que 1.
o Por debajo en presupuesto y calendario
(caso óptimo).
Esta situación se da cuando ambos índices son mayores que 1.
o Por encima en presupuesto y calendario
(peor caso).
Esta situación se da cuando ambos índices son menores que 1.
GESTIÓN DE RIESGOS
Este es un proceso que el gerente de
proyectos debe tener muy claro y de tener una buena comunicación con su equipo
de desarrolladores porque esta gestión se debe llevar a cabo en todo proyecto
de desarrollo de software para que el mismo sea exitoso. Lo que se desea con
esta gestión es crear planes que tiendan a impedir que los riesgos se
conviertan en problemas o que estos tengan una mínima ocurrencia o impacto.
En este modelo de gestión hay 4 etapas o
procesos que son: identificación, análisis, planificación y supervisión y
control de riesgos.
En la identificación de los riesgos se
debe tener mucha disciplina y consistencia para clasificar los componentes
principales, así como los tipos y categorías de riesgos más importantes
En el análisis se deben trasformar los
datos obtenidos en tomas de decisiones, estimación de probabilidad de
ocurrencia y el impacto de cada uno de los riesgos.
En la planificación se tomará la
información relacionada con los riesgos para transformarlos en decisiones y
acciones presentes y futuras. Aquí se debe tener estrategias de:
Eliminación, transferencia, mitigación y
aceptación.
Dichas estrategias servirán para que los
riesgos cada vez sean menores en el proyecto del diseño de software para la
empresa Salud Total.
En la supervisión y control de riesgos el
proceso que se lleva es el de controlar que los planes de riesgo son ejecutados
por los responsables asignados. Se debe estar monitoreando para evitar la
aparición de nuevos riesgos.
Registro de
Riesgos
Riesgo
|
Causa
|
Probabilidad
|
Descripción Probabilidad
|
Impacto
|
Descripción Impacto
|
|||
En lo económico
|
En la disponibilidad de los servicios
|
Reproceso (recuperación de información)
|
Efectos generales de todas las amenazas
|
|||||
Daño a la información
|
Manipulación inadecuada del
software
|
Remota
|
Podría ocurrir
|
Alto
|
Incremento
de costos entre 10 – 20%
|
Entre
1 y 3 días
|
Entre
5 y 7 días
|
Detrimento del patrimonio de la entidad
|
Fallas de software
|
Falta de pruebas en el software
|
probable
|
Podría ocurrir
|
Alto
|
Incremento
de costos entre 10 – 20%
|
Entre
1 y 3 días
|
Entre
5 y 7 días
|
Detrimento del patrimonio de la entidad
|
Pérdida de datos
|
Falta de control y seguridad
|
Ocasional
|
Puede ocurrir algunas veces
|
Medio
|
Incremento de costos entre 5 –
10%
|
Entre 4 y 8 horas
|
Entre 3 y 5 días
|
Alteración de la información
|
Falta de pruebas de software
nuevo con datos productivos
|
No hay Comunicación entre al
área de desarrollo y el de pruebas
|
Probable
|
Podría ocurrir
|
Medio
|
Incremento de costos entre 5 –
10%
|
Entre 4 y 8 horas
|
Entre 3 y 5 días
|
Alteración de la información
|
Fuga de la información
|
Falta de seguridad informática
|
Ocasional
|
Puede ocurrir algunas veces
|
Medio
|
Incremento de costos entre 5 –
10%
|
Entre 4 y 8 horas
|
Entre 3 y 5 días
|
Alteración de la información
|
Mal manejo de los sistemas y
herramientas informáticas
|
Falta de conocimiento de la
herramienta. Manuales de usuario
|
Ocasional
|
Puede ocurrir algunas veces
|
Medio
|
Incremento de costos entre 5 –
10%
|
Entre 4 y 8 horas
|
Entre 3 y 5 días
|
Pérdida de imagen / credibilidad
|
No disponibilidad de la
información
|
Daño en el software.
Infraestructura
|
Ocasional
|
Puede ocurrir algunas veces
|
Medio
|
Incremento de costos entre 5 –
10%
|
Entre 4 y 8 horas
|
Entre 3 y 5 días
|
Peculado
|
Rotación del personal
|
Condiciones laborales poco
favorables.
|
Ocasional
|
Puede ocurrir algunas veces
|
Medio
|
Incremento de costos entre 5 –
10%
|
Entre 4 y 8 horas
|
Entre 3 y 5 días
|
Peculado
|
CONTROLES
DE LOS RIESGOS
AMENAZAS / VULNERABILIDADES
|
CONTROLES EXISTENTES
|
Ponderación controles
|
||||||
Nombre
|
Tipo
|
Probabilidad
|
Impacto
|
Afecta la probabilidad
|
Afecta el impacto
|
|||
Daño a la información
|
Copias de respaldo de la
información
|
Ambos
|
80
|
Remota
|
80
|
Medio
|
30
|
20
|
Capacitación manejo software
|
Ambos
|
30
|
20
|
|||||
Controlar acceso a la
información de desarrollo
|
Ambos
|
20
|
30
|
|||||
Control de virus y software
malicioso
|
Ambos
|
La eventualidad de ocurrencia es muy baja, casi nula
|
Sobre la imagen: Ante entidades
del nivel central. En lo económico: Incremento de costos entre 5 – 10%. En la disponibilidad de los servicios:
Entre 4 y 8 horas. Reproceso (recuperación de información): Entre 3 y 5 días
|
20
|
30
|
|||
Fallas de software
|
Documentación
|
Ambos
|
80
|
Remota
|
80
|
Muy bajo
|
20
|
|
Copias de respaldo del
desarrollo del software
|
Ambos
|
40
|
50
|
|||||
Monitoreo de servicios
|
Ambos
|
20
|
30
|
|||||
Ejecución de Pruebas
|
Ambos
|
La eventualidad de ocurrencia es muy baja, casi nula
|
Sobre la imagen: Ante personal que interactúa en el proceso. En lo
económico: Sobre costos insignificantes. En la disponibilidad de los
servicios: < 2 horas. Reproceso (recuperación de información): < 1 día
|
5
|
20
|
|||
Ayuda para reporte de las
irregularidades.
|
Afecta probabilidad
|
Aceptable
|
15
|
|||||
Pérdida de datos
|
Copias de respaldo
|
Afecta probabilidad
|
80
|
Poco probable
|
80
|
Bajo
|
60
|
|
Copias de cada despliegue por
versión y fecha de publicación
|
Ambos
|
Podría ocurrir sólo bajo circunstancias muy excepcionales
|
Sobre la imagen: Ante áreas de la Entidad. En lo económico: Incremento
costos < 5%. En la disponibilidad de los servicios: Entre 2 y 4 horas.
Reproceso (recuperación de información): Entre 1 y 2 días
|
40
|
100
|
|||
Tolerable
|
||||||||
Falta de pruebas de software nuevo con datos productivos
|
Control de Cambios (formato)
|
Afecta impacto
|
80
|
Remota
|
80
|
Medio
|
30
|
|
Control de versiones
|
Afecta probabilidad
|
30
|
||||||
Documentación y código fuente
|
Ambos
|
40
|
40
|
|||||
Ejecución de Pruebas
|
Ambos
|
La eventualidad de ocurrencia es muy baja, casi nula
|
Sobre la imagen: Ante entidades
del nivel central. En lo económico: Incremento de costos entre 5 – 10%. En la disponibilidad de los servicios:
Entre 4 y 8 horas. Reproceso (recuperación de información): Entre 3 y 5 días
|
30
|
30
|
|||
Aceptable
|
||||||||
Fuga de la información
|
Control de acceso
|
Afecta impacto
|
80
|
Poco probable
|
80
|
Muy bajo
|
60
|
40
|
control de sesiones inactivas
|
Afecta probabilidad
|
40
|
60
|
|||||
Podría ocurrir sólo bajo circunstancias muy excepcionales
|
Sobre la imagen: Ante personal que interactúa en el proceso. En lo
económico: Sobre costos insignificantes. En la disponibilidad de los
servicios: < 2 horas. Reproceso (recuperación de información): < 1 día
|
|||||||
Aceptable
|
||||||||
Mal manejo de los sistemas y herramientas informáticas
|
Documentación
|
Ambos
|
80
|
Poco probable
|
88
|
Muy bajo
|
20
|
40
|
Contactos técnico y funcional
al interior del DNP
|
Ambos
|
20
|
||||||
Manual y Políticas de Seguridad
definidas y revisadas periódicamente
|
Ambos
|
40
|
20
|
|||||
Capacitaciones / transferencia
de conocimientos
|
Ambos
|
Podría ocurrir sólo bajo circunstancias muy excepcionales
|
Sobre la imagen: Ante personal que interactúa en el proceso. En lo
económico: Sobre costos insignificantes. En la disponibilidad de los
servicios: < 2 horas. Reproceso (recuperación de información): < 1 día
|
40
|
30
|
|||
Aceptable
|
||||||||
No disponibilidad de la información
|
Cambio de contraseña
predefinidas de fabrica
|
Ambos
|
216
|
Remota
|
80
|
Bajo
|
20
|
40
|
Existencias de políticas
|
Ambos
|
220
|
10
|
|||||
Actualizar periódicamente
información de los usuarios
|
Afecta probabilidad
|
20
|
10
|
|||||
Manual y Políticas de Seguridad
definidas y revisadas periódicamente
|
Ambos
|
La eventualidad de ocurrencia es muy baja, casi nula
|
Sobre la imagen: Ante áreas de la Entidad. En lo económico: Incremento
costos < 5%. En la disponibilidad de los servicios: Entre 2 y 4 horas.
Reproceso (recuperación de información): Entre 1 y 2 días
|
10
|
40
|
|||
Aceptable
|
||||||||
Rotación del personal
|
Capacitación
|
Ambos
|
80
|
Poco probable
|
80
|
Medio
|
50
|
50
|
Manual y Políticas de Seguridad
definidas y revisadas periódicamente
|
Podría ocurrir sólo bajo circunstancias muy excepcionales
|
Sobre la imagen: Ante entidades
del nivel central. En lo económico: Incremento de costos entre 5 – 10%. En la disponibilidad de los servicios:
Entre 4 y 8 horas. Reproceso (recuperación de información): Entre 3 y 5 días
|
50
|
50
|
||||
Tolerable
|
||||||||
Se realizó un control de los posibles
riesgos que se pueden tener en la empresa Salud Total en cuanto al desarrollo
del software.
En esta tabla se hace un comparativo de
cómo se mitigarían los posibles riesgos en el desarrollo del software en la
organización Salud Total.
Amenaza
|
ANTES DE CONTROLES
|
DESPUES DE CONTROLES
|
||
Probabilidad
|
Impacto
|
Probabilidad
|
Impacto
|
|
Daño de la información
|
Remota
|
Alto
|
Remota
|
Medio
|
Fallas de software
|
probable
|
Alto
|
Remota
|
Muy bajo
|
Pérdida de datos
|
Ocasional
|
Medio
|
Poco probable
|
Bajo
|
Falta de pruebas de software
nuevo con datos productivos
|
Probable
|
Medio
|
Remota
|
Medio
|
Mal manejo de los sistemas y herramientas
informáticas
|
Ocasional
|
Medio
|
Poco probable
|
Muy bajo
|
No disponibilidad de la
información
|
Ocasional
|
Medio
|
Poco probable
|
Bajo
|
Rotación del personal
|
Ocasional
|
Medio
|
Poco probable
|
Medio
|
Para todo lo que abarca el
seguimiento de un proyecto y su estricta coordinación en su ciclo de vida, es
de suma importancia tener en cuenta aspectos fundamentales para su gestión a
desarrollar, donde se garantizara que su implementación este acorde con todos
los requisitos propuestos por las personas involucradas, en este caso los
clientes o usuarios, donde en este proyecto se encontrara unos pasos
elementales para todo el plan de gestión en su implementación y mantenimiento
del mismo, ejecutados por unos procedimientos que serán aplicados y modificados
al trascurrir su ciclo de vida mostrando los diversos procesos, técnicas y
herramientas que los planes de gestión nos entregan.
La importancia que tiene un
plan de gestión se centra en sus fases o características que son implementadas,
las cuales determinan el alcance del proyecto, sus actividades, los recursos a
usar, costos, riesgos y contratos donde su calidad es primordial con todo lo
que es vinculado al proyecto. Para su elaboración o construcción se debe tener
en cuenta diversos elementos que son muchas veces encontrados en las empresas y
que son el fundamento a seguir con un proyecto, entre ellos está los factores
que rodean la organización y algunos procesos directivos que constituyen toda
la gestión de un proyecto.
Un proyecto es la constante
que ensambla todo lo requerido en los términos legales y organizacionales
apoyados totalmente por su dirección para así determinar que conceptos deben ir
documentados en su camino, con el fin de poder asimilar cada proceso que se
efectúa a lo largo de su desarrollo, por eso su gestión se desglosa con sus
costos, alcance y la gestión de la integración en todo su proceso.
Referencias
- Hernández Sampieri, Roberto. 2008.
Metodología de la investigación. DF, México. Cuarta
edición. Recuperado de: http://datateca.unad.edu.co/contenidos/201014/2015-2/SAMPIERI.pdf
- Ramirez Gonzalez, Alberto. 2006.
Metodología de la investigación Científica. Bogotá. Recuperado de: http://www.javeriana.edu.co/ear/ecologia/documents/ALBERTORAMIREZMETODOLOGIADELAINVESTIGACIONCIENTIFICA.pdf
- Reconocimiento de la Unidad II. Recuperado
de: http://datateca.unad.edu.co/contenidos/201014/2015-1/RECONOCIMIENTO_UNIDAD_2.pdf

