DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN

DEDICADA AL DESARROLLO DE SOFTWARE

PILAR STEPHANY MASS LÓPEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD TECNOLÓGICA

INGENIERÍA TELEMÁTICA

BOGOTÁ D.C.

2018

DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN

DEDICADA AL DESARROLLO DE SOFTWARE.

PILAR STEPHANY MASS LÓPEZ

Trabajo de informe de monografía para optar el título de Ingeniera Telemática

Director

NORBERTO NOVOA

Coordinador Tec. Sistematización de Datos e Ingeniería Telemática

Magister en Educación Informática

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD TECNOLÓGICA

INGENIERÍA TELEMÁTICA

BOGOTÁ D.C.

2018

Nota de aceptación.

_______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________

Tutor

_______________________________ Ing. Norberto Novoa

Jurado

______________________________ Ing. Sonia Alexandra Pinzón

Bogotá D.C, Septiembre de 2018

INTRODUCCIÓN

El presente documento describe y muestra las actividades correspondientes al desarrollo del proyecto: DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN DEDICADA AL DESARROLLO DE SOFTWARE, cuyo fin es el de permitir el acceso e integración a múltiples programas, herramientas y configuraciones que determinada empresa necesite para hacer el desarrollo sistemático de su producto final. El objetivo del proyecto descrito en este documento es el de permitir a una determinada empresa mejorar el proceso “End to End” del desarrollo de un software o producto, el cual, comprende las etapas de desarrollo, pruebas y puesta en producción; a partir de la implementación de un sistema web separado entre Back-End y Front-End, que mediante la utilización del patrón MVC orientado a Microservicios y con tecnologías tales como Java Spring Boot, Angular 6 en conjunto con Ionic 3 y REST API permitan la instalación y configuración automática de herramientas DevOps (herramientas de desarrollo y operaciones) en cada ambiente de trabajo de una empresa. Los ambientes de trabajo a considerar son: ambiente de desarrollo, el cual es el entorno en el cual el equipo de desarrollo puede ejecutar sus tareas sin preocuparse por dañar la última versión estable de un producto final; el ambiente de QA es el ambiente propicio en el cual, analistas pueden realizar pruebas unitarias y de integración sobre las entregas ejecutadas en el ambiente de desarrollo, por último, se encuentra el ambiente de producción, en el cual se aloja la versión estable del producto, generalmente aislado para evitar complicaciones de seguridad y/o disponibilidad, entre otros factores. La instalación y configuración automática se lleva a cabo en máquinas conectadas en redes locales para los ambientes de desarrollo y pruebas, para el caso de ambiente productivo el sistema aprovisionador se conectará a través de SSH a una instancia virtual en la nube. Además de las tecnologías mencionadas anteriormente para realizar el desarrollo del presente proyecto, como sistema de gestión de base de datos se utiliza PostgreSQL por ser un motor de base de datos con distribución libre y, además, su capacidad de gestionar bases de datos potentes y robustas, entre otras ventajas. La estructura del desarrollo del proyecto seguirá las fases de la metodología RUP, comenzando con la fase de planeación en donde la idea inicial constituye lo que se quiere crear, contiene el qué y el cómo. Con esta idea se identifican las necesidades, se reconoce el problema definiendo el propósito del aplicativo y se organiza un plan de actividades en donde se define el tiempo de desarrollo.

La siguiente fase, fase de análisis, detallará los requerimientos del sistema, proseguida por la fase de análisis que busca modelar el producto final deseado, a través de diagramas UML. Posteriormente la fase de implementación, en esta fase se construye el software, se integran los elementos del sistema produciéndose las distintas pantallas, se crean y se enlazan los elementos correspondientes. Se materializa el borrador efectuado en la fase del diseño y por último se encuentran las pruebas tienen como finalidad de depurar (hacer correcciones y localizar fallos) del prototipo a partir de su utilización por un grupo de usuarios (colaboradores); estos usuarios serán capaces de señalar puntos débiles, que cosas les agradaría que tuviera el aplicativo y que cosas no, como es la experiencia del manejo del proyecto. El aprovisionamiento automático se realiza con la ayuda de la herramienta Ansible, Ansible es un programa de software libre que realiza instalaciones multi-hilo a través de archivos llamados Task, en donde se encuentra toda la orquestación de la operatividad de Ansible, es decir, todo el libreto que Ansible necesita para realizar instalaciones y configuraciones. Es conveniente aclarar que la plataforma funciona especialmente en sistemas operativos con distribución Linux, debido a que las ventajas de trabajar y operar en software libre son mayores comparadas con trabajar en otros S.O como Windows o IOS, con los cuales se debe pagar para obtener permisos de distribución y de fabricante.

RESUMEN Muchas empresas dedicadas al desarrollo de software tienen la necesidad de automatizar tareas como el aprovisionamiento y configuración de sus diferentes servidores o máquinas de trabajo, automatizar este tipo de tareas puede hacer que la productividad de los desarrolladores, analistas y personal de operaciones incremente sustancialmente. El presente trabajo de informe mostrará el proceso de desarrollo e implementación del sistema PROVISIONER para la creación y administración de ambientes de trabajo, comprendidos en: ambiente de desarrollo, ambiente de pruebas y ambiente de producción; siguiendo la metodología RUP, basándose en el patrón de arquitectura MVC y desarrollado en STS IDE bajo el lenguaje Java Spring Boot en el Back-End y Angular 6/Ionic 3 en el Front-End. Spring Boot permite desarrollar servicios HTTP, dando como resultado una serie de interfaces llamadas REST, que permiten obtener información en formato JSON, el cual es mucho más liviano comparado con el formato XML. En conjunto con el lenguaje java, el sistema PROVISIONER se desarrolló con Angular 6 en el proyecto Front-End, un framework de JavaScript que permite, precisamente, realizar peticiones HTTP sin dificultad alguna hacia el Back-End y, una vez realizada la petición evita sobrecargar con peticiones al servidor. El desarrollo del presente proyecto permite que cualquier empresa pueda realizar el aprovisionamiento de “x” cantidad de máquinas y/o servidores en cada ambiente de trabajo, sin tener que invertir horas de trabajo humano realizando estas tareas, lo que produce mayor productividad y reduce el tiempo ocioso en los integrantes de los equipos de trabajo, además de mantener integración continua en los proyectos de la empresa. El aprovisionamiento de los ambientes de desarrollo y pruebas se realiza en máquinas conectadas en redes de área local, para el ambiente productivo, el sistema se conecta a instancias EC2 Amazon en la nube que contiene el producto estable de la empresa y mantiene aislado al mismo. Los ambientes de trabajo ayudan a aumentar la organización de un proyecto, y reducir los riesgos debido a errores técnicos y humanos que puedan afectar de forma adversa a clientes y propios. Estos están organizados a tres capas: ambiente de desarrollo, ambiente de pruebas y, por último, ambiente de producción. Adicionalmente se utiliza como herramienta clave Ansible, un software libre que logra realizar instalación y configuración de software en múltiples terminales; cuyo funcionamiento se basa en archivos llamados Task con extensión YML, que contienen el paso a paso del qué y cómo realizar aprovisionamiento.

ABSTRACT

Many companies dedicated to the development of software have the need to automate tasks such as the provisioning of their different servers or machines, automating this type of tasks can cause the productivity of the developers, analysts and maintenance personnel to increase substantially. This report will show the process of development and implementation of the PROVISIOINER system for the creation and administration of work environment environments, including: development environment, testing environment and production environment, following the RUP methodology, based on the MVC architecture pattern and developed in STS IDE under the Java Spring Boot language in the Back-End, which allows to develop HTTP services, resulting in a series of interfaces called REST, which allow obtaining information in JSON format, which is much lighter than the XML data format. In conjunction with the java language, the PROVISIONER system was developed with Angular 6 in the Front-End project, a JavaScript framework that allows, precisely, to make HTTP requests without any difficulty towards the Back-End and, once the request is made, it avoids performing new requests to the server. The development of this project allows any company to perform the supply of "x" number of machines and / or servers, without having to invest hours of human work performing these tasks, which produces greater productivity and reduce idle time in the members of work teams. The provisioning of the development and test environments is done in machines connected in local area networks, for the productive environment, the system connects to Amazon EC2 instances in the cloud that contains the stable product of the company and keeps it isolated. Work environments help reduce risks due to technical errors that can adversely affect customers and employees, and are organized into three layers: development environment, testing environment and, finally, production environment. Additionally, Ansible is a key tool, free software that manages installation and configuration of software in multiple terminals, whose operation is based on files called Task with YML extension, which contain the step-by-step of how and how to perform provisioning.

CONTENIDO

2. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN ................... 13

2.1. TÍTULO .............................................................................................. 13

2.2. TEMA ................................................................................................. 13

2.3. PROBLEMÁTICA ............................................................................... 13

2.4. OBJETIVOS ....................................................................................... 14

2.4.1. Objetivo general ................................................................................. 14

2.4.2. Objetivos específicos ......................................................................... 14

2.5. DELIMITACIONES ............................................................................. 14

2.6. MARCO DE REFERENCIA ................................................................ 15

2.6.1. Marco teórico ..................................................................................... 15

2.6.2. Marco histórico ................................................................................... 36

2.7. ALCANCE .......................................................................................... 38

2.8. FACTIBILIDAD ................................................................................... 39

2.8.1. Factibilidad Técnica ........................................................................... 39

2.8.2. Factibilidad Operativa ........................................................................ 39

2.8.3. Factibilidad Legal y Económica .......................................................... 40

2.9. CRONOGRAMA................................................................................. 41

......................................................................................................................... 41

3. MODELO DEL NEGOCIO ........................................................................ 42

3.1. Diagramas de procesos ..................................................................... 42

3.1.1. Módulo de creación del ambiente de desarrollo ................................. 42

3.1.2. Modulo de creación de ambiente de pruebas .................................... 43

3.1.3. Módulo de creación de ambiente de producción ................................ 45

3.2. Modelo de dominio creación del ambiente de desarrollo ................... 46

3.3. Modelo de dominio de creación del entorno de pruebas.................... 46

3.4. Modelo de dominio de creación de ambiente de producción ............. 46

3.5. Modelo de dominio general ................................................................ 47

3.6. Glosario de Términos ......................................................................... 48

4. FASE DE REQUERIMIENTOS ................................................................. 50

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES ....................... 50

4.1. Requerimientos Funcionales .............................................................. 50

4.2. Requerimientos No Funcionales ........................................................ 50

5. FASE DE ANÁLISIS ................................................................................. 52

5.1. Definición de actores .......................................................................... 52

5.2. Lista preliminar de los casos de uso .................................................. 52

5.3. Documentación casos de uso y diagramas de casos de uso ............. 54

5.4. Diagramas de secuencia .................................................................... 59

5.5. Diagramas de actividad ...................................................................... 62

5.6. Diagramas de colaboración ............................................................... 64

6. FASE DE DISEÑO .................................................................................... 66

6.1. Lista inicial de clases ......................................................................... 66

6.2. Diagrama de clases ........................................................................... 66

6.3. Diagrama de Entidad – Relación ....................................................... 68

6.4. Diagrama de Interfaz .......................................................................... 68

6.5. Diccionario de datos ........................................................................... 69

7. FASE DE IMPLEMENTACIÓN ................................................................. 72

7.1. Arquitectura ........................................................................................ 72

7.2. Diagrama de componentes ................................................................ 73

7.3. Diagrama de despliegue .................................................................... 74

7.4. Diagrama de paquetes ....................................................................... 75

8. FASE DE PRUEBAS ................................................................................ 77

8.1. Pruebas unitarias ............................................................................... 80

8.2. Pruebas de Integración ...................................................................... 83 CONCLUSIONES ..................................................................................... 88 RECOMENDACIONES ............................................................................. 89 ANEXOS ................................................................................................... 90 BIBLIOGRAFÍA ....................................................................................... 134

INFOGRAFÍA………………………………………………………………… 135

Índice de Figuras

Figura 1.Modelo entornos desarrollo, prueba y producción. ............................ 18

Figura 2.Infraestructura IaaS. ........................................................................... 30 Figura 3.Centros clientes AMAZON. ................................................................ 32 Figura 4.Muestra un ejemplo básico que se ejecuta en una arquitectura simplificada del sistema informático. ................................................................ 34 Figura 5.Ejecución Docker. .............................................................................. 34

Figura 6.Ansible le permite traducir este diagrama en un plano, que define las políticas de infraestructura. .............................................................................. 36 Figura 7. Diagrama de proceso modulo compañía ........................................... 43 Figura 8. Diagrama de proceso módulo proyecto ............................................. 44 Figura 9. Diagrama de proceso módulo máquinas ........................................... 45

Figura 10. Diagrama de proceso módulo Tasks . ¡Error! Marcador no definido. Figura 11.Diagrama de dominio ambiente de desarrollo .................................. 46

Figura 12.Diagrama de dominio Módulo de creación del entorno de pruebas . 46 Figura 13.Diagrama de dominio Módulo de creación de ambiente de producción ......................................................................................................................... 47 Figura 14.Modelo de dominio del sistema ........................................................ 48

Figura 15.Diagrama caso de uso 3.1 ............................................................... 55 Figura 16.Diagrama de caso de uso 4.1 .......................................................... 56

Figura 17.Diagrama de caso de uso 5.1 .......................................................... 57 Figura 18.Diagrama de caso de uso 6 ............................................................. 59 Figura 19.Diagrama de Secuencia caso de Uso 3.1: Adición de proyecto con sus respectivos ambientes ............................................................................... 60 Figura 20.Diagrama de Secuencia caso de uso 4.1 Adicionar una máquina local ......................................................................................................................... 60

Figura 21.Crear Tasks Ansible (programas y configuraciones) para cada ambiente........................................................................................................... 61 Figura 22.El administrador de cada ambiente ejecuta el aprovisionamiento .... 61

Figura 23.Diagrama de actividad caso 3.1 ....................................................... 62

Figura 24.Diagrama de actividad caso 4.1 ....................................................... 62 Figura 25.Diagrama de actividad caso 5.1 ....................................................... 63

Figura 26.Diagrama de actividad caso 6.1 ....................................................... 63 Figura 27.Diagrama de colaboración caso 3.1 ................................................. 64 Figura 28.Diagrama de colaboración caso 4.1 ................................................. 64

Figura 29.Diagrama de colaboración caso 5.1 ................................................. 65 Figura 30.Diagrama de colaboración caso 6.1 ................................................. 65 Figura 31. Diagrama de clases ......................................................................... 66 Figura 32.Diagrama E-R .................................................................................. 68 Figura 33.Diagrama de interfaz ........................................................................ 69

Figura 34. Diagrama de arquitectura ................................................................ 73 Figura 35.Diagrama de componentes .............................................................. 74 Figura 36.Diagrama de despliegue .................................................................. 75 Figura 37.Diagrama de paquetes ..................................................................... 76

Figura 38. Ejecutar aprovisionamiento Caso 6 ............................................... 133

Índice de tablas

Tabla 1.Presupuesto y fuentes de financiación. Elaboración Propia ................ 40

Tabla 2.Descripción de módulos principales .................................................... 42 Tabla 3.Glosario de Términos .......................................................................... 49 Tabla 4.Descripción de actores ........................................................................ 52 Tabla 5.Lista de casos de uso .......................................................................... 54 Tabla 6.Caso de Uso 3.1 Adición de proyecto con sus respectivos ambientes 54

Tabla 7.Caso de uso 4.1 .................................................................................. 56 Tabla 8.Caso de uso 5.1 .................................................................................. 57 Tabla 9.Caso de uso 6 ..................................................................................... 58 Tabla 10. Lista inicial de clases Back-End ....................................................... 66 Tabla 11.Lista inicial de clases Front-End ........................................................ 66

Tabla 12.Prueba unitaria 1 ............................................................................... 81 Tabla 13.Prueba unitaria 2 ............................................................................... 81 Tabla 14.Prueba unitaria 3 ............................................................................... 82 Tabla 15.Prueba unitaria 4 ............................................................................... 83 Tabla 16. Pruebas de integración 1 .................................................................. 84 Tabla 17.Pruebas de integración 2 ................................................................... 85 Tabla 18.Pruebas de integración 3 ................................................................... 85

Tabla 19.Pruebas de integración 4 ................................................................... 86

13

1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN

1.1. TÍTULO

DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN DEDICADA AL DESARROLLO DE SOFTWARE

1.2. TEMA

En el desarrollo del proyecto son abordados los temas de

metodología de desarrollo de software (RUP), patrón de arquitectura

MVC, servicios REST, cloud, aprovisionamiento, ambientes de

trabajo, front-end, backend y ansible.

1.3. PROBLEMÁTICA

Actualmente las empresas dedicadas a la creación de software deben tener ambientes de trabajo adecuados para los diferentes cargos que hay en el interior de ellas. Los programadores deben tener un ambiente de trabajo que cuente con el software necesario para poder desarrollar los requerimientos y hacer ajustes en el producto en el cual están trabajando; por otro lado, los tester o las personas encargadas en certificar la calidad del software deben tener acceso a los distintos desarrollos que van realizando los programadores a diario, esto con el fin de poder probar y encontrar inconsistencias en el producto, por último, el cliente debe tener a su disposición el sistema desarrollado, éste debe tener las siguientes características: usable, seguro, flexible, portable y tener el nivel de disponibilidad necesaria para todos los usuarios que lo usaran. Teniendo en cuenta que estos ambientes son creados y configurados de manera manual y que por lo general se presentan diversos problemas en la integridad y homogeneidad de los ambientes del mismo tipo, tales como: equipos de trabajo donde el producto no funciona, ambientes de QA que no son homogéneos a los ambientes de desarrollo y producción, ambientes de producción donde el producto instalado no contiene las versiones actualizadas de los desarrollos, el producto tiene inconsistencias no controladas e incluso cuando se realiza la adquisición de nuevos integrantes en la empresa existen demoras en tiempo para la configuración de su ambiente local. ¿Cómo apoyar la mejora de los procesos de generación y configuración de ambientes de trabajo dentro de una organización dedicada al desarrollo software?

