universidad de guayaquilrepositorio.ug.edu.ec/bitstream/redug/36599/1/b-cisc-ptg... ·...
TRANSCRIPT
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
Procedimiento, análisis y desarrollo de un sistema de control de versiones distribuidas, sobre las
base de datos del Sistema PROMEINFO.
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR:
Victoria De Lourdes García Velásquez
TUTOR:
Ing. Alexandra Varela
GUAYAQUIL – ECUADOR
2015
Llenar esta hoja con toda la información necesaria
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGIA
FICHA DE REGISTRO DE TESIS
TITULO: “ Procedimiento, análisis y desarrollo de un sistema de control de versiones distribuidas, sobre las base de datos del Sistema PROMEINFO”
REVISORES: Ing. Bernardo Iñiguez Ing. Luis Arias
INSTITUCION: Universidad de Guayaquil
FACULTAD: Ciencias Matemáticas y Físicas
CARRERA: Ingeniería en Sistemas Computacionales
FECHA DE PUBLICACION: Nº DE PAGS: 144
AREA TEMATICA: Procedimiento, Análisis y Desarrollo.
PALABRAS CLAVES: procedimiento, análisis, desarrollo, control y distribuida.
RESUMEN:
Nº DE REGISTRO: Nº DE CLASIFICACION
Nº DIRECCION URL: ADJUNTO PDF:
SI NO
CONTACTO DE AUTOR:
Teléfono: 0969131098
E-mail: [email protected]
CONTACTO CON LA INSTITUCIÓN:
Nombre: Universidad de Guayaquil
Teléfono:2307729
(PROYECTO DE TITULACION EN LA WEB) (PROYECTO DE TITULACION EN LA WEB)
X
APROBACION DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “PROCEDIMIENTO, ANÁLISIS Y
DESARROLLO DE UN SISTEMA DE CONTROL DE VERSIONES
DISTRIBUIDAS, SOBRE LAS BASE DE DATOS DEL SISTEMA
PROMEINFO“ elaborado por la Sra.
Victoria de Lourdes García Velásquez, Alumno no titulado de la Carrera de
Ingeniería en Sistemas Computacionales de la Facultad de Ciencias Matemáticas y
Físicas de la Universidad de Guayaquil, previo a la obtención del Título de Ingeniero en
Sistemas, me permito declarar que luego de haber orientado, estudiado y revisado, la
Apruebo en todas sus partes.
Atentamente
Ing. Alexandra Varela
TUTOR
DEDICATORIA
Este trabajo está dedicado a
Dios quien en todo momento no
se separó de mí dándome
siempre lo necesario para seguir
adelante como la sabiduría y
capacidad física e intelectual, por
siempre responder a mis
oraciones y la de mi hermosa
madre, a quien también le dedico
este trabajo por su confianza en
mí junto a mi padre me han
sostenido a lo largo de este
arduo camino.
También dedico este trabajo a mi
esposo y mi hijo quienes me dan
fuerzas cuando ya casi se me
agotan, y por supuesto a mis
queridos maestros y amigos que
a lo largo del camino he
encontrado y quienes me han
apoyado a cumplir este sueño,
por cada aporte moral y empuje
a alcanzar mis metas.
AGRADECIMIENTO
Agradezco a la Universidad de
Guayaquil por la oportunidad que
me ha brindado, al abrirme las
puertas de esta faculta para
permitirme cumplir con esta meta
que se culmina con este
proyecto.
A mis padres, familiares, amigos,
profesores, y personas que Dios
puso en mi camino a lo largo de
esta carrera para que sean pilar
fundamental dentro de este
sueño que culmina siendo una
realidad rotunda y exitosa.
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, M.Sc.
DECANO DE LA FACULTAD
CIENCIAS MATEMATICAS Y FISICAS
Ing. Inelda Martillo Alcívar, Mgs
DIRECTORA
CISC, CIN
Nombres y Apellidos
DIRECTOR DEL PROYECTO DE
TITULACIÓN
Nombre y Apellidos
PROFESOR DEL ÁREA – TRI BUNAL
Ab. Juan Chávez A.
SECRETARIO
1
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”
Victoria de Lourdes García Velásquez
2
.
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
PROCEDIMIENTO, ANÁLISIS Y DESARROLLO DE
UN SISTEMA DE CONTROL DE VERSIONES
DISTRIBUIDAS, SOBRE LAS BASE DE
DATOS DEL SISTEMA PROMEINFO.
Proyecto de Titulación que se presenta como requisito para optar por el título de
INGENIERO EN SISTEMAS COMMPUTACIONALES
Autora: Victoria de Lourdes García Velásquez
C.I. 0924906126
Tutor: Ing. Alexandra Varela
Guayaquil, Diciembre del 2015
I
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por la estudiante VICTORIA DE LOURDES GARCIA VELASQUEZ, como requisito previo para optar por el título de Ingeniero en Sistemas Computacionales cuyo problema es:
PROCEDIMIENTO, ANÁLISIS Y DESARROLLO DE UN SISTEMA DE CONTROL DE VERSIONES DISTRIBUIDAS, SOBRE LAS BASE DE DATOS DEL SISTEMA PROMEINFO.
Considero aprobado el trabajo en su totalidad.
Presentado por:
Victoria de Lourdes García Velásquez Cédula de ciudadanía N° 0924906126
Tutor: Ing. Alexandra Varela
Guayaquil, Diciembre de 2015
II
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN SISTEMAS
Autorización para Publicación de Proyecto de Titulación en Formato Digital
1. Identificación del Proyecto de Titulación
Nombre Alumno: Victoria García Velásquez
Dirección: 24 # 1504 y Venezuela
Teléfono: 2473797 - 0969131098 E-mail: [email protected]
Facultad: Ciencias Matemáticas y Físicas
Carrera: Ingeniería en sistemas computacionales
Proyecto de titulación al que opta: Ingeniera en sistemas computacionales
Profesor tutor: Ing. Alexandra Varela
Título del Proyecto de titulación: PROCEDIMIENTO, ANÁLISIS Y DESARROLLO DE UN SISTEMA DE CONTROL DE VERSIONES DISTRIBUIDAS, SOBRE LAS BASE DE DATOS DEL SISTEMA PROMEINFO
Tema del Proyecto de Titulación: (Palabras claves 5 a 8 ) Procedimiento, análisis, desarrollo, control, distribuida.
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación. Publicación electrónica:
Inmediata X Después de 1 año
Firma Alumno: Victoria García Velásquez C.I.0924906126
III
INDICE GENERAL
DEDICATORIA ............................................................................................................................ IV
AGRADECIMIENTO ..................................................................................................................... V
CERTIFICADO DE ACEPTACIÓN DEL TUTOR ...................................................................... I
RESUMEN ...................................................................................................................................... X
ABSTRACT ................................................................................................................................ XIII
INTRODUCCIÓN ............................................................................................................................ 1
C AP I T U L O I .............................................................................................................................. 1
1 . 1 EL PROBLEMA ............................................................................................................ 1
1.1.1 PLANTEAMIENTO DEL PROBLEMA........................................................................ 1
1.2 Situación Conflicto Nudos Críticos ............................................................................. 2
1.3 Causas y Consecuencias del Problema .................................................................... 3
1.4 Delimitación del Problema ........................................................................................... 4
1.5 Formulación del Problema ........................................................................................... 4
1.6 Evaluación del Problema ............................................................................................. 5
1.7 OBJETIVOS ................................................................................................................... 7
1.7.1 OBJETIVO GENERAL .............................................................................................. 7
1.7.2 OBJETIVOS ESPECÍFICOS ...................................................................................... 7
1.8 ALCANCES DEL PROBLEMA .................................................................................... 7
1.9 JUSTIFICACIÓN E IMPORTANCIA ......................................................................... 8
1.10 METODOLOGÍA DEL PROYECTO: ......................................................................... 9
1.10.1 Aplica a proyecto tecnológico funcional: ........................................................ 9
Supuestos y Restricciones .............................................................................................. 10
Plan de Calidad (Pruebas a realizar) ................................................................................. 11
CAPÍTULO II ................................................................................................................................. 12
2.1 MARCO TEÓRICO ..................................................................................................... 12
2.2 FUNDAMENTACIÓN TEÓRICA ............................................................................... 14
2.2.1 Herramientas tecnológicas......................................................................................... 14
2.2.2 Ingenieria de Software ............................................................................................... 17
2.2.3 Seguridad informática ............................................................................................... 22
2.2.4 Bases de Datos .......................................................................................................... 27
2.2.5 Sistemas de control de versiones ............................................................................... 32
2.2.6 Herramientas de Sistemas de control de versiones .................................................... 38
IV
1.2 FUNDAMENTACIÓN LEGAL .................................................................................... 50
2.2.7 CAPÍTULO V.- DE LA GESTIÓN DEL RIESGO OPERATIVO () ....................... 50
2.2.8 SECCIÓN II.- FACTORES DEL RIESGO OPERATIVO ....................................... 52
2.2.9 LEY DE PROPIEDAD INTELECTUAL ................................................................. 59
2.2.10 DE LOS DERECHOS DE AUTOR Y DERECHOS CONEXOS ....................... 59
2.2.11 DISPOSICIONES ESPECIALES SOBRE CIERTAS OBRAS PARÁGRAFO
PRIMERO DE LOS PROGRAMAS DE ORDENADOR .................................................. 63
2.3 PREGUNTA CIENTÍFICA A CONTESTARSE ...................................................... 65
2.4 DEFINICIONES CONCEPTUALES ......................................................................... 65
CAPÍTULO III ................................................................................................................................ 70
3.1 PROPUESTA TECNOLÓGICA ................................................................................ 70
3.1.1 Análisis de factibilidad ........................................................................................ 70
3.1.2 Factibilidad Operacional ..................................................................................... 70
3.1.3 Factibilidad técnica .............................................................................................. 71
3.1.4 Factibilidad Legal ................................................................................................. 72
3.1.5 Factibilidad Económica ...................................................................................... 72
3.2 Etapa de la metodología del desarrollo .............................................................. 73
Comandos para el manejo de Git ......................................................................................... 78
3.3 Entregables del proyecto ........................................................................................ 79
3.4 CRITERIOS DE VALDACIÓN DE LA PROPUESTA ........................................... 79
CAPÍTULO IV ................................................................................................................................ 90
4.1 Criterios de aceptación del producto o Servicio .............................................. 90
4.2 Análisis de la evaluación de riesgo ..................................................................... 92
4.3 Matriz de criterios de Aceptación y Aseguramiento del Proyecto de
Titulación .................................................................................................................................. 93
BIBLIOGRAFIA............................................................................................................................. 94
ANEXOS ........................................................................................................................................ 96
V
ABREVIATURAS ABP Aprendizaje Basado en Problemas UG Universidad de Guayaquil FTP Archivos de Transferencia g.l. Grados de Libertad Html Lenguaje de Marca de salida de Hyper Texto http Protocolo de transferencia de Hyper Texto Ing. Ingeniero CC.MM.FF Facultad de Ciencias Matemáticas y Físicas ISP Proveedor de Servicio de Internet Mtra. Maestra Msc. Master URL Localizador de Fuente Uniforme www world wide web (red mundial)
SIMBOLOGÍA
s Desviación estándar e Error E Espacio muestral E(Y) Esperanza matemática de la v.a. y s Estimador de la desviación estándar e Exponencial
VI
INDICE DE ILUSTRACIÓN
Ilustración 1 Ciclo de vida y límites del proyecto .................................................. 9
Ilustración 2 Pruebas de integración .................................................................. 11
Ilustración 3 ....................................................................................................... 14
Ilustración 4 Los procesos macro en una cadena de suministro. ....................... 15
Ilustración 5 Proceso de Ingeniería de Software ................................................ 17
Ilustración 6 Capas de la Ingeniería de Software ............................................... 19
Ilustración 7 Ciclo de vida de un Sotfware ......................................................... 21
Ilustración 8 Protección...................................................................................... 22
Ilustración 9 Triangulo de las Seguridades ........................................................ 23
Ilustración 10 Gestión de Riesgo ....................................................................... 25
Ilustración 11 Proceso de Control de Cambios ................................................. 26
Ilustración 12 Modelo de Base de datos ............................................................ 27
Ilustración 13 Diagrama de control de versiones local. ...................................... 33
Ilustración 14 Diagrama de control de versiones centralizado............................ 34
Ilustración 15 Forma de trabajo centralizado en un repositorio. ......................... 35
Ilustración 16 Representación DVCS ................................................................. 36
Ilustración 17 Sistemas de Control de Versiones Distribuidas............................ 37
Ilustración 18 Interfaz Bazaar ............................................................................ 38
Ilustración 19 Arquitectura Subversion ............................................................... 40
Ilustración 20 Otros sistemas tienden a almacenar los datos como cambios de
cada archivo respecto a una versión base ......................................................... 41
Ilustración 21 Git almacena la información como instantáneas del proyecto a lo
largo del tiempo ................................................................................................. 42
Ilustración 22 Los Estados De Git ...................................................................... 44
Ilustración 23 Modelado del proyecto ................................................................. 77
Ilustración 24 Encuesta del control de Versiones Distribuidas Pregunta #2 ....... 80
Ilustración 25 Encuesta del control de Versiones Distribuidas Pregunta #2 ....... 81
Ilustración 26 Encuesta del control de Versiones Distribuidas Pregunta # 3 ...... 82
Ilustración 27 Encuesta del control de Versiones Distribuidas Pregunta # 4 ...... 83
Ilustración 28 Encuesta del control de Versiones Distribuidas Pregunta #5 ....... 84
Ilustración 29 Encuesta del control de Versiones Distribuidas Pregunta #6 ....... 85
VII
Ilustración 30 Encuesta del control de Versiones Distribuidas ........................... 86
Ilustración 31 Encuesta del control de Versiones Distribuidas ........................... 87
Ilustración 32 Encuesta del control de Versiones Distribuidas ........................... 88
Ilustración 33Encuesta del control de Versiones Distribuidas Pregunta #10 ...... 89
Ilustración 34 Activos de la ISO 27001 .............................................................. 91
Ilustración 35 Análisis y Evaluación de riesgo .................................................... 92
VIII
INDICE DE TABLAS
Tabla 1 Cusas y consecuencias del problema ..................................................... 3
Tabla 2 Supuestos y Restricciones del proyecto ................................................ 10
Tabla 3 Análisis de Herramientas de control de versiones. ................................ 47
Tabla 4 Interfaces para Git ................................................................................ 48
Tabla 5 Requerimientos para cliente Git ............................................................ 49
Tabla 6 Factibilidad técnica del proyecto ........................................................... 71
Tabla 7 Factibilidad Económica Costo-Beneficios .............................................. 72
Tabla 8 comandos de instalación y configuración .............................................. 78
Tabla 9 Pruebas de integración del aplicativo ............................................... 79
Tabla 10 Encuesta del control de Versiones Distribuidas Pregunta #1 .............. 80
Tabla 11 Encuesta del control de Versiones Distribuidas Pregunta #2 .............. 81
Tabla 12 Encuesta del control de Versiones Distribuidas Pregunta #3 .............. 82
Tabla 13 Encuesta del control de Versiones Distribuidas Pregunta # 4 ............. 83
Tabla 14 Encuesta del control de Versiones Distribuidas Pregunta # 5 ............. 84
Tabla 15 Encuesta del control de Versiones Distribuidas Pregunta #6 .............. 85
Tabla 16 Encuesta del control de Versiones Distribuidas Pregunta #7 .............. 86
Tabla 17 Encuesta del control de Versiones Distribuidas Pregunta #8 .............. 87
Tabla 18 Encuesta del control de Versiones Distribuidas Pregunta #9 .............. 88
Tabla 19 Encuesta del control de Versiones Distribuidas Pregunta # 10 ........... 89
Tabla 20 Matriz de criterio de Aceptación. ......................................................... 93
IX
INDICE DE ANEXOS
ANEXO 1Cronograma de actividades ....................................................................................... 97
ANEXO 2 Grupo de procesos de dirección de proyecto ........................................................ 99
ANEXO 3 Plan de Gestión de Proyecto .................................................................................. 100
ANEXO 4 Requerimiento del proyecto .................................................................................... 102
ANEXO 5 Plan de gestión de alcances ................................................................................... 103
ANEXO 6 PLAN DE RECURSO HUMANO ............................................................................ 104
ANEXO 7 Plan de Gestión interesados .................................................................................. 105
ANEXO 8 Preguntas y cálculo de respuesta de la encuesta realizada ............................. 100
ANEXO 9 Análisis y Evaluación de Riesgo .......................................................................... 104
ANEXO 10 Control de Riesgo ISO 27001 ............................................................................. 107
ANEXO 11 INFORME DE METRICAS DE CALIDAD ........................................................... 109
X
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Procedimiento, análisis y desarrollo de un sistema de
control de versiones distribuidas, sobre las base de
datos del Sistema PROMEINFO.
Autor: Victoria García Velásquez Tutor: Ing. Alexandra Varela
XI
RESUMEN
En estos tiempos de constantes cambios y agíl utilización de las tecnologias, se
necesita herramientas que contribuyan al trabajo de respaldo a diario, que
permita tener la informacion de inmediato al mismo tiempo que la mantendra
segura y con posibilidades de realzar un retorno a la versión anterior.Esta
herrmienta que sera implementada para PROMEINFO, quienes no cuentan con
control de cambios de versiones, backup y menos historial de los proyecto, lo
cual permite la existencia de este proyecto de titulación, para el cual se propone
un producto open source que nos brinda lo que se busca de una herrmienta de
control de versiones distribuidas.
Estos sistemas de control de versiones no solo brinda la posibilidad de control de
versiones, va mas allá pues permite estar siempre actualizado con los proyectos
relacionados a la institución. Como alcance en general. Uno de los alcances
principales es dejar establecidos repositorios centrales dentro de un servidor de
aplicaciones y al ser un sistema de control distribuidas no se necesita de
conexion para seguir avanzando de manera independiente lo cual permitira que
no cause retraso entre desarrolladores, adicional se necesita manejar el
concepto de control de versión y para ello lo que se necesita es que cada
recurso cuente con la herramienta y el ambiente de desarrollo de manera
individual para que puedan continuar con las tareas
Este proceso garantiza el tabajo de manera distribuida ahorrando en tiempo de
cada uno de los proyecto ademas de estar organizados y esta herramienta
mantiene las mas altas seguridades y es confiable dentro de las auditorias ya
que este sistema no permite modificaciones luego de cofirmado el cambio.
Por medio de la metodologia se mostrara lo factible que del proyecto y las Iso
27001 nos asegura la seguridades ante los posibles riesgos y poder mitigarlos o
mejor aun evitarlos.
XII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Procedure, analysis and development of a
distributed control system versions, on
PROMEINFO database system.
Author: Victoria García Velásquez Tutor: Ing. Alexandra Varela
XIII
ABSTRACT
In these times of constant change and agile use of technologies, tools that
contribute to the daily backup job, that allows to have information immediately at
the same time needs to secure and enhance chances of a return to the previous
version will keep .This Supplied tools that will be implemented to PROMEINFO,
who do not have versions change control, backup and less history of the project,
allowing the existence of titling project, for which a proposed open source product
that gives us which is seeking a Supplied tools for distributed version control.
These version control systems not only provides the ability to version control,
goes beyond by allowing stay current with projects related to the institution. As a
general scope. One of the main achievements is to leave established central
repositories within an application server and being a distributed system control is
not needed Connection to move forward independently which allow it does not
delay between developers, additional handling is required version control concept
and to do what is required is that each resource has the tools and the
development environment individually so they can continue working,
This process ensures the toil of distributed manner saving time each of the
project in addition to being organized and this tool maintains the highest
Securities and reliable part of the audits as this system does not permit co-signed
amendments after the change.
Through the methodology that the project feasible and ISO 27001 assures us the
assurances to the potential risks and to mitigate or avoid them even better show.
1
INTRODUCCIÓN
En la actualidad en los departamentos de informática se debe contar con una
organización que apunte hacia la perfección en cuanto a lo que se trate de
salvaguardar la información al momento de comenzar a desarrollar. El contar con
la organización aportara con el buen desempeño de los trabajos a realizar y
posteriores.
Como sabemos en el mundo de la tecnología siempre está en constante
evolución, por la búsqueda de las mejoras para competir en el mundo moderno,
la disponibilidad durante el ciclo de vida del proyecto no debe interponerse entre
las mejoras y el confort, es ahí cuando empieza a los debidos cambios a realizar,
para actualizarse.
Es donde entra la necesidad de contar con una herramienta de control de
cambios, la cual nos podrá mantener siempre conectados con los cambios
realizados diariamente, esta herramienta permitirá que no exista error alguno
que no podamos solo regresarlo a una versión funcional, esta también nos
permitirá mantenernos un historial a la mano de los cambios o cualquier
actividad realizada.
Con el crecimiento de las empresas la necesidad de llevar este tipo de control es
mucho más necesaria y es el caso de POMEINFO, los mismos que cada vez
tienen cambios en sus proyectos pero no cuentan con tal historial, para lo cual s
ha desarrollado este completo trabajo de titulación detallados en 4 capítulos, en
los cuales se describen paso a paso las diferentes etapas antes de la
implementación de la herramienta.
1
CAPITULO I
1.1 EL PROBLEMA
1.1.1 PLANTEAMIENTO DEL PROBLEMA
Ubicación del Problema en un Contexto
Durante el año 2014 y lo que va del 2015 se ha venido desarrollando un
sistemas de información para un hospital, como parte de este proyecto se ha
investigado en las seguridades, protocolos y procedimientos del sistemas y se ha
notado que el sistema no cuenta con una herramienta que le proporcione
mecanismos de almacenamientos de los elementos que se deban gestionar,
tampoco cuenta con la posibilidad de realizar cambios sobre los elementos
almacenados y además no existe un registro histórico de las acciones realizas
como por ejemplo volviendo a un estado anterior después de haber realizado un
cambio que no haya sido favorable para el sistema.
Notando esta falencia en el sistema se expone la necesidad de realizar un
sistema de control de versiones distribuidas para mejorar los puntos antes
mencionados, sin interrumpir los procesos actuales de los sistemas y muchos
menos el trabajo del grupo por cual se propone un sistema distribuido que
permita trabajar a la par y sin que necesariamente un cambio en algún modulo
no afecten a todo el grupo de trabajo.
Antes de la masificación de los sistemas de control de versiones, se
solían guardar los hitos (una especie de versión) del proyecto en
archivos comprimidos y medios de almacenamiento como diskettes y
CD’s. ¿Se imaginan lo insostenible que resultaba esta práctica en
proyectos de gran envergadura? Los sistemas de control de
versiones nacen de la necesidad de solventar y facilitar este tedioso
proceso. (Hipertextual SL, 2005).
Los retraso en el proceso de producción a la entrada de nuevos grupos de
trabajos, nacen justamente por la falta de documentación, orden en procesos y
2
lugares de repositorios, los ajustes sin control, de los innumerables cambios de
versiones en los sistemas, la falta de historial como respaldo, al realizarse la
integración de nuevos recursos al proyecto con poco o nada de información
pasada o simplemente para los lideres o dueños del proyecto que necesitan
tener evidencia de los eventos ocurridos sobre el sistema para la toma de
decisiones y así determinar el rumbo que debe tomar en cuanto al avance del
mismo.
1.2 Situación Conflicto Nudos Críticos
El problema surge en el momento en el que más de una persona quiere realizar
aportes significativos para la mejora del sistema o aplicación, al no contar con
una herramienta de control comenzamos a quedar desprotegidos sin poder
volver atrás y recuperar lo modificado.
Al momento se continúa con esta problemática debido a que en el plan principal
del proyecto no se consideró una herramienta que aportara con el trabajo de un
gran grupo de trabajo para el desarrollo.
“¿Alguna vez has hecho una copia de un archivo o un directorio y de
agregar una marca de tiempo a la original, de modo que usted puede hacer
cambios experimentales?” (Gyerik, 2013:8), pues para el caso del proyecto
analizado, nunca se ha realizado una actividad de este tipo y por ello el conflicto
al momento de empezar los cambios o restaurar una versión funcional, el
mantener el historial de cada una de las acciones dentro del ámbito de desarrollo
es lo más importante para no tener consecuencias graves como no encontrar el
error y dejar fuera de producción por largo tiempo el sistema del cual dependerá
muchas áreas de trabajo.
Actualmente el 99.9% de los programadores del sistema trabajan de manera
totalmente aislada y con falta de conocimiento de las versiones realizadas por
los antiguos desarrolladores.
3
1.3 Causas y Consecuencias del Problema
Tabla 1 Cusas y consecuencias del problema
Elaborado por: Victoria García Velásquez
Fuente: Vías de Investigación
CAUSAS CONSECUENCIAS
No tener disponible
una herramienta de
control de versiones.
Quedar desprotegidos a futuras modificaciones
de la aplicación, documentos y demás
secciones del sistema.
No tener respaldo del historial de incorporación,
modificación o eliminación.
Modalidad de trabajos
para proyectos
grandes, manejando
gran cantidad de
recursos.
El desarrollo es dependiente, no se puede
avanzar si los módulos no se completan.
Todos tienen que trabajar en un mismo
repositorio central o red, disminuyendo la
agilidad con la que se pueda avanzar.
Tiempo, costos y
disponibilidad
El tiempo que implicas desarrollar y luego
integra lo realizado con el resto de módulos, es
muy lento y casi siempre atrae problemas.
Debido a la lentitud, el tiempo y costo del
proyecto aumentara.
La puesta a producción será demorada, al no
contar con un controlador distribuido los errores
y fallos serán más difíciles de detectar.
Conectividad
Es necesario depender del servidor o hosting en
el que se encuentre alojado nuestro repositorio
central.
El otorgar los permisos de escritura y cambios es
muy complejo y sin conexión no se puede
trabajar, generando grandes retrasos en el
cronograma de entregables y funcionales.
4
1.4 Delimitación del Problema
Campo : Desarrollo Promeinfo
Área : Base de Datos y Seguridades
Aspecto : Herramienta de Control de Versiones, para realizar el
historial y control de versionamiento.
Tema : Procedimiento, análisis y desarrollo de un sistema de
control de versiones distribuidas, sobre las base de
datos del Sistema PROMEINFO.
Geográfica : Hospital Universitario
Guayaquil – Vía Perimetral Km. 23,5
Espacio : 2015
1.5 Formulación del Problema ¿Cuán importante sería un Sistema de control de cambio en el desarrollo de software, como una herramienta para llevar una trazabilidad de los cambios sobre un objeto especifico de un determinado proyecto y como mecanismo de mejora continua en el software?
5
1.6 Evaluación del Problema
Los aspectos generales de evaluación son:
Delimitado: Este producto será implementado para la mejora de los tiempos
para el desarrollo dentro del grupo de trabajo promeinfo, el mismo se
implementara en el Hospital universitario durante el año 2015.
Evidente: “Dejar de hacer copias y no perderse en el mar de sellos de
tiempo archivos y directorios. Usted es libre de experimentar, a sabiendas
de que puede volver a cualquier estado anterior en cualquier momento.”
(Gyerik, 2013:8), las manifestaciones del versionador son tan evidentes y útiles,
debido a que guarda el historial de los documentos y demás actividades que se
llevan en el sistema.
Concreto: “En un proyecto en el que muchos desarrolladores trabajan en
paralelo, habrá muchas líneas diferentes de desarrollo. La fuerza de Git
está en las herramientas que pueden ayudar a hebras de desarrollo
reintegrar: fusión, cambio de base, cherry-picking, etc” (Preißel, René, &
Stachmann, Bjørn, 2014:1), visualizar de manera amigable los repositorios
remotos y los controles realizados como los eliminados, editados entre otras
acciones.
Original: Solución novedosa a serios y críticos problemas en el ámbito del
desarrollo de este proyecto, “sistema de control de versiones capaces de
apoyar el desarrollo en todo el mundo de software a gran escala” (Loeliger
& Matthew McCullough, 2012:2), esta solución no solo mejorara el rendimiento
de los recursos, si no también mejorara costo y tiempos de puesta a producción.
Factible: La factibilidad de esta herramienta de trabajo es darle al desarrollador
de sistemas la facilidad de trabajar de manera libre, evitando dependencias que
retrasan la puesta a producción del proyecto.
6
En un sistema de control de versiones distribuidas no hay separación
entre el entorno de desarrollo y el entorno de servidor. Cada
desarrollador tiene tanto un espacio de trabajo con los archivos que
se está trabajando y de su propio repositorio local (llamado un clon)
con todas las versiones. (Preißel, René, & Stachmann, Bjørn, 2014:10)
Identifica los productos esperados: Los resultados que nos presta esta
herramienta, se pueden divisar desde el inicio en que se le asigna la tarea, al no
ser centralizado cualquiera integrante del grupo puede tomar el módulo de
trabajo y continuar, haciendo una extensión del mismo para evitar así los
retrasos o conflictos.
Un sistema de control de versiones (VCS) es esencialmente una
herramienta para organizar y realizar un seguimiento de la historia de
los cambios a los archivos en un proyecto. Esto es más que sólo una
buena contabilidad. Un sistema de control de versiones puede
cambiar la forma de trabajar y ser más productivo. (Gyerik, 2013:7)
Variable: En este proyecto se reconoce como:
o Variable independiente al Procedimiento, análisis y
desarrollo de un sistema de control de versiones
distribuidas, de este análisis sabremos lo factible
al instalar la herramienta de control funcione
correctamente.
o Variable dependiente serán sobre las base de datos
del Sistema PROMEINFO, del procedimiento
análisis y el desarrollo de la herramienta de control
dependerá el funcionamiento en la estructura del
sistema del cliente.
Las cuales nos llevaran a un exitoso proyecto de control que maneje de manera
correcta los cambios, el historial y que permita trabajar siempre de manera
independiente y así evitar los contratiempos dentro del sistema del cliente.
7
1.7 OBJETIVOS
1.7.1 OBJETIVO GENERAL
Establecer una herramienta de control de versiones distribuidas, mediante el uso
de soluciones tecnologías ya existentes en el mercado que permita almacenar la
base de conocimiento existentes, para el control y seguimiento de las actividades
que se irán realizando y aprobando dentro del proyecto.
1.7.2 OBJETIVOS ESPECÍFICOS
1 Definir una herramienta de control de versión distribuida y establecer el
cliente para la comunicación entre cliente y servidor, atreves de la selección
entre las diferentes soluciones tecnológicas existentes, para obtener los
altos beneficios que se busca de la herramienta.
2 Implementación del ambiente de trabajo, herramientas tecnológicas y
seguridades, mediante la correspondiente configuración para cada uno de
los ambientes, que aportara al correcto funcionamiento de la solución
tecnológica que se establecerá.
3 Definir protocolos de seguridad para la comunicación de la herramienta de
control de versiones, definiendo políticas de seguridad con el propósito de
que la seguridad de los datos e información no lleguen a ser vulneradas.
1.8 ALCANCES DEL PROBLEMA
Construir un repositorio o varios del proyecto que sirvan como sincronizador
de los repositorios locales, esto para que los desarrolladores puedan sacar
copias y trabajar de manera individual, para luego subir los cambios y
finalmente integrarlos.
Mantener flujos de trabajos con un gestor de integración, para los repositorios.
Brindar las seguridades que el sistema requiere como: confiabilidad, integridad
y disponibilidad de los datos.
Personalizar el control de versiones con la configuración del cliente y del
servidor.
8
1.9 JUSTIFICACIÓN E IMPORTANCIA
Ninguna persona prudente, creativo comienza un proyecto hoy en día sin una
estrategia de copia de seguridad. “Dado que los datos son efímeros y puede
perderse fácilmente a través de un cambio de código errante o un
accidente catastrófico del disco, dice, es aconsejable mantener un archivo
vivo de todo el trabajo “(Loeliger & Matthew McCullough, 2012:1), esta
situación que presenta la empresa PROMEINFO es la que ha inducido a
proponer una solución realtivamente descomplicada pero efectiva de mantener
el orden el contenido de los sistemas.
Un sistema de control de versiones (VCS) es esencialmente una
herramienta para organizar y realizar un seguimiento de la historia de
los cambios a los archivos en un proyecto. Esto es más que sólo una
buena contabilidad. Un sistema de control de versiones puede
cambiar la forma de trabajar y hacer más productivo. (Gyerik, 2013:7).
para la construccion de un beneficio evidente de consevar el historial.
Los desarrollares tanto nuevos como antiguos dentro del proyecto y podran
tener una facilidad de ponerse al corriente con lo que se les solicite realizar en
el proyecto.
Este estudio nos llevara a la nmejora de los tiempo, el optimo desempeño de
los recursos y la reduccion de costo.
Esta herramienta es ligera de facil interacción con la comunidad y es un
software libre, da las faciidades que necesita el desarrollador ademas de poder
detecctar los errores de la manera mas simple, pues trabaja por repositorios est
o nos ayuda a mantener el ritmo de trabajo y dar las soluciones correspondiente
a los problemas.
Los cambios drásticos siempre van orientados a optimizar y mejorar los
procesos pero con total seguridad, teniendo en cuenta que siempre esta
disponible el hechar un vistazo al historial, volver a la version anterior, restaurar
lo eliminado; esto es lo que en la aculidad se realiza para tener mas confianza
al desarrollar con beneficios incalculables.
9
1.10 METODOLOGÍA DEL PROYECTO:
1.10.1 Aplica a proyecto tecnológico funcional: Para realizar este proyecto se tomará el método guía del pmbok para la
fundamentación de la dirección del proyecto, se seguirá el ciclo de vida
mostrado en la ilustración 1, la cual nos muestra el ciclo de vida del proyecto y
las limitantes del mismo.
Elaborado por: Victoria García Velásquez Fuente: Libro PMBOK1 Los lineamientos según las áreas de conocimiento y los grupos de proceso de
dirección del proyecto serán detallados en el ANEXO 2, extraído del PmBok 5ta
edición y ha sido modificado al proyecto que vamos a desarrollar.
Áreas de conocimiento
Gestión de la integración
Gestión del alcance
Gestión del tiempo
Gestión del costo
Gestión de la calidad
Gestión de los recursos humanos
Gestión del riesgo
Gestión de compra
Gestión de los interesados (Project Management Institute, 2013)
1 Imagen extraída de la Guía de los fundamentos para la dirección de proyectos PMBOK 5ta
edición Pag. 54
Ilustración 1 Ciclo de vida y límites del proyecto
10
Supuestos y Restricciones
Tabla 2 Supuestos y Restricciones del proyecto
SUPUESTOS RESTRICCIONES
Instalación de la herramienta de
Control de versiones, que permitirá
revisar, controlar y manejar de manera
muy fácil el proyecto y documentos
dentro de la empresa.
Equipos de tecnología que
soporten la herramienta que se
desea implementar.
Configuración de la herramienta para
mantener un completo historial de
cambios, para que se pueda ingresar
en cualquier momento y volver a una
versión anterior.
Tiempo de pruebas y análisis del
comportamiento de la herramienta.
Los archivos Binarios no pueden
realizar Merchs.
Los márgenes de tiempos para la
puesta en producción cuentan con un
cronograma de actividades, elaborado
de manera que se puedan ejecutar en
los plazos establecidos.
Los tiempos sean modificados o
retrasados por falta de premura en
el cronograma establecido a la
entidad.
Adaptación de la herramienta dentro
de la forma de trabajo y capacitación
de la herramienta para el proceso de
desarrollo de los diversos proyectos y
procesos.
Personal renuente al cambio al
inicio de inducción de la
herramienta.
Elaborado Por: Victoria García Velásquez. Fuente: Vías de Investigación.
11
Ilustración 2 Pruebas de integración
Plan de Calidad (Pruebas a realizar)
Pruebas integrales o pruebas de integración son aquellas que se
realizan en el ámbito del desarrollo de software una vez que se han
aprobado las pruebas unitarias. Únicamente se refieren a la prueba o
pruebas de todos los elementos unitarios que componen un proceso,
hecha en conjunto, de una sola vez.
Consiste en realizar pruebas para verificar que un gran conjunto de
partes de software funcionan juntos.
Las pruebas de integración (algunas veces llamadas integración y
testeo I&t) es la fase del testeo de software en la cual módulos
individuales de software son combinados y testeados como un grupo.
Son las pruebas posteriores a las pruebas unitarias y preceden el
testeo de sistema. (https://maperz1130.wordpress.com/, 2010)
Elaborado por: Victoria García Velásquez. Fuente: portal web2
2 Imagen extraída del portal Web https://maperz1130.wordpress.com/2010/09/06/pruebas-de-
integracion/
12
CAPÍTULO II
2.1 MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
A nivel mundial el control de versiones ha sido la solución a innumerables
dolores de cabezas de los desarrolladores y como lo indican Loeliger(2012) hoy
en día ninguna persona prudente que trabaje dentro del area de sistemas,
empieza un proyecto sin las debidas estrategias antes posibles catastrofes o
simples cambiosa lo largo del proyecto.
Según Chacon & Straud(2009) mencionan que desde el nacimiento de la
herramienta de control de versiones Git en el año 2005 ha evolucionado la
forma de uso de los controladores de versión pues hoy en día no existe otro
versionador que nos brinde la rapidez, eficacia para grandes proyectos, y su
forma en ramificar para un desarrollo lineal, lo cual lo ha hecho muy requerido a
nivel del mundial.
Po su agíl desempeño en multiples papeles el control de versión de cambio, ha
venido ganando terreno dentro de las empresas que manejan grandes grupos de
trabajo, puede soportar muchos recursos al mismo tiempo trabajando en el
mismo codigo al mismo tiempo, esto le ha quitado un gran dolor de cabeza a los
desarrolladores y diseñadores que deben lidiar con el intercambio de información
entre compañeros de labores.
Los desarrolladores y diseñadores web se benefician de realizar respaldos de
seguridad sobre sus archivos y demas documentos de manera simultanea, el
poder retroceder si se realizo un error o simplemento no funciono el cambio
realizado, esto permite trabajar de manera de ida y vuelta sin preocupaciones a
errores. El mas utilizado de esta herramienta es de forma distribuida ya que da
los beneficios de trabajar dsin conexión y de forma independiente.
13
En Ecuador no somos la excepcion, muchas empresa regionales de las cuales
manejan proyectos que requieren por lo general de un número significatico de
desarrolladores han implementado nuevas tecnologías como el controlador de
Versiones Git y otro tipos de controladores de versión.
Este es el caso de las empresas de servicio público en lo que corresponde a
electricas del país, las mismas que cuentan con cantidades grandes de procesos
internos y por su gran afluencias de clientes, siempre deben mantenerse
actualizados y avanzando en rapidez para la eficacia en su servicio, por ello se
aprobó el cambio interno de la forma de manejar sus aplicativos, y se da paso a
una nueva herramienta tecnológica, esta les ha dado el despunte para continuar
con los avances para el progreso de la entidad, por esto ha buscado mejorar sus
estrategias para continuar dando mejor servicio a sus clientes en menos tiempos
y al mismo tiempo controlar y revisar al personal.
Las empresas que han implementado esta herramienta de control dentro de la
ciudad de Guayaquil, son empresa que buscan la mejora en sus servicios, esto
utilizando esta herraminetas y otras adicionales generando estrategias con la
finalidad de ir a la banguardia y ser competitivos dentro del mercado.
Se ha identificado dentro del área empresarial que han implementado la
herramienta de control de versiones son las empresas de telecomunicaciones,
dichas empresas manejan grandes grupos de trabajos para el desarrollo de sus
aplicaciones y sistemas de información, su objetivo es siempre estar avanzando
en tecnología y servicio, es por ello que adquieren esta nueva herramienta
tecnológica que proporciona rapidez, orden y que es capaz de guardar todo tipo
de cambio de manera que proporciona un historial completo y confiable para
estar siempre seguros que se podrá retornar a una versión funcional.
Esta herramientas les ha facilitado el trabajo de organizar a los desarrolladores
al momento de poner en marcha nuevos proyectos, el manejo de tiempos se ha
mejorado en gran manera y lo más importante es que obtener estos beneficios
para las empresas tiene un costo relativamente bajo ya que esta herramienta no
tiene costo pues es de código abierto.
14
2.2 FUNDAMENTACIÓN TEÓRICA
2.2.1 Herramientas tecnológicas
Las herramientas de tecnologías de la información y las
comunicaciones (TIC’s) son elementos de gran importancia para los
seres humanos y para las empresas, en cuanto que permiten conocer
la condición real de las cosas y permiten realizar la gestión de las
actividades que máquinas y seres humanos realizan. El cambio
tecnológico producido con la revolución de la tecnología, de la mano
del inmenso avance de los computadores, marcan la diferencia entre
una civilización desarrollada y otra en vías de desarrollo. Por tanto, es
posible afirmar que una organización que no integre tecnología a sus
actividades, es una organización que está quedándose rezagada en el
mundo actual. (Zapata Cortés, 2010:87)
Ilustración 3
Actividades de las Herramientas Tecnológicas
Elaboración: Victoria García Velásquez Fuente: portal web
(herramientastecnologicasyelzudielis.blogspot.com/p/blog-page_56.html)
15
Desde el inicio de los proyectos tecnológicos, utilizando las TICs, pues es la que
nos ayuda con la gestión de proyectos que permite ser eficientes y veraces en la
adquisición de la información, permitiendo así generar procesos y operaciones
con los clientes, la administración de la cadena de suministro y relación con los
proveedores pues la necesidad de agrupar e interrelacionar el proceso para la
transferencia de la información.
Ilustración 4 Los procesos macro en una cadena de suministro.
Elaborado: Chopra y Meindl Fuente: (Zapata Cortés, 2010:89)
TECNOLOGÍAS DE LA INFORMACIÓN ASOCIADAS A LA CAPTURA Y
LA TRANSFERENCIA DE LA INFORMACIÓN
La transferencia de la información juega un papel fundamental dentro
de la logística, pues de la velocidad de esta depende la correcta
operación de las actividades logísticas, así como la reducción del
efecto látigo en las organizaciones. Las herramientas para la captura
y transferencia de la información, más relevantes en logística son la
Internet, la banda ancha, el EDI y el XML (Zapata Cortés, 2010:89)
TECNOLOGÍAS DE LA INFORMACIÓN ASOCIADAS AL
ALMACENAMIENTO Y A LA RECUPERACIÓN DE LA INFORMACIÓN
Las tecnologías de la información destinadas al almacenamiento y la
recuperación de la información son las bases de datos, las cuales se
conciben como la organización de los datos y la información que es
guardada electrónicamente.
Existen varios tipos de bases de datos, donde la más común es la
base de datos relacional, la cual almacena grupos de datos
16
relacionados en tablas individuales y permiten la recuperación
(entrega de la información consultada) mediante el uso de un
lenguaje estándar llamado SQL – Structured Query Language.
Una base de datos está definida por el nivel de detalle en la
información que almacena, donde la variable más importante es el
balance entre tener la información altamente agregada o altamente
detallada, lo cual depende de las necesidades específicas de los
usuarios y de los costos de almacenar información altamente
detallada.
Una característica fundamental de las bases de datos es que permite
que las transacciones puedan ser registradas, almacenadas y
posteriormente consultadas, y es el administrador de la base de datos
quien determina que operaciones, en qué nivel de detalle y con qué
excepciones dichas transacciones son registradas y vigiladas.
Además, estas transacciones son registradas y pueden ser
observadas en tiempo real o por baches de tiempo, lo cual es también
determinado por el administrador.
Las bases de datos permiten entregar la información almacenada de
diferentes formas, dependiendo las necesidades de los usuarios.
Estas diferentes formas de ver la información se conocen con el
nombre de vistas y se deben a que no todos los usuarios pueden o
necesitan ver la totalidad de información contenida en una búsqueda
específica, por ejemplo, cuando el personal de ventas de una
compañía está interesado en obtener información sobre un producto,
seguramente está buscando información relacionada con históricos
de venta, precios de fabricación, de producción, garantías, entre
otras, mientras que una persona de producción no estará, ni tendrá
porque estar interesada en esta información y por el contrario el
buscará datos concernientes a materias primas, condiciones de
operación, entre otros parámetros. (Zapata Cortés, 2010:90-91)
17
2.2.2 Ingenieria de Software
En efecto en la epoca que aparecen los software se diseña una estrategia que
pudiera llevar al enfoque sistematico con disciplina y que al ser desarrollado se
lleve en los tiempos estimados y es donde nace la ingenieria de sotfware , su
enfoque esta dirigido mas a la ciencia de realizar un diseño, manejarlo y
mantenerlo en progreso, mediantes metodos, tecnicas y herramientas que nos
facilitaran el proceso de la aplicación
La ingeniería de software trata del establecimiento de los principios y
métodos de la ingeniería a fin de obtener software de modo rentable,
que sea fiable y trabaje en máquinas reales (Bauer, 1972)
Elaborado: Victoria García Velásquez.
Fuente: portal web educa – planifica
https://educa-planifica.wikispaces.com/
Ilustración 5 Proceso de Ingeniería de Software
18
El software se ha incrustado profundamente en casi todos los
aspectos de nuestras vidas y, como consecuencia, el número de
personas que tienen interés en las características y funciones que
brinda una aplicación específica ha crecido en forma notable. Cuando
ha de construirse una aplicación nueva o sistema incrustado, deben
escucharse muchas opiniones. Y en ocasiones parece que cada una
de ellas tiene una idea un poco distinta de cuáles características y
funciones debiera tener el software. Se concluye que debe hacerse un
esfuerzo concertado para entender el problema antes de desarrollar
una aplicación de software.
Los requerimientos de la tecnología de la información que
demandan los individuos, negocios y gobiernos se hacen más
complejos con cada año que pasa. En la actualidad, grandes equipos
de personas crean programas de cómputo que antes eran elaborados
por un solo individuo. El software sofisticado, que alguna vez se
implementó en un ambiente de cómputo predecible y auto contenido,
hoy en día se halla incrustado en el interior de todo, desde la
electrónica de consumo hasta dispositivos médicos o sistemas de
armamento. La complejidad de estos nuevos sistemas y productos
basados en computadora demanda atención cuidadosa a las
interacciones de todos los elementos del sistema. Se concluye que el
diseño se ha vuelto una actividad crucial. (Roger S. Pressman,
2010:10).
La ingeniería de software deberá estar presente en cada uno los aspectos de los
proyectos que se lleven a cabo en una empresa u institución, sus procesos
iniciales hasta los mantenimientos deberán esta especificados en la producción
del software, siempre teniendo presente la esencia de la misma que son:
La Disciplina la cual se debe recalcar es la que hace posible a los
programadores llegar a sus objetivos mediantes el uso de herramientas y
métodos sin olvidar siempre que dependerá también de las diferentes áreas de
conocimiento que pueda otorgar el ambiente.
19
[La ingeniería de software es] el establecimiento y uso de principios
fundamentales de la ingeniería con objeto de desarrollar en forma
económica software que sea confiable y que trabaje con eficiencia en
máquinas reales. (Roger S. Pressman, 2010:11).
Aun así, el enfoque “sistemático, disciplinado y cuantificable” aplicado por un equipo de software podría ser algo burdo para otro. Se necesita disciplina, pero también adaptabilidad y agilidad. La ingeniería de software es una tecnología con varias capas, cualquier enfoque de ingeniería (incluso la de software) debe basarse en un compromiso organizacional con la calidad. La administración total de la calidad, Six Sigma y otras filosofías similares 10 alimentan la altura de mejora continua, y es esta cultura la que lleva en última instancia al desarrollo de enfoques cada vez más eficaces de la ingeniería de software. El fundamento en el que se apoya la ingeniería de software es el compromiso con la calidad. El fundamento para la ingeniería de software es la capa proceso. El proceso de ingeniería de software es el aglutinante que une las capas de la tecnología y permite el desarrollo racional y oportuno del software de cómputo. El proceso define una estructura que debe establecerse para la obtención eficaz de tecnología de ingeniería de software. El proceso de software forma la base para el control de la administración de proyectos de software, y establece el contexto en el que se aplican métodos técnicos, se generan productos del trabajo (modelos, documentos, datos, reportes, formatos, etc.), se establecen puntos de referencia, se asegura la calidad y se administra el cambio de manera apropiada. (Roger S. Pressman, 2010:11-12)
Elaborado: Victoria García Velásquez. Fuente: Libro Ingeniería del Software: un enfoque práctico 7 ma edición (Roger S. Pressman, 2010:11)
Ilustración 6 Capas de la Ingeniería de Software
20
Categorías del Software Existen al menos 7 categorías del software pero para este proyecto se
mencionara solo las indicadas para el mismo:
Software de sistemas: conjunto de programas escritos para dar
servicio a otros programas. Determinado software de sistemas (por
ejemplo, compiladores, editores y herramientas para administrar
archivos) procesa estructuras de información complejas pero
deterministas. Otras aplicaciones de sistemas (por ejemplo,
componentes de sistemas operativos, manejadores, software de
redes, procesadores de telecomunicaciones) procesan sobre todo
datos indeterminados. En cualquier caso, el área de software de
sistemas se caracteriza por: gran interacción con el hardware de la
computadora, uso intensivo por parte de usuarios múltiples,
operación concurrente que requiere la secuenciación, recursos
compartidos y administración de un proceso sofisticado,
estructuras complejas de datos e interfaces externas múltiples.
Software de aplicación: programas aislados que resuelven una
necesidad específica de negocios. Las aplicaciones en esta área
procesan datos comerciales o técnicos en una forma que facilita las
operaciones de negocios o la toma de decisiones administrativas o
técnicas. Además de las aplicaciones convencionales de
procesamiento de datos, el software de aplicación se usa para
controlar funciones de negocios en tiempo real (por ejemplo,
procesamiento de transacciones en punto de venta, control de
procesos de manufactura en tiempo real).
Aplicaciones web: llamadas “webapps”, esta categoría de
software centrado en redes agrupa una amplia gama de aplicaciones.
En su forma más sencilla, las webapps son poco más que un
conjunto de archivos de hipertexto vinculados que presentan
información con uso de texto y gráficas limitadas. Sin embargo,
21
desde que surgió Web 2.0, las webapps están evolucionando hacia
ambientes de cómputo sofisticados que no sólo proveen
características aisladas, funciones de cómputo y contenido para el
usuario final, sino que también están integradas con bases de datos
corporativas y aplicaciones de negocios.
Software de inteligencia artificial: hace uso de algoritmos no
numéricos para resolver problemas complejos que no son fáciles de
tratar computacionalmente o con el análisis directo. Las aplicaciones
en esta área incluyen robótica, sistemas expertos, reconocimiento de
patrones (imagen y voz), redes neurales artificiales, demostración de
teoremas y juegos. (Roger S. Pressman, 2010:5)
Ciclo de vida de un Software
Es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. (AUDITORIA DE SISTEMAS , 2010)
Elaborado: Victoria García Velásquez. Fuente: Portal web: http://sisteaudi.blogspot.com/2010/09/ciclo-de-vida-y-desarrollo-de-sistemas.html
Ilustración 7 Ciclo de vida de un Sotfware
22
2.2.3 Seguridad informática
Lo primordial en los sistemas es buscar la seguridad en todas sus instancias,
para evitar perdida de información o transacciones fraudulentas, siempre la
seguridad se debe basar en la integridad, confiabilidad y disponibilidad.
Elaborado: Victoria García Velásquez Fuente: Portal Web http://servicities.com/blog/categoria/seguridad-informatica/
Para afrontar el establecimiento de un sistema de seguridad en
necesario conocer:
• Cuáles son los elementos que componen el sistema. Esta
información se obtiene mediante entrevistas con los responsables o
directivos de la organización para la que se hace el estudio de riesgos
y mediante apreciación directa.
• Cuáles son los peligros que afectan al sistema, accidentales o
provocados. Se deducen tanto de los datos aportados por la
organización como por el estudio directo del sistema mediante la
realización de pruebas y muestreos sobre el mismo.
• Cuáles son las medidas que deberían adoptarse para conocer,
prevenir, impedir, reducir o controlar los riesgos potenciales. Se trata
de decidir cuáles serán los servicios y mecanismos de seguridad que
reducirían los riesgos al máximo posible.
Ilustración 8 Protección
23
Tras el estudio de riesgos y la implantación de medidas, debe hacerse
un seguimiento periódico, revisando y actualizando las medidas
adoptadas. (López, 2010:5)
Propiedades de un sistema de información seguro
Los daños producidos por falta de seguridad pueden causar pérdidas
económicas o de credibilidad y prestigio a una organización.
Su origen puede ser:
• Fortuito. Errores cometidos accidentalmente por los usuarios,
accidentes, cortes de fluido eléctrico, averías del sistema, catástrofes
naturales…
• Fraudulento. Daños causados por software malicioso, intrusos o por
la mala voluntad de algún miembro del personal con acceso al
sistema, robo o accidentes provocados.
Se considera seguro un sistema que cumple con las propiedades de
integridad, confidencialidad y disponibilidad de la información. Cada
una de estas propiedades con lleva la implantación de determinados
servicios y mecanismos de seguridad que se estudiarán más
adelante.
Elaborado: Victoria García Velásquez Fuente: Portal Web
http://so2-caece.wikispaces.com/M%C3%B3dulo+8.+Tolerancia+a+Fallos
Ilustración 9 Triangulo de las Seguridades
24
Integridad
Este principio garantiza la autenticidad y precisión de la información
sin importar el momento en que esta se solicita, o dicho de otra
manera, una garantía de que los datos no han sido alterados ni
destruidos de modo no autorizado.
Para evitar este tipo de riesgos se debe dotar al sistema de
mecanismos que prevengan y detecten cuándo se produce un fallo de
integridad y que puedan tratar y resolver los errores que se han
descubierto.
Confidencialidad
La OCDE (Organización para la Cooperación y el Desarrollo
Económico), en sus Directrices para la Seguridad de los Sistemas de
Información define la confidencialidad como «el hecho de que los
datos o informaciones estén únicamente al alcance del conocimiento
de las personas, entidades o mecanismos autorizados, en los
momentos autorizados y de una manera autorizada».
Para prevenir errores de confidencialidad debe diseñarse un control
de accesos al sistema: quién puede acceder, a qué parte del sistema,
en qué momento y para realizar qué tipo de operaciones. (AUDITORIA
DE SISTEMAS , 2010:6)
Disponibilidad
La información ha de estar disponible para los usuarios autorizados
cuando la necesiten.
El programa MAGERIT define la disponibilidad como «grado en el que
un dato está en el lugar, momento y forma en que es requerido por el
usuario autorizado.
Situación que se produce cuando se puede acceder a un sistema de
información en un periodo de tiempo considerado aceptable. La
25
disponibilidad está asociada a la fiabilidad técnica de los
componentes del sistema de información».
Se deben aplicar medidas que protejan la información, así como crear
copias de seguridad y mecanismos para restaurar los datos que
accidental o intencionadamente se hubiesen dañado o destruido.
(AUDITORIA DE SISTEMAS , 2010:7)
Proceso del análisis de riesgos
Para implantar una política de seguridad en un sistema de
información es necesario seguir un esquema lógico.
• Hacer inventario y valoración de los activos.
• Identificar y valorar las amenazas que puedan afectar a la seguridad
de los activos.
• Identificar y evaluar las medidas de seguridad existentes.
• Identificar y valorar las vulnerabilidades de los activos a las
amenazas que les afectan.
• Identificar los objetivos de seguridad de la organización.
• Determinar sistemas de medición de riesgos.
• Determinar el impacto que produciría un ataque.
• Identificar y seleccionar las medidas de protección. (AUDITORIA DE
SISTEMAS , 2010:11)
Elaborado: Victoria García Velásquez Fuente: Portal Web http://esteban.opentelematics.org/2010/10/19/gestion-de-
riesgos/
CONTROL DE CAMBIOS
Ilustración 10 Gestión de Riesgo
26
El proceso de control de cambios busca resguardar el modelo de
seguridad de una organización de la implementación de determinadas
modificaciones que puedan corromperlo. Comúnmente, un usuario
pide un cambio en algún sistema que genera una posible brecha de
seguridad. Puede ser la instalación de un software especial, el
reemplazo de determinado hardware, la modificación de reglas en un
firewall y un largo etcétera. En términos generales, los usuarios no
son conscientes de las implicancias que las modificaciones pueden
tener para la seguridad de la organización. Es el responsable de
seguridad de la información quien debe analizar el impacto de dichos
cambios antes de implementarlos.
La efectividad en los controles de cambios permite, entre otras cosas,
determinar problemas como violaciones de políticas internas, fallas
de hardware e infecciones por malware. (Benchimol, 2011:23)
Ilustración 11 Proceso de Control de Cambios
Elaborado: Victoria García Velásquez
Fuente: http://www.asprotech.com https://asprotech.wordpress.com/2011/06/30/cambios-a-requisitos-y-control-de-
cambios/
27
2.2.4 Bases de Datos
Según Sudarshan,( 2002), nos reseñan que el proceso de datos fortalecen el
crecimiento constante de las computadoras en el ambito comercial, y cabe aclara
rque el autoiamatizar las tareas de guardado de datos para mantener un
historico muy bien guardado se convirtieron en una herramienta indispensable, al
inicio se utilizaron las ya extintas tarjetas perforadas estgas fueron utilizadas al
final de siglo XX como medios para ingresar los datos.
Elaborado: Victoria García Velásquez
Fuente: http://www.taringa.net http://www.taringa.net/post/apuntes-y-monografias/18875477/Bases-de-
datos.html
Pasan los años y a medida que pasaban se mejoraba la tecnología es por ello
que en 1960 nace las cintas magneticas a finales de este mismo año nacen los
discos fijos quienes comenzaron a desplazar toda tecnoogia existente hasta ese
momento en lo que respeta a el almacenamiento de información, la
particularidad de este disco fijo es que se podia acceder en milisegundos a la
información y entre otras mas ventajas, a inicios de 1990 el lenguaje SQL es
diseñado para la toma de decisiones en los asiostentes de ayuda que son de
exclusiva consulta y detalle, los que distribuian las bases de datos ingresaron
algunmos tipos de bases de datos en ese periodo y a finales de la decada de
1990 aparece la WWW, las bases de datos tuvieron que ser extendidas y es por
ello que en la actualidad contamos con el soporte de transciones en altas tareas
y con gran disponibilidad todos los días de la semana durante todo el año, para
las bases de datos la palabra inactividad no existe, gracias a los avances
tecnologicos y de punta.
Ilustración 12 Modelo de Base de datos
28
Ventajas e inconvenientes de los sistemas de bases de datos
Los sistemas de bases de datos presentan numerosas ventajas
gracias, fundamentalmente, a la integración de datos y a la interfaz
común que proporciona el SGBD. Estas ventajas se describen a
continuación.
Control sobre la redundancia de datos. Los sistemas de ficheros
almacenan varias copias de los mismos datos en ficheros distintos.
Esto hace que se desperdicie espacio de almacenamiento, además de
provocar faltas de consistencia de datos (copias que no coinciden).
En los sistemas de bases de datos todos estos ficheros están
integrados, por lo que no se almacenan varias copias de los mismos
datos. Sin embargo, en una base de datos no se puede eliminar la
redundancia completamente, ya que en ocasiones es necesaria para
modelar las relaciones entre los datos, o bien es necesaria para
mejorar las prestaciones.
Control sobre la consistencia de datos. Eliminando o controlando las
redundancias de datos se reduce en gran medida el riesgo de que
haya inconsistencias. Si un dato está almacenado una sola vez,
cualquier actualización se debe realizar sólo una vez, y está
disponible para todos los usuarios inmediatamente. Si un dato está
duplicado y el sistema conoce esta redundancia, el propio sistema
puede encargarse de garantizar que todas las copias se mantengan
consistentes. Desgraciadamente, no todos los SGBD de hoy en día se
encargan de mantener automáticamente la consistencia.
Compartición de datos. En los sistemas de ficheros, los ficheros
pertenecen a los departamentos que los utilizan, pero en los
sistemas de bases de datos, la base de datos pertenece a la
empresa y puede ser compartida por todos los usuarios que estén
autorizados. Además, las nuevas aplicaciones que se vayan creando
pueden utilizar los datos de la base de datos existente.
29
Mantenimiento de estándares. Gracias a la integración es más fácil
respetar los estándares necesarios, tanto los establecidos a nivel de
la empresa como los nacionales e internacionales. Estos estándares
pueden establecerse sobre el formato de los datos para facilitar su
intercambio; pueden ser estándares de documentación,
procedimientos de actualización y también reglas de acceso.
Mejora en la integridad de datos. La integridad de la base de datos
se refiere a la validez de los datos almacenados. Normalmente, la
integridad se expresa mediante restricciones o reglas que no se
pueden violar. Estas restricciones se pueden aplicar tanto a los
datos, como a sus relaciones, y es el SGBD quien se encargará de
mantenerlas.
Mejora en la seguridad. La seguridad de la base de datos consiste la
protección de la base de datos frente a usuarios no autorizados. Sin
unas buenas medidas de seguridad, la integración de datos en los
sistemas de bases de datos hace que éstos sean más vulnerables
que en los sistemas de ficheros. Sin embargo, los SGBD permiten
mantener la seguridad mediante el establecimiento de claves para
identificar al personal autorizado a utilizar la base de datos. Las
autorizaciones se pueden realizar a nivel de operaciones, de modo
que un usuario puede estar autorizado a consultar ciertos datos
pero no a actualizarlos, por ejemplo.
Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan
lenguajes de consulta o generadores de informes que permiten al
usuario hacer cualquier tipo de consulta sobre los datos, sin que
sea necesario que un programador escriba una aplicación que
realice tal tarea.
Mejora en la productividad. El SGBD proporciona muchas de las
funciones estándar que el programador necesita escribir en un
sistema de ficheros. A nivel básico, el SGBD proporciona todas las
30
rutinas de manejo de ficheros típicas de los programas de
aplicación. El hecho de disponer de estas funciones permite al
programador centrarse mejor en la función específica requerida por
los usuarios, sin tener que preocuparse de los detalles de
implementación de bajo nivel. Muchos SGBD también proporcionan
un entorno de cuarta generación consistente en un conjunto de
herramientas que simplifican, en gran medida, el desarrollo de las
aplicaciones que acceden a la base de datos. Gracias a estas
herramientas, el programador puede ofrecer una mayor
productividad en un tiempo menor.
La integración de los datos y la existencia del SGBD también plantean
ciertos inconvenientes, como los que se citan a continuación.
Alta complejidad. Los SGBD son conjuntos de programas muy
complejos con una gran funcionalidad. Es preciso comprender muy
bien esta funcionalidad para poder sacar un buen partido de ellos.
Gran tamaño. Los SGBD son programas complejos y muy extensos
que requieren una gran cantidad de espacio en disco y de memoria
para trabajar de forma eficiente.
Coste económico del SGBD. El coste de un SGBD varía dependiendo
del entorno y de la funcionalidad que ofrece. Por ejemplo, un SGBD
para un ordenador personal puede costar 500 e, mientras que un
SGBD para un sistema multiusuario que dé servicio a cientos de
usuarios puede costar entre 10000 y 100000 e. Además, hay que
pagar una cuota anual de mantenimiento que suele ser un
porcentaje del precio del SGBD. En los últimos años han surgido
SGBD libres (open source) que ofrecen una gran funcionalidad y
muy buenas prestaciones. (Marqués, 2011:9-11)
31
MySQL
MySQL es el más popular sistema de gestión de base de datos
relacional SQL Open Source. MySQL es uno de los mejores RDBMS
que se utiliza para el desarrollo de aplicaciones de software basadas
en la Web.
Este tutorial te dará inicio rápido con MySQL y que se sienta cómodo
con la programación de MySQL.
Audiencia
Esta referencia se ha preparado para los principiantes para ayudarles
a entender los conceptos básicos de los conceptos avanzados
relacionados con las lenguas de MySQL.
Requisitos previos
Antes de empezar a hacer la práctica con varios tipos de ejemplos
dados en esta referencia, estoy haciendo una suposición de que ya
está al tanto de lo que es la base de datos, especialmente RDBMS y lo
que es un lenguaje de programación informática.
(http://www.tutorialspoint.com, 2016).
Elaborado: Victoria García Velásquez
Fuente:http://tics.org.mx/blog-tics/mysql-sistema-gestor-de-base-de-datos.php?w=1366
32
2.2.5 Sistemas de control de versiones
Para Chacon & Straub,( 2014), el control de versiones es una aplicación para
guardar los cambios dentro de la aplicación en cualquiera de sus contenidos ya
sean archivos, documentos o procesos para posterior recuperar o volver a lo que
antes de realizar un cambio ya sea este para apartar en el proyecto para mejoras
o por errores al realizar los cambios y se puede recuperar el cambioo realizado
en cualquiera de los archivos o documenación del computador.
Siempre que usted tiene que hacer una considerable cantidad de
cambios en el contenido existente puede marcar esos cambios como
una etapa (con una etiqueta) que se puede volver más tarde; esto
sirve como un mecanismo de seguridad por si las cosas no van de
acuerdo a su plan y desea revertir el contenido del documento a un
estado más antiguo en particular. (Somasundaram, 2013:9)
Un CVS (Concurrent Versions System), un sistema de control de versiones es de
suma importancia entre los programadores debido a los constantes cambio a los
que se está obligado a realizar, muchas grandes empresas en su
configuraciones del sistema en la actualidad cuentan con pequeñas formas de
salvaguardase como recuperación de Windows, punto de recuperación entre
otras formas que lo único que hacen es resguardar office, pero según
Somasundaram, ( 2013), el sistema de control de versiones impresionaria a
todas estas empresas con su habilidad de jugar con los movimientos constante
que ocurren en la documentación.
Dentro de los control de versiones encontramos diversas herramientas que
permiten trabajar de diferentes maneras, a continuación se detallara algunas de
las herramientas existentes y sus forma de trabajo, que nos permitira tener una
idea mas clara de como queremos llevar el proceso.
Se puede trabajar de manera Local, centralizados y distribuidas cada uno de
estos metodos tiene una herramienta en especifico que lo puede desarrollar de
la mejor, mencionaremos las que se han destacado en control de versión.
33
Sistemas de control de versiones locales
Un método de control de versiones usado por mucha gente es copiar
los archivos a otro directorio (quizás indicando la fecha y hora en que
lo hicieron, si son avispados). Este enfoque es muy común porque es
muy simple, pero también tremendamente propenso a errores. Es
fácil olvidar en qué directorio te encuentras, y guardar
accidentalmente en el archivo equivocado o sobrescribir archivos que
no querías. (Chacon & Straub, 2014:23)
Elaboración: Victoria García Velásquez Fuente: Libro Pro Git 3
Para hacer frente a este problema, los programadores desarrollaron
hace tiempo VCSs locales que contenían una simple base de datos en
la que se llevaba registro de todos los cambios realizados sobre los
archivos.
Una de las herramientas de control de versiones más popular fue un
sistema llamado rcs, que todavía podemos encontrar en muchos de
los ordenadores actuales. Hasta el famoso sistema operativo Mac OS
3 Libro Pro Git 2da edición por Scot Chacon y Ben Strub en el año 2014 imagen extraída de la
pág. 24
Ilustración 13 Diagrama de control de versiones local.
34
X incluye el comando rcs cuando instalas las herramientas de
desarrollo. Esta herramienta funciona básicamente guardando
conjuntos de parches (es decir, las diferencias entre archivos) de una
versión a otra en un formato especial en disco; puede entonces
recrear cómo era un archivo en cualquier momento sumando los
distintos parches. (Chacon & Straub, 2014:24)
Sistemas de control de versiones centralizados
El siguiente gran problema que se encuentra la gente es que
necesitan colaborar con desarrolladores en otros sistemas. Para
solventar este problema, se desarrollaron los sistemas de control de
versiones centralizados (Centralized Version Control Systems o
CVCSs en inglés). Estos sistemas, como CVS, Subversion, y Perforce,
tienen un único servidor que contiene todos los archivos
versionados, y varios clientes que descargan los archivos desde ese
lugar central. Durante muchos años éste ha sido el estándar para el
control de versiones.
Ilustración 14 Diagrama de control de versiones centralizado.
Elaboración: Victoria García Velásquez Fuente: Libro Pro Git4
4 Libro Pro Git 2da edición por Scot Chacon y Ben Strub en el año 2014 imagen extraída de la
pág. 25
35
Esta configuración ofrece muchas ventajas, especialmente frente a
VCSs locales. Por ejemplo, todo el mundo puede saber (hasta cierto
punto) en qué están trabajando los otros colaboradores del proyecto.
Los administradores tienen control detallado de qué puede hacer
cada uno; y es mucho más fácil administrar un CVCS que tener que
lidiar con bases de datos locales en cada cliente.
Sin embargo, esta configuración también tiene serias desventajas. La
más obvia es el punto único de fallo que representa el servidor
centralizado. Si ese servidor se cae durante una hora, entonces
durante esa hora nadie puede colaborar o guardar cambios
versionados de aquello en que están trabajando. Si el disco duro en el
que se encuentra la base de datos central se corrompe, y no se han
llevado copias de seguridad adecuadamente, pierdes absolutamente
todo —toda la historia del proyecto salvo aquellas instantáneas que la
gente pueda tener en sus máquinas locales. Los VCSs locales sufren
de este mismo problema— cuando tienes toda la historia del proyecto
en un único lugar, te arriesgas a perderlo todo.
Elaboración: Victoria García Velásquez Fuente web: http://www.nebaris.com/5
5 Imagen extraida del sitio Web http://www.nebaris.com/post/37/control-de-versiones-con-git-
parte-1
Ilustración 15 Forma de trabajo centralizado en un repositorio.
36
Sistemas de control de versiones distribuidos
(DVCS) Sistemas de control de versiones distribuidos fueron creados
para hacer posible la colaboración sin un servidor central, y así
superar muchos de los problemas comunes con CVCS.
Esto puede funcionar sobre la base de unos principios básicos:
• Cada colaborador tiene la historia completa revisión
• Los colaboradores pueden ramificar y fusionar entre sí fácilmente
El resultado es una arquitectura donde no hay centro técnico, y
cualquier participante potencialmente puede ser el centro: (Gyerik,
2013:14)
Elaboración: Victoria García Velásquez Fuente: Libro Bazaar Version Control6
En lugar de un servidor central con la historia completa revisión, cada
colaborador tiene la historia completa en sus / sus propias ramas
personales. Aunque técnicamente no es ninguna la necesidad de un
servidor central, por lo general hay un "oficial" común designado
pública rama de la suma del trabajo de todos los colaboradores:
6 Libro Bazaar Version Control de Jano Gyerik en el 2013 imagen extraída de la pág. 14
Ilustración 16 Representación DVCS
37
En general, un DCVS puede hacer todo lo que un CVCS puede, y
permitir a muchos adicional características. Una de las características
añadidas más interesantes es los muchos flujos de trabajo posibles
para el intercambio de revisiones entre colaboradores, tales como:
• La fusión de las revisiones peer-to-peer
• Centralizado-una rama se designa como la rama "oficial", que se
puede utilizar
por los colaboradores de la misma manera como en el control de
versiones centralizado
• Centralizada con porteros en la rama "oficial" es accesible por
mantenedores designados del proyecto, que se funden cambios peer-
to-peer y publicar comunicados en la rama "oficial" Control de
versiones distribuido es especialmente adecuado para grandes
equipos con física colaboradores desconectados, como la mayoría de
los proyectos de código abierto. Sin embargo, se puede ser igual de
útil a escalas más pequeñas también, incluso en un proyecto en
solitario. (Gyerik, 2013:15)
Elaboración: Victoria García Velásquez Fuente: Libro Bazaar Version Control 7
7 Libro Bazaar Version Control de Jano Gyerik en el 2013 imagen extraída de la pág. 15
Ilustración 17 Sistemas de Control de Versiones Distribuidas
38
2.2.6 Herramientas de Sistemas de control de versiones
Bazaar
Bazaar es una de las herramientas que despunta en el mercado para el
control de versiones, maneja con claridad los aspectos de sistema de
control distribuido, su interfaz es amigable y muy fácil de usar, es
compatible para las plataformas Linux, Windows y Mac OSX y además es
de código abierto.
Bazaar es un sistema de control de versiones distribuido, y como tal,
uno de las más poderosas herramientas de control de versiones que
existen en la actualidad. Al mismo tiempo, es amigable, flexible,
consistente y fácil de aprender. Se puede utilizar con eficacia desde
muy pequeños proyectos en solitario, a grandes proyectos
distribuidos, y todo lo demás en el medio.
Bazaar está escrito en Python, es de código abierto y totalmente
gratuito, y es un funcionario Proyecto GNU, licenciado bajo GPLv2.
Está patrocinado por Canonical, y usada por muchos proyectos
grandes, como el sistema operativo Ubuntu, Launchpad, MySQL,
OpenStack, Inkscape, y muchos otros. La página web oficial del
alojamiento Bazar proyectos es Launchpad (http://launchpad.net/),
donde puedes encontrar modelos proyectos interesantes que utilizan
Bazar. (Gyerik, 2013:16).
Elaboración: Victoria García Velásquez Fuente web: Sitio Web Bazaar8
8 Imagen extraída del Sitio Web http://bazaar.canonical.com/en/
Ilustración 18 Interfaz Bazaar
39
Subversion
Subversion es una herramienta que trabaja de manera centralizada por ello
ahora no es frecuentemente utilizada para empresas que manejan grandes
grupos de trabajo y que se necesita de modelos distribuidos, es multiplataforma
y también es de código abierto.
Subversion es un sistema de control de versiones libre / de código
abierto. Es decir, Subversion maneja ficheros y directorios a través
del tiempo. Un árbol de archivos se coloca en un centro
de repositorio. El repositorio es como un servidor de archivos
ordinario, salvo que recuerda todos los cambios que se hayan hecho
a sus archivos y directorios. Esto le permite recuperar versiones
antiguas de sus datos, o examinar la historia de cómo cambiaron sus
datos. En este sentido, muchas personas piensan de un sistema de
control de versiones como una especie de "máquina del tiempo".
Subversion puede acceder a su repositorio a través de redes, lo que
permite que pueda ser utilizado por personas en diferentes
equipos. En algún nivel, la capacidad para que varias personas
puedan modificar y administrar el mismo conjunto de datos de sus
respectivas ubicaciones fomenta la colaboración. El progreso puede
ocurrir más rápidamente sin un único conducto a través del cual
deben producirse todas las modificaciones. Y debido a que el trabajo
se versiona, no tienes que temer que la calidad es la compensación
por la pérdida de ese conducto, si se hace algún cambio incorrecto a
los datos, simplemente deshaga ese cambio.
Algunos sistemas de control de versiones también son de gestión de
configuración de software (SCM). Estos sistemas están diseñados
específicamente para manejar árboles de código fuente, y tienen
muchas características que son específicas para el desarrollo de
software, tales como la comprensión de forma nativa los lenguajes de
programación, o el suministro de herramientas para la construcción
40
de software. Subversion, sin embargo, no es uno de estos
sistemas. Se trata de un sistema general que puede ser utilizado para
manejar cualquier colección de archivos. Para usted, esos archivos
pueden ser de código para la fuente de los demás, nada de listas de la
compra de comestibles para combinaciones de vídeo digitales y más
allá. (Collins-Sussman, Fitzpatrick, & Pilato, 2005:XIV)
Elaboración: Victoria García Velásquez
Fuente: Libro Version Control with Subversion9
9 Libro Version Control with Subversion de Ben Collins-Sussman, Brian W. Fitzpatrick, C.
Michael Pilato en el 2005 imagen extraída de la pág. XVII
Ilustración 19 Arquitectura Subversion
41
GIT
Este sistema de control de versiones contiene la forma d trabajo distribuid, es de
código abierto, multiplataforma y ha legado a revolucionar los sistemas de
control de versiones distribuidas, se generó con mejoras en rapidez, modelo
amigable, diseño de ramas para evitar el desarrollo lineal, totalmente distribuido
y con capacidad de manejo de proyectos de grandes magnitudes con la
velocidad y tamaño de los datos.
Desde su nacimiento en 2005, Git ha evolucionado y madurado para
ser fácil de usar y aun así conservar estas cualidades iniciales. Es
tremendamente rápido, muy eficiente con grandes proyectos, y tiene
un increíble sistema de ramas (branching) para desarrollo no lineal
(Chacon & Straub, Pro Git 2nd Edition, 2014:27)
Instantáneas, no diferencias
La principal diferencia entre Git y cualquier otro VCS (Subversion y
compañía incluidos) es cómo Git modela sus datos.
Conceptualmente, la mayoría de los demás sistemas almacenan la
información como una lista de cambios en los archivos. Estos
sistemas (CVS, Subversion, Perforce, Bazaar, etc.) modelan la
información que almacenan como un conjunto de archivos y las
modificaciones hechas sobre cada uno de ellos a lo largo del tiempo.
(Chacon & Straub, Pro Git 2nd Edition, 2014:28)
Ilustración 20 Otros sistemas tienden a almacenar los datos como cambios
de cada archivo respecto a una versión base
Elaborado: Victoria García Velásquez. Fuente: Libro Pro Git10
10 Imagen extraída del Libro Pro Git 2nd Edition Pag. 28
42
Git no modela ni almacena sus datos de este modo. En cambio, Git
modela sus datos más como un conjunto de instantáneas de un mini
sistema de archivos. Cada vez que confirmas un cambio, o guardas el
estado de tu proyecto en Git, él básicamente hace una foto del
aspecto de todos tus archivos en ese momento, y guarda una
referencia a esa instantánea. Para ser eficiente, si los archivos no se
han modificado, Git no almacena el archivo de nuevo — sólo un
enlace al archivo anterior idéntico que ya tiene almacenado —(Chacon
& Straub, Pro Git 2nd Edition, 2014:28).
Elaborado: Victoria García Velásquez. Fuente: Libro Pro Git11
Esta es una diferencia muy importante entre Git y prácticamente
todos los demás VCSs. Hace que Git reconsidere casi todos los
aspectos del control de versiones que muchos de los demás sistemas
copiaron de la generación anterior. Esto hace a Git más como un mini
sistema de archivos con algunas herramientas tremendamente
potentes construidas sobre él, más que como un VCS. Exploraremos
algunos de los beneficios que obtienes al modelar tus datos de esta
manera cuando veamos las ramas (branching) en Git. (Chacon &
Straub, Pro Git 2nd Edition, 2014:29).
11 Imagen extraída del Libro Pro Git 2nd Edition Pag. 28
Ilustración 21 Git almacena la información como instantáneas del proyecto a lo largo del tiempo
43
Según Chacon & Straub, ( 2014), por lo genral todas las operaciones de Git son
local debido a que necesita solo de archivos y configuración local para trabajar,
que al estar acostumbrado al lento trabajo de CVCS que se produce al tranbajar
en la red, pues con Git eso no es problema y que en cuanto se empoieza a
trabajar con esta herramienta no se va a querer regresar a ninguna otra debido a
su gran rapidez dentro de la red como se tiene el proyecto en su local se
realizara de manera instantanea.
Tambien indican que Git mantiene la integirdad de sus documentos ya que es
improbable que se pueda realizar algun cambio en los archivos, directorios,
documentos etc sin que git lo registre y lo identifique en su ChemSum, esta
suma se trata de hash SHA-1.
La particularidad del los controladores de versiones es que luego de confirmar el
cambio es totalmente seguro que no se podra eliminar el cambio, tus bases de
datos en repositorio de Git permite que sea un placer trabajr sin el temor de
pensar que se puede equivocar de la forma mas grave, Git almacena la
información y la puedes recuperar en cuanto pongas en ejecución tu busquedad
dentro del repositorio.
Git tiene tres estados principales en los que se pueden encontrar tus
archivos: confirmado (committed), modificado (modified), y preparado
(staged). Confirmado significa que los datos están almacenados de
manera segura en tu base de datos local. Modificado significa que
has modificado el archivo pero todavía no lo has confirmado a tu
base de datos. Preparado significa que has marcado un archivo
modificado en su versión actual para que vaya en tu próxima
confirmación.
Esto nos lleva a las tres secciones principales de un proyecto de Git:
el directorio de Git (Git directory), el directorio de trabajo (working
directory), y el área de preparación (staging area). (Chacon & Straub,
Pro Git 2nd Edition, 2014:31)
44
Elaborado: Victoria García Velásquez. Fuente: Libro Pro Git12
El directorio de Git es donde Git almacena los metadatos y la base de
datos de objetos para tu proyecto. Es la parte más importante de Git,
y es lo que se copia cuando clonas un repositorio desde otro
ordenador.
El directorio de trabajo es una copia de una versión del proyecto.
Estos archivos se sacan de la base de datos comprimida en el
directorio de Git, y se colocan en disco para que los puedas usar o
modificar.
El área de preparación es un sencillo archivo, generalmente
contenido en tu directorio de Git, que almacena información acerca
de lo que va a ir en tu próxima confirmación. A veces se denomina el
índice, pero se está convirtiendo en estándar el referirse a ello como
el área de preparación.
12 Imagen extraída del Libro Pro Git 2nd Edition Pag. 31
Ilustración 22 Los Estados De Git
45
El flujo de trabajo básico en Git es algo así:
1. Modificas una serie de archivos en tu directorio de trabajo.
2. Preparas los archivos, añadiendo instantáneas de ellos a tu área de
preparación.
3. Confirmas los cambios, lo que toma los archivos tal y como están
en el área de preparación, y almacena esa instantánea de manera
permanente en tu directorio de Git.
Si una versión concreta de un archivo está en el directorio de Git, se
considera confirmada (committed). Si ha sufrido cambios desde que
se obtuvo del repositorio, pero ha sido añadida al área de
preparación, está preparada (staged). Y si ha sufrido cambios desde
que se obtuvo del repositorio, pero no se ha preparado, está
modificada (modified). (Chacon & Straub, 2014:31)
Gogs Git
Gogs , para Go Servicio Git, es un auto alojado repositorio git de
código abierto plataforma de alojamiento bajo licencia MIT. Escrito en
Ir, Gogs, es fácil de instalar (ya sea con o ventana acoplable con los
binarios), ligero (requisitos mínimos).
A través de una interfaz web, que le permite compartir, gestionar y
controlar la revisión de su código fuente con diferentes derechos de
acceso a diferentes personas y varias características de colaboración
(gestor de fallos,).
Gogs es también multi-plataformas (se puede ejecutar en Windows,
MacOS y Linux tipo de sistemas). Ellos aceptan MySQL, PostgreSQL
y SQLite como base de datos y pueden funcionar con Apache o
Nginx. Bastante flexible a continuación.
46
Usted puede tratar directamente su versión de demostración o seguir
los pasos de instalación siguientes para ejecutar su propia instancia
de gogs en su servidor.
Instalación
Gogs ofrece varios paquetes binarios para Debian, Ubuntu, CentOS e
incluso Arco. Por lo que la instalación será sencilla. (KARIBU, 2015)
Elaborado: Victoria García Velásquez. Fuente: http://freedif.org/gogs-opensource-alternative-to-github/
Análisis y selección de la herramienta a implementar
Al realizar un análisis entre las tres herramientas propuestas como solución
tecnológica expuesta dentro del proceso, se establece varias condicionantes que
nos aporten a evidenciar que la herramienta que conviene para implementar es
la Herramienta de control de versiones a continuación en la Tabla 3 se mostrara
un cuadro comparativo de las características de cada una de ellas, este cuadro
permitirá visualizar una serie de requerimiento que necesita este proyecto para
llegar a ser viable con respecto a las necesidades expuestas por la problemática.
Por las características mencionadas en la tabla 3 se ha seleccionado la
herramienta GIT, como solución tecnológica para este proyecto, por contar con
la mayoría de características necesarias para el óptimo desarrollo de la
aplicación.
47
Requerimientos para Selección de herramienta de control
BA
ZA
AR
SU
BV
ER
SIO
N
GIT
No necesita de un repositorio central. X X
Puede Replicar en su totalidad el repositorio, de manera que si el servidor falle se pueda restaurar con alguna copia de los clientes.
X X
Modela los datos como un conjunto de instantáneas de un mini sistema de archivos.
X
Ágil y de rendimiento eficaz X
Permite la integración de herramientas relacionadas X
Cumple con validación criptografía para el contenido, protegiendo de ataques a los repositorios.
X
Permite la revisión de un subárbol y no permite clonar. X X
Proporciona una auditoría de las ramificaciones y merge realizados.
X X
Ahorra espacio en disco realizando árbol de trabajos que se utilizan para múltiples ramas.
X
Elaborado por: Victoria García Velásquez. Fuente: Vías de investigación
Tabla 3 Análisis de Herramientas de control de versiones.
48
Tabla 4 Interfaces para Git
Elaborado por: Victoria García Velásquez Fuente: Vías de investigación13 De estas interfaces para Git se ha seleccionado SOURCE TREE, el mismo que
“simplifica la forma de interactuar con los repositorios Git y Hg para que
pueda centrarse en la codificación. Gestione todos sus repositorios -
Alojado o local - a través de la sencilla interfaz de SourceTree.” (Atlassian,
2016).
Se ha tomado como referencia esta herramienta ya que mediante análisis
cumple con los requerimiento básicos que se necesitan para realizar este
proyecto, estos requerimientos pueden ser visto en la Tabla # 5, los mismo que
resaltan que SOURCE TREE cumple con la mayoría de puntos analizados, no
13 Imágenes extraídas de la Web y extraídos de libros Introducing GitHub Pag.24, Libro GitLab
Repository Management Pág. 6 y la web http://hipertextual.com/archivo/2014/05/github-y-
bitbucket/ y https://www.atlassian.com/software/sourcetree/overview
49
es requisito obligatorio que se tome esta herramienta como cliente para
interactuar con el Git del servidor, pues el usuario podrá utilizar el cliente para Git
que más se ajuste a sus necesidades y conocimiento.
Tabla 5 Requerimientos para cliente Git
Requerimientos para GUI de GIT
SO
UR
CE
TR
EE
GIT
HU
B
GIT
LA
B
Es compatible con Windows X X
Es de total acceso local como cliente. X
X
Guarda total privacidad gratuita. X
X
no requiere de muchos comandos para realizar las actividades con ramas, empujar entre otras
X
Permite la integración de herramientas relacionadas X
Es de fácil entendimiento y control. X X
Tiene interfaz web.
X X
Los repositorios privados no tienen costos en la web
X
Elaborado por: Victoria García Velásquez. Fuente: Vías de investigación
50
1.2 FUNDAMENTACIÓN LEGAL
2.2.7 CAPÍTULO V.- DE LA GESTIÓN DEL RIESGO OPERATIVO (14)
SECCIÓN I.- ÁMBITO, DEFINICIONES Y ALCANCE
ARTÍCULO 2.- Para efectos de la aplicación de las disposiciones del
presente capítulo, se considerarán las siguientes definiciones:
2.11 Datos.- Es cualquier forma de registro electrónico, óptico,
magnético, impreso o en otros medios, susceptible de ser capturado,
almacenado, procesado y distribuido;
2.12 Información.- Es cualquier forma de registro electrónico, óptico,
magnético o en otros medios, previamente procesado a partir de
datos, que puede ser almacenado, distribuido y sirve para análisis,
estudios, toma de decisiones, ejecución de una transacción o entrega
de un servicio;
2.13 Información crítica.- Es la información considerada esencial para la
continuidad del negocio y para la adecuada toma de decisiones;
2.14 Administración de la información.- Es el proceso mediante el cual
se captura, procesa, almacena y transmite información,
independientemente del medio que se utilice; ya sea impreso, escrito
en papel, almacenado electrónicamente, transmitido por correo o por
medios electrónicos o presentado en imágenes;
2.15 Tecnología de la información.- Es el conjunto de herramientas y
métodos empleados para llevar a cabo la administración de la
información. Incluye el hardware, software, sistemas operativos,
sistemas de administración de bases de datos, redes, multimedia,
(14) Constitución de la República del Ecuador – Asamblea Constituyente - DE LA
GESTIÓN DEL RIESGO OPERATIVO (incluido con resolución No JB-2005-834 de 20 de
octubre del 2005 Administración del Sr. Ec. Rafael Correa Delgado)
51
servicios asociados, entre otros; (reformado con resolución No. JB-
2014-3066 de 2 de septiembre del 2014)
2.16 Aplicación.- Se refiere a los procedimientos programados a través
de alguna herramienta tecnológica, que permiten la administración de
la información y la oportuna toma de decisiones;
2.17 Instalaciones.- Es la infraestructura que permite alojar los recursos
físicos relacionados con la tecnología de la información; (reformado
con resolución No. JB-2014- 3066 de 2 de septiembre del 2014)
2.18 Responsable de la información.- Es la persona encargada de cuidar
la integridad, confidencialidad y disponibilidad de la información;
debe tener autoridad para especificar y exigir las medidas de
seguridad necesarias para cumplir con sus responsabilidades;
(sustituido con resolución No. JB-2014-3066 de 2 de septiembre del
2014)
2.19 Seguridad de la información.- Son los mecanismos implantados que
garantizan la confidencialidad, integridad y disponibilidad de la
información y los recursos relacionados con ella;
2.20 Seguridades lógicas.- Se refieren a la seguridad en el uso del
software, la protección de los datos, procesos y programas, así como
la del acceso ordenado y autorizado de los usuarios a la información;
2.43 Incidente de tecnología de la información.- Evento asociado a
posibles fallas en la tecnología de la información, fallas en los
controles, o situaciones con probabilidad significativa de
comprometer las operaciones del negocio; y, (incluido con resolución
No. JB-2014-3066 de 2 de septiembre del 2014)
2.44 Incidente de seguridad de la información.- Evento asociado a
posibles fallas en la seguridad de la información, o una situación con
52
probabilidad significativa de comprometer las operaciones del
negocio y amenazar la seguridad de la información. (Incluido con
resolución No. JB-2014-3066 de 2 de septiembre del 2014)
2.2.8 SECCIÓN II.- FACTORES DEL RIESGO OPERATIVO15
4.3 Tecnología de la información.- Las instituciones controladas deben
contar con la tecnología de la información que garantice la captura,
procesamiento, almacenamiento y transmisión de la información de
manera oportuna y confiable; evitar interrupciones del negocio y
lograr que la información, inclusive aquella bajo la modalidad de
servicios provistos por terceros, sea íntegra, confidencial y esté
disponible para una apropiada toma de decisiones. (reformado con
resolución No. JB- 2014-3066 de 2 de septiembre del 2014) Para
considerar la existencia de un apropiado ambiente de gestión de
riesgo operativo, las instituciones controladas deberán definir
políticas, procesos, procedimientos y metodologías que aseguren
una adecuada planificación y administración de la tecnología de la
información. (inciso reformado con resolución No. JB-2014-3066 de
2 de septiembre del 2014) Dichas políticas, procesos,
procedimientos y metodologías se referirán a: (inciso reformado con
resolución No. JB-2014-3066 de 2 de septiembre del 2014)
4.3.1 Con el objeto de garantizar que la administración de la
tecnología de la información soporte adecuadamente
los requerimientos de operación actuales y futuros de
la entidad, las instituciones controladas deben contar
al menos con lo siguiente: (reformado con resolución
No. JB-2014-3066 de 2 de septiembre del 2014)
4.3.1.4 Tecnología de la información acorde a las
operaciones del negocio y al volumen de
15 Constitución de la República del Ecuador – Asamblea Constituyente - Resolución No. JB- 2014-3066 de 2 de septiembre del 2014 (Administración del Sr. Ec. Rafael Correa Delgado)
53
transacciones, monitoreada y proyectada según las
necesidades y crecimiento de la institución, con su
correspondiente portafolio de proyectos
tecnológicos a ejecutarse en el corto, mediano y
largo plazo; (reformado con resolución No. JB-
2014-3066 de 2 de septiembre del 2014)
4.3.1.5 Políticas, procesos, procedimientos y metodologías
de tecnología de la información definidos bajo
estándares de general aceptación que garanticen la
ejecución de los criterios de control interno de
eficacia, eficiencia y cumplimiento, alineados a los
objetivos y actividades de la institución, así como
las consecuencias de la violación de éstas. (numeral
sustituido con resolución No. JB-2014-3066 de 2 de
septiembre del 2014)
Los procesos, procedimientos y metodologías de
tecnología de la información deben ser revisados
por el comité de tecnología y propuestos para la
posterior aprobación del directorio o el organismo
que haga sus veces;
4.3.1.6 Difusión y comunicación a todo el personal
involucrado de las mencionadas políticas, procesos,
procedimientos y metodologías, de tal forma que se
asegure su implementación; y, (reformado con
resolución No. JB-2014-3066 de 2 de septiembre del
2014)
4.3.1.7 Una metodología de administración de proyectos que
considere al menos su planificación, ejecución, control
y cierre, enfocada en la optimización de recursos y la
54
gestión de riesgos. (incluido con resolución No. JB-
2014-3066 de 2 de septiembre del 2014)
4.3.2 Con el objeto de garantizar que las operaciones de tecnología
de la información satisfagan los requerimientos de la entidad,
las instituciones controladas deben contar al menos con lo
siguiente: (reformado con resolución No. JB-2014-3066 de 2
de septiembre del 2014)
4.3.2.1 Procedimientos que establezcan las actividades y
responsables de la operación y el uso de las
instalaciones de procesamiento de información;
(sustituido con resolución No. JB-2014-3066 de 2 de
septiembre del 2014)
4.3.2.2 Procedimientos de gestión de incidentes de tecnología
de la información, que considere al menos su
registro, priorización, análisis, escalamiento y
solución; (sustituido con resolución No. JB- 2014-
3066 de 2 de septiembre del 2014)
4.3.3 Con el objeto de garantizar que el proceso de adquisición,
desarrollo, implementación y mantenimiento de las aplicaciones
satisfagan los objetivos del negocio, las instituciones
controladas deben contar al menos con lo siguiente:
4.3.3.1 Requerimientos contractuales convenidos que definan
la propiedad de la información y de las aplicaciones;
y, la responsabilidad de la empresa proveedora de la
tecnología en caso de ser vulnerables sus sistemas, a
fin de mantener la integridad, disponibilidad y
confidencialidad de la información; y,
55
4.3.3.2 Requerimientos contractuales convenidos que
establezcan que las aplicaciones sean
parametrizables, que exista una transferencia del
conocimiento y que se entregue documentación
técnica y de usuario, a fin de reducir la dependencia
de las instituciones controladas con proveedores
externos y los eventos de riesgo operativo que esto
origina.
4.3.4 Con el objeto de garantizar que el sistema de administración de
seguridad satisfaga las necesidades de la entidad para
salvaguardar la información REPUBLICA DEL ECUADOR
SUPERINTENDENCIA DE BANCOS Y SEGUROS 256 contra el
uso, revelación y modificación no autorizados, así como daños
y pérdidas, las instituciones controladas deben contar al menos
con lo siguiente:
4.3.4.1 Políticas y procedimientos de seguridad de la
información que establezcan sus objetivos,
importancia, normas, principios, requisitos de
cumplimiento, responsabilidades y comunicación de
los incidentes relativos a la seguridad; considerando
los aspectos legales, así como las consecuencias de
violación de estas políticas;
4.3.4.2 La identificación de los requerimientos de seguridad
relacionados con la tecnología de información,
considerando principalmente: la evaluación de los
riesgos que enfrenta la institución; los requisitos
legales, normativos, reglamentarios y contractuales;
y, el conjunto específico de principios, objetivos y
condiciones para el procesamiento de la información
que respalda sus operaciones;
56
4.3.4.3 Los controles necesarios para asegurar la integridad,
disponibilidad y confidencialidad de la información
administrada;
4.3.4.4 Un sistema de administración de las seguridades de
acceso a la información, que defina las facultades y
atributos de los usuarios, desde el registro,
eliminación y modificación, pistas de auditoría;
además de los controles necesarios que permitan
verificar su cumplimiento en todos los ambientes de
procesamiento;
4.3.4.5 Niveles de autorización de accesos y ejecución de las
funciones de procesamiento de las aplicaciones,
formalmente establecidos, que garanticen una
adecuada segregación de funciones y reduzcan el
riesgo de error o fraude;
4.3.4.6 Adecuados sistemas de control y autenticación para
evitar accesos no autorizados, inclusive de terceros;
y, ataques externos especialmente a la información
crítica y a las instalaciones de procesamiento;
4.3.4.7 Controles adecuados para detectar y evitar la
instalación de software no autorizado o sin la
respectiva licencia, así como instalar y actualizar
periódicamente aplicaciones de detección y
desinfección de virus informáticos y demás software
maliciosos;
4.3.4.8 Controles formales para proteger la información
contenida en documentos; medios de
almacenamiento u otros dispositivos externos; el uso
e intercambio electrónico de datos contra daño, robo,
57
accesos, utilización o divulgación no autorizada de
información para fines contrarios a los intereses de la
entidad, por parte de todo su personal y de sus
proveedores;
4.3.4.9 Instalaciones de procesamiento de información crítica
en áreas protegidas con los suficientes controles que
eviten el acceso de personal no autorizado y daños a
los equipos de computación y a la información en
ellos procesada, almacenada o distribuida;
4.3.5 Con el objeto de garantizar la continuidad de las operaciones,
las instituciones controladas deben contar al menos con lo
siguiente:
4.3.5.1 Controles para minimizar riesgos potenciales de sus
equipos de computación ante eventos imprevistos,
tales como: fallas, daños o insuficiencia de los
recursos de tecnología de información; robo;
incendio; humo; inundaciones; polvo; interrupciones
en el fluido eléctrico, desastres naturales; entre
otros;
4.3.5.2 Políticas y procedimientos de respaldo de información
periódicos, que aseguren al menos que la
información crítica pueda ser recuperada en caso de
falla de la tecnología de información o con
posterioridad a un evento inesperado;
4.3.5.3 Mantener los sistemas de comunicación y redundancia
de los mismos que permitan garantizar la continuidad
de sus servicios; y,
58
4.3.5.4 Información de respaldo y procedimientos de
restauración en una ubicación remota, a una
distancia adecuada que garantice su disponibilidad
ante eventos de desastre en el centro principal de
procesamiento.
4.3.6 Con el objeto de garantizar que el proceso de adquisición,
desarrollo, implementación y mantenimiento de las aplicaciones
satisfagan los objetivos del negocio, las instituciones
controladas deben contar al menos con lo siguiente:
4.3.6.1 Una metodología que permita la adecuada
administración y control del proceso de compra de
software y del ciclo de vida de desarrollo y
mantenimiento de aplicaciones, con la aceptación de
los usuarios involucrados;
4.3.6.2 Documentación técnica y de usuario permanentemente
actualizada de las aplicaciones de la institución;
4.3.6.3 Controles que permitan asegurar la adecuada
administración de versiones de las aplicaciones
puestas en producción; y,
4.3.6.4 Controles que permitan asegurar que la calidad de la
información sometida a migración, cumple con las
características de integridad, disponibilidad y
confidencialidad.
4.3.7 Con el objeto de garantizar que la infraestructura tecnológica
que soporta las operaciones, sea administrada, monitoreada y
documentada de forma adecuada, las instituciones controladas
deberán contar con políticas y procedimientos que permitan la
adecuada administración, monitoreo y documentación de las
bases de datos, redes de datos, software de base y hardware.
59
4.4 Eventos externos.- En la administración del riesgo operativo,
las instituciones controladas deben considerar la posibilidad de
pérdidas derivadas de la ocurrencia de eventos ajenos a su
control, tales como: fallas en los servicios públicos, ocurrencia de
desastres naturales, atentados y otros actos delictivos, los cuales
pudieran alterar el desarrollo normal de sus actividades. Para el
efecto, deben contar con planes de contingencia y de continuidad
del negocio. (Constituyente, 2014)
2.2.9 LEY DE PROPIEDAD INTELECTUAL
TITULO PRELIMINAR
Art. 3. El Instituto Ecuatoriano de la Propiedad Intelectual (IEPI), es el
Organismo Administrativo competente para propiciar, promover,
fomentar, prevenir, proteger y defender a nombre del Estado
Ecuatoriano, los derechos de propiedad intelectual reconocidos en la
presente Ley y en los tratados y convenios internacionales, sin
perjuicio de las acciones civiles y penales que sobre esta materia
deberán conocerse por la Función Judicial.
2.2.10 DE LOS DERECHOS DE AUTOR Y
DERECHOS CONEXOS
CAPITULO I
DEL DERECHO DE AUTOR
SECCIÓN I
Art. 4. Se reconocen y garantizan los derechos de los autores y los
derechos de los demás titulares sobre sus obras.
Art. 6. El derecho de autor es independiente, compatible y
acumulable con:
60
a) La propiedad y otros derechos que tengan por objeto la cosa
material a la que esté incorporada la obra;
b) Los derechos de propiedad industrial que puedan existir sobre la
obra; y,
c) Los otros derechos de propiedad intelectual reconocidos por la
ley.
Art. 7. Para los efectos de este Título los términos señalados a
continuación tendrán los siguientes significados:
Autor: Persona natural que realiza la creación intelectual.
Artista intérprete o ejecutante: Persona que representa, canta, lee,
recita, interpreta o ejecuta en cualquier forma una obra.
Ámbito doméstico: Marco de las reuniones familiares, realizadas en la
casa de habitación que sirve como sede natural del hogar.
Base de datos: Compilación de obras, hechos o datos en forma
impresa, en una unidad de almacenamiento de ordenador o de
cualquier otra forma.
Causahabiente: Persona natural o jurídica que por cualquier título ha
adquirido derechos reconocidos en este Título.
Emisión: Difusión a distancia de sonidos, de imágenes o de ambos,
por cualquier medio o procedimiento, conocido o por conocerse, con
o sin la utilización de satélites, para su recepción por el público.
Comprende también la producción de señales desde una estación
terrestre hacia un satélite de radiodifusión o de telecomunicación.
61
Fijación: Incorporación de signos, sonidos, imágenes o su
representación digital, sobre una base material que permita su
lectura, percepción, reproducción, comunicación o utilización.
Licencia: Autorización o permiso que concede el titular de los
derechos al usuario de la obra u otra producción protegida, para
utilizarla en la forma determinada y de conformidad con las
condiciones convenidas en el contrato. No transfiere la titularidad de
los derechos.
Productor: Persona natural o jurídica que tiene la iniciativa, la
coordinación y la responsabilidad en la producción de una obra, por
ejemplo, de la obra audiovisual, o del programa de ordenador.
Productor de fonogramas: Persona natural o jurídica bajo cuya
iniciativa, responsabilidad y coordinación se fijan por primera vez los
sonidos de una ejecución, u otros sonidos o sus representaciones
digitales.
Programa de ordenador (software): Toda secuencia de instrucciones
o indicaciones destinadas a ser utilizadas, directa o indirectamente,
en un dispositivo de lectura automatizada, ordenador, o aparato
electrónico o similar con capacidad de procesar información, para la
realización de una función o tarea, u obtención de un resultado
determinado, cualquiera que fuere su forma de expresión o fijación.
El programa de ordenador comprende también la documentación
preparatoria, planes y diseños, la documentación técnica, y los
manuales de uso.
Titularidad: Calidad de la persona natural o jurídica, de titular de los
derechos reconocidos por el presente Libro.
SECCIÓN II
OBJETO DEL DERECHO DE AUTOR
62
Art. 8. La protección del derecho de autor recae sobre todas las
obras del ingenio, en el ámbito literario o artístico, cualquiera que sea
su género, forma de expresión, mérito o finalidad. Los derechos
reconocidos por el presente Título son independientes de la
propiedad del objeto material en el cual está incorporada la obra y su
goce o ejercicio no están supeditados al requisito del registro o al
cumplimiento de cualquier otra formalidad.
Las obras protegidas comprenden, entre otras, las siguientes:
- a. Libros, folletos, impresos, epistolarios, artículos, novelas,
cuentos, poemas, crónicas, críticas, ensayos, misivas, guiones para
teatro, cinematografía, televisión, conferencias, discursos, lecciones,
sermones, alegatos en derecho, memorias y otras obras de similar
naturaleza, expresadas en cualquier forma;
- b. Colecciones de obras, tales como antologías o compilaciones
y bases de datos de toda clase, que por la selección o disposición de
las materias constituyan creaciones intelectuales, sin perjuicio de los
derechos de autor que subsistan sobre los materiales o datos;
- g. Proyectos, planos, maquetas y diseños de obras
arquitectónicas y de ingeniería;
- k. Programas de ordenador; y,
- i. Adaptaciones, traducciones, arreglos, revisiones,
actualizaciones y anotaciones; compendios, resúmenes y extractos;
y, otras transformaciones de una obra, realizadas con expresa
autorización de los autores de las obras originales, y sin perjuicio
de sus derechos.
SECCIÓN V
63
2.2.11 DISPOSICIONES ESPECIALES SOBRE CIERTAS OBRAS
PARÁGRAFO PRIMERO DE LOS PROGRAMAS DE ORDENADOR
Art. 28. Los programas de ordenador se consideran obras literarias y
se protegen como tales. Dicha protección se otorga
independientemente de que hayan sido incorporados en un
ordenador y cualquiera sea la forma en que estén expresados, ya sea
en forma legible por el hombre (código fuente) o en forma legible por
máquina (código objeto), ya sean programas operativos y programas
aplicativos, incluyendo diagramas de flujo, planos, manuales de uso,
y en general, aquellos elementos que conformen la estructura,
secuencia y organización del programa.
Art. 29. Es titular de un programa de ordenador, el productor, esto es
la persona natural o jurídica que toma la iniciativa y responsabilidad
de la realización de la obra. Se considerará titular, salvo prueba en
contrario, a la persona cuyo nombre conste en la obra o sus copias
de la forma usual.
Dicho titular está además legitimado para ejercer en nombre propio
los derechos morales sobre la obra, incluyendo la facultad para
decidir sobre su divulgación.
El productor tendrá el derecho exclusivo de realizar, autorizar o
prohibir la realización de modificaciones o versiones sucesivas del
programa, y de programas derivados del mismo.
Las disposiciones del presente artículo podrán ser modificadas
mediante acuerdo entre los autores y el productor.
Art. 30. La adquisición de un ejemplar de un programa de ordenador
que haya circulado lícitamente, autoriza a su propietario a realizar
exclusivamente:
64
a) Una copia de la versión del programa legible por máquina (código
objeto) con fines de seguridad o resguardo;
b) Fijar el programa en la memoria interna del aparato, ya sea que dicha
fijación desaparezca o no al apagarlo, con el único fin y en la medida
necesaria para utilizar el programa; y,
c) Salvo prohibición expresa, adaptar el programa para su exclusivo uso
personal, siempre que se limite al uso normal previsto en la licencia.
El adquirente no podrá transferir a ningún título el soporte que
contenga el programa así adaptado, ni podrá utilizarlo de ninguna
otra forma sin autorización expresa, según las reglas generales.
Se requerirá de autorización del titular de los derechos para
cualquier otra utilización, inclusive la reproducción para fines de uso
personal o el aprovechamiento del programa por varias personas, a
través de redes u otros sistemas análogos, conocidos o por
conocerse.
Art. 31. No se considerará que exista arrendamiento de un programa
de ordenador cuando éste no sea el objeto esencial de dicho
contrato. Se considerará que el programa es el objeto esencial
cuando la funcionalidad del objeto materia del contrato, dependa
directamente del programa de ordenador suministrado con dicho
objeto; como cuando se arrienda un ordenador con programas de
ordenador instalados previamente.
Art. 32. Las excepciones al derecho de autor establecidas en los
artículos 30 y 31 son las únicas aplicables respecto a los programas
de ordenador.
Las normas contenidas en el presente Parágrafo se interpretarán de
manera que su aplicación no perjudique la normal explotación de la
obra o los intereses legítimos del titular de los derechos.
(Constituyente, 2014)
65
2.3 PREGUNTA CIENTÍFICA A CONTESTARSE
¿Una herramienta de control de versiones dentro del programa continuo
PROMEINFO, para el control, supervisión y ordenamiento de los proyectos
aplicaciones y archivos en general se podría ver reflejado en los proceso en la
agilidad de distribuir los proyectos mejorando en tiempo de trabajo, habilitación
de recursos y costos?
2.4 DEFINICIONES CONCEPTUALES
Sistema de información (SI)
Es un conjunto de elementos organizados, relacionados y
coordinados entre sí, encargados de facilitar el funcionamiento global
de una empresa o de cualquier otra actividad humana para conseguir
sus objetivos.
Recursos
Pueden ser físicos, como ordenadores, componentes, periféricos y
conexiones, recursos no informáticos; y lógicos, como sistemas
operativos y aplicaciones informáticas.
Equipo humano
Compuesto por las personas que trabajan para la organización.
Información
Conjunto de datos organizados que tienen un significado. La
información puede estar contenida en cualquier tipo de soporte.
Actividades
A realizan en la organización, relacionadas o no con la informática.
Sistemas informáticos
Está constituido por un conjunto de elementos físicos (hardware,
dispositivos, periféricos y conexiones), lógicos (sistemas operativos,
66
aplicaciones, protocolos…) y con frecuencia se incluyen también los
elementos humanos (personal experto que maneja el software y el
hardware). (López, 2010:8)
Repositorio
Es un término que tiene su raíz etimológica en repositorĭum, un
vocablo latino. Un repositorio es un espacio que se utiliza
para almacenar distintas cosas. Por ejemplo: “El repositorio de la
distribuidora de alimentos queda a dos kilómetros de distancia”, “Las
autoridades deben proteger este importante repositorio de agua
dulce”, “Esta nueva biblioteca se constituirá como un repositorio de
conocimientos a disposición de toda la población”.
Puede asociarse la idea de repositorio al concepto de archivo o
de depósito. En un repositorio, se guarda algo, que puede ser
material (físico) o simbólico. En este sentido, actualmente se suele
hacer referencia a las bases de datos digitales y a diversos sistemas
informáticos como repositorios.16 (Definicion.De,2015)
Ramas
Puede tratarse de aquello que se constituye como lo secundario de
algo central, de lo cual procede o emana.17 (Definicion.De, 2015)
Una rama es el medio fundamental de poner en marcha una línea
separada de desarrollo dentro de un proyecto de software. Una rama
es una división de una especie de estado primitivo unificada,
permitiendo para continuar el desarrollo en múltiples direcciones
simultáneamente y potencialmente, al producir diferentes versiones
del proyecto. A menudo, una rama se reconcilia y se fusionó con
otras ramas para reunir esfuerzos dispares. (Loeliger & Matthew
McCullough, 2012:89)
16 Lee todo en: Definición de repositorio - Qué es, Significado y Concepto
http://definicion.de/repositorio/#ixzz3rISsfZvx
17Lee todo en: Definición de repositorio - Qué es, Significado y Concepto
http://definicion.de/rama/#ixzz3rIYQsLWo
67
Bases de Datos
“Una base de datos es un conjunto de datos almacenados en
memoria externa que están organizados mediante una estructura de
datos.” (Marqués, 2011:2)
Control
La palabra control proviene del término francés contrôle y
significa comprobación, inspección, fiscalización o intervención.
También puede hacer referencia al dominio, mando y preponderancia,
o a la regulación sobre un sistema.18 (Definicion.De, 2015)
Control de versiones
Un sistema capaz de grabar los cambios realizados en un archivo o
un conjunto de archivos a través de un período de tiempo de tal
manera que nos permite obtener en el tiempo desde el futuro para
recuperar una versión específica de ese archivo, se llama control de
versiones del sistema.
Para una explicación más formal, un sistema de control de versiones
es un paquete de software que cuando inició supervisará sus
archivos de cambios y permitir etiquetar los cambios en los
diferentes niveles para que pueda volver a los escenarios con
etiqueta siempre que sea necesario. (Somasundaram, 2013:8)
Sistema de control de versiones distribuido
En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no
sólo descargan la última instantánea de los archivos: replican
completamente el repositorio. Así, si un servidor muere, y estos
sistemas estaban colaborando a través de él, cualquiera de los
repositorios de los clientes puede copiarse en el servidor para
restaurarlo. Cada vez que se descarga una instantánea, en realidad se
hace una copia de seguridad completa de todos los datos. (Chacon &
Straub, 2014:26)
18 Lee todo en: Definición de repositorio - Qué es, Significado y Concepto
http://definicion.de/control/#ixzz3rJJIAaja
68
Interfaz
Es un término que procede del vocablo inglés interface.
En informática, esta noción sirve para señalar a la conexión que se da
de manera física y a nivel de utilidad entre dispositivos o sistemas.
La interfaz, por lo tanto, es una conexión entre dos máquinas de
cualquier tipo, a las cuales les brinda un soporte para la
comunicación a diferentes estratos. Es posible entender la interfaz
como un espacio (el lugar donde se desarrolla la interacción y el
intercambio), instrumento (a modo de extensión del cuerpo humano,
como el mouse que permite interactuar con una computadora) o
superficie (el objeto que aporta información a través de su textura,
forma o color).
Cuando hacemos utilización del término interfaz dentro del sector de
Internet, del mundo web, tendríamos que decir que aquel se emplea
para referirse a todo el conjunto de elementos que aparecen
reflejados en la pantalla y que permiten al usuario llevar a cabo
diversas acciones concretas.
En concreto, la interfaz estará compuesta, además de elementos de
acción, de alternativas en cuanto a navegación, identificación y, por
supuesto, contenidos.19 (Definicion.De, 2015)
Seguridad
Una de las acepciones de la RAE para el término seguro, que es la
que aquí nos interesa, es la de estar libre y exento de todo peligro,
daño o riesgo. Este es el concepto en el que se basa el contenido de
este libro y tiene el mismo sentido aplicado a sistemas de
información y sistemas informáticos. (López, 2010:9)
Información
Está constituida por un grupo de datos ya supervisados y ordenados,
que sirven para construir un mensaje basado en un cierto fenómeno o
ente. La información permite resolver problemas y tomar decisiones,
19 Lee todo en: Definición de repositorio - Qué es, Significado y Concepto
http://definicion.de/interfaz/#ixzz3rJM6YfPM
69
ya que su aprovechamiento racional es la base del conocimiento.20
(Definicion.De,2015)
Confirmaciones puntuales
La forma canónica de referirse a una confirmación de cambios es
indicando su código-resumen criptográfico SHA-1. Pero también
existen otras maneras más sencillas. En esta sección se verán las
diversas formas existentes para referirse a una determinada
confirmación de cambios (commit). (Chacon & Straub, Pro Git 2nd
Edition, 2014:249)
SHA cortó
Simplemente dándole los primeros caracteres del código SHA-1, Git
es lo suficientemente inteligente como para figurarse cuál es la
confirmación de cambios (commit) deseada. Es necesario teclear por
lo menos 4 caracteres y estos han de ser no ambiguos — es decir,
debe existir un solo objeto en el repositorio cuyo código comience
por dicho trozo inicial del SHA —. (Chacon & Straub, Pro Git 2nd
Edition, 2014:249)
Open source
Es una expresión de la lengua inglesa que pertenece al ámbito de
la informática. Aunque puede traducirse como “fuente abierta”, suele
emplearse en nuestro idioma directamente en su versión original, sin
su traducción correspondiente.
Se califica como open source, por lo tanto, a los programas
informáticos que permiten el acceso a su código de programación, lo
que facilita modificaciones por parte de otros programadores ajenos
a los creadores originales del software en cuestión. (Definicion.De,
2015)21
20 Lee todo en: Definición de repositorio - Qué es, Significado y Concepto
http://definicion.de/informacion/#ixzz3rJkqugkj 21 Lee todo en: Definición de repositorio - Qué es, Significado y Concepto
http://definicion.de/open-source/#ixzz3rJhOBlhc
70
CAPÍTULO III
3.1 PROPUESTA TECNOLÓGICA
El éxito de un proyecto está determinado por el grado de factibilidad
que se presente en cada una de los tres aspectos. Para esto se realiza
un estudio de factibilidad que sirve para recopilar datos relevantes
sobre el desarrollo de un proyecto y en base a ello tomar la mejor
decisión, si procede su estudio, desarrollo o implementación. (DX,
2013)22
3.1.1 Análisis de factibilidad
El proyecto dirigido al aporte con el programa continuo PROMEINFO, es
totalmente factible para el manejo, organización y progreso del desarrollo del
sistema, la continuidad del desarrollo entre programadores para que sea posible
el avance del proyecto de manera fluida y sin interrupciones es el objetivo, en
este análisis demostraremos cuan factible puede llegar a ser con respecto a la
funcionalidad en el ambiente de instalación , la información técnica y los costos –
beneficios, los cuales aportaran con la toma de la decisión para proceder con el
proyecto.
3.1.2 Factibilidad Operacional
Este proyecto está dirigido para que sea manejado por personal de áreas a
fines a sistemas en especial desarrolladores de sistemas, manejo de bases de
datos ente otros, por lo tanto los usuarios deberán tener conocimiento en manejo
de comandos y tener conocimientos en el área tecnológica de acuerdo al manejo
de los archivos y documentos que se manejara dentro del sistema de control de
versión.
¿Es conveniente insertar el proyecto dentro de PromeInfo?
¿La adaptación del proyecto podría llegar a causar malestar entre los usuarios?
¿Cumple el proyecto con lo solicitado por el cliente?
22 Mensaje extraído de la Web http://es.slideshare.net/helodtk1/factibilidad-tecnica-operativa-y-
economica-20908957
71
3.1.3 Factibilidad técnica
Este Proyecto cumple con lo propuesto al cliente, para resguardas el control del
cambio de sus bases de datos y el acceso de colaboradores a sus proyectos de
desarrollo, adicional este proyecto se ejecutara en equipos específicos de
características básicas para el correcto funcionamiento de la herramienta,
detalladas en la Tabla 4.
Tabla 6 Factibilidad técnica del proyecto
REQUERIMIENTO ACTIVIDAD
Servidor
Procesador Intel Xeon Este servidor será utilizado para instalar la herramienta que permitirá que el servido se convierta en el repositorio central, donde se manejaran los proyectos en general del cliente.
Velocidad 3.1 GHz
Memoria Ram 4 Gb
Disco Duro 500 Gb
Velocidad del Disco 7200
Sistema Operativo
Windows Serve 2008 R2 o Posteriores
Ordenadores
Procesador Quad Core Cada recurso deberá tener su ambiente de desarrollo y también debe contar con la herramienta en s escritorio para realizar las descargas y actualizaciones de los proyectos.
Velocidad 2.4 GHz
Memoria Ram 4 Gb
Disco Duro 500 Gb
Velocidad del Disco 7200
Sistema Operativo Windows 7 o Posteriores
Recursos
Personal del área de Sistemas
Junior El personal deberá ser capacitado en la herramienta para que pueda utilizar los beneficios de la misma.
Semi Senior
Senior
Pasantes de área de Sistemas
Junior
Semi Senior
Senior
Redes
Router Realizar la conexión con la red.
Elaborado por: Victoria García Velásquez Fuente: Vías de investigación
72
3.1.4 Factibilidad Legal
Según los estatus, normas y reglamentos con respecto a la propiedad intelectual,
este proyecto no infringe en ninguna forma posible lo establecido en la misma,
debido a que se desarrolla en base a lo aprendido a lo largo de la carrera
profesional y desarrollada de forma personalizada.
De la misma forma no incurre en falta alguna con el derecho de autor ya que
todas las ideas, conocimientos y experiencias tomadas de libros, folletos,
revistas científicas entre otros, han sido debidamente mencionados como lo
establece las normas APA 6ta edición y las leyes vigentes.
El software y herramientas utilizados son de libre uso (open Source), esto nos
garantiza el completo y absoluto cumplimiento dentro del margen de la ley.
3.1.5 Factibilidad Económica
En la Tabla 6, se justificaran los valores a invertir y sus beneficios desde el punto
de vista de recuperación inmediata, continuidad del negocio y el control de
versiones.
Tabla 7 Factibilidad Económica Costo-Beneficios
REQUERIMIENTO COSTO DIRECTOS
COSTOS INDIRECTOS
BENEFICIOS
Servidor $ 1,000.00 $ - El no contar con un equipo Servidor para el respaldo de la información y controlar las modificaciones que se realicen en el sistema o proyectos, se expone a que puedan ocurrir cualquier tipo de incidencias algunas con consecuencias fatales que pueden costar hasta millones de dólares y perdidas de clientes.
Ordenadores $ - $ 400.00
Recursos $ - $ 354.00
Herramienta de Control de versiones
$ - $ -
Router $ 150.00 $ -
Elaborado por: Victoria García Velásquez Fuente: Vías de investigación.
73
3.2 Etapa de la metodología del desarrollo
Gestión de integración
Ante Proyecto
Se realizó la entrega de un ante proyecto para dar a conocer la propuesta al
cliente, esperando que el mismo sea aceptado en su propuesta inicial y luego de
saber si la decisión es favorable se empezara a desarrollar el proyecto el mismo
que se realizará con el compromiso entre los representantes de Promeinfo y el
grupo de trabajo.
Dicho ante proyecto podrá ser revisada en el anexo 3, para que sirva de
constancia y pueda ser utilizada para fines pertinentes.
Plan de Gestión del proyecto
Para la planificación del plan de gestión del proyecto se realizara los siguientes
pasos para obtener los mejores resultados por etapas:
Plan de gestión alcance el cual nos permitirá recopilar los requisitos y
requerimientos que se requiere.
Se realizará el plan de Gestión tiempo quien nos ayudara con la
planificación de las actividades tomara en cuenta las actividades a
realizar , la secuencia a seguir , definir los recursos humanos, la duración
del proyecto y su debido cronograma
Se definirán el plan gestión de costos que nos reflejara los costos a
considerar y realizar un presupuesto acorde a lo estimado dentro del
proyecto.
Se llevará a cabo también el plan de calidad del proyecto.
Se considerara el plan de recursos humanos.
Para amortiguar los riesgos y consecuencias se tomara en cuenta el plan
de Riesgos, que identificara los diferentes riesgos y sus respectivos
análisis, para que en caso de suceder alguna anomalía se pueda dar
respuestas inmediatas a la situación.
Se analizara el plan de compras si fuese necesario.
74
y por último se realizara un plan gestión de los interesados, para llegar a
un acuerdo de lo solicitado.
En el anexo 3, se puede revisar más detalles acerca del formato realizado para
el plan de gestión del proyecto.
Dirigir y manejar el proyecto
Para manejar el manejo del proyecto seguiremos los siguientes pasos:
Se buscara formas de realizar el aseguramiento de la calidad del
proyecto.
Se estimara la adquisición, desarrollo y gestión de equipos de ser
necesarios.
Compra de Equipos y Software de ser necesario.
Y se medirá la gestión del compromiso de los interesados para la
adquisición o facilitar los equipos o recursos necesarios para implantar el
proyecto.
Monitoreo y control del trabajo y de cambios
Para garantizar que el proceso o etapas de la dirección del proyecto se
realizaran las siguientes fases:
Se validara y controlara los alcances.
Se Validara el cumplimiento del cronograma, así como el control de
ajustes al cronograma inicial.
Se controlara los costos y el control de la calidad.
Se realizara controles a los riesgos establecidos.
Se podrá realizar el control de las compras realizadas
El control de los interesados para que sea posible que los recursos
solicitados se hayan cumplido.
75
Cerrar el proyecto o Fase.
Por último se realizara el cierre formal del proyecto y entrega a los
representantes de Promeinfo, incluyendo una exposición de lo realizado, dentro
del proyecto y la metodología utilizada para que al ser entregados con el fin de
dar continuidad a posibles actualizaciones.
Gestión del alcance
En este proceso se ha identificado los alcances requeridos para obtener la más
alta disponibilidad y satisfacción para los interesados del proyecto.
En el anexo 4, podremos observar la información levantada para obtener los
requerimientos por parte de los interesados, el anexo 5 nos muestra todo lo
relacionado al alcance y la creación del WBS y por último en el anexo 2
identificaremos el diagrama de WBS estructurado de acuerdo a lo analizado
dentro del proyecto.
Gestión de tiempo
Los recursos para este proyecto son mencionados y requeridos en la Tabla 6
Factibilidad técnica del proyecto los cuales justifican el uso de cada recurso, en
el anexo 1 se podrá tener acceso al cronograma del proyecto, al cual mostrara la
secuencia de actividades y el tipo estimado para este proyecto.
Gestión de costo
Los costos para este proyecto se han definido en la tabla 6, donde nos muestra
el costo – beneficio de invertir en lo requerido para el aseguramiento de la
herramienta, el presupuesto seria previamente asumido por el cliente.
Gestión de calidad
Las métricas de calidad están adjunta en el informe que se encuentra en el
Anexo 11, muestra cada una de la validación tomadas para demostrar la calidad
de este producto.
76
Gestión de los recursos humanos
Para la gestión de recursos humanos, se han detallado los recursos necesarios
en el informe que se encuentra en anexo 6 de este proyecto.
Gestión del riesgo
En el anexo 9, se realiza una matriz de evaluación y control de los posibles
riesgos que podrían suscitarse, y el control mediantes normas específicas de
seguridad.
Gestión de compra
Para el desarrollo de esta herramienta de control de versiones, se ha propuesto
realizarlo de manera open source y se solicita la adquisición de un servidor que
sirva de repositorio para el respaldo de los proyectos, con más detalles se
explica en la tabla 6 y se explica y justifica su adquisición.
Gestión de los interesados
Se justifican los interesados del proyecto en el informe que al momento se puede
revisar en el anexo 7, en este informe se puede identificar de manera apropiada
a cada uno de los interesados, su cargo y lo que representa dentro del proyecto.
Ejecución del Proyecto
Se ha analizado la instalación del repositorio central para la herramienta de
control de versiones, la versión del sistema operativo para que el servidor sea
compatible con la herramienta y la preparación del ambiente para proceder a
crear el ambiente de trabajo.
77
En la ilustración 22 se ha definido el diseños referente a la estructura global del
proyecto, además de especificar cada una de las funciones que realizara y como
se conecta cada una de sus partes.
Ilustración 23 Modelado del proyecto
Elaborado por: Victoria García Velásquez Fuente: Vías de investigación
78
Tabla 8 comandos de instalación y configuración
Elaborado por: Victoria García Velásquez Fuente: Proceso de configuración de la herramienta.
Comandos para el manejo de Git
Comandos básicos GIT
Git bash Consola de trabajo git
git help <comando> Buscar ayuda para los comando especificados
mkdir Crea un nuevo directorio
git config --global user.name " nombre del usuario"
Establecer usuario para las confirmaciones de cambios (commit)
git config --global user.email " email del usuario"
Establecer correo para las confirmaciones de cambios (commit)
git version Muestra la versión actual del Git
ls -la
git status Muestra la situación actual del trabajo local realizado
git log Examina el histórico del commit para un rango o a ruta es opcional
Creación de repositorio :
git init Crea un repositorio en el directorio actual
git add <dir> Añade un archivo o directorio de manera recursiva
git remote Lista los repositorios remotos que pueda encontrar
git remote add alias url Añade un repositorio a la lista de repositorios registrados
git remote -v Muestra los repositorios remotos.
git commit -m "mensaje del commit"
Realiza la confirmación de los cambios realizados a los archivos, es importante el -m y el mensaje
git push Empuja los cambios a un repositorio remoto
git fecth Descarga objetos y referencias de otros repositorios
git clone <url> Clona un repositorio remoto dentro de un directorio local.
79
3.3 Entregables del proyecto
Para este proyecto se entregaran lo siguiente:
Instalación y configuración de la Herramienta de control de versiones en
el Windows server 2008.
Informes de prueba y control de funcionamiento.
Manual de configuración y Operación.
3.4 CRITERIOS DE VALDACIÓN DE LA PROPUESTA
Para realizar las pruebas del sistema de control de versiones hemos establecido
las pruebas de integración que será detallada en la siguiente tabla.
Tabla 9 Pruebas de integración del aplicativo
Escenario de prueba
Resultado
Esperado
Resultado
Obtenido
1
Integrar una aplicación Web Open Source con herramienta local del servidor, cliente principal.
Integración del portal Web open source con el cliente
del servidor.
Resultado de la integración exitoso.
Sistema Configurable.
2 Creación de usuarios en interfaz web.
Cada usuario deberá tener usuario y clave en el
sitio web
Resultados usuarios
creados.
3 Creación de reposito en el servidor local y creación de repositorios en el portal web.
Crear repositorio y que estos sean empujados a la interfaz y viceversa.
Empuje de los repositorios
exitoso.
4 Asignación de proyectos a recursos con usuarios, dentro de la interfaz.
Cada proyecto tenga
usuarios específicos y relacionados al tema.
Asignación de proyectos desde la
interfaz web exitoso
5 Descargas de copias repositorios y Ramas.
Que los recursos puedan realizar descargas se repositorio y pueda
realizar ramas del mismo.
Descargas y ramificación
exitosa.
6 Verificación de cambio
Se espera visualizar el control de los cambios realizados al repositorio.
Control de
cambios exitoso.
7 Recuperación de versión Regresar a una versión antigua del repositorio.
Recuperación exitosa.
Elaborado por: Victoria García Velásquez Fuente: Pruebas realizadas a la herramienta.
80
Análisis de la encuesta de control de versiones realizada.
Tabla 10 Encuesta del control de Versiones Distribuidas Pregunta #1
¿En la empresa o área donde labora cuantas personas están directamente ligados al desarrollo de proyectos tecnológicos?
De 1 a 5 Personas 5 25%
De 6 a 10 Personas 1 5%
De 11 a 15 Personas 1 5%
De 15 o más Personas 13 65%
TOTAL ENCUESTAS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Ela
borado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 65% de las personas trabajan en equipos de más de 15 personas
en el área de sistemas siendo así la mayoría, el 25% trabajan en grupos de 11 a
15 personas dentro del área de sistemas siendo el 2do grupo preponderante
ligadas al área de sistemas y quedando con un 5% el trabajar entre 1 a 5
personas y otro 5% el trabajar en grupos de 6 a 10 personas del área de
sistemas.
Ilustración 24 Encuesta del control de Versiones Distribuidas Pregunta #2
81
Ilustración 25 Encuesta del control de Versiones Distribuidas Pregunta #2
Tabla 11 Encuesta del control de Versiones Distribuidas Pregunta #2
¿Qué le parece empezar a trabajar sin respaldos y sin backup inmediatos?
Riesgoso 19 95%
Normal 0 0%
Indiferente 1 5%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 95% de las personas opinan que es riesgoso trabajar sin respaldo
y sin backup mientras que a un 5% les paree totalmente normal, esto nos
permite llegar a la conclusión que en su mayoría las personas ligadas al
desarrollo requieren saber que están seguros al momento de realizar cambios y
avanzar en el desarrollo de proyectos.
82
Ilustración 26 Encuesta del control de Versiones Distribuidas
Pregunta # 3
Tabla 12 Encuesta del control de Versiones Distribuidas Pregunta #3
¿Cómo consideran al trabajar con grandes grupos de manera distribuida, sin tener que interrumpir el trabajo entre los de los integrantes?
Excelente 4 20%
Muy Bueno 10 50%
Bueno 6 30%
Regular 0 0%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 50% de las personas opinan que es Excelente trabajar en grupo de
manera distribuidas, permitiéndoles el avance y sin interferencia entre los
integrantes del grupo, al 30% le parece muy buena propuesta, al 20% le parece
bueno pero no los convence la propuesta, pero ninguno descarta la idea de
trabajar de esta manera.
83
Ilustración 27 Encuesta del control de Versiones Distribuidas
Pregunta # 4
Tabla 13 Encuesta del control de Versiones Distribuidas Pregunta # 4
¿Estaría usted dispuesto a integrar una herramienta de control de versiones distribuidas?
De acuerdo 13 65%
Talvez 4 20%
No necesariamente 2 10%
Total desacuerdo 1 5%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 65% de las personas estarían dispuesta a integrar una herramienta
de control de versiones, mientras que el 20% indica que talvez pensarían en la
opción de integrar esta herramienta, un 10% no necesariamente permitiría la
integración dentro de su grupo de trabajo y el 5% está totalmente en desacuerdo
con lo propuesta de integración de una herramienta de control.
84
Ilustración 28 Encuesta del control de Versiones Distribuidas
Pregunta #5
Tabla 14 Encuesta del control de Versiones Distribuidas Pregunta # 5
¿En las auditorias de control el controlador de versiones le ayudaría a emitir un informe más real y efectivo?
De acuerdo 13 65%
Talvez 6 30%
No necesariamente 1 5%
Regular 0 0%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 65% de las personas concuerdan en que la herramienta de control
de versiones aportaría en un mejor resultado para las auditorías, un 30% opina
que talvez aportaría pero quizás tengan otro método, el 5% piensa que no
necesariamente aportaría, pero podemos observar que la mayoría de los
encuestados estaría dispuestos a permitir que esta herramienta aporte a sus
auditorías.
85
Ilustración 29 Encuesta del control de Versiones Distribuidas
Pregunta #6
Tabla 15 Encuesta del control de Versiones Distribuidas Pregunta #6
¿Cada que tiempo realizan respaldo de los proyectos en la empresa que laboran?
Semanal 14 70%
Mensual 1 5%
De vez en cuando 4 20%
Nunca 1 5%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Elaborado por: Victoria García Velásquez
Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 70% de las personas que trabajan dentro de las áreas de sistemas
o de desarrollo, realizan sus respaldos de manera semanal un 20% lo realizan
de manera mensual, el 5 % los realiza de vez en cuando y el 5% restante nunca
realizan un respaldo, pero nos evidencia que no trabajan con respaldo
inmediatos de los proyectos.
86
Tabla 16 Encuesta del control de Versiones Distribuidas Pregunta #7
¿Propondría usted la inversión para la compra de un servidor que contenga la herramienta de control de versiones y sus repositorios?
Inversión no justificado 3 15%
Inversión Justificada 16 80%
Nunca 1 5%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Ilustración 30 Encuesta del control de Versiones Distribuidas Pregunta #7
Elaborado por: Victoria García Velásquez
Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 80% de las personas que trabajan dentro de las áreas de sistemas
o de desarrollo, propondrían la compra de un servidor que justificarían la
inversión aduciendo el que sea un repositorio de todos los proyectos y poder
siempre tenerlos disponibles, aunque un 15% no lo justifica y el 5% nunca lo
propondría, permite analizar que la mayoría esta predispuesta a mejorar en
infraestructura para los cambios en los proyectos.
87
Tabla 17 Encuesta del control de Versiones Distribuidas Pregunta #8
¿Se han definido políticas para proceder con los respaldo de datos?
SI 13 65%
No 7 35%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Ilustración 31 Encuesta del control de Versiones Distribuidas
Pregunta #8
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 65% de las personas que indicaron que trabajan bajo políticas de
seguridad y un 35% que no trabajan con políticas de seguridad, lo cual nos deja
ver una gran falencia en parte de su trabajo, para lo cual necesitaría n considerar
el trabajar con políticas que permitan salvaguardar los trabajos realizados dentro
de la empresa y con el personal que laboran en ella.
88
Tabla 18 Encuesta del control de Versiones Distribuidas Pregunta #9
¿Si ocurriese una catástrofe que implica perder los datos, están ustedes preparados para volver a estar funcionales?
Totalmente 9 45%
Talvez 7 35%
Nada 4 20%
TOTAL ENCUESTADOS 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Ilustración 32 Encuesta del control de Versiones Distribuidas Pregunta #9
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 45% de las personas que indicaron que ante una catástrofe están
preparados y el 35% tal vez estén preparados y el 20% no tienen nada de
protegerse ante alguna catástrofe que los pueda dejar sin servicio
ocasionándoles posiblemente grandes pérdidas económicas y por lo tano
perdidas de los clientes.
89
Ilustración 33Encuesta del control de Versiones Distribuidas
Pregunta #10
Tabla 19 Encuesta del control de Versiones Distribuidas Pregunta # 10
¿En qué tiempo recuperan la información, datos y más pérdidas, para continuar con la operación del negocio?
En menos de 1 hora 3 15%
De 1 a 2 Horas 9 45%
De 24 Horas en adelante 7 35%
Nunca 1 5%
TOTAL ENCUESTADO 20 100%
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Elaborado por: Victoria García Velásquez Fuente: Encuesta
Análisis.- De las 20 personas a las que se les realizo la encuesta, se pudo
observar que 45% de las personas que indicaron que ante una catástrofe su
tiempo de respuesta es de 1 a 2 horas para volver a dar servicio, el 35%
indicaron que volverían a producción en 24 horas o más, el 15% indicaron que
en menos de 1 hora y un 5% considera que no podrían volver a producción.
90
CAPÍTULO IV
4.1 Criterios de aceptación del producto o Servicio
Dentro de las empresas usualmente se compran los mejores equipos que
puedan existir en el mercado para asegurar nuestra información, esto se lo
realizar por la constante búsqueda de mantener y salvaguardar el triángulo de
seguridad, que no es más que buscar la confiabilidad del acceso a la
información para personas autorizadas, la integridad que nos asegura que los
datos y la información están de forma exacta sin ninguna alteración y por último
la disponibilidad que nos promete el total acceso a la información que necesite
el usuario en cualquier instante.
Pero no solo con los equipos podemos estar protegidos y obtener en un 100%
mantener el triángulo de la seguridad, es por este motivo que este proyecto de
titulación se lo ha realizado bajo las normas ISO 27001-2013, norma que nos
brinda un sistema de gestión de la seguridad informática o sus siglas SGSI.
El SGSI para garantizar que la información procesada es correcta, debe realiza
procesos sistemáticos, documentado y sobre todo de conocimiento general en la
empresa u organización, buscar el enfoque de riesgo empresarial para su
constitución, el SGSI nos impone el modelo e visualizar políticas, procedimiento,
planificación e implementación controles de seguridad en base a la evaluación
del riesgo y en la medida de efectividad del mismo.
Los activos que intervienen la ISO 27001 son:
Información.- referenciando a los datos y manual de usuario entre otros.
Software.- aplicaciones, código fuente y más relacionados.
Físicos.- computadoras en general, servidores y más relacionados.
Personas.- Clientes, operadores entre otros.
Imagen de la empresa.
Servicios.- comunicación.
91
Ilustración 34 Activos de la ISO 27001
En la ilustración 34, podemos observar una estructura jerárquica de los
activos a analizar por la ISO.
Elaborado por: Victoria García Velásquez
Fuente: Porta web23 (Balaguer, 2014)
Los activos de este proyecto de titulación son:
Servidor
Sistema operativo
Red
Manual de configuración y operación
Personal de desarrollo o recursos de proyectos
23 Imagen extraída de la presentación del Ing. Manuel Collazos Balaguer
https://www.google.com.ec/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&v
ed=0ahUKEwicxK_vu8_JAhWBjIMKHT4oB4kQFggsMAM&url=http%3A%2F%2Fwww.cip.or
92
4.2 Análisis de la evaluación de riesgo
Ahora que se han establecidos los activos del proyecto que intervienen para el
manejo y desarrollo de la herramienta de control de versiones, mostraremos en
el anexo 9 un análisis de las vulnerabilidades que se puedan presentar y en el
anexo 10, se mostrara el proceso de control estimado por el anexo A de las
normas ISO 2007.
Elaborado por: Victoria García Velásquez
Fuente: portal web24
24 Imagen extraída del portal web http://www.scielo.org.ve/scielo.php?pid=S1690-
75152009000100004&script=sci_arttext Análisis y evaluación del riesgo de la información.
Ilustración 35 Análisis y Evaluación de riesgo
93
4.3 Matriz de criterios de Aceptación y Aseguramiento del
Proyecto de Titulación
Como parte del control de calidad se elaborará la matriz de aceptación del proyecto, el cual tomara partes relevantes para asegurarse de que se esté cumpliendo con los alcances propuestos. La siguiente Matriz validara una ponderación de 1 a 5, siendo 1 la menor d las ponderaciones y 5 la mayor ponderación para el criterio `para establecer la calidad del proyecto tecnológico.
Tabla 20 Matriz de criterio de Aceptación.
Elaborado por: Victoria García Velásquez Fuente: Vías de investigación.
Criterio Valoración
1 2 3 4 5
Servidor de aplicaciones configurado x
Configuración de Active Directory Funcional x
Herramienta de control configurada x
Repositorios locales disponibles x
Flujo de trabajos con los repositorios x
Pruebas de configuración del Herramienta de control
x
Validación de configuración de almacenamiento en repositorios
x
Validación de conexión Active Directory x
Validar Seguridades del Servidor x
Validar el control de versiones x
Prueba de Comunicación del Ordenador del cliente
x
Capacitación e integración al personal x
94
BIBLIOGRAFIA
Fogel, K., & Bar, M. (2001). Open Source Development with CVS. Arizona:
Paraglyph Press.
Amaya, J. A. (2010). Sistemas de Información Gerenciales 2da edición.
BOGOTA: Ecoe.
Atlassian. (2016). https://www.atlassian.com. Obtenido de
https://www.atlassian.com/software/sourcetree/overview
AUDITORIA DE SISTEMAS . (10 de 09 de 2010). http://sisteaudi.blogspot.com/.
Obtenido de http://sisteaudi.blogspot.com/2010/09/ciclo-de-vida-y-
desarrollo-de-sistemas.html: http://sisteaudi.blogspot.com/2010/09/ciclo-
de-vida-y-desarrollo-de-sistemas.html
Balaguer, I. M. (2014). La nueva versión ISO 27001:2013. Un cambio en la
integración de los sistemas de control. Lima, Perú.
Bauer. (1972). En Bauer.
Bell, P., & Beer, B. (2015). Introducing GitHub. Sebastopol: O’Reilly Media, Inc.
Benchimol, D. (2011). Hacking. Lomas de Zamora: Fox Andina.
Chacon, S., & Straub, B. (2014). Pro Git 2nd Edition. San Francisco: it.book.com.
Chacon, S., & Straud, B. (2009). Pro Git 1st Edition. San Francisco: it-book.com.
Obtenido de http://librosweb.es/libro/pro_git/.
Collins-Sussman, B., Fitzpatrick, B., & Pilato, C. (2005). Version Control with
Subversion. Chicago: O'Reilly.
Constituyente, A. (2014). TITULO X.- DE LA GESTION Y ADMINISTRACION DE
RIESGOS. CAPÍTULO V.- DE LA GESTIÓN DEL RIESGO OPERATIVO,
(pág. 18). ECUADOR.
Dawson, C., & Ben, S. (2010). GitHub. Sebastopol: O’Reilly Media, Inc.
Definicion.De. (2015). Definicion.De. Obtenido de http://definicion.de
DX, H. (10 de 05 de 2013). Slideshare. Obtenido de http://es.slideshare.net/:
http://es.slideshare.net/helodtk1/factibilidad-tecnica-operativa-y-
economica-20908957
Falgueras, B. C. (2003). Ingeniería del software. BARCELONA: UOC.
Gyerik, J. (2013). Bazaar Version Control. Birmingham: Packt Publishing Ltd.
Hethey, J. M. (2013). GitLab Repository Management. Birmingham: Packt
Publishing Ltd.
Hipertextual SL. (2005). HIPERTEXTUAL. Obtenido de HIPERTEXTUAL:
hipertextual.com/archivo/2014/04/sistema-control-versiones/
http://www.tutorialspoint.com. (2016). http://www.tutorialspoint.com. Obtenido de
http://www.tutorialspoint.com/mysql/mysql-introduction.htm
https://maperz1130.wordpress.com/. (06 de 09 de 2010). Obtenido de
https://maperz1130.wordpress.com/2010/09/06/pruebas-de-integracion/
95
KARIBU. (03 de 05 de 2015). http://freedif.org/gogs-opensource-alternative-to-
github/. Obtenido de http://freedif.org/gogs-opensource-alternative-to-
github/
Loeliger, J., & Matthew McCullough. (2012). Version Control with Git Second
Edition (Vol. Second Edition). (A. Oram, Ed.) Sebastopol, Gravenstein
Highway North: O’Reilly Media, Inc.
López, P. A. (2010). Sistemas de información. EDITEX.
Marqués, M. (2011). Bases de datos. Castelló de la Plana: Publicacions de la
Universitat Jaume I.
Ploski, J., Hasselbring, W., Rehwinkel, J., & Schwierz, S. (2007). Introducing
Version Control to Database-Centric Applications in a Small Enterprise.
United States, US: IEEE Computer Society.
Preißel, René, & Stachmann, Bjørn. (2014). Git: Distributed Version Control –
Fundamentals and Workflows. Heildelberg, Alemania: dpunkt.verlag
GmbH.
Project Management Institute. (2013). Guía de los fundamentos para la dirección
de proyectos Quinta Edición. Newtown Square: Project Management
Institute, Inc.
Roger S. Pressman, P. (2010). INGENIERÍA DEL SOFTWARE. UN ENFOQUE
PRÁCTICO 7 ma edición. Mexico: The McGraw-Hill Companies, Inc.
Sampieri, D. R. (2010). Metodología de la Investigación 5ta edición. BOGOTA:
McGRAW-HILL.
Santillán, M. (08 de 07 de 2014). http://www.ecuadorvirtual.ec/introduciendo-git-
a-nuestros-proyectos/. Obtenido de www.ecuadorvirtual.ec/
Somasundaram, R. (2013). Git: Version Control for Everyone. Birmingham: Packt
Publishing Ltd.
Somasundaram, R. (2013). Git: Version Control for Everyone. Birmingham: Packt
Publishing Ltd.
Sudarshan, S., F. Korth, H., & Silberschatz, A. (2002). FUNDAMENTOS DE
BASES DE DATOS. Cuarta edición. Madrid: Mc Graw-Hill Inc.
Zapata Cortés, J. A. (2010). Herramientas Tecnológicas al Servicio de la Gestión
Empresarial. Revista Avances en Sistemas e Informática, 87-101.
96
ANEXOS
ANEXOS
97
ANEXO 1 Cronograma de actividades
Nombre de tarea Duración Comienzo Fin
Predecesoras
Procedimiento, análisis y desarrollo de un sistema de control de versiones distribuidas, sobre las base de datos del Sistema PROMEINFO.
20 días vie 07/08/15 vie 04/09/15
Gestión de proyecto 20 días vie 07/08/15 vie 04/09/15
Iniciación 20 días vie 07/08/15 vie 04/09/15
Recopilación de información 1 día vie 07/08/15 vie 07/08/15
Requerimientos 1 día lun 10/08/15 lun 10/08/15 4
Definición de objetivos y alcances 1 día mar 11/08/15 mar 11/08/15 5
Entrega de ante proyecto 5 días mié 12/08/15 mié 19/08/15 6
Reunión de aprobación 5 días jue 20/08/15 mié 26/08/15 7
Corrección del anteproyecto 3 días jue 27/08/15 lun 31/08/15 8
Aprobación del tema y asignación de tutor y coordinador del proyecto
4 días mar 01/09/15 vie 04/09/15 9
ANALISIS Y DISEÑO DEL PROYECTO 20 días lun 07/09/15
vie 02/10/15
CONFIGURACIÓN DEL PROYECTO 30 días lun 05/10/15 mié 18/11/15
Instalación del ambiente para implementación
9 días lun 05/10/15 vie 16/10/15
Instalación y configuración del Window server 2008R2
5 días lun 05/10/15 lun 12/10/15 21
Configuración del Active directory 4 días mar 13/10/15
vie 16/10/15 24
Instalación de la herramienta de Control de versiones
15 días lun 19/10/15
mar 10/11/15
Instalación de la herramienta de control de versiones GIT
2 días lun 19/10/15 mar 20/10/15
25
Configuración de la herramienta de control de versiones GIT
5 días mié 21/10/15
mar 27/10/15
27
Instalación de la herramienta cliente SOURCE TREE
1 día mié 28/10/15
mié 28/10/15 28
98
Configuración de la herramienta cliente SOURCE TREE
3 días jue 29/10/15 mié 04/11/15 29
Configuración de Protocolos de seguridad HTTPS
2 días jue 05/11/15 vie 06/11/15 30
Configuración de Protocolos de seguridad SSH
2 días lun 09/11/15 mar 10/11/15
31
Pruebas del ambiente de Desarrollo 6 días mié 11/11/15
mié 18/11/15
Pruebas Técnicas del ambiente de desarrollo
3 días mié 11/11/15
vie 13/11/15 32
Pruebas Funcionales del ambiente de desarrollo
3 días lun 16/11/15 mié 18/11/15 34
EJECUCION DEL PROYECTO 8 días jue 19/11/15
lun 30/11/15
Creación de repositorios en el servidor 4 días jue 19/11/15 mar 24/11/15
35
Pruebas de conexión con los reportorios remotos
4 días mié 25/11/15
lun 30/11/15 37
Monitoreo y Control 5 días mar 01/12/15
lun 07/12/15
Pruebas con el repositorio que aloja la base de conocimiento de las bases de datos SQL
4 días mar 01/12/15
vie 04/12/15 38
Entrega del proyecto 1 día lun 07/12/15 lun 07/12/15 40
Cierre de Proyecto 7 días mar 08/12/15
mié 16/12/15
Creación de Documentos, ANEXOS, MANUALES y ENCUESTAS
4 días mar 08/12/15
vie 11/12/15 41
Presentación del Proyecto 3 días lun 14/12/15 mié 16/12/15 43
99
ANEXO 2 Grupo de procesos de dirección de proyecto
Áreas de conocimiento
Grupo de procesos de Iniciación
Grupo de procesos de Planificación
Grupo de procesos de Ejecución
Grupo de procesos de Monitoreo y Control
Grupo de procesos de Cierre
Gestión de la Integración
Ante - Proyecto Plan de gestión Dirigir y Manejar Proyectos
Monitoreo y Control Cierre del proyecto
Gestión del Alcance
Definición de alcances Validar Alcances
Gestión del Tiempo Definición de actividades. Cronograma de Actividades
Gestión del Costo Factibilidad Económica
Gestión de la Calidad
Gestión de recursos Humanos
Plan de Recursos Humanos Gestionar equipos
Gestión del Riesgo Plan de Riesgos
Gestión de compras Plan de Compras Cerrar Compras
Gestión de los interesados
Identificar Interesados Plan de Interesados Gestión de Interesados Control de Compromisos
Elaborado por: Victoria García Velásquez Fuentes:PMBOK5ta edición25
25 Cuadro extraído del PmBok 5ta edición, con modificaciones para la adaptación al proyecto desarrollo.
100
ANEXO 3 Plan de Gestión de Proyecto
PLAN DE GESTION DE PROYECTO
Fecha: 2015/08/07
Página: 1 de 5
Código: Git 2015-08
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Herramienta de control de Versiones GIT
ENFOQUE DE TRABAJO: Herramienta de control de versiones.
El ciclo de vida del proyecto GIT, se apilaría un plan de dirección del proyecto para dirigir el proceso del desarrollo y el manejo estable del proyecto, se excluirá fases dependiendo un entregable o implementación, el proyecto será dirigido y administrado por el coordinador asignado para monitorear el avance y buena dirección del proyecto , el mismo que estará ligado directamente al cliente y quien nos aportara con las reuniones y definición de lo requerido por el cliente, se llevará a cabo una identificación, seguimiento, control de riesgos, para maximizar las probabilidades de éxito del proyecto, minimizando el impacto de los problemas identificados. El proyecto será monitoreado para controlar la calidad y el control de los posibles riesgos y aplicar las correcciones debidas a tiempo. Los requerimientos serán gestionados de manera que apunten a garantizar el cumplimiento y la toma de decisiones dentro del proyecto.
PLAN DE GESTION DE CAMBIOS: Detalles de cambios en los requerimientos
Se realizará un control en los cambios realizados por el cliente o por parte del desarrollador del tema, se deberán detallar paso a paso los procesos de cambios si estos llegaran a ser solicitados. * Todo cambio deberá ser debidamente reportado con el coordinador del proyecto. *Los cambios deberán ser incluidos en el formato de requerimientos, tomadas al inicio del proyecto
101
PLAN DE GESTION DE LA CONFIGURACIÓN:
PLAN DE GESTION
Manual de configuración y operación
Control de calidad
Control de riesgos
GESTION DE LÍNEAS BASE:
El seguimiento se lo realizara por medio de reuniones para revisión con el coordinador, para analizar los avances y las pruebas realizadas.
LINEA BASE Y PLANES SUBSIDIARIOS: DEFINICION DE LINEA BASE Y PLANES SUBSIDIARIOS QUE SE ADJUNTAN
AL PLAN DE GESTION DEL PROYECTO.
LINEA BASE PLANES SUBSIDIARIOS
DOCUMENTO ADJUNTO
(SI/NO) TIPO PLAN
ADJUNTO (SI/NO)
LINEA BASE DEL ALCANCE
PLAN DE GESTION DE ALCANCE SI
PLAN DE GESTION DE REQUESITOS SI
PLAN DE GESTION DE SCHEDULE SI
LINEA BASE DEL TIEMPO
PLAN DE GESTION DE COSTOS SI
PLAN DE GESTION DE CALIDAD SI
PLAN DE MEJORAS DE PROCESOS SI
LINEA BASE DEL COSTO
PLAN DE RECURSOS HUMANOS SI
PLAN DE GESTION DE RIESGOS SI
PLAN DE GESTION DE ADQUISICIONES SI
Elaborado por: Victoria García Velásquez Fuente: Vías de investigación
102
ANEXO 4 Requerimiento del proyecto
FORMATO DE REQUERIMIENTO
FECHA DE SOLICITUD: 2015/08/07
DATOS DEL CLIENTE
CLIENTE: PROMEINFO
NOMBRE DEL CONTACTO : Ing. Jorge Chicala
CARGO DEL CONTACTO: Coordinador PROMEINFO
AUTORIZADO POR: Ing. Harry Luna
DETALLE DEL REQUERIMIENTO
REFERENCIA: Cronograma en anexo #
# PROCESO DESCRIPCION ESPECÍFICA DEL
REQUERIMIENTO INICIAL O CAMBIO
AFECTACION
1 Documentación
Se solicitó por parte del cliente la documentación del proyecto relacionado al sistema de control de versiones.
INICIAL NO APLICA
2 Herramienta Creación de la herramienta de control de versiones que sea Open Source.
INICIAL NO APLICA
4 Proceso Repositorio este alojado en un servidor INICIAL NO APLICA
5 Proceso La herramienta deberá permitir que más de usuario trabaje sobre los archivos
INICIAL NO APLICA
7 Web
La interfaz para publicar los repositorios deberá permitir que sean públicos o privados ambas formas sin costo alguno.
INICIAL NO APLICA
DETALLE DE HORAS ESTÁNDAR O DESARROLLO ADICIONAL
CANTIDAD DE HORAS ESTANDAR NO APLICA NO APLICA CANTIDAD DE HORAS DE DESARROLLO ADICIONAL NO APLICA NO APLICA
OBSERVACIONES
NO APLICA
APROBACIONES: Firmas
Nombre y Apellido
Nombre y Firma del
Cliente Nombre y Firma del
coordinador
103
ANEXO 5 Plan de gestión de alcances
PLAN DE GESTION DE ALCANCE Fecha: 2015/08/07
Página: 2 de 5
Código: Git 2015-08
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Herramienta de control de Versiones GIT
Proceso de definición de alcance:
La definición del alcance del proyecto de a herramienta de control de versiones,, se llevara cabo e la siguiente manera: • Construir un repositorio o varios del proyecto que sirvan como sincronizador de los repositorios locales, esto para que los desarrolladores puedan sacar copias y trabajar de manera individual, para luego subir los cambios y finalmente integrarlos. • Mantener flujos de trabajos con un gestor de integración, para los repositorios. • Brindar las seguridades que el sistema requiere como: confiabilidad, integridad y disponibilidad de los datos. • Personalizar el control de versiones con la configuración de los clientes y servidor.
Proceso para elaboración de WBS:
EL proceso para la elaboración del WBS son:
Estructura de acuerdo a lo aplicado dentro del proyecto.
Identificación de entregables, al menos los principales
Identificación de costos, calidad y riesgos
Proceso para verificación del alcance Al finalizar etapas de los alcances se realizara entregas al coordinador asignado para mantener la dirección de lo requerido entre los alcances.
104
ANEXO 6 PLAN DE RECURSO HUMANO
PLAN DE RECURSOS HUMANO
Pagina: 4 de 5
Fecha: 2015/08/07
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Herramienta de control de Versiones Git
TIPO RECURSO RECURSOS REQUISITOS ADICIONALES CANTIDAD
HUMANO DESARROLLADOR CONOCIMIENTO DE SISTEMAS 1
HUMANO COORDINADOR NO APLICA 1
HUMANO TUTOR NO APLICA 1
105
ANEXO 7 Plan de Gestión interesados
REGISTRO DE STAKEHOLDER
Pagina: 3 de 5
Fecha: 2015-08-07
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Herramienta de control de Versiones GIT
EMPRESA Y PUESTO
LOCALIZACION
ROL EN EL PROYECTO
INFORMACION DE CONTACTO
REQUERIMIENTOS
PRIMORDIALES
EXPECTATIVAS PRINCIPALES
INFLUENCIA POTENCIAL
INTERNO/
EXTERNO
APOYO/
NEUTRAL
REQUIERE
CAPACITACION
DESCRIPCION DE LA
CAPACITACION
COORDINADOR DEL PROYECTO
CISC COORDINAD
OR jchicala19@gmailcom
Planificar, supervisar y gestionar el desarrollo del proyecto
Cumplimiento de tiempos planificados, garantias de la elaboracion del proyecto
Experiencias en las herramientas que intervienenen el desarrollo del proyecto
Interno Apoyo No
TUTORA CISC TUTOR [email protected]
Planificar, supervisar y gestionar el desarrollo del proyecto
Cumplimiento de tiempos planificados, garantias de la elaboracion del proyecto
Experiencias en las la documentación a entregar.
Interno Apoyo No
106
COORDINADOR DEL PROYECTO
PROMEINFO CISC
COORDINADOR
PROMEINFO
Revisor de avances y comprobación del producto
Producto funciona y en producción
Capacidad de gestionar acciones requeridas dentro de su empresa para el cumplimiento del proyecto
Externo Apoyo SI
Demostracion y capacitación de manejo del producto
Director CISC Control de
Calidad [email protected]
Comprobar que la implementación este correcta.
Producto funciona y en producción
Mitigar falencias en el codigo de desarrollo y/o documentacion del proyecto antes d eser entregado al cliente.
Externo Apoyo SI
Demostracion y capacitación de manejo del producto
100
ANEXO 8 Preguntas y cálculo de respuesta de la encuesta realizada
101
102
103
104
ANEXO 9 Análisis y Evaluación de Riesgo
Activos
Tasación
Amenazas
Po
sib
ilid
ad
Oc
urr
en
cia
Vulnerabilidad
Po
sib
le E
xp
lota
ció
n d
e
Vu
lne
rab
ilid
ad
Va
lor
Acti
vo
Po
sib
le O
cu
rre
nc
ia
To
tal
Co
nfi
den
cia
lid
ad
Inte
gri
dad
Dis
po
nib
ilid
ad
To
tal
Hardware A A A A
Daño de la red A Cableado estropeado en algún tramo.
M
A A A
Disco duro no booteable M Apagado de manera brusca.
M
Fuente y Mainboard no responden B Falta de enfriamiento puede ocasionar que se queme la fuente y el mainboard
M
Siniestros M Incendios causados por falta de ventilación en el cuarto de servidores
M
Energía Eléctrica M Corte de energía puede ocasionar problemas con los equipos.
M
105
Traslado de equipos B Manipular los equipos de un lugar otro sin la debidas precauciones
M
Falta de Ups adecuados A
Sin un Ups acorde a los equipos los cambios en la energía y apagones pueden interrumpir el buen funcionamiento del equipo.
M
Catástrofes Naturales A Inhabilidad por situaciones de emergencia.
M
Software A A A A
Instalación incorrecta M Falta de conocimiento para la instalación de la herramienta.
M
A M M
Inserción de virus M Manejo de dispositivos externos y falta de antivirus.
M
Falta de seguridades M Falla de equipos adecuados para la seguridad.
M
Sistema operativo se corrompa M Falla fatal por mala manipulación.
M
Perdida de la información M Falta de respaldos A
106
Servicios Activos
A A A A
Servidor fuera de servicio M Apagado o con problemas. M
A M M Herramienta de control de versiones abajo
M funcionamiento con conflictos
M
Sin disponibilidad de servicio Mala instalación en usuario B
Información del Cliente
A A A A
Robo de información M Por falta de seguridad por parte del cliente
B
Falta de Privacidad Unificación de contra
Documentación
A A A A
Manuales de uso o Guías de usuarios
M Falta de conocimiento para el uso de la herramienta
A
A M A Contingencia M
No existe tiempo de respuesta, si llegase a pasar imprevistos
A
Políticas de seguridad M No establecer políticas, deja abierto el camino a cualquier atacante.
A
LEYENDA: ALTO = A MEDIO= M BAJO = B
107
ANEXO 10 Control de Riesgo ISO 27001
Activos Objetivo de Control Control Justificación
Ha
rdw
are
A.9.1 A.9.1.1 aseguramiento del perímetro, tales como paredes, puertas de ingreso y cableados, en oficinas y habitaciones y medios, diseñar y aplicar para catástrofes naturales y sinestros
A.9.1.2
A.9.1.3
A.9.1.4
A.9.2 A.9.2.1
Evitar la pérdida de daño y robo o compromisos de los activos, se busca reducir riesgos y amenazas y peligros ambientales y permitir su continua disponibilidad e integridad.
A.9.2.2
A.9.2.3
A.9.2.4
A.10.6 A.10.6.1
A.10.6.2
So
ftw
are
Y S
erv
icio
s A
ctivo
s A.10.3 A.10.3.1
Aseguramiento de la información segura y protegida y cumplir con la regla de oro de la seguridad informática, la disponibilidad, integridad y confidencialidad.
A.10.3.2
A.10.4 A.10.4.1
A.10.10 A.10.10.3
A.10.10.4
A.10.10.5
A.10.10.6
A.11.5 A.11.5.1
A.11.5.2
A.11.5.5
A.11.5.6
108
A.11.6 A.11.6.1
A.11.6.2
A.12.2 A.12.2.2
A.12.3 A.12.3.1
A.12.4 A.12.4.1
A.12.4.3
A.12.5 A.12.5.1
A.12.5.2
A.12.5.3
A.12.5.4
A.12.6 A.12.6.1
A.13.1 A.13.1.1
A.12.1.2
A.14.1 A.14.1.2
A.14.1.3
A.14.1.5
Do
cum
enta
ció
n A.5.1
A.5.1.1 A.5.1.2
Desde la gerencia se deberán comprometer para el completo y mantener en regla los manuales de usuario e instalación que incluyan los lineamientos procedimientos y políticas de la empresa. Para el plan de contingencia todos deberán estar capacitados.
A.6.1 A.6.1.2
A.6.1.3
A.6.1.5
A.10.5 A.10.5.1
A.10.9 A.10.9.3
109
ANEXO 11 INFORME DE METRICAS DE CALIDAD
PROYECTO: SIGLAS DEL PROYECTO
Herramienta de control d versiones GIT
POLÍTICA DE CALIDAD DEL PROYECTO: ESPECIFICAR LA INTENCIÓN DE DIRECCIÓN QUE FORMALMENTE TIENE EL EQUIPO DE PROYECTO CON RELACIÓN A LA CALIDAD DEL PROYECTO.
Este proyecto debe cumplir con los requisitos de calidad desde el punto de PMBOOK y las normas ISO27001, es decir acabar dentro del tiempo y el presupuesto planificados, y también debe cumplir con los requisitos de calidad para PRMEINFO, es decir resguardar la información y mantener las seguridades los cursos y obtener un buen nivel de satisfacción por parte de los participantes.
LÍNEA BASE DE CALIDAD DEL PROYECTO: ESPECIFICAR LOS FACTORES DE CALIDAD RELEVANTES PARA EL PRODUCTO DEL PROYECTO Y PARA LA GESTIÓN DEL PROYECTO. PARA CADA FACTOR DE
CALIDAD RELEVANTE DEFINIR LOS
OBJETIVOS DE CALIDAD, LAS MÉTRICAS A UTILIZAR, Y LAS FRECUENCIAS DE MEDICIÓN Y DE REPORTE.
FACTOR DE
CALIDAD
RELEVANTE
OBJETIVO DE
CALIDAD MÉTRICA A
UTILIZAR FRECUENCIA Y MOMENTO DE MEDICIÓN FRECUENCIA Y MOMENTO DE REPORTE
Perfomance del Proyecto
CPI>= 0.95 CPI= Cost Perfomance Index Acumulado
Frecuencia Semanal Reportes me informes
Perfomance del Proyecto
SPI >= 0.95 SPI= Schedule Perfomance Index Acumulado
Frecuencia Semanal Reportes me informes
Matriz de critero de aceptación
Nivel de Satisfacción >= 4.0
Nivel de Satisfacción= Promedio entre 1 a 5 de 11 factores sobre las
Frecuencia Semanal Reportes me informes
110
pruebas
PLAN DE MEJORA DE PROCESOS: ESPECIFICAR LOS PASOS PARA ANALIZAR PROCESOS, LOS CUALES FACILITARÁN LA IDENTIFICACIÓN DE ACTIVIDADES QUE GENERAN DESPERDICIO O QUE NO AGREGAN
VALOR. Cada vez que se deba mejorar un proceso se seguirán los siguientes pasos: 1. Delimitar el proceso 2. Determinar la oportunidad de mejora 3. Tomar información sobre el proceso 4. Analizar la información levantada 5. Definir las acciones correctivas para mejorar el proceso 6. Aplicar las acciones correctivas 7. Verificar si las acciones correctivas han sido efectivas 8. Estandarizar las mejoras logradas para hacerlas parte del proceso
MATRIZ DE ACTIVIDADES DE CALIDAD: ESPECIFICAR PARA CADA PAQUETE DE TRABAJO SI EXISTE UN ESTÁNDAR O NORMA DE CALIDAD APLICABLE A SU ELABORACIÓN. ANALIZAR LA
CAPACIDAD DEL PROCESO QUE GENERARÁ
CADA ENTREGABLE Y DISEÑAR ACTIVIDADES DE PREVENCIÓN Y DE CONTROL QUE ASEGURARÁN LA OBTENCIÓN DE ENTREGABLES CON EL NIVEL DE CALIDAD REQUERIDO (VER MATRIZ ADJUNTA).
PAQUETE DE TRABAJO ESTÁNDAR O
NORMA DE
CALIDAD
APLICABLE
ACTIVIDADES DE
PREVENCIÓN ACTIVIDADES DE CONTROL
Gestión de Proyecto PmBok Aprobación por Interesados
Iso 27001 Normas Anexo A
Aprobación por Interesados
Informes de Alcance PmBok Aprobación por Interesados
Informes semanal PmBok Aprobación por Interesados
Cierre del proyecto Normas Anexo A
Aprobación por Interesados
Entrega a Promeinfo Normas Aprobación por Interesados
111
Anexo A
ROLES PARA LA GESTIÓN DE LA CALIDAD: ESPECIFICAR LOS ROLES SERÁN NECESAROS PARA CUMPLIR LAS METRICAS DE SEGURIDAD
ROL NO 1 : SPONSOR Objetivos del rol: Responsable ejecutivo y final por la calidad del proyecto
Funciones del rol: Revisar, aprobar, y tomar acciones correctivas para mejorar la calidad
Niveles de autoridad: Aplicar a discreción los recursos de Dharma para el proyecto, renegociar contratos
Reporta a: Directorio
Supervisa a: Project Manager
Requisitos de conocimientos: Project Management y Gestión en General
Requisitos de habilidades:
Liderazgo, Comunicación, Negociación, Motivación, y Solución de Conflictos
Requisitos de experiencia: más de 20 años de experiencia en el ramo
ROL NO 2 : PROJECT MANAGER
Objetivos del rol: Gestionar operativamente la calidad
Funciones del rol: Revisar estándares, revisar entregables, aceptar entregables o disponer su reproceso, deliberar para generar acciones correctivas, aplicar acciones correctivas
Niveles de autoridad :
Exigir cumplimiento de entregables al equipo de proyecto
Reporta a: Sponsor
Supervisa a: Equipo de Proyecto
Requisitos de conocimientos: Gestión de Proyectos
112
Requisitos de habilidades: Liderazgo, Comunicación, Negociación, Motivación, y Solución de Conflictos
Requisitos de experiencia: 3 años de experiencia en el cargo
ROL NO 3 : MIEMBROS DEL EQUIPO DE PROYECTO
Objetivos del rol: Elaborar los entregables con la calidad requerida y según estándares
Funciones del rol :
Elaborar los entregables
Niveles de autoridad:
Aplicar los recursos que se le han asignado
Reporta a: Project Manager
Supervisa a:
Requisitos de conocimientos: Gestión de Proyectos y las especialidades que le tocan según sus entregables asignados
Requisitos de habilidades: Específicas según los entregables
Requisitos de experiencia: Específicas según los entregables
ORGANIZACIÓN PARA LA CALIDAD DEL PROYECTO: ESPECIFICAR EL ORGANIGRAMA DEL PROYECTO INDICANDO CLARAMENTE DONDE ESTARÁN SITUADOS LOS ROLES PARA LA GESTIÓN DE
LA CALIDAD CLIENTE
PROMEINFO - INTERESADOS
DOCUMENTOS NORMATIVOS PARA LA CALIDAD: ESPECIFICAR QUE DOCUMENTOS NORMATIVOS REGIRÁN LOS PROCESOS Y ACTIVIDADES DE GESTIÓN DE LA CALIDAD
PROCEDIMIENTOS 1 .Para Mejora de Procesos
2. Para Auditorias de Procesos
3. Para Reuniones de Aseguramiento de Calidad
4. Para Resolución de Problemas
PLANTILLAS 1. Métricas
113
2. Plan de Gestión de Calidad
3
4
FORMATOS 1. Métricas
2. Línea Base de Calidad
3. Plan de Gestión de Calidad
4
CHECKLISTS 1. De Métricas
2. De Auditorias
3. De Acciones Correctivas
4
OTROS
DOCUMENTOS
1
2
3
4
PROCESOS DE GESTIÓN DE LA CALIDAD: ESPECIFICAR EL ENFOQUE PARA REALIZAR LOS PROCESOS DE
GESTIÓN DE LA CALIDAD INDICANDO EL QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, CON QUÉ, Y PORQUÉ ENFOQUE DE
ASEGURAMIENTO
DE LA CALIDAD
El aseguramiento de calidad se hará monitoreando continuamente la perfomance del trabajo, los resultados del control de calidad, y sobre todo las métricas
De esta manera se descubrirá tempranamente cualquier necesidad de auditoria de procesos, o de mejora de procesos
Los resultados se formalizarán como solicitudes de cambio y/o acciones correctivas/preventivas
Asimismo se verificará que dichas solicitudes de cambio, y/o acciones correctivas/preventivas se hayan ejecutado y hayan sido efectivas
ENFOQUE DE
CONTROL DE LA
CALIDAD
El control de calidad se ejecutara revisando los entregables para ver si están conformes o no
Los resultados de estas mediciones se consolidarán y se enviarán al proceso de aseguramiento de calidad
Asimismo en este proceso se hará la medición de las métricas y se informarán al proceso de aseguramiento de calidad
Los entregables que han sido reprocesados se volverán a revisar para verificar si ya se han vuelto conformes
114
Para los defectos detectados se tratará de detectar las causas raíces de los defectos para eliminar las fuentes del error, los resultados y conclusiones se formalizarán como solicitudes de cambio y/o acciones correctivas/preventivas
ENFOQUE DE
MEJORA DE
PROCESOS
Cada vez que se requiera mejorar un proceso se seguirá lo siguiente: 1. Delimitar el proceso 2. Determinar la oportunidad de mejora 3. Tomar información sobre el proceso 4. Analizar la información levantada 5. Definir las acciones correctivas para mejorar el proceso 6. Aplicar las acciones correctivas 7. Verificar si las acciones correctivas han sido efectivas 8. Estandarizar las mejoras logradas para hacerlas parte del proceso
104
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
1
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Procedimiento, análisis y desarrollo de un sistema de
control de versiones distribuidas, sobre las
base de datos del Sistema PROMEINFO.
MANUAL DE CONFIGURACIÓN
AUTOR:
Victoria De Lourdes García Velásquez
TUTOR:
Ing. Alexandra Varela
GUAYAQUIL – ECUADOR
2015
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
2
Tabla de contenido
INTRODUCCION ............................................................................................................. 3
PANATALLAS Y COMANDOS ................................................................................. 3
Descarga e instalación GIT.................................................................................. 3
Descargar e Instalar My SQl ................................................................................ 6
Configuración e Instalación del GOGS ............................................................ 7
Manual de Usuario ......................................................................................................... 9
INTRODUCCION ............................................................................................................. 9
Descarga e instalación Cliente Git Source tree ........................................... 10
Utilizando Source Tree ....................................................................................... 11
Glosario de Términos ................................................................................................. 13
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
3
INTRODUCCION Mediante este documento se darán las directrices para la instalación de esta
herramienta tecnológica.
PANATALLAS Y COMANDOS
Descarga e instalación GIT Como principio para trabajar con la herramienta GIT, debemos visitar la dirección
https://git-scm.com/downloads la cual es la página oficial de GIT, donde de
manera segura se puede descargar la herramienta.
Luego de la instalación podemos trabajar mediante consola Promt o directamente
la consola de Git llamada GIT BASH.
En la siguiente imagen podemos ver la consola Git-Bash,.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
4
Lo primero que realizaremos en esta consola es identificarnos, esto lo haremos con los siguientes comandos.
$ git config --global user.name "Promeinfo"
$ git config --global user.email [email protected]
$ git log muestra los datos del usuario que se está utilizando
Con el Git Log nos muestra lo realizado dentro de los repositorios como lo muestra la imagen.
Git –versión nos muestra en que versión de Git estamos trabajando.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
5
Mkdir nos permite crear un directorio y con cd + el nombre del directorio se
establece la carpeta en la que se requiere trabajar.
Git init para crear un repositorio lo utilizaremos y con el comando LS-LA quien
nos muestra lo que se tiene dentro de los directorios.
Como vemos en la imagen en el direcorio no indican el .GIT con azul, esto es lo
que nos asegura que se ha convertido el directorio en un repositorio GIT.
Commit en consola Git en 2 pasos
1.- lo podemos en una zona intermedia temporal que la llamamos zona de index,
ahí guardamos los ficheros que luego vamos a darle commit.
Git Status me permite ver el estado de mi repositorio de Git.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
6
2.- git commit -m “mensaje del commit” con este comando damos por finalizado
el cambio realizado al repositorio, una vez que se da commit no se realizar un
retorno, a menos que vayamos al Commit anterior y regresar a lo que se tenía
hasta esa fecha.
Descargar e Instalar My SQl
Es necesario realizar la instalación de la base de datos, para este proyecto he
instalado My-Sql, esto es previo a la instalación y configuración del Gosth Git.
La guía de Instalaión se dan dentro de la pagina oficial de My sql.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
7
Configuración e Instalación del GOGS En e siguiente link https://gogs.io/ se puuede descargar el Gogs, que en si cumple
la function de ser la parte visible y amigable para evitar trabajar con comandos
dentro del git bash en el servidor.
Registramos la base de datos y procecedemos a conectarnos.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
8
Una vez registrados podremos accede y realizer las diversas actividades que se
deseen, desde crear o clonar un repositorio, hasta realizer los merch y las ramas,
cabe aclarar que todo lo trabajado en GOGS, se actulizará en el servidor.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
9
Manual de Usuario
INTRODUCCION
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
10
Con el fin de poder interactuar con el servidor donde se encuentran los
repositorios, cada usuario o participante del grupo deberán contar con un cliente
para GIT , el mismo que servirá de comunicación con el Gogs.
Descarga e instalación Cliente Git Source tree
En el siguiente link https://git-scm.com/downloads/guis podremos ent¡contrar
diferentes opciones de clients para GIT,para los diversos sistemas operativos
existentes, no es necesario imponer alguno se puede trabajar con el de su eleción,
para este proyecto hemos elegido trabajar con SOURCE TREE.
Este cliente GIT es compatible con los Sistemas operativos Wimdows, Mac y
Linux.
Una vez descargada, procedemos a la instalación de la misma siguiendo las
instrucciones que el instalador nos indique.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
11
Al finalizar la instalación nos mostrara la siguiente pantalla, totalmente vacia
pues aún no tiene conexión con el servidor.
Utilizando Source Tree
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
12
Lo primero que se debe realizar es el clonar un repositorio.
Nos pide la URL, que en este caso será la dirección IP que apunta al servidor de
aplicaciones donde se encuentra el repositorio.
Una vez clonados los repositorios tendremos la siguiente pantalla.
Este cliente no trabaja bajo comandos, es mucho más práctico y amigable al
usuario, pues ya trae los botones determinados para realizar las diferentes
acciones principales y primordiales del GIT.
ESTA INFORMACION ES CONFIDENCIAL Y DE USO EXCLUSIVO DE LA UNIVERSIDAD DE GUAYAQUIL
13
Glosario de Términos
GIT Herramienta de control de Versiones.
GOGS Go Servicio Git, es un auto alojado repositorio git de código abierto
plataforma de alojamiento bajo licencia MIT. Escrito en Ir, Gogs, es fácil de
instalar (ya sea con o ventana acoplable con los binarios), ligero (requisitos
mínimos).
GIT_BASH Consola de comandos GIT.