14

1.4. OBJETIVOS

1.4.1. Objetivo general

Diseñar y desarrollar un sistema web que permita el aprovisionamiento automático de herramientas DevOps en una organización dedicada al desarrollo de software.

1.4.2. Objetivos específicos

• Diseñar y desarrollar un módulo que permita crear y parametrizar un ambiente de trabajo dinámico de desarrollo, a la medida de las necesidades de la empresa.

• Diseñar y desarrollar un módulo que permita la creación automática de un entorno de pruebas de integración que permita la certificación de la calidad de los desarrollos de la empresa basándose en la NORMA ISO/IEC 29119.

• Diseñar y desarrollar un módulo que permita crear un ambiente de producción ajustable a la demanda de los productos de la empresa utilizando instancias virtuales de AWS Amazon.

• Realizar la documentación técnica y funcional correspondiente al presente proyecto, incluyendo también manuales técnicos y funcionales.

1.5. DELIMITACIONES

Delimitación Geográfica El sistema será desarrollado en la domiciliación del estudiante.

Delimitación Temporal El sistema incluyendo la documentación y manuales de usuario se

ha proyectado a un tiempo de (6) meses.

Delimitación Temática El sistema abordará los siguientes temas:

RUP Modelado de negocio Requisitos Análisis Diseño Implementación Pruebas

15

UML 2.0

Patrón de arquitectura de Software

MVC

1.6. MARCO DE REFERENCIA

El diseño e implementación de un sistema de aprovisionamiento automático de herramientas DevOps (herramientas de desarrollo y operaciones) para una organización dedicada al desarrollo de software nace de la necesidad que tienen las fábricas de software al momento de contratar personal nuevo o incluso iniciar un la elaboración de un producto nuevo, ya que, el proceso de instalación y configuración para que una maquina posea el software necesario con el cual, un desarrollador, un “tester” o empleado operativo pueda realizar su trabajo, puede llegar a ser muy largo y/o desgastante. El sistema de aprovisionamiento “Provisioner”, pretende automatizar tareas humanas de búsqueda, descarga, instalación, actualización y configuración de software y/o herramientas, con el fin reducir tiempos de ejecución de las anteriores tares previamente mencionadas logrando que la curva de aprendizaje de un equipo de trabajo incremente, y aumentar productividad en fábricas de software.

1.6.1. Marco teórico

Ambientes de trabajo

El manejo de los ambientes de trabajo dentro de una organización se hizo imprescindible desde que se deseaba obtener un producto estable sin que pruebas o nuevos desarrollos realizados sobre el software afectan la funcionalidad de este.

Fue así como se dio lugar a diferentes políticas y estándares que dan como resultado buenas prácticas dentro de un equipo de trabajo. “El modelo de desarrollo, testing y producción es esencial para proveer los controles y el balance necesario para ejecutar un entorno de producción de alta disponibilidad de forma eficiente.” El modelo de desarrollo, testing y producción. (2013). Recuperado de: https://www.linuxito.com/programacion/237-el-modelo-de-desarrollo-testing-y-produccion. Las diferentes practicas comprenden:

• Analizar las características de cada ambiente, en el cual se incluyan limitantes, características necesarias, etc.

16

• Podría residir en el computador personal del desarrollador, en otros casos, podría ser un servidor compartido en el cual varios desarrolladores trabajan sobre el mismo proyecto.

• Ser lo más similar posible a los ambientes de pruebas y producción, a efectos de prevenir situaciones en las cuales el software desarrollado presente comportamientos distintos y errores en esos ambientes.

• También en componentes de infraestructura de TI deben ser similares, por ejemplo, ¿usa clúster en producción?, si es así, ¿Cómo se asegura que los componentes instalados en un servidor puedan desplegarse hacia otros servidores que componen el clúster? La única forma, es tener un ambiente de desarrollo o pruebas configurado en clúster en el cual los desarrolladores puedan validar sus programas.

• “Incluir réplicas de todos los componentes con los cuales el software tendrá interoperación en producción incluyendo: otras aplicaciones cliente servidor, bases de datos relacionales, componentes middleware, interfaces, demonios (Daemon), procesos personalizados, utilidades FTP y otros.”

• Utilizar nombres de dominio diferentes para los ambientes de producción, pruebas y desarrollo, a efectos de evitar confusión durante la ejecución de las pruebas.

• “Tener instalado el mismo manejador de base de datos, versión y calidad de los ambientes de prueba y producción. Si esto no es posible, usar herramientas automatizadas de propagación de una base de datos a otros.”. Norma de separación de Ambientes de trabajo Sistemas. (s,f). Recuperado de: https://www.hospitalitaliano.org.ar/multimedia/archivos/clases_attachs/1982-19.pdf

Herramientas DevOps

DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones o sistemas); se refiere a una práctica de ingeniería de software que se centra en realizar la unificación entre el desarrollo de software (Dev) y la operación (Ops). La principal característica del movimiento DevOps es proveer enérgicamente la automatización y el monitoreo en todos los pasos de la construcción

17

del software, desde la integración, las pruebas, la liberación hasta la implementación y la administración de la infraestructura.1

Ambientes de trabajo basados en el modelo desarrollo, testing, producción

Un entorno es un espacio técnico de trabajo que posee un alcance bien definido y respetado. La principal ventaja de los entornos es que ayudan a reducir los riesgos debido a errores técnicos que puedan afectar de forma adversa a un grupo de personas mayor al absolutamente necesario.

El modelo de desarrollo, pruebas y producción es esencial para un software final eficiente y que cumpla con las expectativas.

Creación de aplicaciones a tres capas:

Desarrollo: Es el entorno de trabajo para desarrolladores individuales o pequeños equipos de desarrolladores. Trabajando de forma aislada con el resto de los ambientes, para permitir a los desarrolladores realizar y probar cambios radicales en el código sin afectar de forma adversa al resto del equipo de trabajo. Estos entornos suelen estar ubicados localmente.

Pruebas de integración QA: Es un entorno común donde todos los desarrolladores realizan la “subida” de los cambios en el código. La meta de este entorno es combinar y validar el trabajo del equipo completo del proyecto para que pueda ser testeado.

La capa de pruebas es un entorno lo más idéntico posible al entorno de producción. El objetivo principal del entorno de QA es simular al entorno de producción con el fin de testear las actualizaciones (en un entorno similar al de producción) para asegurar que las mismas no corrompen la aplicación existente en los servidores en producción. De esta forma se minimizan los errores en producción, las demoras en entregas y las posibles marchas atrás a cambios indeseados.

Producción: La capa de producción puede incluir un servidor único o un “clúster” de servidores, bien sea físicos o virtualizados en la nube.

1 Somerville, I. (2011). Ingeniería de Software, p. 30. México: Editorial Pearson

18

Es el entorno donde trabajan los usuarios finales y se trabaja con los datos reales de negocio.

Figura 1.Modelo entornos desarrollo, prueba y producción. Recuperado de www.programacion/237-el-modelo-de-desarrollo-testing-y-produccion.

Metodología de desarrollo RUP Concepto El Rational Unified Process (RUP) es un proceso de ingeniería de software, creado por Ivar Jacobson, Grady Booch y James Rumbaugh, podemos definir RUP como el proceso unificado de desarrollo cuyo principal objetivo es el de mejorar la productividad y el proceso de desarrollo de software de un equipo de trabajo, así como también dar como resultado la puesta en marcha de las mejores prácticas en el desarrollo de software por parte de los integrantes de dicho equipo. RUP y la arquitectura Según Marcela García Alonso de la Universidad Tecnológica de Izucar de Matamoros el RUP es un proceso centrado en la arquitectura. La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además, la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo.

19

La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema. En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.2 Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software. Fases de trabajo en RUP • Modelado Del Negocio: Etapa del proceso que ayuda a establecer las reglas dentro de las cuales se puede llevar a cabo la creación o puesta en marcha del proyecto, además nos ayuda a identificar las posibles restricciones que se tendrán en la ejecución del proyecto. Se establecen y se tienen claros los objetivos, la misión y visión del proyecto. • Requerimientos: En esta etapa se deben establecer las necesidades funcionales y no funcionales del sistema que se quiera desarrollar en el proyecto; identificar los requerimientos permite visualizar la funcionalidad y los insumos necesarios para que el proyecto se vuelva una realidad. Requerimientos funcionales:

2 Rueda, J. (2006). Aplicación De La Metodología RUP Para El Desarrollo Rápido De

Aplicaciones basado En El Estándar J2EE, p. 4. Guatemala.

20

Se describen las operaciones y/o acciones que los futuros usuarios tengan que realizar al utilizar el sistema, y las operaciones que debe realizar el sistema para dar respuesta óptima al usuario. Requerimientos No Funcionales: Se enumeran los recursos necesarios para la Implementación del sistema (Software), como son el hardware y el software que no permitirán ejecutar el proyecto. • Análisis: Identificar y establecer las especificaciones técnicas del proyecto (Software), es decir identificar los requerimientos utilizando el leguaje de los desarrolladores para producir una proyección interna (Conceptual) del sistema. Buscar un puente entre el lenguaje que maneja el desarrollador y el lenguaje común para el usuario.3 En esta etapa se deben realizar las siguientes actividades: Realizar un diagrama de secuencia de cada caso de uso. Realizar los correspondientes diagramas de actividad. Realizar un diagrama de colaboración de cada caso de uso. Obtener un diagrama de estado de cada caso de uso general. • Diseño: Etapa en la cual se debe tener como resultado un modelo lógico del sistema a implementar, el cual debe ser físico y concreto. Es un plano de la implantación. El resultado del diseño debe ser mantenido durante todo el ciclo de vida del Software. Los pasos por seguir son los siguientes:

▪ Lo primero que se tiene que realizar es una lista inicial de objetos.

▪ Se debe retinar las responsabilidades de los objetos. ▪ Se deben identificar operaciones y atributos de los objetos,

e interacciones entre Estos. ▪ Por último, se tiene que detallar las relaciones entre los

objetos. • Implementación: Etapa en la que se deben codificar los resultados obtenidos en el diseñó en a nivel de componentes como archivos de código fuente, ejecutables, scripts, etc. Lo más lógico es que aquí se implementen

3 Rueda, J. (2006). Aplicación De La Metodología RUP Para El Desarrollo Rápido De:

Aplicaciones basado En El Estándar J2EE, p. 6. Guatemala: Grijalbo

21

las clases encontradas durante el diseño convirtiéndolas, si es necesario, en código. Otro de los objetivos de la implementación radica en probar los componentes individualmente e integrarlos en uno o más ejecutables. Los pasos por seguir son:

▪ Realizar pruebas de unidad (componentes individuales) ▪ Unificar componentes de acuerdo con el diagrama de

componentes, en donde se establece como se organizan los componentes y dependen unos de otros.

▪ Identificar componentes e incorporarlos al modelo general. • Pruebas: En esta etapa se prueba la estructura en general del sistema implementado y cada uno de los componentes o subsistemas que la conforman. Las pruebas se pueden realizar en diferentes casos y se deben realizar de acuerdo con el siguiente orden: Ejecutar las pruebas, comparar los resultados de las pruebas con los resultados esperados y ver las diferencias. Analizar los componentes y las pruebas diseñadas que presentaron esas discrepancias para un posible rediseño del componente o cambios en la prueba. Pueden realizarse pruebas de dos tipos: de integración y de aceptación. Pruebas de Integración: Las pruebas de integración buscan probar la combinación de las distintas partes de la aplicación para determinar si funcionan correctamente en conjunto.4 Pruebas de sistema: Pruebas que buscan garantizar que el desarrollo cumpla con los objetivos planteados inicialmente. Iteraciones: Se realizan cada una de las etapas correspondientes a la metodología, durante 4 iteraciones, las cuales son: iniciación, elaboración, construcción, y transición.

4 Pruebas de integración, la hora de la verdad para el software. (2017). Recuperado de:

https://www.obs-edu.com/int/blog-investigacion/sistemas/pruebas-de-integracion-la-hora-de-la-verdad-para-el-software

22

Iniciación: En esta iteración encontramos la primera fase de un proyecto y en gran parte se encuentran asociadas actividades de la fase de modelado de negocio. Elaboración: En esta iteración podemos encontrar las actividades relacionadas en mayor volumen a la fase de requerimientos Construcción: En esta iteración encontramos en su gran mayoría actividades de la fase de implementación. Transición: En esta iteración encontramos las actividades relacionadas a la fase final de RUP denominada despliegue. Según Departamento de Sistemas Informáticos y Computación de la Universidad Politécnica de Valencia: Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía. Cabe anotar que las actividades de cada fase son independientes de las iteraciones, lo cual a su vez permite identificar de una manera eficiente que operaciones se están realizando en tiempos que no corresponden para establecer correcciones sobre un proyecto.5

NORMA DE PRUEBAS ISO/IEC/IEEE 29119

Esta norma surge como la necesidad de estandarizar pruebas a nivel mundial, pues no existía claridad a la hora de realizar testing. Esta norma define el vocabulario, procesos, documentación, técnicas y un modelo de evaluación del proceso de pruebas de software que se puede utilizar dentro de cualquier ciclo de vida de desarrollo. Servirá para guiar la tendencia que existe en torno a la mejora de las pruebas del software, permitiendo normalizar el modo en que se planifican, diseñan, ejecutan y mantienen las pruebas, así como la manera en que se gestiona dentro de una organización el conocido, pero normalmente olvidado, proceso de Testing.6

5 Introducción a RUP, (s, f). Universidad Politécnica de Valencia. Recuperado de:

https://pid.disc.upv.es/C1/Material/Documentos%Documentos&2Disponibles/Introducción%20a/.doc

6 Jimenez B. NORMA ISO 29119 PRUEBAS/TESTING, p.3. (2012). Santa Cruz: Grijalbo.

23

ISO / IEC 29119 consta de las siguientes partes principalmente:

Parte 1 Definiciones y Vocabulario Su objetivo es dar una visión general de la norma y de los conceptos generales de pruebas de software y proporcionar un vocabulario de términos de pruebas de software que cubren las pruebas de todo el ciclo de vida del software.

Parte 2 Proceso de Pruebas La norma define un modelo de prueba de proceso genérico

que se puede utilizar dentro de cualquier desarrollo de software y ciclo de vida de la prueba. Este proceso se basa en un proceso de prueba de cuatro capas de cobertura: Especificaciones de organización de prueba (política organizativa de prueba, prueba de Estrategia Organizacional) Gestión de pruebas (prueba de gestión de proyectos, gestión de la fase de prueba) Los procesos dinámicos de prueba, incluyendo el diseño e implementación de prueba, entorno de prueba puesta a punto y mantenimiento, ejecución de pruebas y notificación de incidentes.

Parte 3 Documentación de Pruebas El estándar cubrirá documentación de pruebas en todo el ciclo de vida completo del software de prueba. Esto incluye plantillas que se pueden personalizar y que cubra todas las fases del proceso de pruebas.

Parte 4 Técnicas de Pruebas Descripción de las técnicas aplicadas.

Java Spring Boot

Para comenzar con la definición de Java Spring Boot es necesario remontarse a Spring, un framework muy popular en los últimos años que permite realizar aplicaciones empresariales, compuesto de herramientas que optimizan el rendimiento de cualquier aplicación, pues, utiliza la inyección de dependencias como filosofía principal, de esta manera, “la inyección de dependencias nos permite solucionar de forma sencilla y elegante cómo proporcionar a un objeto cliente acceso a un objeto que da un servicio que este necesita”. Introducción a Spring, p.5. (2012). Recuperado de: http://www.jtech.ua.es/j2ee/publico/spring-2012-13/wholesite.pdf

Angular

Angular es un framework de desarrollo para JavaScript creado por Google. La finalidad de Angular es facilitarnos el desarrollo de aplicaciones web SPA, es decir, una sola página, en la cual la navegación entre secciones y páginas de la aplicación, así como la carga de datos, se realiza de manera dinámica, casi instantánea,

24

asíncronamente haciendo llamadas al servidor (Back-End con un API REST) y sobre todo sin refrescar la página en ningún momento.7 Actualmente está disponible la versión 6, la cual tiene como particularidades que todas las respuestas del Back-End vienen por defecto en formato JSON, sin tener que utilizar funciones adicionales para realizar conversiones de datos.

JSON JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje, pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos.8

REST API

Una API REST es una interfaz de programación de aplicaciones que utiliza solicitudes HTTP para obtener datos de solicitudes GET, PUT, POST y DELETE. Cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún estado previo para satisfacerla.9 Una API REST, también conocida como RESTful web service, se basa en la tecnología de transferencia de estado representacional (REST), un estilo arquitectónico y un enfoque de las comunicaciones que a menudo se utilizan en el desarrollo de servicios web. Grandes empresas como Twitter, YouTube y los sistemas de identificación con Facebook utilizan REST al ser una solución más sencilla y más flexible que los servicios SOAP.

Microservicios

7 Robles, V. (Diciembre 2017), ¿Qué es angular y para qué sirve? Recuperado de:

https://victorroblesweb.es/2017/08/05/que-es-angular-y-para-que-sirve/ 8 Introducción a JSON, (s, f). Recuperado de: https://www.json.org/json-es.html 9 API REST: qué es y cuáles son sus ventajas en el desarrollo de proyectos. (Marzo 2016).

Recuperado de: https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos

25

Una arquitectura de microservicios se compone de una colección de servicios autónomos y pequeños. Cada servicio es independiente el uno del otro y cada uno debe implementar una funcionalidad de negocio individual. “Estas son algunas de las características que definen un microservicio:

• En una arquitectura de microservicios, los servicios son pequeños e independientes y están acoplados de forma flexible.

• Cada servicio es un código base independiente, que puede administrarse por un equipo de desarrollo pequeño.

• Los servicios pueden implementarse de manera independiente. Un equipo puede actualizar un servicio existente sin tener que volver a generar e implementar toda la aplicación.

• Los servicios son los responsables de conservar sus propios datos o estado externo. Esto difiere del modelo tradicional, donde una capa de datos independiente controla la persistencia de los datos.

• Los servicios se comunican entre sí mediante API bien definidas. Los detalles de la implementación interna de cada servicio se ocultan frente a otros servicios.

• No es necesario que los servicios compartan la misma pila de tecnología, las bibliotecas o los marcos de trabajo.” Wasson, M. (2017). Estilo de arquitectura microservicios. Recuperado de: https://docs.microsoft.com/es-es/azure/architecture/guide/architecture-styles/microservices

IONIC 3

Ionic es una herramienta, gratuita y open source, para el desarrollo de aplicaciones híbridas basadas en HTML5, CSS y JS. Está construido con Sass y optimizado con Angular. Ionic está construido para ser rápido gracias a la mínima manipulación del DOM, con cero jQuery y con aceleraciones de transiciones por hardware. Ionic utiliza Angular con el fin de crear un marco más adecuado para desarrollar aplicaciones ricas y robustas. Ionic no sólo se ve bien, sino que su arquitectura central es robusta y seria para el desarrollo de aplicaciones. Trabaja perfectamente con Angular.10

10 Pérez, J, J. (2015). Qué es y cómo empezar con Ionic Framework. Recuperado de:

http://www.phonegapspain.com/que-es-y-como-empezar-con-ionic-framework/

26

UML: Unified Modeler Language

Permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de la industria, para comprender qué es el UML, podemos analizar cada una de las palabras que lo componen, por separado. • Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación. • Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretación y entendimiento de éste. • Unificado: unifica varias técnicas de modelado en una única. Ya que el UML proviene de técnicas orientadas a objetos, se crea con la fuerte intención de que este permita un correcto modelado orientado a objetos, La principal diferencia de UML 2.0 con sus versiones anteriores se enfoca en estos dos objetivos: 1. Hacer el lenguaje de modelado mucho más extensible de lo que era. 2. Permitir la validación y ejecución de modelos creados mediante el UML. En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un lenguaje de programación. Un modelo creado mediante UML no podía ejecutarse. En el UML 2.0, esta percepción cambió de manera drástica y se modificó el lenguaje, de manera que permitiera capturar mucho más comportamiento. De esta forma, se permitió la creación de herramientas que soporten la automatización y generación de código ejecutable, a partir de modelos UML.11

PostgrestSQL

PostgreSQL es un motor de base de datos más avanzado y popular en el manejo de bases de datos relacionales open-source se refiere,

11 Rumbough J. Jacobson I. Booch, J. (2000). El lenguaje unificado de modelado. Manual de

referencia, p. 7. Editorial Parsons

27

además de ser gratuito y libre, ofrece una gran cantidad de opciones avanzadas. Una de las características de PostgreSQL es el control de concurrencias multisesión; o MVCC por sus siglas en inglés, lo cual nos permite hacer transacciones eventualmente consistentes, ofreciéndonos grandes ventajas en el rendimiento. En Postgres no se requiere usar bloqueos de lectura al realizar una transacción lo que nos brinda una mayor escalabilidad. También PostgreSQL tiene Hot-Standby. Este permite que los clientes hagan búsquedas (sólo de lectura) en los servidores mientras están en modo de recuperación o espera. Así podemos hacer tareas de mantenimiento o recuperación sin bloquear completamente el sistema.12

SSH

SSH o Secure Shell, es un protocolo de administración remota que permite controlar y modificar servidores remotos a través de Internet. Proporciona varios mecanismos de autenticación través de diferentes técnicas de cifrado como lo es la encriptación simétrica, el cual utiliza una clave secreta tanto para el cifrado como para el descifrado de un mensaje tanto por el cliente como por el host. Esta clave es conocida como llave que cumplen la función de cifrar la información entre un cliente y un servidor.

Integración continua

La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas.

Los objetivos clave de la integración continua consisten en encontrar y arreglar errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se tarda en validar y publicar nuevas actualizaciones de software.13

Con la integración continua, los desarrolladores envían los cambios de forma periódica a un repositorio compartido con un sistema de

12 Dontares, C, A. (2015). Qué es Postgres y cuáles son sus ventajas. Recuperado de:

https://platzi.com/blog/que-es-postgresql/ 13 Integración Continua ¿Qué, Cuando y Como? (noviembre 2016). Recuperado de

https://otroespacioblog.wordpress.com/2016/11/17/integracion-continua-entrega-continua-y-despliegue-continuo-que-cuando-y-como/

28

control de versiones como Git. Antes de cada envío, los desarrolladores pueden elegir ejecutar pruebas de unidad local en el código como medida de verificación adicional antes de la integración. El servicio de integración continua detecta los envíos al repositorio compartido y crea y ejecuta de forma automática pruebas de unidad en los cambios en el código para detectar al instante cualquier error funcional o de integración.14

Entrega continua

Con la entrega continua, se crean, prueban y preparan automáticamente los cambios en el código y se entregan para la fase de producción. La entrega continua amplía la integración continua al implementar todos los cambios en el código en un entorno de pruebas y/o de producción después de la fase de creación.

Despliegue continuo

El Despliegue Continuo es la implementación del patrón clásico Fail Fast (Fallar Rápido) para un proceso de entrega de software. Mientras más cerca ocurra un error del punto en el que fue introducido, más datos vamos a tener para corregir dicho error. En el código, Fail Fast significa que se debe lanzar una excepción ni bien detectamos parámetros o entradas incorrectas, en vez de esperar a que algo se rompa más adelante. En un proceso de entrega de software, Fail Fast significa entregar código a producción lo más rápido posible, en vez de esperar a todo un ciclo semanal o mensual (¡o más!) para que algo se rompa.

El Despliegue Continuo es muy simple: hay que entregar el código a los clientes lo más rápido que podamos. Quizás hoy signifique hacerlo semanalmente en vez de mensualmente, pero con el tiempo vamos a poder acercarnos al ideal, e iremos viendo los beneficios en todo este proceso.15

Infraestructura como servicio (IaaS) y Hardware como servicio

Las soluciones de infraestructura y hardware como servicio (IaaS / HaaS) son el segmento de mercado más popular y desarrollado de la computación en la nube. Proporcionan infraestructura

14 Amazon Web Services (AWS). ¿Qué es la integración continua?,(s, f). Recuperado de

“https://aws.amazon.com/es/devops/continuous-integration/” 15 Timothy, F. (2009). Continuos Deployment. Recuperado de

“http://timothyfitz.com/2009/02/08/continuous-deployment/”

29

personalizable a pedido. Las opciones disponibles dentro de IaaS ofrecen un rango de paraguas desde servidores individuales hasta infraestructuras enteras, incluidos dispositivos de red, balanceadores de carga y servidores de bases de datos y Web.

La principal tecnología utilizada para entregar e implementar estas soluciones es la virtualización de hardware: una o más máquinas virtuales configuradas e interconectadas oportunamente definen el sistema distribuido sobre el cual se instalan y despliegan las aplicaciones.

Las máquinas virtuales también constituyen los componentes atómicos que se implementan y tasan de acuerdo con las características específicas del hardware virtual: memoria, cantidad de procesadores y almacenamiento en disco.

Las soluciones IaaS / HaaS ofrecen todos los beneficios de la virtualización de hardware: partición de la carga de trabajo, aislamiento de aplicaciones, sandboxing y ajuste de hardware. Desde la perspectiva del proveedor de servicios, IaaS / HaaS permite explotar mejor la infraestructura de TI y proporciona un entorno más seguro donde ejecutar aplicaciones de terceros. 16

Desde la perspectiva del cliente, reduce los costos de administración y mantenimiento, así como los costos de capital asignados para comprar hardware. Al mismo tiempo, los usuarios pueden aprovechar la personalización completa que ofrece la virtualización para desplegar su infraestructura en la nube; en la mayoría de los casos, las máquinas virtuales vienen con solo el sistema operativo seleccionado instalado y el sistema se puede configurar con todos los paquetes y aplicaciones requeridos.

Otras soluciones proporcionan imágenes del sistema que ya contienen la pila de software requerida para los usos más comunes: Web servidores, servidores de bases de datos o LÁMP. Además de la gestión básica de la máquina virtual se pueden proporcionar servicios adicionales, generalmente incluyendo lo siguiente: basado en recursos del SLA asignación, gestión de carga de trabajo, soporte para diseño de infraestructura a través de interfaces web avanzadas, caras y la capacidad de integrar soluciones de IaaS de terceros.17

16 Duarte, E. (Julio 2017). Cerrando la brecha de la discapacidad tecnológica. Recuperado de:

http://blog.capacityacademy.com/2017/07/07/cerrando-la-brecha-de-la-discapacidad-tecnologica-rafael-gerardo-tedxsantodomingo/

17 Rajkumar B, Christian V, Thamarai S. (2013). Mastering Cloud Computing. Morgan

Kaufmann, p. 114

30

Figura 2.Infraestructura IaaS. Recuperado de: https://garatucloud.com/beneficios-cloud-gestionado-para-empresas/iaas-gestionado-infraestructura-como-servicio/

Computación en la nube

Casi todas las soluciones de TI están etiquetadas con el término computación en la nube o simplemente en la nube hoy en día. Una palabra de moda puede ayudar a vender, pero es difícil trabajar en un libro. La computación en la nube, o la nube, es una metáfora para el suministro y el consumo de recursos de TI. Los recursos de TI en la nube no son visibles directamente para el usuario; hay capas de abstracción en el medio. El nivel de abstracción ofrecido por la nube puede variar de hardware virtual a sistemas distribuidos complejos.18

Los recursos están disponibles bajo demanda en cantidades enormes y se pagan uso. Las nubes a menudo se dividen en los siguientes tipos:

Público: Una nube administrada por una organización y abierta al uso por el público en general.

Privado: una nube que virtualiza y comparte la infraestructura de TI dentro de una sola organización.

18 Computación en la nube, (s.f). Recuperado de http://www.mintic.gov.co/portal/604/w3-

propertyvalue-34317.html

31

Híbrido: una mezcla de una nube pública y una privada. AWS es una nube pública. Los servicios de computación en la nube también tienen varias clasificaciones:

Infraestructura como servicio (IaaS): ofrece recursos fundamentales como la informática, el almacenamiento y las capacidades de red, utilizando servidores virtuales como Amazon EC2, Google Compute Engine y máquinas virtuales de Microsoft Azure.

Plataforma como servicio (PaaS): proporciona plataformas para desplegar aplicaciones personalizadas en la nube, como AWS Elastic Beanstalk, Google App Engine y Heroku.

Software como servicio (SaaS): combina la infraestructura y el software que se ejecutan en la nube, incluidas aplicaciones de oficina como Amazon WorkSpaces, Google Apps for Work y Microsoft Office 365.19

Amazon web services (AWS)

Amazon Web Services (AWS) es una plataforma de servicios web que ofrece soluciones para computación, almacenamiento y redes, en diferentes niveles de abstracción. Puede usar estos servicios para alojar sitios web, ejecutar aplicaciones empresariales y extraer enormes cantidades de datos. El término servicio web significa que los servicios se pueden controlar a través de una interfaz web. La interfaz web puede ser utilizada por máquinas o por humanos a través de una interfaz gráfica de usuario. Los servicios más destacados son EC2, que ofrece servidores virtuales y S3, que ofrece capacidad de almacenamiento. Los servicios en AWS funcionan bien juntos; puede usarlos para replicar la configuración local existente o diseñar una nueva configuración desde cero. Los servicios se cobran en un modelo de precios de pago por uso.20 La siguiente imagen muestra los centros de datos disponibles para todos los clientes:

19 Andreas, M (2016). Amazon web services in action, p. 4 Manning 20 Andreas, M (2016). Amazon web services in action, p. 3 Manning

32

Figura 3.Centros clientes AMAZON, Recuperado de: https://services.amazon.es/servicios/amazon-ventas-globales/informacion-general.html

Software enfocado a orquestación de ambientes de desarrollo, QA y producción de forma distribuida

Docker

Docker es un programa de línea de comandos, un Daemon de fondo y un conjunto de servicios remotos que toman un enfoque logístico para resolver problemas de software comunes y simplificar su experiencia de instalación, ejecución, publicación y eliminación de software. Logra esto utilizando una tecnología UNIX llamada contenedores.21

Contenedores

Históricamente, los sistemas operativos de estilo UNIX han utilizado el término “jail” para describir un entorno de ejecución modificado para un programa que evita que el programa acceda a recursos protegidos. Desde 2005, tras el lanzamiento de Solaris 10 y Solaris Containers de Sun, el contenedor se ha convertido en el término preferido para este entorno de tiempo de ejecución. El objetivo se ha ampliado de impedir el acceso a los recursos protegidos para aislar un proceso de todos los recursos excepto cuando se permita explícitamente.

El uso de contenedores ha sido una buena práctica durante mucho tiempo. Sin embargo, la construcción manual de contenedores puede ser difícil y fácil de hacer incorrectamente. Este desafío los ha puesto fuera de alcance para algunos, y contenedores mal

21 Nickoloff, J. (2016). Docker in action, p. 4. Manning Segunda Edición.

33

configurados han embrollado a otros en una falsa sensación de seguridad. Necesitamos una solución a este problema, y Docker ayuda. Cualquier software ejecutado con Docker se ejecuta dentro de un contenedor. Docker utiliza motores de contenedores existentes para proporcionar contenedores consistentes construidos de acuerdo con las mejores prácticas. Esto pone una mayor seguridad al alcance de todos. Con Docker, los usuarios obtienen contenedores a un costo mucho menor.

A medida que Docker y sus motores de contenedores mejoran, obtendrá las últimas y mayores características de la cárcel. En lugar de mantenerse al día con el rápido desarrollo y el mundo altamente técnico de la construcción de cárceles de aplicación fuerte, puede dejar Docker manejar la mayor parte de eso para usted. Esto le ahorrará mucho tiempo y dinero y traerá la paz de la mente.22

Los contenedores no son virtualización

Sin Docker, las empresas normalmente utilizan la virtualización de hardware (también conocida como máquinas virtuales) para proporcionar aislamiento. Las máquinas virtuales proporcionan hardware virtual en el que se puede instalar un sistema operativo y otros programas. Tienen un tiempo largo (a menudo minutos) para crear y requieren gastos indirectos significativos del recurso porque ejecutan una copia entera de un sistema operativo además del software que usted desea utilizar.

A diferencia de las máquinas virtuales, los contenedores Docker no utilizan virtualización de hardware. Los programas que se ejecutan dentro de los contenedores de Docker interactúan directamente con el kernel Linux del host. Debido a que no hay capa adicional entre el programa que se ejecuta dentro del contenedor y el sistema operativo de la computadora, no se desperdician recursos ejecutando software redundante o simulando hardware virtual. Esta es una distinción importante. Docker no es una tecnología de virtualización. En su lugar, le ayuda a utilizar la tecnología de contenedor ya incorporada en su sistema operativo.23

Ejecución de software en contenedores para aislamiento Como se señaló anteriormente, los contenedores han existido durante décadas. Docker utiliza los namespaces y cgroups de Linux, que han sido parte de Linux desde 2007. Docker no proporciona la tecnología de contenedores, pero específicamente hace que sea

22 Nickoloff, J. (2016). Docker in action, p. 4. Manning Segunda Edición. 23 Nickoloff, J. (2016). Docker in action, p. 4. Manning Segunda Edición.

34

más fácil de usar. Para entender cómo se ven los contenedores en un sistema, establezcamos primero una línea de base con la siguiente figura:

Figura 4.Muestra un ejemplo básico que se ejecuta en una arquitectura simplificada del sistema informático. Recuperado de: https://www.redhat.com/es/topics/containers/what-is-

docker

Observe que la interfaz de línea de comandos, o CLI, se ejecuta en lo que se llama memoria de espacio de usuario al igual que otros programas que se ejecutan en la parte superior del sistema operativo. Idealmente los programas que se ejecutan en el espacio del usuario no pueden modificar la memoria del espacio del kernel. En términos generales, el sistema operativo es la interfaz entre todos los programas de usuario y el hardware en el que se está ejecutando el equipo. En la siguiente figura se puede ver que ejecutar Docker significa ejecutar dos programas en el espacio de usuario. El primero es el Daemon Docker. Si se instala correctamente, este proceso siempre debe estar en ejecución. El segundo es el Docker CLI. Este es el programa Docker con el que los usuarios interactúan. Si desea iniciar, detener o instalar software, emitirá un comando utilizando el programa Docker.

Figura 5.Ejecución Docker. Recuperado de https://www.redhat.com/es/topics/containers/what-is-docker

Muestra tres contenedores en ejecución. Cada uno se ejecuta como un proceso secundario del Daemon Docker, envuelto con un

35

contenedor y el proceso de delegado se ejecuta en su propio subespacio de memoria del espacio de usuario. Los programas que se ejecutan dentro de un contenedor pueden tener acceso sólo a su propia memoria y recursos según el alcance del contenedor.24

Software enfocado al aprovisionamiento y configuración de máquinas virtuales

Ansible

Ansible es una herramienta sencilla, flexible y extremadamente potente que le permite automatizar tareas comunes de infraestructura, ejecutar comandos e implementar aplicaciones multi-techo que abarcan varias máquinas. A pesar de que puede utilizar Ansible para ejecutar comandos en varios hosts en paralelo, la verdadera potencia radica en administrar aquellos que usan playbooks. Como ingenieros de sistemas, la infraestructura que normalmente necesitamos automatizar contiene aplicaciones multitier complejas. Cada uno de los cuales representa una clase de servidores, por ejemplo, equilibradores de carga, servidores web, servidores de bases de datos, aplicaciones de almacenamiento en caché y colas de middleware. Dado que muchas de estas aplicaciones tienen que trabajar en tándem para proporcionar un servicio, también hay topología implicada. Por ejemplo, un equilibrador de carga se conecta a los servidores web, que a su vez leen / escriben en una base de datos y se conectan al servidor de almacenamiento en caché para recuperar objetos en memoria. La mayoría de las veces, cuando lanzamos dichas pilas de aplicaciones, necesitamos configurar estos componentes en un orden muy específico.

24 Nickoloff, J. (2016). Docker in action, p. 5. Manning Segunda Edición.

36

Figura 6.Ansible le permite traducir este diagrama en un plano, que define las políticas de infraestructura. Recuperado de

https://www.ansible.com/resources/whitepapers/devops-and-legacy

1.6.2. Marco histórico

Historia de los entornos de los entornos de desarrollo integrados.

Enero 1, 1952

El primer compilador fue escrito por Grace Hopper para el lenguaje de programacion A-0. Un compilador es un programa que se encarga de pasar el codigo fuente a lenguaje de bajo nivel capaz de ser interretado por una máquina.

Posteriormente, Grace Hopper acuñó el término BUG. De ahí nace el termino Debugger o Depurador que es un ejecutable o una herramienta para probar y eliminar errores.

Enero 1, 1975

El primer entorno integrado para desarrolladores se llamó Maestro que es un producto de Softlab Munich y fue el primero en el mundo del software.

Enero 1, 1980

Las interfaces graficas se popularizan y como consecuencia se obtienen las GUI. La Interfaz Gráfica de Usuario (GUI) es el conjunto de elementos gráficos como ventanas, iconos, botones, etc.; que permiten una interacción Usuario-Aplicación. Algunos IDEs tienen incorporada esta herramienta para un buen desarrollo de software.

Enero 1, 1984

VisualAge era el nombre de una familia de entorno integrado de desarrollo el cual manejaba múltiples lenguajes de programacion como: BASIC, COBOL, C, C + +, EGL, Fortran, Java, PACBASE,

37

Smalltalk y era multiplataforma. Con la salida al público del JDK desarrollado por SunMycrosystem, los IDE’s dieron un nuevo giro en cuanto a IDES más intuitivos y amables con el desarrollador, como por ejemplo Netbeans en Jan 1, 1997 totalmente escrito en Java.

Por otro lado, en May 1, 1997 nace Visual Studio, un entorno diseñado para Sistemas Operativos Windows.

Finalmente, en enero de 2001 nace el popular Eclipse, un reemplazo de VisualAge. Este Entorno Integrado de Desarrollo es de código abierto, los lenguajes de programacion que acepta son: JAVA, C, C++, JSP, PHP, etc.25

Historia de los entornos de prueba o Sandbox

Un sandbox, en el contexto de desarrollo de software o desarrollo web, es un entorno de pruebas o cerrado que aísla los cambios en el código, fruto de la experimentación, del propio entorno de producción.

El sandbox protege en tiempo real los servidores de datos, y hace de control preventivo de la ejecución de código fuente, datos o contenido, evitando unos cambios que podrían ser perjudiciales (independientemente de la intención del autor de los mismos) para un sistema, o que simplemente, podrían ser cambios de difícil reversión.

Antes de 1956. Periodo orientado a debugging.

“En este momento todas las pruebas que se realizaban estaban orientadas a la corrección directa del código fuente de los programas. Eran realizadas directamente por los programadores y no estaba clara la diferencia entre: checkout, debugging y testing”. Turing, A. (1949): Checking a Large Routine, p. 5.

2. Entre 1957 y 1978. Periodo orientado a demostración.

“En este momento las pruebas se centran en la realización de checkouts exhaustivos que se focalizan en dos aspectos clave. Por un lado, hay que asegurar que el programa funciona (Debugging) y por otro asegurar que el programa resuelve el problema (Testing)”. C. Baker. (1957). Review of D.D. McCracken’s Digital Computer Programming.

25 Gonzales, C, (s, f). Historia de los entornos integrados. Recuperado de:

https://www.timetoast.com/timelines/historia-de-los-entornos-integrados-de-desarrollo-ide

38

3. Entre 1979 y 1982. Periodo orientado a destrucción.

En este periodo las pruebas se enfocan en encontrar errores en los sistemas, buscar debilidades y puntos de quiebre: En 1979 G.J. Myers, publica The Art of Software Testing, donde expone que el “Testing es el proceso de ejecutar un programa con la intención de encontrar errores.”

4. Entre 1983 y 1984. Periodo orientado a evaluación.

Las pruebas de Software empiezan a integrarse en las diferentes metodologías de desarrollo de software. “El objetivo general de las pruebas de software es confirmar la calidad de los sistemas software ejercitando sistemáticamente el software en unas circunstancias cuidadosamente controladas” E.F. Miller.

5. Entre 1985 y la actualidad. Periodo orientado a prevención

En 1985 H. Hetzel, y D. Gelperin, implementan STEP (Systematic Test and Evaluation Process) sobre los estándares formales IEEE 829-1983 y 828-1998. Este hecho consigue que las pruebas del software cobren una mayor importancia en el ciclo de desarrollo de software con lo que se abre la posibilidad de integrar pruebas en las diferentes fases de este.26

1.7. ALCANCE

La elaboración del sistema de aprovisionamiento comprenderá dentro de su desarrollo los siguientes alcances:

• Módulo de creación del ambiente de desarrollo: Permite administrar máquinas al ambiente de desarrollo, crear Taks y seleccionar el Software a ser aprovisionado por Ansible que aprovisionará dichas máquinas. El aprovisionamiento se realizará en redes locales, así como también en máquinas desplegadas en la nube.

• Módulo de creación del ambiente de pruebas: Permite administrar máquinas del ambiente de pruebas, crear Taks y seleccionar el Software a ser aprovisionado por Ansible que aprovisionará dichas máquinas. El aprovisionamiento se realizará en redes locales, así como también en máquinas desplegadas en la nube.

26 Hetzel, H. (1985). Systematic Test And Evaluation Process, p. 463-474.

39

• Módulo de creación de ambiente de producción: Permite administrar máquinas del ambiente de producción, crear Taks y seleccionar el Software a ser aprovisionado por Ansible que aprovisionará dichas máquinas. El aprovisionamiento se realizará en redes locales, así como también en máquinas desplegadas en la nube.

1.8. FACTIBILIDAD

1.8.1. Factibilidad Técnica

Para el desarrollo del sistema multinivel se contará con 1 equipos de cómputo con las siguientes características y una instancia de Amazon EC2.

Equipo de cómputo:

● 1TB de espacio en disco ● 16GB memoria RAM ● Intel Corei5 2.3 GHz ● Sistema Operativo Ubuntu 17.10 ● Motor de base de datos Postgres 9.6

Instancia AWS: Instancia T2 nano: CPU Intel Xeon Virtual:1 Cruds por la Hora de CPU: 3 Memoria: 0.5 GB

1.8.2. Factibilidad Operativa

Los equipos desde donde se instalará el software deberán

poseer los siguientes requerimientos mínimos:

Procesador Intel/AMD + 2.0 GHz 768 Mb de memoria RAM 500MB de espacio en disco UBUNTU 9.04 en adelante

40

1.8.3. Factibilidad Legal y Económica

PRESUPUESTO Y FUENTES DE FINANCIACION

RECURSO ESTUDIANTE UNIVERSIDAD EMPRESA/ ENTIDAD

Bibliografía $150.000 $560.000 $0

Papelería $250.000 $0 $0

Telecomunicaciones $1’200.000 $0 $0

Equipos $2’000.000 $0 $0

Transporte $600.000 $0 $0

Asistencia a eventos $1’300.000 $0 $0

Gastos de representación $0 $0 $0

Trabajo Estudiante $18’000.000 $0 $0

Trabajo director $0 $6’000.000 $0

Trabajo Asesor $0 $0 $0

Software licenciado $730.000 $0 $0

Software Libre $0 $0 $0

Otro $0 $0 $0

Subtotal $24’230.000 $6’560.000 $0

Subtotal $30’790.000

Imprevistos (10%) $3’079.000

Total $33’869.000 Tabla 1.Presupuesto y fuentes de financiación. Elaboración Propia

41

1.9. CRONOGRAMA

Figura 7. Cronograma del proyecto

42

2. MODELO DEL NEGOCIO

A continuación, se desarrolla la etapa del proyecto que ayuda a establecer las

reglas dentro de las cuales se llevarán a cabo los procesos, además nos ayuda

a identificar las posibles restricciones que se tendrán en la ejecución y aporta

una idea general de cuál debe ser el curso normal de los eventos.

Módulos principales del sistema de aprovisionamiento

Nombre Descripción

Módulo de creación del ambiente de desarrollo

Instalación y configuración de herramientas de desarrollo y herramientas operativas seleccionadas por el administrador del ambiente.

Módulo de creación del entorno de pruebas

Instalación y configuración de herramientas de “testeo” y herramientas operativas seleccionadas por el administrador Tester QA

Módulo de creación de ambiente de producción

Instalación y configuración de software del cual dependerá el producto final en AWS

Tabla 2.Descripción de módulos principales

2.1. Diagramas de procesos

A continuación, se describen los procesos principales que se utilizaron para la realizar la gestión de las actividades principales del sistema “Provisioner”.

• Módulo de creación del ambiente de desarrollo

• Módulo de creación del entorno de pruebas

• Módulo de creación de ambiente de producción

2.1.1. Módulo de creación del ambiente de desarrollo En este proceso el administrador de la aplicación se encarga de registrar los datos de la compañía, posteriormente registra el nombre del proyecto, el que por defecto tendrá tres ambientes de trabajo asociado, siendo uno de estos el ambiente de desarrollo. En el ambiente de desarrollo podrá adicionar y gestionar máquinas que pertenecerán a este ambiente y gestionar software a partir de plantillas existentes por defecto o crear una nueva plantilla, para poder aprovisionar este ambiente.

43

Figura 8. Diagrama de proceso modulo compañía

2.1.2. Modulo de creación de ambiente de pruebas

Al registrar un proyecto, el administrador puede acceder al ambiente de pruebas. En el ambiente de pruebas podrá adicionar y gestionar máquinas que pertenecerán a este ambiente y gestionar

44

software a partir de plantillas existentes por defecto o crear una nueva plantilla, para poder aprovisionar este ambiente.

Figura 9. Diagrama de proceso módulo proyecto

45

2.1.3. Módulo de creación de ambiente de producción Después de crear una empresa y registrar un proyecto, el administrador puede acceder al ambiente de producción. En el ambiente de pruebas podrá adicionar y gestionar máquinas que pertenecerán a este ambiente y gestionar software a partir de plantillas existentes por defecto o crear una nueva plantilla, para poder aprovisionar este ambiente

Figura 10. Diagrama de proceso módulo máquinas

46

2.2. Modelo de dominio creación del ambiente de desarrollo

Este módulo realizará la creación y configuración dinámica del entorno de desarrollo en las máquinas locales de los developers, con los programas y configuraciones necesarias para que el desarrollador de una empresa o proyecto determinado pueda ejercer su trabajo de forma eficiente.

Figura 11.Diagrama de dominio ambiente de desarrollo

2.3. Modelo de dominio de creación del entorno de pruebas

Módulo cuyo objetivo principal será la creación y configuración automatizada del ambiente de pruebas basado en el ambiente productivo, con los programas y configuraciones necesarias para que un tester de una empresa o proyecto determinado pueda ejercer su trabajo de forma eficiente.

Figura 12.Diagrama de dominio Módulo de creación del entorno de pruebas

2.4. Modelo de dominio de creación de ambiente de producción

El módulo de creación del ambiente productivo se encargará de montar en cloud en los programas y configuraciones necesarias para que en el ambiente productivo se pueda instalar y configurar las

47

últimas versiones estables del software/ producto realizado y testeado en los ambientes anteriores.

Figura 13.Diagrama de dominio Módulo de creación de ambiente de producción

2.5. Modelo de dominio general

El modelo de dominio es una vista de todos los objetos que hacen un área de interés, y sus relaciones. Se usa para capturar los objetos significativos dentro de un sistema, organización o cualquier dominio de destino. En este caso de muestran todas las entidades del sistema y sus respectivas operaciones, sus relaciones con otras entidades con el objetivo de modelar su participación dentro del sistema de aprovisionamiento y cómo se realiza el mismo.

48

Figura 14.Modelo de dominio del sistema

2.6. Glosario de Términos

TÉRMINO DESCRIPCIÓN

Administradores

Es la persona encargada de hacer uso de los servicios del proyecto “Provisioner”

Máquina Hace referencia a los equipos donde trabajan las personas encargadas de ejercer su respectivo rol dentro del proyecto

Ambiente

Los ambientes de trabajo para software son una práctica recomendada. Esto se hace para realizar cambios, probarlos sin afectar el funcionamiento estable del aplicativo y afectar a los clientes. En general siempre he trabajado con tres ambientes: desarrollo, pruebas y producción.

49

Ansible Es un sistema de orquestación escrito en Python, que nos permite automatizar la configuración de una máquina

Ansible Tasks

Los ansibles Tasks son scripts, interpretados por Ansible para saber qué aplicaciones y configuraciones debe instalar en cada máquina de cada ambiente

Tabla 3.Glosario de Términos

50

3. FASE DE REQUERIMIENTOS

A continuación, se presentarán algunos de los requisitos funcionales y no

funcionales del sistema.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

3.1. Requerimientos Funcionales

• Creación de empresa, el proyecto de una empresa y configuración de las máquinas asociadas a un ambiente del proyecto.

• Documentación disponible del sistema, documentación técnica, de usuario, de procesos, modelo de datos y cualquier otro documento de caracterización del sistema.

• El acceso a la plataforma “Provisioner” está limitado a las personas que se registren en la plataforma, las cuales poseerán un usuario y contraseña para poder entrar y hacer uso de los servicios.

• La plataforma “Provisioner” debe tener una interfaz que incluya y separe todas las funciones para los usuarios según las opciones de trabajo disponibles.

• Permitir al administrador de todo el sistema gestionar usuarios y proyectos.

• Permitir al administrador del módulo de Desarrollo crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

• Permitir al administrador del módulo de Pruebas QA crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

• Permitir al administrador del módulo de Producción crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

3.2. Requerimientos No Funcionales

● Glosario de Términos Módulo de Soporte La plataforma siempre estará disponible 24/7.

● La plataforma siempre operará con óptimo rendimiento. ● El sistema debe estar en capacidad de permitir en el futuro el

desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en funcionamiento.

● El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, etc.

● El sistema tendrá el mismo comportamiento en todos los

51

navegadores web y en cualquier dispositivo en donde se acceda a esta.

● La eficiencia de los reportes estará́ determinada en gran medida por el aprovechamiento de los recursos, y la velocidad de las consultas en la Base de Datos.

52

4. FASE DE ANÁLISIS

El objetivo de esta fase es obtener un borrador de lo que será el producto final.

En esta fase se estructura los contenidos que la fase de planeación determinó

que serán desarrollados en el aplicativo.

4.1. Definición de actores

A continuación, se definen las entidades externas al sistema que

guardarán relación con este y harán demandas a su funcionalidad.

Actor Descripción

Administrador de Ambientes de Desarrollo (Desarrollador)

Puede definir cuáles programas y configuraciones llamados “Ansible Tasks “son necesarios en las máquinas que pertenecen al ambiente de desarrollo.

Administrador de ambientes de QA (Analista QA)

Puede definir cuáles programas y configuraciones llamados “Ansible Tasks “son necesarios en las máquinas que pertenecen al ambiente de QA.

Administrador de DevOps

Puede gestionar y autorizar que programas y configuraciones son necesarias para el ambiente de producción

Usuario Administrador de todo el sistema

Este usuario tiene las tareas específicas de configurar la empresa que va a implementar el software “Provisioner”. Con el objetivo de definir proyectos y asignarlos a ambientes establecidos previamente, así como también asignar usuarios a dichos proyectos.

Tabla 4.Descripción de actores

4.2. Lista preliminar de los casos de uso El modelo de casos de uso es un catálogo de la funcionalidad del sistema que se describe usando casos de uso UML. Cada caso de uso representa una sola interacción repetible que un usuario o "actor" experimenta cuando usa el sistema.

Casos de uso

Super Administrador

Administrador de Desarrollo

Administrador de Pruebas QA

Administrador DevOps

1 Login

1.2 Registro

1.3 Administración de Roles - Permisos

1.4 Logout

53

CRUD EMPRESA

2.1 Adicionar empresa

2.2 Editar datos de una empresa

2.3 Listar todas las empresas

2.4 Filtrar una empresa

CRUD PROYECTO

3.1

Adición de proyecto con sus respectivos ambientes

3.2 Edición de proyecto

3.3 Deshabilitar/ Habilitar un proyecto

3.4

Listar todos los proyectos de una empresa

3.5 Filtrar un proyecto

CRUD MÁQUINA

4.1 Adicionar una máquina local

4.2 Edición de maquina

4.3 Deshabilitar/Habilitar una maquina

4.4 Listar todas maquinas

4.5 Filtrar una maquina

4.6

Asignar una máquina a un usuario

CRUD TAREAS (TASK ANSIBLE)

5.1

Crear Tasks Ansible (programas y configuraciones) para cada ambiente

5.2

Eliminar Task Ansible (programas y configuraciones) para ambiente

5.3 Listar Task Ansible (programas y

54

configuraciones) para cada ambiente

EJECUCIÓN DEL APROVISIONAMIENTO

6

El administrador de cada ambiente ejecuta el aprovisionamiento

Tabla 5.Lista de casos de uso

4.3. Documentación casos de uso y diagramas de casos de uso

A continuación, se presentarán los casos de uso más relevantes del

sistema, los que describen los puntos críticos del negocio.

Caso 3.1: Adicionar proyecto

IDENTIFICACIÓN CASO DE USO ACTORES

3.1 Adición de

proyecto con sus

respectivos

ambientes

Usuario Súper administrador

OBJETIVO

Permitir al usuario crear un proyecto

DESCRIPCION

Permitir al usuario crear un proyecto perteneciente a una compañía específica

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Haber creado una empresa dentro del sistema “Provisioner”

Pos condiciones El proyecto estará creado dentro de los tres ambientes de la empresa: desarrollo , QA, Producción.

Alternativas y excepciones

No puede crear el proyecto porque no existe la empresa

CURSO NORMAL DE LOS EVENTOS

ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1 ) El usuario ingresa al módulo de proyectos 3) ingresa a la opción de crear proyecto 5) Diligencia formulario

2) Muestra listado de proyectos asociados a una empresa. 4) Muestra formulario para la creación de proyecto. 6) guarda los datos diligenciados y crea el proyecto.

PUNTOS DE INTERRUPCION El usuario interrumpe la solicitud de crear proyecto en el punto 3.

Tabla 6.Caso de Uso 3.1 Adición de proyecto con sus respectivos ambientes

55

Figura 15.Diagrama caso de uso 3.1

Caso 4.1 Adicionar una máquina local

IDENTIFICACION CASO DE USO ACTORES

4.1 Adicionar una maquina local a un

ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO

Permitir al usuario (Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps) adicionar una

maquina a un ambiente.

DESCRIPCION

Permitir al usuario (Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps) adicionar una

maquina a un ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos.

Pos condiciones La máquina creada ya está asociada a un ambiente

Alternativas y excepciones

El servidor no tiene conexión con la maquina a crear

CURSO NORMAL DE LOS EVENTOS

ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1) El usuario ingresa al módulo de máquinas. 3) ingresa a la opción de crear máquina. 5) diligencia formulario y da clic en crear.

2) Muestra un listado de máquinas agrupados por ambiente. 4) muestra formulario con los campos respectivos a la creación de máquina. 6) valida la conexión con esta

56

máquina y hace un intercambio de llaves SSH con la maquina

PUNTOS DE INTERRUPCION El usuario interrumpe la solicitud de generar reporte en el punto 5.

Tabla 7.Caso de uso 4.1

Figura 16.Diagrama de caso de uso 4.1

Caso 5.1 Crear Tasks Ansible (programas y configuraciones) para cada ambiente

IDENTIFICACIÓN CASO DE USO ACTORES

5.1 Crear Tasks Ansible (programas y configuraciones) para cada ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO

Permitir al usuario (Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps) adicionar

programas y configuraciones a las máquinas del respectivo ambiente

DESCRIPCIÓN

Permitir al usuario (Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps) adicionar

programas y configuraciones a las máquinas del respectivo ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos.

57

Pos condiciones Las máquinas quedan con el script de Ansible disponible

Alternativas y excepciones

Si el usuario es Super Administrador le pregunta sobre cuál ambiente va a trabajar

CURSO NORMAL DE LOS EVENTOS

ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA

1) El usuario ingresa al módulo de Tareas 2) ingresa a la opción de añadir programas y configuraciones 4) Selecciona los programas necesarios

3) El sistema despliega los programas a instalar disponibles

PUNTOS DE INTERRUPCIÓN El usuario interrumpe la solicitud de generar reporte en el punto 2

Tabla 8.Caso de uso 5.1

Figura 17.Diagrama de caso de uso 5.1

Caso 6: El administrador de cada ambiente ejecuta el aprovisionamiento

IDENTIFICACION CASO DE USO ACTORES

58

06 El administrador de cada ambiente ejecuta el aprovisionamiento

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO

Permitir al usuario (Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps) ejecutar las

tareas (Tasks Ansible) seleccionadas previamente

DESCRIPCION

Permitir al usuario (Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps) ejecutar las

tareas (Tasks Ansible) seleccionadas previamente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Haber seleccionado previamente los programas y configuraciones para ser ejecutadas por Ansible

Pos condiciones Las máquinas de cada ambiente de trabajo poseen los programas necesarios para que cada empleado pueda desempeñar su trabajo

Alternativas y excepciones

No se realizar la instalación debido a problemas de conexión a la red o compatibilidad

CURSO NORMAL DE LOS EVENTOS

ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA

5. El usuario ingresa al módulo de Tareas

5. Da clic en ejecutar

4) Realiza las instalaciones solicitadas

PUNTOS DE INTERRUPCIÓN El usuario interrumpe la solicitud de generar reporte en el punto 2

Tabla 9.Caso de uso 6

59

Figura 18.Diagrama de caso de uso 6

4.4. Diagramas de secuencia

El propósito de los diagramas de secuencia es mostrar la

interacción que existe entre el Back-End y el Front-end, es decir,

las solicitudes que realiza el usuario final son preparadas por el

Front-End y envía peticiones HTTP hacia los servicios

desarrollados en el Back-End, a su vez, el Back-End le devuelve

las respuestas a dichas peticiones al Front; estas interacciones

están representadas a través mensajes.

60

Diagrama se secuencia escenario 3.1

Figura 19.Diagrama de Secuencia caso de Uso 3.1: Adición de proyecto con sus respectivos ambientes

Diagrama se secuencia escenario 4.1

Figura 20.Diagrama de Secuencia caso de uso 4.1 Adicionar una máquina local

61

Diagrama se secuencia escenario 5.1

Figura 21.Crear Tasks Ansible (programas y configuraciones) para cada ambiente

Diagrama se secuencia escenario 6.1

Figura 22.El administrador de cada ambiente ejecuta el aprovisionamiento

62

4.5. Diagramas de actividad

Los diagramas de actividades muestran el proceso de negocio que sucede desde que el administrador o administradores del sistema de aprovisionamiento ejecutan cierta actividad, como un flujo de trabajo a través de una serie de acciones. Estas acciones las pueden llevar a cabo los administradores, el Back-End o el Front-End.

Diagrama de secuencia caso 3.1

Figura 23.Diagrama de actividad caso 3.1

Diagrama de secuencia caso 4.1

Figura 24.Diagrama de actividad caso 4.1

63

Diagramas de actividad caso 5.1

Figura 25.Diagrama de actividad caso 5.1

Diagrama de actividad caso 6.1

Figura 26.Diagrama de actividad caso 6.1

64

4.6. Diagramas de colaboración

Los diagramas de colaboración buscan mostrar las interacciones organizadas alrededor de los roles participantes en el sistema a considerar: los administradores, la interfaz gráfica o Front-End y el proyecto Back-End quien procesa las peticiones al servidor e interactúa con la base de datos. A continuación, muestro los diagramas de colaboración de los casos de uso más relevantes del proyecto.

Diagrama de colaboración caso 3.1

Figura 27.Diagrama de colaboración caso 3.1

Diagrama de colaboración caso 4.1

Figura 28.Diagrama de colaboración caso 4.1

65

Diagrama de colaboración caso 5.1

Figura 29.Diagrama de colaboración caso 5.1

Diagrama de colaboración caso 6.1

Figura 30.Diagrama de colaboración caso 6.1

66

5. FASE DE DISEÑO

El propósito de esta fase es la de transformar los requerimientos del sistema en

un modelo de diseño al producto final deseado, que en este caso es el proyecto

aprovisionador de software “Provisioner”, y a su vez dejar el diseño listo para

ser adaptado a un entorno de implementación, pensando siempre en la

eficiencia.

5.1. Lista inicial de clases

El proyecto Back-End se compone principalmente de las siguientes clases:

Entity DTO Service Controller

Company.java CompanyDto.java CompanyService.java CompanyController.java

Employee.java EmployeeDto.java EmployeeService.java EmployeeController.java

Environment.java EnvironmentDto.java EnvironmentService.java EnvironmentController.java

Machine.java MachineDto.java MachineService.java MachineController.java

Project.java ProjectDto.java ProjectService.java ProjectController.java

TaskAnsible.java TaskAnsibleDto.java TaskAnsibleService.java TaskAnsibleController.java

User.java UserDto.java UserService.java UserController.java

Tabla 10. Lista inicial de clases Back-End

Proyecto Front-End Pages Providers Company.html - Company.ts CompanyProvider.ts Employee.html- Employee.ts EmployeeProvider.ts Home.html

Machine.html- Machine.ts MachineProvider.ts

Login.html-Login.ts LoginProvider.ts

Project.html-Project.ts ProjectProvider.ts

Task.html-Task.ts TaskProvider.ts Tabla 11.Lista inicial de clases Front-End

5.2. Diagrama de clases

Describe el esquema de las clases existentes en el proyecto “Provisioner”

Figura 31. Diagrama de clases

67

68

5.3. Diagrama de Entidad – Relación

Describe el esquema de las tablas existentes en la Base de Datos “Provisioner”.

Figura 32.Diagrama E-R

5.4. Diagrama de Interfaz

La siguiente es una representación ideal de cómo sería la interfaz de usuario, también se establecen las reglas de navegación que tendrá el sistema.

En la página home.xhtml (página inicial de la plataforma) se encuentra el mensaje de bienvenida y el menú principal, vertical, se encuentra disponible en todas las páginas.

La página de Login Y registro comparten la misma interfaz, a continuación, más al detalle:

69

Figura 33.Diagrama de interfaz

5.5. Diccionario de datos

A continuación, se presenta el diccionario de datos de la BD Provisioner

Tabla Company

70

Tabla Employee

Tabla Environment

Tabla LogProvision

Tabla Machine

71

Tabla Project

Tabla Task_Ansible

Tabla Template_Ansible

72

6. FASE DE IMPLEMENTACIÓN El objetivo de esta fase es tomar como punto de partida el modelo de la fase anterior, se procede a programar o implementar los diseños especificados en el modelo de diseño.

6.1. Arquitectura

La arquitectura empleada en el presente proyecto emplea MVC orientado a microservicios, a continuación, se detalla la función de cada capa del MVC Vista: Es la encargada de presentar el sistema al usuario, permite presentar y obtener información del usuario, por ejemplo: mostrarle lista completa de máquinas del ambiente de desarrollo. También es conocida como la interfaz gráfica o GUI. Debe tener la característica de ser "amigable" con el usuario (entendible y fácil de usar). Esta capa se comunica únicamente con la capa de Lógica. El Front-End, desarrollado en Angular 6 en conjunto con Ionic3, ejerce su función como capa de presentación, ya que es el encargado de realizar las tareas mencionadas anteriormente y realiza su comunicación a través de HTTP Request hacia los servicios del Back-End. Controlador: Responde a las peticiones realizadas por el usuario a través del Front-End e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información, ejemplo: consultar datos de un proyecto. El controlador recibe la petición getProjectById(1) a través de un servicio tipo GET, captura los datos de los parámetros,en este caso “1”, gestiona a las demás clases para poder obtener una respuesta, y poder responderle al Front de forma correcta los datos del proyecto cuyo ID es 1. El Back-End, desarrollado en Spring Boot se encarga de controlar todas las peticiones del Front, así mismo de realizar acciones lógicas y operativas y responder los datos expuestos en microservicios. Modelo: Es donde residen los datos y es el encargado de acceder a los mismos. Está formada por al menos un motor de base de datos y es donde se realiza todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

73

Figura 34. Diagrama de arquitectura

6.2. Diagrama de componentes

Con este diagrama se pretende mostrar los elementos de diseño del sistema para visualizar con más facilidad la estructura general del sistema y el comportamiento del servicio que este tendrá.

El proyecto front se comunica con el servicio de Auth0 para realizar la autenticación de usuarios, es necesario obtener un token de este servicio para que los usuarios no puedan realizar inicios de sesión ilegalmente. A su vez, el Back-End se comunica con Front mediante HTTP Request,

El proyecto Back-End posee tres paquetes importantísimos para realizar toda la lógica de negocio: Controller, Services, Reposirtory: los controladores exponen los servicios HTTP, le pasan a la capa de Services los datos que vienen junto con el consumo del servicio y le otorga la responsabilidad al Repository para realizar operaciones de Base de Datos. Dichas operaciones e realizan con JPA quien comunica a la Base de Datos que transacción se debe realizar.

Posteriormente, el Back-End intercambia llaves con la instancia AWS para establecer comunicación con esta a través de SSH y poder aprovisionar las máquinas remotas indicadas en el ambiente de pruebas.

Back es el único punto de contacto con Ansible, que es la herramienta que ayuda a realizar instalaciones automáticas.

74

Figura 35.Diagrama de componentes

6.3. Diagrama de despliegue

El diagrama de despliegue modela la arquitectura del sistema en tiempo de ejecución, con el objetivo de mostrar la configuración de los elementos de hardware que utiliza tanto Front-End como Back-End y muestra cómo los elementos y artefactos del software se trazan en esos nodos.

En el diagrama se muestra que el Servidor Tomcat embebido en Spring Boot, contiene el proyecto Back-End; se comunica mediante SSH con la Instancia Virtual de Amazon con el objetivo de aprovisionar las máquinas de este ambiente.

Por otro lado, Back mantiene comunicación con Front de la siguiente manera: Front le notifica a Back que el usuario realizó una petición, ejemplo: Crear Compañía, la petición de crear compañía se pasa al Back a través de HTTP Request, cuando Back realiza toda la transacción de guardar compañía le response en formato JSON al front la respuesta según sea el caso.

El Front-End tiene comunicación con el navegador del Client Machine del usuario final, el usuario es quien realiza peticiones HTTP Request ya que es el quien ejecuta las diferentes operaciones de funcionalidades del sistema, ejemplo: Editar Compañía.

La comunicación del Back-End con la Base de datos es gestionada por JPA/Hibernate.

75

Figura 36.Diagrama de despliegue

6.4. Diagrama de paquetes

La finalidad de este diagrama de paquetes es indicar como el sistema Provisioner está dividido en agrupaciones lógicas que contienen las clases lógicas del mismo. Las agrupaciones que se tienen en cuenta se hacen basadas en la arquitectura MVC (Modelo, Vista, Controlador).

76

Figura 37.Diagrama de paquetes

77

7. FASE DE PRUEBAS ISO/IEC/IEEE 29119

La fase de pruebas se basa en la Norma ISO/IEC/IEEE 29119, que sugiere realizar los siguientes pasos: Parte 1 Definiciones y Vocabulario

Su objetivo es proporcionar un vocabulario de términos de pruebas de software.

Parte 2 Proceso de Pruebas Los procesos de prueba: 1. Analizar los requerimientos de

desarrollo de software, 2. Identificar las funcionalidades más relevantes de los sistemas deben probarse, 3.Definición de pruebas, planificación de las pruebas

Parte 3 Documentación de Pruebas El estándar cubrirá documentación de pruebas.

Parte 4 Técnicas de Pruebas Descripción de las técnicas aplicadas.

Parte 1 Vocabulario:

• Pruebas unitarias: Las pruebas unitarias comprueban el correcto funcionamiento de la unidad de código que ejecuta los casos de uso más relevantes del sistema.

• Pruebas unitarias: prueban es que todos los elementos unitarios que componen el software funcionan juntos correctamente probándolos en grupo.

• API: URL del servicio que se va a probar.

• Tipo: Tipo de petición HTTP que se ejecuta.

• JSON: formato de texto ligero para el intercambio de datos.

• HTTP: el protocolo de comunicación que permite las transferencias de información en la internet.

Parte 2 Proceso de Pruebas

1. Analizar los requerimientos de desarrollo de software:

• Creación de empresa, el proyecto de una empresa y configuración de las máquinas asociadas a un ambiente del proyecto.

• El acceso a la plataforma “Provisioner” está limitado a las personas que se registren en la plataforma, las cuales poseerán un usuario y contraseña para poder entrar y hacer uso de los servicios.

• La plataforma “Provisioner” debe tener una interfaz que incluya y separe todas las funciones para los

78

usuarios según las opciones de trabajo disponibles.

• Permitir al administrador de todo el sistema crear usuarios y proyectos.

• Permitir al administrador del módulo de Desarrollo crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

• Permitir al administrador del módulo de Pruebas QA crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

• Permitir al administrador del módulo de Producción crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

2. Identificar las funcionalidades más relevantes de los sistemas deben probarse

• crear una compañía, crear proyecto, crear máquina en un ambiente, crear un nuevo Tasks, ejecutar aprovisionamiento.

3. Definición de pruebas:

Se realizarán pruebas unitarias para verificar que cada funcionalidad funcione correctamente

4. Definir los criterios de inicio, aceptación y suspensión de pruebas

a. Crear una compañía: se crea la compañía con los datos proporcionados por el usuario.

b. crear proyecto: se crea el proyecto con los datos proporcionados por el usuario, si no existe una compañía no se puede crear un proyecto.

c. crear máquina en un ambiente: la máquina se crea con la IP de la máquina real, si la IP no corresponde a ninguna máquina no se puede hacer aprovisionamiento. Sin proyecto no se puede crear máquinas.

d. crear un nuevo Tasks: Permitir crear un nuevo Task a partir de una plantilla o bien, crear una nueva plantilla de Ansible.

e. ejecutar aprovisionamiento: Verificar que el aprovisionamiento haya sido efectivo en las máquinas del ambiente aprovisionado.

5. Elaborar la planificación de las pruebas

Pantalla Criterio de Tester Tiempo estimado

79

suspensión

Crear Compañía Código de respuesta HTTP 500. Se suspende la prueba , se verifica en logs el error.

Pilar Mass 20 minutos

Crear Proyecto Código de respuesta HTTP 500. Se suspende la prueba , se verifica en logs el error.

Error 404 si la compañía no existe.

Dallys Lopez 10 minutos

Adicionar máquina a un ambiente

Código de respuesta HTTP 500. Se suspende la prueba , se verifica en logs el error.

Error 404 si el proyecto no existe.

Juan Orjuela 10 minutos

Crear Task Ansible

Código de respuesta HTTP 500. Se suspende la prueba , se verifica en logs el error.

Error 404 si la compañía no existe.

Jose Castillo 10 minutos

Tabla 12. Planificación de pruebas

Parte 3 Documentación de Pruebas

Documentar cada una de las pruebas según la definición dada anteriormente.

80

7.1. Pruebas unitarias Las pruebas unitarias se realizaron con el fin de comprobar el correcto funcionamiento de la unidad de código que ejecuta los casos de uso más relevantes del sistema.

Prueba unitaria 1

Identificador de caso de uso: Caso de uso 3.1

Nombre de caso de uso: Adición de proyecto con sus respectivos ambientes

Descripción Prueba: Permitir al usuario crear un proyecto

Responsable: Pilar Mass

Prerrequisitos

Debe existir una compañía creada previamente.

Descripción de Casos de Prueba

Caso: Verificar el correcto funcionamiento del módulo de creación de proyectos.

Servicio (s) Probados: Tipo: POST API: /provisioner/api/project

Instrucciones de Prueba 1. Hacer uso del servicio POST /provisioner/api/project, pasando como parámetro los siguientes datos en JSON { "id": 1, "name": "proyecto 2", "status": "A", "idCompany": { "id": 1, "name": "empresa 1", "nit": "10083463", "address": "cra con calle", "phone": "123456789" }, "idCompanyLong": 1, "environmentList": null } 2. localhost:8100/project: Ingresar al módulo de proyectos, clic en crear proyecto, digitar datos en el formulario, guardar datos

Resultado 1. Utilizando la aplicación Portman se evidencia el código de respuesta HTTP

200, proyecto guardado correctamente.

2. localhost:8100/project: Se guardan correctamente los datos digitados por el usuario, el proyecto recientemente creado aparece en la lista de proyectos.

81

Tabla 13.Prueba unitaria 1

Prueba unitaria 2

Identificador de caso de uso: Caso de uso 4.1

Nombre de caso de uso: Adicionar una máquina local a un ambiente

Descripción Prueba: Permitir al administrador de cada ambiente adicionar máquinas

Responsable: Pilar Mass

Prerrequisitos

Debe existir un proyecto creado previamente.

Descripción de Casos de Prueba

Caso: Verificar el correcto funcionamiento del módulo de creación de máquinas.

Servicio (s) Probados: Tipo: POST API: /provisioner/api/machine

Instrucciones de Prueba 1. Hacer uso del servicio POST /provisioner/api/machine, pasando como parámetro los siguientes datos en JSON { "hostName":"dev", "ip":"192.168.32.2", "operativeSystem": "UBUNTU", "userName":"vagrant", "passwordMachine":"vagrant", "idEnvironmentLong":1 } 2. localhost:8100/machine: Ingresar al módulo de máquinas, clic en crear máquina, digitar datos en el formulario, guardar datos

Resultado 1. Utilizando la aplicación Postman se evidencia el código de respuesta HTTP

200, proyecto guardado correctamente.

2. localhost:8100/machine: Se guardan correctamente los datos digitados por el usuario, la máquina recientemente creada aparece en la lista de máquinas.

Tabla 14.Prueba unitaria 2

Prueba unitaria 3

Identificador de caso de uso: Caso de uso 5.1

82

Nombre de caso de uso: Crear Task Ansible (programas y configuraciones para cada ambiente)

Descripción Prueba: Permitir al administrador de cada ambiente adicionar programas y configuraciones a las máquinas de su respectivo ambiente

Responsable: Pilar Mass

Prerrequisitos

Debe existir una máquina creada previamente.

Descripción de Casos de Prueba

Caso: Verificar el correcto funcionamiento del módulo de Task Ansible

Servicio (s) Probados: Tipo: POST API: /provisioner/api/task

Instrucciones de Prueba 1. Hacer uso del servicio POST /provisioner/api/task, pasando como parámetro los siguientes datos en JSON { "idEnvironmentLong": 1, "idTemplateAnsibleLong": 2, "nameTask":"prueba tarea 1" } 2. localhost:8100/task : Ingresar al módulo de Taks, clic en crear Task, digitar datos en el formulario, guardar datos

Resultado 1. Utilizando la aplicación Postman se evidencia el código de respuesta HTTP

200, proyecto guardado correctamente.

2. localhost:8100/task : Se guardan correctamente los datos digitados por el usuario, la tarea recientemente creada aparece en la lista de Tasks

Tabla 15.Prueba unitaria 3

Prueba unitaria 4

Identificador de caso de uso: Caso de uso 6

Nombre de caso de uso: El administrador de cada ambiente ejecuta el aprovisionamiento

Descripción Prueba: Permitir al administrador de cada ambiente ejecutar el aprovisionamiento

Responsable: Pilar Mass

Prerrequisitos

Deben existir Taks (software a instalar)

Descripción de Casos de Prueba

83

Caso: Verificar el correcto funcionamiento del Aprovisionamiento

Servicio (s) Probados: Tipo: POST API: /provisioner/api/provision

Instrucciones de Prueba 1. Hacer uso del servicio POST /provisioner/api/provision, pasando como parámetro los siguientes datos en JSON { "projectId": 1, "environmentId":1 } 2. localhost:8100/machine : Ingresar al módulo de Máquinas de determinado ambiente, seleccionar Mysql a instalar y hacer clic en Aprovisionar

Resultado 1. Utilizando la aplicación Postman se evidencia el código de respuesta HTTP

200, proyecto guardado correctamente.

2. Se verifica al menos una de las máquina del ambiente aprovisionado para determinar si se instaló MySql

Tabla 16.Prueba unitaria 4

7.2. Pruebas de Integración

Las pruebas de integración se realizan para comprobar que el desarrollo de una unidad de código no afecte el funcionamiento de los demás módulos del sistema aprovisionador.

Prueba Modulo de Creación de Proyecto

Dirigida por: Pilar Mass Asistente Estado

Hora Inicio: 9:30 am Pilar Mass Proceso OK

Hora Fin: 11:20 am Terminada SI

Concepto Revisar el funcionamiento de las páginas asociadas al módulo de proyectos

ACCION ELEMENTO A PRUEBA

Resultado esperado

Rol Estado

Crear proyecto Formulario nuevo proyecto

El usuario crea un nuevo proyecto el cual ya es visible en la página de proyectos.

Super Administrador

OK

Consultar listado de proyectos

Página inicial de proyectos

Después de creado el proyecto se puede observar el proyecto recién creado.

Super Administrador

OK

Editar Formulario de El usuario edita un Super OK

84

proyecto edición de proyecto

proyecto el cual ya es visible en la página de proyectos.

Administrador

Errores • En el formulario de creación de proyectos es poco intuitivo para el usuario.

Correcciones • Se rediseñaron las paginas para que sean más llamativas y más amigables con los usuarios.

Tabla 17. Pruebas de integración 1

Prueba Modulo de Creación de Máquinas

Dirigida por: Pilar Mass Asistente Estado

Hora Inicio: 9:55 am Pilar Mass Proceso OK

Hora Fin: 10:05 am Terminada SI

Concepto Revisar el funcionamiento de las páginas asociadas al módulo de máquinas

ACCION ELEMENTO A PRUEBA

Resultado esperado

Rol Estado

Crear máquina Formulario nueva máquina

El usuario crea una nueva máquina la cual ya es visible en la página de máquinas.

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Consultar listado de máquinas por ambiente

Página inicial de máquinas

Después de creada la máquina se puede observar la máquina recién creado.

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Consultar listado de ambientes

Página de ambientes

El usuario consulta los ambientes del proyecto creado anteriormente

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Editar máquina

Formulario de edición de máquinas

El usuario edita una máquina el cual ya es visible en la página de máquinas.

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

85

Errores • En el formulario de creación de máquinas es poco intuitivo para el usuario.

Correcciones • Se rediseñaron las paginas para que sean más llamativas y más amigables con los usuarios.

Tabla 18.Pruebas de integración 2

Prueba Modulo de Creación de Tasks

Dirigida por: Pilar Mass Asistente Estado

Hora Inicio: 10:05 am Pilar Mass Proceso OK

Hora Fin: 10:20 am Terminada SI

Concepto Revisar el funcionamiento de las páginas asociadas al módulo de máquinas

ACCION ELEMENTO A PRUEBA

Resultado esperado

Rol Estado

Crear task Formulario nuevo Task

El usuario crea un nuevo Task el cual ya es visible en la página de Tasks.

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Consultar templates disponibles

Página inicial de Templates

El usuario se dirige a la página de templates y consulta los templates disponibles

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Consultar listado de Tasks

Página inicial de Tasks

El usuario se dirige a la página de Tasks y consulta los Tasks disponibles

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Errores • En el formulario de creación de Tasks es poco intuitivo para el usuario.

Correcciones • Se rediseñaron las paginas para que sean más llamativas y más amigables con los usuarios.

Tabla 19.Pruebas de integración 3

Prueba Ejecutar aprovisionamiento

Dirigida por: Pilar Mass Asistente Estado

86

Hora Inicio: 10:20 am Pilar Mass Proceso OK

Hora Fin: 10:55 am Terminada SI

Concepto Revisar el funcionamiento de las páginas asociadas al módulo de máquinas

ACCION ELEMENTO A PRUEBA

Resultado esperado

Rol Estado

Consultar listado de ambientes

Página de ambientes

El usuario consulta los ambientes del proyecto creado anteriormente

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Consultar máquinas

Página inicial de máquinas

Después de creada la máquina se puede observar la máquina recién creado.

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Seleccionar Tasks Página inicial de Tasks

El usuario se dirige a la página de Tasks y consulta los Tasks disponibles

Super Administrador, Administrador desarrollo, administrador QA, administrador producción

OK

Ejecutar aprovisionamiento

Página inicial de máquinas

Selecciona software a ser instalado en el ambiente seleccionado

Super Administrador

OK

Errores

Correcciones Tabla 20.Pruebas de integración 4

Parte 4: Técnicas de Pruebas

• Pruebas unitarias: Descomponen las funciones del sistema Provisioner en comportamientos comprobables, como el de creación de compañía, creación de proyecto, creación de máquina y creación de Task. Estas pruebas son discretas ya que se pueden probar como unidades individuales.

• Pruebas de integración: El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente. En este caso se

87

compruebas que sin una compañía no se pueda acceder a la página de creación de proyecto o al contrario. Se comprueba que existan ambientes de trabajo y por tanto se puede acceder al funcionamiento de creación de máquina y Taks.

88

CONCLUSIONES

• El levantamiento de información previo al desarrollo del software permite tener un panorama general y claro del objetivo y dirección del proyecto, permite esclarecer dudas previas al inicio de un proyecto y también establecer la organización inicial del mismo.

• Un correcto diseño de la base de datos evitar la redundancia de información utilizada en los distintos módulos del sistema.

• El desarrollo de una aplicación con microservicios permite que esta misma se pueda dividir en servicios independientes. Eso significa que la arquitectura de microservicios brinda a los desarrolladores la libertad de desarrollar e implementar servicios sin afectar todo el sistema.

• Una documentación funcional es clave para el buen uso del sistema de

aprovisionamiento por parte de los usuarios finales, quienes van a ser los principales beneficiados con el uso de la aplicación. Además, se evitará la pérdida de clientes quienes por falta de entendimiento lleguen a dejar de usar la aplicación.

• El desarrollo de este proyecto aportará una solución informática a los problemas a los que se enfrentan empresas dedicadas al desarrollo de software, y, personal nuevo, quienes deben asumir la responsabilidad de actualizar y organizar su propia máquina de trabajo.

• Documentar cada etapa del proyecto hace que el desarrollo de este sea eficiente y se tenga una visión más adecuada y organizada, lo cual implica menos gastos en el tratamiento de reparación de errores o imprevistos.

• Dividir el sistema en módulos permitió establecer un mejor orden y esclarecer cuales eran las principales características del sistema, lo cual fue muy significativo al momento del desarrollo ya que permitió reutilizar código y ahorrar más en tiempos.

• Es importante diseñar interfaces amigables para los usuarios de un sistema, ya que esto garantiza en cierto modo el éxito del proyecto.

• La utilización de tecnologías de última generación como Ionic 3, Auth0, Ansible, Vagrant y Amazon me permitieron como desarrolladora, incrementar mi experiencia y conocimientos, lo cual permite entregar un producto confiable e innovador.

89

RECOMENDACIONES

Es Importante resaltar estas recomendaciones para futuras mejoras del Sistema PROVISIONER.

• Es importante tener en cuenta que Amazon no es la única plataforma

para Instancias Virtuales en la Nube, el proyecto se podría implementar con Azure, Google Cloud, entre otras.

• Una vez implementado el proyecto en una empresa real, se debe seguir

y coordinar el crecimiento de la plataforma, con el fin de identificar las necesidades propias para enriquecer el sistema.

• Es necesario que el Super Administrador del sistema esté al tanto de las

cuentas hacia Amazon, así como de nuevas modificaciones que tengan los servicios web de tales servicios, con el fin de que los servicios estén siempre en funcionamiento.

• Es importante saber que el sistema funciona en sistemas operativos basados en Linux.

90

ANEXOS

A continuación, se listan los demás diagramas de la fase de análisis, iniciando por los diagramas de caso de uso y su respectiva documentación, diagramas de secuencia, diagramas de colaboración y por último de actividad. 1. DIAGRAMAS DE CASO DE USO

1.1. Login

IDENTIFICACION CASO DE

USO ACTORES

1.1 Login Usuario Super administrador, Administrador de desarrollo, Administrador de QA, Administrador DevOps

OBJETIVO Permitir a los usuarios registrados de la plataforma iniciar sesión.

DESCRIPCION Permitir a un usuario iniciar sesión en la aplicación, a través de un formulario de inicio

de sesión, en donde se pide usuario y contraseña para poder ingresar satisfactoriamente.

Precondiciones El usuario debe iniciar sesión. Pos condiciones El usuario puede acceder a la aplicación y acceder a los

servicios de esta. Alternativas y excepciones

El usuario no posee sus datos de ingreso a la plataforma. Recuperación de datos de inicio de sesión. El usuario no recuerda sus datos de inicio de sesión.

91

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1. El usuario se dirige al formulario de inicio de sesión.

2. El usuario digita los datos de inicio de sesión y dar clic en el botón entrar.

3. Verificar datos. 4. Cargar página principal del usuario

PUNTOS DE INTERRUPCION El usuario no recuerda sus datos o no posee dichos datos

No digitar correctamente la información punto 2 Cancelar operación punto 2 Falla la verificación de datos

1.2. Registro

IDENTIFICACION CASO DE

USO ACTORES

1.2 Registro de usuarios

Usuario Super administrador, Administrador de desarrollo, Administrador de QA, Administrador DevOps

OBJETIVO Permitir a los usuarios registrarse en la plataforma.

DESCRIPCION Permitir a un usuario registrarse en la plataforma, a través de un formulario de registro,

en donde se piden datos relevantes para poder hacer un registro satisfactoriamente. Precondiciones

92

Pos condiciones El usuario queda registrado en la plataforma y puede acceder a la aplicación y acceder a los servicios de esta.

Alternativas y excepciones

El usuario no sabe o no registra los datos requeridos de registro en la plataforma. El usuario no completa el formulario de registro y no se efectúa dicho registro.

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1. El usuario se dirige al formulario de registro.

2. El usuario digita los datos de registro y da clic en el botón registrar.

3. Verificar datos. 4. Crear registro de usuario nuevo. 5. Dirigir a página que indica registro exitoso.

PUNTOS DE INTERRUPCION El usuario no recuerda sus datos o no posee dichos datos

No digitar correctamente la información punto 2 Cancelar operación punto 2 Falla la verificación de datos

1.3. Administración de Roles – Permisos

IDENTIFICACION CASO DE USO ACTORES

1.3 Administración de Roles - Permisos

Usuario super Administrador

OBJETIVO Permitir al usuario super administrador asignarles permisos a los usuarios registrados en la plataforma

DESCRIPCION Permitir al usuario super administrador asignar y desasignar permisos a los demás usuarios registrados dentro de la plataforma Precondiciones El usuario debe iniciar sesión y tener los permisos ser super

administrador Pues condiciones Los demás usuarios registrados en la plataforma podrán

93

tener permiso de administrador de ambiente, según solicitud Alternativas y excepciones

Si el usuario da clic en cancelar el sistema lo redirigirá a la página de inicio.

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario accede al módulo de administración de roles. 3. Selecciona la persona y le asigna el ambiente solicitado y los permisos correspondientes.

2.Muestra el listado de personas pertenecientes a la plataforma 4. Guarda permisos asignados

PUNTOS DE INTERRUPCION El usuario interrumpe la operación en el punto 3

Un usuario no existe en la plataforma, se debe registrar

1.4. Logout

IDENTIFICACION CASO

DE USO ACTORES

1.4 Logout Usuario Super administrador, Administrador de desarrollo, Administrador de QA, Administrador DevOps

OBJETIVO Permitir a los usuarios registrados de la plataforma cerrar sesión.

DESCRIPCION Permitir a un usuario cerrar su sesión en la aplicación, a través del botón de cierre de

sesión Precondiciones El usuario debe haber iniciado sesión Pos condiciones El usuario puede acceder a la aplicación y acceder a los

servicios de esta. Alternativas y excepciones

El usuario no posee sus datos de ingreso a la plataforma. Recuperación de datos de inicio de sesión.

94

El usuario no recuerda sus datos de inicio de sesión. CURSO NORMAL DE LOS EVENTOS

ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1)El usuario da clic en Cerrar Sesión

2)El sistema saca de sesión al usuario

PUNTOS DE INTERRUPCION El usuario no recuerda sus datos o no posee dichos datos

No digitar correctamente la información punto 2 Cancelar operación punto 2 Falla la verificación de datos

1.5. Adicionar empresa Caso 2.1

IDENTIFICACION CASO DE USO ACTORES

2.1 Adicionar compañía Usuario super administrador OBJETIVO

Permitir al usuario super administrador adicionar una Compañía dentro de la plataforma “Provisioner”

DESCRIPCION Permitir al usuario super administrador adicionar una Compañía dentro de la

plataforma “Provisioner” Precondiciones El usuario debe ser super administrador y haber iniciado

sesión, Pos condiciones Se pueden adicionar proyectos a la empresa creada Alternativas y excepciones

El usuario no sabe o no registra los datos requeridos de registro en la plataforma. EL usuario no completa el formulario de creación de empresa, o da clic en botón cancelar creación de empresa

95

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario ingresa al módulo de Compañías 2. El usuario da clic en crear nueva Compañía 3. Diligencia los datos solicitados

2. El sistema despliega la lista de compañías activas

3. Abre el formulario de creación de compañía

5. Guarda la información.

PUNTOS DE INTERRUPCION El usuario interrumpe la operación en el punto 3

El sistema no puede enviar los mensajes debido a fallas ajenas a la plataforma en el punto 5

1.6. Editar datos de una empresa Caso 2.2

IDENTIFICACION CASO DE USO ACTORES

2.2 Editar compañía Usuario super administrador OBJETIVO

Permitir al usuario super administrador editar una Compañía dentro de la plataforma “Provisioner”

DESCRIPCION Permitir al usuario super administrador editar una Compañía dentro de la plataforma

“Provisioner” Precondiciones El usuario debe ser super administrador y haber iniciado

sesión, Pos condiciones Se pueden editar los datos asociados a una compañía

existente Alternativas y excepciones

El usuario no sabe o no registra los datos requeridos de registro en la plataforma. EL usuario no completa el formulario de creación de

96

empresa, o da clic en botón cancelar edición de empresa CURSO NORMAL DE LOS EVENTOS

ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario ingresa al módulo de Compañías 3.EL usuario selecciona la empresa que desea editar 4. El usuario da clic en editar Compañía 6. Diligencia los datos solicitados

2. El sistema despliega la lista de compañías activas 5. Abre el formulario de edición de compañía 7. Guarda la información.

PUNTOS DE INTERRUPCION El usuario interrumpe la operación en el punto 1, 6

El sistema no puede enviar los mensajes debido a fallas ajenas a la plataforma en el punto 7

1.7. Listar todas las empresas Caso 2.3

IDENTIFICACION CASO DE USO ACTORES

2.3 Listar compañías Usuario super administrador OBJETIVO

Permitir al usuario super administrador mirar la lista de Compañías dentro de la plataforma “Provisioner”

DESCRIPCION Permitir al usuario super administrador mirar la lista de Compañías dentro de la

plataforma “Provisioner” Precondiciones El usuario debe ser super administrador y haber

iniciado sesión, Pos condiciones Se pueden detallar los datos asociados a una

compañía existente Alternativas y excepciones El usuario no sabe o no registra los datos requeridos

de registro en la plataforma. CURSO NORMAL DE LOS EVENTOS

ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario ingresa al módulo de Compañías

2. El sistema despliega la lista de compañías activas

97

3.EL usuario selecciona la empresa que desea detallar

PUNTOS DE INTERRUPCION El usuario interrumpe la operación en el punto 1,

1.8. Filtrar una empresa Caso 2.4

IDENTIFICACION CASO DE USO ACTORES

2.4 Filtrar compañías Usuario super administrador OBJETIVO

Permitir al usuario super administrador mirar la lista de Compañías dentro de la plataforma “Provisioner”

DESCRIPCION Permitir al usuario super administrador mirar la lista de Compañías dentro de la

plataforma “Provisioner” Precondiciones El usuario debe ser super administrador y haber

iniciado sesión, Pos condiciones Se pueden detallar los datos asociados a una

compañía existente Alternativas y excepciones El usuario no sabe o no registra los datos requeridos

de registro en la plataforma. CURSO NORMAL DE LOS EVENTOS

ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario ingresa al módulo de Compañías 3.El usuario digita en el buscador la empresa que desea encontrar

2. El sistema despliega la lista de compañías activas 4. Muestra las coincidencias que coincidan con la búsqueda

PUNTOS DE INTERRUPCION El usuario interrumpe la operación en el punto 1,

98

1.9. Edición de proyecto Caso 3.2

IDENTIFICACIÓN CASO DE USO ACTORES

3.2 Edición de proyecto Usuario Super administrador

OBJETIVO Permitir al usuario editar un proyecto existente

DESCRIPCION Permitir al usuario editar un proyecto existente.

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Haber creado una empresa dentro del sistema “Provisioner”

Pos condiciones El proyecto creado dentro de los tres ambientes de la empresa: desarrollo, QA, Producción será editado

Alternativas y excepciones

No puede editar el proyecto porque no existe

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1) El usuario ingresa al módulo de proyectos 3) Ingresa a la opción de editar proyecto 5) Diligencia formulario

2) Muestra listado de proyectos asociados a una compañía. 4) Muestra formulario para la edición de proyecto. 6) guarda los datos diligenciados y crea el proyecto.

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de crear proyecto en el punto 3.y 5

1.10. Deshabilitar/ Habilitar un proyecto Caso 3.3

99

IDENTIFICACIÓN CASO DE USO ACTORES

3.3 Habilitar/Deshabilitar de proyecto Usuario Super administrador

OBJETIVO Permitir al usuario habilitar/deshabilitar un proyecto existente

DESCRIPCION Permitir al usuario habilitar/deshabilita un proyecto existente.

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Haber creado una empresa y un proyecto dentro del sistema “Provisioner”

Pos condiciones El proyecto creado dentro de los tres ambientes de la empresa: desarrollo, QA, Producción será deshabilitado o habilitado según corresponda

Alternativas y excepciones

No puede editar el proyecto porque no existe

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1) El usuario ingresa al módulo de proyectos 3) Ingresa a la opción de editar proyecto 5) Selecciona la opción de habilitar/deshabilitar proyecto

2) Muestra listado de proyectos asociados a una compañía. 4) Muestra formulario para la edición de proyecto. 6) guarda los datos diligenciados y crea el proyecto.

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de crear proyecto en el punto 3.y 5

100

1.11. Listar todos los proyectos de una empresa Caso 3.4

IDENTIFICACIÓN CASO DE USO ACTORES

3.4 Listar todos los proyectos de una empresa

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador de Producción

OBJETIVO Permitir al usuario ver los proyectos existentes pertenecientes a una compañía

DESCRIPCION Permitir al usuario ver los proyectos existentes pertenecientes a una compañía

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Haber creado una empresa y un proyecto dentro del sistema “Provisioner”

Pos condiciones El proyecto creado dentro de los tres ambientes de la empresa: desarrollo, QA, y producción podrá ser detallado

Alternativas y excepciones

No puede listar el proyecto porque no existe

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1) El usuario ingresa al módulo de proyectos

2) Muestra listado de proyectos asociados a una compañía.

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de crear proyecto en el punto 1

1.12. Filtrar un proyecto Caso 3.5

101

IDENTIFICACIÓN CASO DE USO ACTORES

3.5 Filtrar todos los proyectos de una empresa

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador de Producción

OBJETIVO Permitir al usuario buscar los proyectos existentes pertenecientes a una compañía

DESCRIPCION Permitir al usuario buscar los proyectos existentes pertenecientes a una compañía

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Haber creado una empresa y un proyecto dentro del sistema “Provisioner”

Pos condiciones El proyecto creado dentro de los tres ambientes de la empresa: desarrollo, QA, y producción podrá ser detallado

Alternativas y excepciones

No puede listar el proyecto porque no existe

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

1) El usuario ingresa al módulo de proyectos 3) Escribe en el buscador el nombre del proyecto requerido

2) Muestra listado completo de proyectos 4) Muestra las coincidencias encontradas

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de crear proyecto en el punto 1

1.13. Adicionar una máquina local Caso 4.1

102

IDENTIFICACIÓN CASO DE USO ACTORES

4.1 Adicionar una máquina local a

un ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) adicionar una maquina a un ambiente.

DESCRIPCION Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) adicionar una maquina a un ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones La máquina creada ya está asociada a un ambiente Alternativas y excepciones

El servidor no tiene conexión con la maquina a crear

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA

103

1) El usuario ingresa al módulo de máquinas. 3) ingresa a la opción de crear máquina. 5) diligencia formulario y da clic en crear.

2) Muestra un listado de máquinas agrupados por ambiente. 4) muestra formulario con los campos respectivos a la creación de máquina. 6) valida la conexión con esta máquina y hace un intercambio de llaves ssh con la maquina

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de generar reporte en el punto 5.

1.14. Edición de maquina Caso 4.2

IDENTIFICACIÓN CASO DE

USO ACTORES

4.2 Editar datos de una

máquina

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) editar una maquina a un ambiente.

DESCRIPCION Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) adicionar una maquina que pertenece a un ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones Los datos de una máquina serán modificados, tales datos son:

nombre y estado e IP Alternativas y excepciones

No hay conexión hacia la plataforma

104

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al módulo de máquinas. 3) El usuario selecciona la máquina que desea editar 4) El usuario da clic en el botón editar 6) Da clic en guardar cambios

2) Muestra un listado de máquinas agrupados por ambiente. 5) Se muestra el formulario que permite editar una máquina 7) Guarda los cambios realizados por el usuario

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de generar reporte en el punto 6

1.15. Deshabilitar/Habilitar una maquina Caso 4.3

IDENTIFICACIÓN CASO DE USO ACTORES

4.3 Habilitar / Deshabilitar una

máquina

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) habilitar o deshabilitar una máquina perteneciente a un ambiente

DESCRIPCION Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) habilitar o deshabilitar una máquina perteneciente a un ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones Los datos de una máquina serán modificados, tales datos

105

son: estado Alternativas y excepciones

No hay conexión hacia la plataforma

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al módulo de máquinas. 3) El usuario selecciona la máquina que desea editar 4) El usuario da clic en el botón editar y selecciona la opción habilitar o deshabilitar según sea el caso- 6) Da clic en guardar cambios

2) Muestra un listado de máquinas agrupados por ambiente. 5) Se muestra el formulario que permite editar una máquina 7) Guarda los cambios realizados por el usuario

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de generar reporte en el punto 6

1.16. Listar todas maquinas Caso 4.4

IDENTIFICACIÓN CASO DE

USO ACTORES

4.4 Listar todas máquinas

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario observar todas las máquinas independientemente del ambiente al

cual pertenecen DESCRIPCION

Permitir al usuario observar todas las máquinas independientemente del ambiente al cual pertenecen

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones Alternativas y excepciones

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al 2) Muestra un listado de máquinas agrupados por

106

módulo de máquinas. 3) El usuario selecciona ver todo

ambiente. 4) El sistema muestra todas las máquinas

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de generar reporte en el punto 3

1.17. Filtrar una maquina Caso 4.5

IDENTIFICACIÓN CASO DE

USO ACTORES

4.5 Filtrar una máquina

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario buscar una máquina por el nombre, independientemente del

ambiente al cual pertenece DESCRIPCION

Permitir al usuario buscar una máquina por el nombre, independientemente del ambiente al cual pertenece

Precondiciones Haber iniciado sesión, poseer permisos respectivos Pos condiciones Alternativas y excepciones

No se encuentra la máquina

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR 1) El usuario ingresa al módulo de máquinas. 2) Ingresa los caracteres de búsqueda en el buscador

3) El sistema le muestra los resultados que coinciden con la búsqueda

107

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de generar reporte en el punto 2

1.18. Asignar una máquina a un usuario Caso 4.6

IDENTIFICACIÓN CASO DE

USO ACTORES

4.6 Asignar máquina a un ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario asignar una máquina a un ambiente

108

DESCRIPCION Permitir al usuario asignar una máquina a un ambiente

Precondiciones Haber iniciado sesión, poseer permisos respectivos Pos condiciones La máquina queda asignada a un ambiente determinado Alternativas y excepciones

El usuario desde crear una máquina o editar una previamente existente

CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR 1) El usuario ingresa al módulo de máquinas. 3) EL usuario da clic en la opción de crear máquina 5) El usuario llena el formulario y escoge el ambiente al cual la va a asignar y da clic en guardar Nota: Si la máquina ya existe el usuario puede editar una creada previamente

2) El sistema muestra el listado de máquinas existentes 6) El sistema guarda los cambios

PUNTOS DE INTERRUPCION

El usuario interrumpe la solicitud de generar reporte en el punto 3

1.19. Crear Tasks Ansible (programas y configuraciones) para cada ambiente Caso 5.1

IDENTIFICACIÓN CASO DE USO ACTORES

5.1 Crear Tasks Ansible Usuario Super administrador,

109

(programas y configuraciones) para cada ambiente

administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) adicionar programas y configuraciones a las máquinas del respectivo ambiente

DESCRIPCIÓN Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) adicionar programas y configuraciones a las máquinas del respectivo ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones Las máquinas quedan con el script de Ansible disponible Alternativas y excepciones

Si el usuario es Super Administrador le pregunta sobre cuál ambiente va a trabajar

CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al módulo de Tareas 2) ingresa a la opción de añadir programas y configuraciones 4) Selecciona los programas necesarios

3) El sistema despliega los programas a instalar disponibles

PUNTOS DE INTERRUPCIÓN

El usuario interrumpe la solicitud de generar reporte en el punto 2

1.20. Eliminar Task Ansible (programas y configuraciones) para ambiente Caso 5.2

110

IDENTIFICACIÓN CASO DE USO ACTORES

5.2 Eliminar Task Ansible (programas y configuraciones) para ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) eliminar programas y configuraciones a las máquinas del respectivo ambiente

DESCRIPCIÓN Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) eliminar programas y configuraciones a las máquinas del respectivo ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones El script de Ansible se actualiza para que no ejecuta la descarga

e instalación de los programas eliminados por el usuario Alternativas y excepciones

Si el usuario es Super Administrador le pregunta sobre cuál ambiente va a trabajar

CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al módulo de Tareas 2) ingresa a la opción de eliminar programas y configuraciones

3) El sistema despliega los programas disponibles 6) El sistema guarda los cambios

111

4) Selecciona los programas a ser eliminados

PUNTOS DE INTERRUPCIÓN

El usuario interrumpe la solicitud de generar reporte en el punto 4

1.21. Listar Task Ansible (programas y configuraciones) para cada

ambiente Caso 5.3

IDENTIFICACIÓN CASO DE USO ACTORES

5.3 Listar Task Ansible (programas y configuraciones) para cada ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) observar programas y configuraciones a las máquinas del respectivo ambiente

DESCRIPCIÓN Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) observar programas y configuraciones a las máquinas del respectivo ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones Alternativas y excepciones

Si el usuario es Super Administrador le pregunta sobre cuál ambiente va a trabajar

112

CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al módulo de Tareas

2) El sistema despliega los programas disponibles para determinado ambiente

PUNTOS DE INTERRUPCIÓN

El usuario interrumpe la solicitud de generar reporte en el punto 1

1.22. Ejecutar aprovisionamiento IDENTIFICACIÓN CASO DE USO ACTORES

5.3 Listar Task Ansible (programas y configuraciones) para cada ambiente

Usuario Super administrador, administrador de desarrollo, administrador de QA, administrador DevOps

OBJETIVO Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) observar programas y configuraciones a las máquinas del respectivo ambiente

DESCRIPCIÓN Permitir al usuario (Usuario Super administrador, administrador de

desarrollo, administrador de QA, administrador DevOps) observar programas y configuraciones a las máquinas del respectivo ambiente

Precondiciones Haber iniciado sesión. Poseer permisos respectivos. Pos condiciones Alternativas y excepciones

Si el usuario es Super Administrador le pregunta sobre cuál ambiente va a trabajar

CURSO NORMAL DE LOS EVENTOS ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1) El usuario ingresa al módulo de Tareas

2) El sistema despliega los programas disponibles para determinado ambiente

PUNTOS DE INTERRUPCIÓN

El usuario interrumpe la solicitud de generar reporte en el punto 1

2. Diagramas de secuencia 2.1. Login Caso 1.1

113

2.2. Registro Caso 1.2

2.3. Administración de Roles – Permisos Caso 1.3

2.4. Logout Caso 1.4

114

2.5. Adicionar empresa Caso 2.1

2.6. Editar datos de una empresa Caso 2.2

115

2.7. Listar todas las empresas Caso 2.3

2.8. Filtrar una empresa Caso 2.4

2.9. Adición de proyecto con sus respectivos ambientes Caso 3.1

116

2.10. Edición de proyecto Caso 3.2

2.11. Deshabilitar/ Habilitar un proyecto Caso 3.3

117

2.12. Listar todos los proyectos de una empresa Caso 3.4

2.13. Filtrar un proyecto Caso 3.5

118

2.14. Adicionar una máquina local Caso 4.1

2.15. Edición de maquina Caso 4.2

119

2.16. Deshabilitar/Habilitar una maquina Caso 4.3

2.17. Listar todas maquinas Caso 4.4

120

2.18. Filtrar una maquina Caso 4.5

2.19. Asignar una máquina a un usuario Caso 4.6

121

2.20. Crear Tasks Ansible (programas y configuraciones) para cada ambiente Caso 5.1

2.21. Eliminar Task Ansible (programas y configuraciones) para ambiente Caso 5.2

2.22. Listar Task Ansible (programas y configuraciones) para cada ambiente Caso 5.3

122

2.23. El administrador de cada ambiente ejecuta el aprovisionamiento Caso 6

3. Diagramas de actividad 3.1. Login Caso 1.1

123

3.2. Registro Caso 1.2

3.3. Administración de Roles – Permisos Caso 1.3

3.4. Logout Caso 1.4

124

3.5. Adicionar empresa Caso 2.1

3.6. Editar datos de una empresa Caso 2.2

3.7. Listar todas las empresas Caso 2.3

125

3.8. Adición de proyecto con sus respectivos ambientes Caso 3.1

3.9. Edición de proyecto Caso 3.2

3.10. Listar todos los proyectos de una empresa Caso 3.4

126

3.11. Adicionar una máquina local Caso 4.1

3.12. Listar todas maquinas Caso 4.4

127

3.13. Asignar una máquina a un usuario Caso 4.6

3.14. Crear Tasks Ansible (programas y configuraciones) para

cada ambiente Caso 5.1

128

3.15. Eliminar Task Ansible (programas y configuraciones) para

ambiente Caso 5.2

3.16. El administrador de cada ambiente ejecuta el

aprovisionamiento Caso 6

129

4. Diagramas de colaboración 4.1. Login Caso 1.1

4.2. Administración de Roles – Permisos Caso 1.3

4.3. Adicionar empresa Caso 2.1

130

4.4. Editar datos de una empresa Caso 2.2

4.5. Adición de proyecto con sus respectivos ambientes Caso 3.1

4.6. Edición de proyecto Caso 3.2

131

4.7. Adicionar una máquina local Caso 4.1

4.8. Edición de maquina Caso 4.2

132

4.9. Asignar una máquina a un usuario Caso 4.6

4.10. Crear Tasks Ansible (programas y configuraciones) para cada ambiente Caso 5.1

133

4.11. Eliminar Task Ansible (programas y configuraciones) para

ambiente Caso 5.2

4.12. El administrador de cada ambiente ejecuta el aprovisionamiento Caso 6

Figura 38. Ejecutar aprovisionamiento Caso 6

134

BIBLIOGRAFÍA

• Somerville, I. (2011). Ingeniería de Software. México: Editorial Pearson.

• Rueda, J. (2006). Aplicación De La Metodología RUP Para El Desarrollo Rápido De Aplicaciones basado En El Estándar J2EE. Guatemala.

• Rumbough J. Jacobson I. Booch, J. (2000). El lenguaje unificado de modelado. Manual de referencia. Editorial: Parsons.

• Rajkumar B, Christian V, Thamarai S. (2013). Mastering Cloud Computing. Editorial: Morgan Kaufmann.

• Andreas, M (2016). Amazon web services in action, Editorial: Manning.

• Nickoloff, J. (2016). Docker in action, Editorial: Manning Segunda Edición.

• Thompson, C. (2015). Vagrant virtual development environment cookbook, Editorial: Packt Publishing.

• Hetzel, H. (1985). Systematic Test And Evaluation Process, p. 463-474.

135

INFOGRAFÍA

• El modelo de desarrollo, testing y producción. (2013). Recuperado de: https://www.linuxito.com/programacion/237-el-modelo-de-desarrollo-testing-y-produccion.

• Norma de separación de Ambientes de trabajo Sistemas. (s,f). Recuperado de: https://www.hospitalitaliano.org.ar/multimedia/archivos/clases_attachs/1982-19.pdf

• Pruebas de integración, la hora de la verdad para el software. (2017). Recuperado de: https://www.obs-edu.com/int/blog-investigacion/sistemas/pruebas-de-integracion-la-hora-de-la-verdad-para-el-software

• Introducción a RUP, (s, f). Universidad Politécnica de Valencia. Recuperado de: https://pid.disc.upv.es/C1/Material/Documentos%Documentos&2Disponibles/Introducción%20a/.doc

• Robles, V. (Diciembre 2017), ¿Qué es angular y para qué sirve? Recuperado de: https://victorroblesweb.es/2017/08/05/que-es-angular-y-para-que-sirve/

• API REST: qué es y cuáles son sus ventajas en el desarrollo de proyectos. (Marzo 2016). Recuperado de: https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos

• Wasson, M. (2017). Estilo de arquitectura microservicios. Recuperado de: https://docs.microsoft.com/es-es/azure/architecture/guide/architecture-styles/microservices

• Pérez, J, J. (2015). Qué es y cómo empezar con Ionic Framework. Recuperado de: http://www.phonegapspain.com/que-es-y-como-empezar-con-ionic-framework/

• Dontares, C, A. (2015). Qué es Postgres y cuáles son sus ventajas. Recuperado de: https://platzi.com/blog/que-es-postgresql/

• Integración Continua ¿Qué, Cuando y Como? (noviembre 2016). Recuperado de https://otroespacioblog.wordpress.com/2016/11/17/integracion-continua-entrega-continua-y-despliegue-continuo-que-cuando-y-como/

136

• Amazon Web Services (AWS). ¿Qué es la integración continua?,(s, f). Recuperado de https://aws.amazon.com/es/devops/continuous-integration/

• Timothy, F. (2009). Continuos Deployment. Recuperado de http://timothyfitz.com/2009/02/08/continuous-deployment/

• Duarte, E. (Julio 2017). Cerrando la brecha de la discapacidad tecnológica. Recuperado de: http://blog.capacityacademy.com/2017/07/07/cerrando-la-brecha-de-la-discapacidad-tecnologica-rafael-gerardo-tedxsantodomingo/7

• Valero, E (2016). Terraform, la navaja suiza para dominar todos los IaaS. Recuperado de https://www.paradigmadigital.com/dev/terraform-la-navaja-suiza-dominar-todos-los-iaas/

• Gonzales, C, (s, f). Historia de los entornos integrados. Recuperado de: https://www.timetoast.com/timelines/historia-de-los-entornos-integrados-de-desarrollo-ide

MANUAL FUNCIONAL SISTEMA

PROVISIONER

INTRODUCCIÓN El sistema Provisioner ha sido diseñado y desarrollado para permitir a su empresa automatizar los

procesos de instalación y configuración de software en las máquinas que se utilizan en su empresa.

A continuación, se muestra el paso a paso de como utilizar el sistema.

DESCRIPCIÓN El sistema Provisioner tiene como objetivo permitir a su empresa mejorar el proceso “End to End” del

desarrollo de un software o producto, el cual, comprende las etapas de desarrollo, pruebas y puesta

en producción; a partir de la implementación de un sistema web separado entre Back-End y Front-

End, que mediante la utilización del patrón MVC orientado a Microservicios y con tecnologías tales

como Java Spring Boot, Angular 6 en conjunto con Ionic 3 y REST API permitan la instalación y

configuración automática de herramientas DevOps (herramientas de desarrollo y operaciones) en

cada ambiente de trabajo de una empresa.

REQUISITOS FUNCIONALES Y NO

FUNCIONALES 1.1. Requerimientos Funcionales

• Creación de empresa, el proyecto de una empresa y configuración de las máquinas asociadas a un ambiente del proyecto.

• Documentación disponible del sistema, documentación técnica, de usuario, de procesos, modelo de datos y cualquier otro documento de caracterización del sistema.

• El acceso a la plataforma “Provisioner” está limitado a las personas que se registren en la plataforma, las cuales poseerán un usuario y contraseña para poder entrar y hacer uso de los servicios definidos para cada tipo de rol.

• La plataforma “Provisioner” debe tener una interfaz que incluya y separe todas las funciones para los usuarios según las opciones de trabajo disponibles para cada tipo de rol.

2

• Permitir al administrador de todo el sistema gestionar usuarios y proyectos.

• Permitir al administrador del módulo de Desarrollo crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

• Permitir al administrador del módulo de Pruebas QA crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

• Permitir al administrador del módulo de Producción crear los “ansible Tasks” para cada máquina dentro de dicho ambiente.

1.2. Requerimientos No Funcionales

● Glosario de Términos Módulo de Soporte La plataforma siempre estará disponible 24/7.

● La plataforma siempre operará con óptimo rendimiento. ● El sistema debe estar en capacidad de permitir en el futuro el desarrollo de

nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción y puesta en funcionamiento.

● El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, etc.

● El sistema tendrá el mismo comportamiento en todos los navegadores web y en cualquier dispositivo en donde se acceda a esta.

● La eficiencia de los reportes estará́ determinada en gran medida por el aprovechamiento de los recursos, y la velocidad de las consultas en la Base de Datos.

ALCANCES La elaboración del sistema de aprovisionamiento comprende dentro de su desarrollo los siguientes alcances:

• Módulo de compañía: Permite registrar y gestionar los datos de la compañía que usará el presente sistema de aprovisionamiento.

• Módulo de proyectos: Permite gestionar los proyectos que estén activos dentro de la compañía que usará el sistema de aprovisionamiento.

• Módulo de máquinas: permite administrar las máquinas que pertenecen a determinado ambiente de trabajo, dentro de cada proyecto de la compañía

• Módulo de Tasks: Permite administrar las tareas (software a aprovisionar) dentro de cada ambiente de trabajo, y ejecutar el aprovisionamiento de estas tareas. El aprovisionamiento se realizará en redes locales, así como también en máquinas desplegadas en la nube.

3

PROCESOS

• Inicio de Sesión

Se puede iniciar sesión con datos previamente utilizados en el registro o la

cuenta de Google de la persona

4

• Menú principal

El menú está compuesto por la opción de “Compañias” redirige a la página de

compañías y la opción “Planntillas” en donde se ueden ver las plantillas Ansible

disponibles.

• Módulo de crear compañía

Existe el botón de crear compañía , la lista de compañías creadas y la opción de

gestión de cada una

• Formulario de compañía

5

• Después de digitar los datos aparece una pantalla parecida a esta:

• Ahora se puede ver la compañía en la lista de compañías

• Botón Empleados

Permite ver la lista completa de empleados de una compañía y el botón

crear empleado.

• Crear Empleado

6

• Ver empleado

El empleado creado anteriormente ahora es visible

• Editar compañía

Permite editar los datos de una compañía

7

• Detalles de la compañía

Abre una modal con los datos de la compañía creada

• Crear proyecto

Permite crear un proyecto, el cual quedará asociado a la empresa creada

anteriormente

8

• Ver lista de proyectos

http://localhost:8100/#/tabs-page/conference-schedule/projectDetail/1

• Ver lista de ambientes del proyecto creado previamente

• Ver lista de máquinas

http://localhost:8100/#/tabs-page/conference-

schedule/environmentMachineDetail/1

9

• Editar una máquina

• Crear una nueva máquina

10

• Ver lista de máquinas

• Ver listado de Tasks

http://localhost:8100/#/tabs-page/conference-schedule/task

11

• Creación de nueva tarea

• Ver listado de tareas

• Listado de plantillas disponible

12

13

• Crear nueva plantilla

• Listado de plantillas

1

1

Documentación técnica del Sistema Provisioner

Documentación técnica

Esta documentación técnica del producto provisioner los requisitos técnicos que deben reunirse para

implementarlo , las soluciones técnicas que utiliza y otorga Provisioner

Especificación del producto

Realizado en Java 1.8 Srpring Boot con STS IDE, y Angular 6 / Ionic 3.

Base de datos: Postgres 10.

2

Estándares

Técnicos: El producto está basados en estándares amplios establecidos por las organizaciones de

estandarización internacionales tales como ISO y W3C, Ecmascrypt y Sun Mycrosystem.

FACTIBILIDAD

Factibilidad Técnica

Para el desarrollo del sistema multinivel se contará con 1 equipos de cómputo con las siguientes

características y una instancia de Amazon EC2.

Equipo de cómputo:

● 1TB de espacio en disco

● 16GB memoria RAM

● Intel Corei5 2.3 GHz

● Sistema Operativo Ubuntu 17.10

● Motor de base de datos Postgres 9.6

Instancia AWS: Instancia T2 nano:

CPU Intel Xeon Virtual:1

Cruds por la Hora de CPU: 3

Memoria: 0.5 GB

Factibilidad Operativa

Los equipos desde donde se instalará el software deberán poseer los siguientes requerimientos mínimos:

Procesador Intel/AMD + 2.0 GHz

768 Mb de memoria RAM

500MB de espacio en disco

UBUNTU 9.04 en adelante

3

LAN/WAN

LAN Backbone (entre el servidor de aplicación y el servidor de la base de datos) 10 Mb - lo

recomendado es 100Mb. LAN (entre el banco de trabajo, el servidor de aplicación y el de la base de

datos) 10Mb. WAN no tiene requisitos especiales, y debe tolerar la circulación ordinaria de HTTP

Escalabilidad

El sistema es muy escalable y podrá tolerar muchos queries. Un caching sofisticado de las estructuras

de los datos y el pre- cálculo de las operaciones ha sido creado, y se necesitan unos pocos recursos

durante la operación, excepto cuando se actualizan nuevas organizaciones, nodos y datos de nodos, ya

que en ese caso se vuelven a construir las estructuras de datos. Esto no suele ocurrir durante la

operación.

Seguridad

Mecanismos de seguridad

Se utilize Auht0 para la implematción de seguridad en Back-End y en Front-End.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Requerimientos Funcionales

• Creación de empresa, el proyecto de una empresa y configuración de las máquinas asociadas a un

ambiente del proyecto.

• Documentación disponible del sistema, documentación técnica, de usuario, de procesos, modelo de datos

y cualquier otro documento de caracterización del sistema.

• El acceso a la plataforma “Provisioner” está limitado a las personas que se registren en la plataforma, las

cuales poseerán un usuario y contraseña para poder entrar y hacer uso de los servicios.

• La plataforma “Provisioner” debe tener una interfaz que incluya y separe todas las funciones para los

usuarios según las opciones de trabajo disponibles.

• Permitir al administrador de todo el sistema gestionar usuarios y proyectos.

• Permitir al administrador del módulo de Desarrollo crear los “ansible Tasks” para cada máquina dentro de

dicho ambiente.

• Permitir al administrador del módulo de Pruebas QA crear los “ansible Tasks” para cada máquina dentro

de dicho ambiente.

• Permitir al administrador del módulo de Producción crear los “ansible Tasks” para cada máquina dentro de

4

dicho ambiente.

Requerimientos No Funcionales

● Glosario de Términos Módulo de Soporte La plataforma siempre estará disponible 24/7.

● La plataforma siempre operará con óptimo rendimiento.

● El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades,

modificar o eliminar funcionalidades después de su construcción y puesta en funcionamiento.

● El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el

proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de

campos, longitud de caracteres permitida por campo, manejo de tipos de datos, etc.

● El sistema tendrá el mismo comportamiento en todos los navegadores web y en cualquier dispositivo en

donde se acceda a esta.

● La eficiencia de los reportes estará́ determinada en gran medida por el aprovechamiento de los recursos, y

la velocidad de las consultas en la Base de Datos.

DOCUMENTOS ANEXOS:

DocumentacionTecnicaAnexo.html

DocumentacionTecnica_files