“Easy POA”

Memoria de estadía

Ingeniería en Software

Presentada por:

Latorre Villeda Luis Angel

Jimenez Granados Ivan Uriel

Santillan Calvillo Leylani C.

García Paredes José Armando

Perez Vazquez Aairam Jared

Manzano Tello Daniel Andres

Martínez Barragán Daniel

Saldaña Solis Jose Emmanuel

Zempoala, Hgo. México Octubre 2022

 Easy POA

Índice

Resumen 5

Capítulo I Introducción 6
1.1 Datos generales de la empresa 6
1.2 Planteamiento de la problemática del proyecto 7
1.3 Justificación del proyecto 7
1.4 Propuesta de Solución 7
1.5 Objetivo 8
1.5.1 Objetivo general 8
1.5.2 Objetivos específicos 8
1.6 Metas 8
1.7 Metodología de desarrollo del proyecto 8
1.8 Estructura general de la tesis 9

Capítulo II Conceptos básicos 10

2.1 Ingeniería en software 10
2.2 Metodología para el desarrollo de software 10
2.2.1 Metodologías de desarrollo de software tradicionales 11
2.2.2 Metodologías de desarrollo de software ágiles 12
2.3 Bases de datos 13
2.3.1 Tipos de bases de datos 13
2.3.2 Ejemplos de gestores de base de datos 14
2.4 Lenguaje de programación 15
2.4.1 Tipos de lenguaje de programación 15
2.4.2 Ejemplos de lenguajes de programación 16
2.5 Etapas del desarrollo de software 17
2.5.1 Análisis de requerimientos. 17
2.5.2 Diseño 17
2.5.3 Construcción. 17
2.5.4 Implementación 17
2.5.5 Pruebas. 18
2.5.6 Liberación 18

Capítulo III Herramientas 19

3.1 Jira 19
3.2 GitHuB 19
3.3 Testim 20
3.4 Sonarqube 21
3.5 Jest 21

Capítulo IV Metodología 22
4.1 Scrum 22
4.2 SRS 22

2
 Easy POA

4.3 Historia de usuario 23

4.4 Sprint 23
4.4.1 Sprints 23
4.4.2 Lista de tareas de la iteración (Sprint Backlog) 24
4.4.2.1 Primer Sprint 24
4.4.2.2 Segundo Sprint 24
4.4.2.3 Tercero Sprint 24
4.4.2.4 Cuarto Sprint 24
4.4.2.5 Quinto Sprint 24
4.4.3 El tablero de tareas (Scrum Taskboard) 25
4.5 PSP 25

Capítulo V Arquitectura de software 26

5.1 Modelo de vistas 4+1 26
5.1.1 Vista Lógica: 26
5.1.1.1 Diagrama de clases 26
5.1.1.2 Diagrama de Secuencia 26
5.1.2 Vista de Despliegue: 26
5.1.2.1 Diagrama de componentes 26
5.1.3 Vista de Procesos: 26
5.1.3.1 Diagrama de actividad 26
5.1.4 Vista Física: 26
5.1.4.1 Diagrama de despliegue 27
5.1.5 “+1” Vista de Escenarios: 27
5.1.5.1 Diagrama de casos de uso 28
5.1.5.2 Diagrama Entidad-Relación 29

Capítulo VI Patrones arquitectónicos 31

6.1 Maestro-esclavo 31
Este patrón consiste en dos partes; maestro y esclavos. El componente maestro
distribuye el trabajo entre componentes esclavos idénticos y calcula el resultado final de
los resultados que devuelven los esclavos. 31
6.2 Patrones de diseño 31
6.2.1 Creacional 31
6.2.1.1Factory Method 31
6.2.1.2 Patrón Constructor 31
6.2.1.3 Patrón Constructor con prototipo 31
6.2.1.4 Patrón Módulo 31
6.2.1.5 Patrón Módulo Revelador 32
6.2.1.6 Patrón Prototipo 32
6.2.2 Estructural 32
6.2.2.1 Bridge 32
6.2.2.2 Patrón Mixin 32
6.2.2.3 Patrón Decorador 32
6.2.3 Comportamiento 32

3
 Easy POA

6.2.3.1 Chain of Responsibility 32

6.2.3.2 Patrón Observador 33
6.2.3.3 Patrón Cadena de Responsabilidad 33
6.2.3.4 Patrón Iterador 33

Capítulo VII Diseño de interfaces 34

Capítulo VIII Pruebas 37

8.1 Pruebas a realizar 37
8.2 Versión del producto a probar 38
8.3 Hardware usado para las pruebas 38
8.4 Ambiente de prueba 38
8.5 Evidencia de pruebas 39

Capítulo IX Conclusiones 40

Referencias 41

4
 Easy POA

Resumen
En esta memoria de estadía, se aborda la problemática con la que cuenta el
departamento de planeación de la Universidad Politécnica de Pachuca realizar el
control de gran variedad de POA de cada departamento que cuenta la institución,
para mantener el control de cada uno de ellos, así como también sus actividades a
realizar y la manera en que se trabajará para su organización.

5
 Easy POA

Capítulo I Introducción
1.1 Datos generales de la empresa
Universidad Politécnica de Pachuca

Figura 1. 1. Ubicación de la empresa.

Figura 1. 2. Logotipo de la Universidad Politécnica de pachuca

La Universidad Politécnica de Pachuca ha puesto en el horizonte de las vocaciones

las carreras de Biomédica, Financiera, las Licenciaturas en Terapia Física, Médico
Cirujano; ingeniería en Redes y Telecomunicaciones, Software; y actualmente se
suma la Ingeniería en Sistemas y Tecnologías Industriales.

6
 Easy POA

1.2 Planteamiento de la problemática del proyecto

El departamento de planeación de la Universidad Politécnica de Pachuca necesita
agilizar la realización y control de Presupuesto autorizado (POA) de cada
departamento

1.3 Justificación del proyecto

Los alumnos utilizarán sus conocimientos adquiridos en la carrera de
Ingeniería en Software, asegurando la calidad del software. Desarrollar un sistema
de gestión de datos que optimice el proceso de planificación del POA dentro de la
Universidad Politécnica de Pachuca.

Dado que este proceso como el llenado de la documentación aún se lleva a mano y
se entrega de manera física se pretende realizar un sistema donde se pueda hacer
el llenado de las requisiciones de bienes y/o servicios de manera digital, una
calendarización por componente y todas las personas involucradas en la planeación
puedan tener acceso al sistema.

Este proyecto afectará a los departamentos responsables de las 22 actividades

administrativas que disponen del POA cada año. También, el departamento de
planeación y finanzas que son responsables directos de todo este proceso, por lo
que se beneficiarán del mismo.

1.4 Propuesta de Solución

Se realizará un crud desarrollado en Web con Node.js conectado desde una base
de datos en MysQL para lograr cubrir la cantidad de usuarios que encontrarán a
dicho sistema gestionado y controlado desde el Departamento de Tecnologías de la
Información y Comunicación de la Universidad Politécnica de Pachuca.

Para el desarrollo de nuestro producto ocuparemos Scrum el cual es una

metodología ágil que nos permite trabajar de manera colaborativa, la metodología
Scrum se centra en iteraciones más pequeñas y de longitud fija. Una vez finalizado
el periodo para un sprint, se determinan las historias o las entradas de backlog del
producto que se pueden implementar durante este ciclo de sprint. Esta es la
metodología que implementaremos en el producto, ya que nos permite conectar los
tiempos de ambos equipos.

Para el proceso de obtención de requisitos ocupamos el documento IEEE830 ya

que nos permitió tener un listado de requerimientos y del contexto de la solución al
problema así como una descripción general del diseño por medio de casos de uso y
escenarios.

7
 Easy POA

1.5 Objetivo

1.5.1 Objetivo general

Realizar un sistema que gestione el proceso de planificación del POA y la
calendarización de cada componente para automatizar, facilitar y llevar una mejor
administración con una base de datos establecida por parte del departamento de
planeación.

1.5.2 Objetivos específicos

1. Desarrollar una aplicación web para
2. Crear una aplicación web que sea intuitiva

1.6 Metas
Realizar un sistema de dicho sistema para la solución y resolución de ante
proyectos de cada actividades, facilita el trabajo de cada una de ellas así como
también tener el control más a fondo de cada área

1.7 Metodología de desarrollo del proyecto

A continuación se presentan los pasos a seguir en forma de esquema para llevar a
cabo el proyecto .

Figura 1. Metodología de desarrollo del proyecto de software

8
 Easy POA

1.8 Estructura general de la tesis

La tesis se estructura en 9 capítulos: Introducción, Marco contextual, Herramientas,
Metodología, Arquitectura de software, Patrones arquitectónicos, Diseño de
interfaces, Pruebas y Conclusiones los cuales se describen a continuación:

En el Capítulo 1 – Se plantea el contexto que da soporte a este trabajo de tesis, se

presentan los datos generales de la empresa, planteamiento de la problemática del
proyecto, justificación del proyecto, objetivo y metas, la metodología de desarrollo
del proyecto.

En el Capítulo 2 – En este capítulo se describen

En el Capítulo 3 – En el siguiente capítulo se describen las herramientas que no

ayudarán a agilizar el desarrollo del software, las cuáles son Jira, GitHub, Testim,
Sonarqube y Jest.

En el Capítulo 4 – En este capítulo se desarrolla la metodología a utilizar al igual las

historias de usuario, los sprints y el PSP personal de cada integrante del equipo de
trabajo.

En el Capítulo 5 – En el siguiente capítulo se describe la arquitectura de software a

utilizar en la construcción de la aplicación web, el cual es el modelo de vista 4+1 y
se describen cada una de sus vistas.

En el Capítulo 6 – En este capítulo se describen los patrones arquitectónicos a

utilizar los cuales son patrones cliente-servidor, patrones de diseño que incluyen los
creacionales, estructurales y de comportamiento.

En el Capítulo 7 – En el siguiente capítulo se muestra el diseño de interfaces el cual

está representado por la realización de los mockups.

En el Capítulo 8 – Se describen las conclusiones obtenidas a partir del desarrollo del

proyecto, se mencionan las aportaciones obtenidas y se finaliza con los trabajos
futuros a desarrollar a partir de esta investigación además se incluyen los artículos
realizados para la participación en los congresos.

9
 Easy POA

Capítulo II Conceptos básicos

2.1 Ingeniería en software

Tomando en cuenta las siguientes definiciones de Ingeniería de Software:

● La Ingeniería de Software es una disciplina de la Ingeniería que concierne a

todos los aspectos de la producción de software. Los Ingenieros de Software
adoptan un enfoque sistemático para llevar a cabo su trabajo y utilizan las
herramientas y técnicas necesarias para resolver el problema planteado, de
acuerdo a las restricciones de desarrollo y recursos disponibles.

● La ingeniería del software es una disciplina que implica el uso de estructuras,

herramientas y técnicas para construir programas informáticos.

● La Ingeniería de Software es la disciplina de la ingeniería que estudia la

naturaleza, los enfoques y metodología de desarrollo a gran escala del
software. Además de las teor´ıas y leyes detr´as de las prácticas ingenieriles
y el comportamiento del software

● Es la rama de la ingeniería que se encarga de la estructuración y

construcción de programas informáticos diseñados con herramientas y
técnicas dignas de la ingeniería. En este caso se utilizan los algoritmos, la
programación, las estructuras de datos y los documentos para el desarrollo
web de sistemas informáticos, programas, aplicaciones, entre otros.

2.2 Metodología para el desarrollo de software

Las metodologías de desarrollo de software son un conjunto de técnicas y métodos
organizativos que se aplican para diseñar soluciones de software informático. El
objetivo de las distintas metodologías es el de intentar organizar los equipos de
trabajo para que estos desarrollen las funciones de un programa de la mejor manera
posible.

Cuando se trata de desarrollar productos o soluciones para un cliente o mercado

concreto, es necesario tener en cuenta factores como los costes, la planificación, la
dificultad, el equipo de trabajo disponible, los lenguajes utilizados, etc. Todos ellos
se engloban en una metodología de desarrollo que permite organizar el trabajo de la
forma más ordenada posible.

10
 Easy POA
En la actualidad se pueden diferenciar dos grandes grupos de metodologías de
desarrollo de software: las ágiles y las tradicionales. A continuación, se explican las
características de cada una de ellas.

2.2.1 Metodologías de desarrollo de software tradicionales

Las metodologías de desarrollo de software tradicionales se caracterizan por definir
total y rígidamente los requisitos al inicio de los proyectos de ingeniería de software.
Los ciclos de desarrollo son poco flexibles y no permiten realizar cambios, al
contrario que las metodologías ágiles; lo que ha propiciado el incremento en el uso
de las segundas.

La organización del trabajo de las metodologías tradicionales es lineal, es decir, las

etapas se suceden una tras otra y no se puede empezar la siguiente sin terminar la
anterior. Tampoco se puede volver hacia atrás una vez se ha cambiado de etapa.
Estas metodologías, no se adaptan nada bien a los cambios, y el mundo actual
cambia constantemente.

Las principales metodologías tradicionales o clásicas son:

Waterfall (cascada): Es una metodología en la que las etapas se organizan de

arriba a abajo, de ahí el nombre. Se desarrollan las diferentes funciones en etapas
diferenciadas y obedeciendo un riguroso orden. Antes de cada etapa se debe
revisar el producto para ver si está listo para pasar a la siguiente fase. Los requisitos
y especificaciones iniciales no están predispuestos para cambiarse, por lo que no se
pueden ver los resultados hasta que el proyecto ya esté bastante avanzado.

Prototipado: se basa en la construcción de un prototipo de software que se

construye rápidamente para que los usuarios puedan probarlo y aportar feedback.
Así, se puede arreglar lo que está mal e incluir otros requerimientos que puedan
surgir. Es un modelo iterativo que se basa en el método de prueba y error para
comprender las especificidades del producto.

Espiral: es una combinación de los dos modelos anteriores, que añade el concepto
de análisis de riesgo. Se divide en cuatro etapas: planificación, análisis de riesgo,
desarrollo de prototipo y evaluación del cliente. El nombre de esta metodología da
nombre a su funcionamiento, ya que se van procesando las etapas en forma de
espiral. Cuanto más cerca del centro se está, más avanzado está el proyecto.

Incremental: en esta metodología de desarrollo de software se va construyendo el

producto final de manera progresiva. En cada etapa incremental se agrega una
nueva funcionalidad, lo que permite ver resultados de una forma más rápida en
comparación con el modelo en cascada. El software se puede empezar a utilizar
incluso antes de que se complete totalmente y, en general, es mucho más flexible
que las demás metodologías.

11
 Easy POA
Diseño rápido de aplicaciones (RAD): esta metodología permite desarrollar
software de alta calidad en un corto periodo de tiempo. Los costes son mucho más
altos y el desarrollo más flexible, aunque requiere una mayor intervención de los
usuarios. Por otro lado, el código puede contener más errores, y sus funciones son
limitadas debido al poco tiempo del que se dispone para desarrollarlas. El objetivo
es iterar el menor número posible de veces para conseguir una aplicación completa
de forma rápida.

2.2.2 Metodologías de desarrollo de software ágiles

Las metodologías ágiles de desarrollo de software son las más utilizadas hoy en día
debido a su alta flexibilidad y agilidad. Los equipos de trabajo que las utilizan son
mucho más productivos y eficientes, ya que saben lo que tienen que hacer en cada
momento. Además, la metodología permite adaptar el software a las necesidades
que van surgiendo por el camino, lo que facilita construir aplicaciones más
funcionales.

Las metodologías ágiles se basan en la metodología incremental, en la que en cada

ciclo de desarrollo se van agregando nuevas funcionalidades a la aplicación final.
Sin embargo, los ciclos son mucho más cortos y rápidos, por lo que se van
agregando pequeñas funcionalidades en lugar de grandes cambios.

Las principales metodologías ágiles son:

Kanban: metodología de trabajo inventada por la empresa de automóviles Toyota.

Consiste en dividir las tareas en porciones mínimas y organizarlas en un tablero de
trabajo dividido en tareas pendientes, en curso y finalizadas. De esta forma, se crea
un flujo de trabajo muy visual basado en tareas prioritarias e incrementando el valor
del producto.

Scrum: es también una metodología incremental que divide los requisitos y tareas
de forma similar a Kanban. Se trabaja sobre bloques de tiempos cortos y fijos (entre
dos y cuatro semanas) para conseguir un resultado completo en cada iteración. Las
etapas son: planificación de la iteración (planning sprint), ejecución (sprint), reunión
diaria (daily meeting) y demostración de resultados (sprint review). Cada iteración
por estas etapas se denomina también sprint.

Lean: está configurado para que pequeños equipos de desarrollo muy capacitados
elaboren cualquier tarea en poco tiempo. Los activos más importantes son las
personas y su compromiso, relegando así a un segundo plano el tiempo y los
costes. El aprendizaje, las reacciones rápidas y potenciar el equipo son
fundamentales.

Programación extrema (XP): es una metodología de desarrollo de software basada

en las relaciones interpersonales, que se consideran la clave del éxito. Su principal
objetivo es crear un buen ambiente de trabajo en equipo y que haya un feedback

12
 Easy POA
constante del cliente. El trabajo se basa en 12 conceptos: diseño sencillo, testing,
refactorización y codificación con estándares, propiedad colectiva del código,
programación en parejas, integración continua, entregas semanales e integridad con
el cliente, cliente in situ, entregas frecuentes y planificación.

2.3 Bases de datos

Una base de datos es una recopilación organizada de información o datos
estructurados, que normalmente se almacena de forma electrónica en un sistema
informático. Normalmente, una base de datos está controlada por un sistema de
gestión de bases de datos (DBMS). En conjunto, los datos y el DBMS, junto con las
aplicaciones asociadas a ellos, reciben el nombre de sistema de bases de datos,
abreviado normalmente a simplemente base de datos.

Los datos de los tipos más comunes de bases de datos en funcionamiento

actualmente se suelen utilizar como estructuras de filas y columnas en una serie de
tablas para aumentar la eficacia del procesamiento y la consulta de datos. Así, se
puede acceder, gestionar, modificar, actualizar, controlar y organizar fácilmente los
datos. La mayoría de las bases de datos utilizan un lenguaje de consulta
estructurada (SQL) para escribir y consultar datos.

2.3.1 Tipos de bases de datos

Existen muchos tipos diferentes de bases de datos. La mejor base de datos para
una organización específica depende de cómo pretenda la organización utilizar los
datos.

Bases de datos relacionales: Las bases de datos relacionales se hicieron

predominantes en la década de 1980. Los elementos de una base de datos
relacional se organizan como un conjunto de tablas con columnas y filas. La
tecnología de bases de datos relacionales proporciona la forma más eficiente y
flexible de acceder a información estructurada.

Bases de datos orientadas a objetos: La información de una base de datos

orientada a objetos se representa en forma de objetos, como en la programación
orientada a objetos.

Bases de datos distribuidas: Una base de datos distribuida consta de dos o más
archivos que se encuentran en sitios diferentes. La base de datos puede
almacenarse en varios ordenadores, ubicarse en la misma ubicación física o
repartirse en diferentes redes.

Almacenes de datos: Un repositorio central de datos, un data warehouse es un tipo

de base de datos diseñado específicamente para consultas y análisis rápidos.

13
 Easy POA
Bases de datos NoSQL: Una base de datos NoSQL, o base de datos no relacional,
permite almacenar y manipular datos no estructurados y semiestructurados (a
diferencia de una base de datos relacional, que define cómo se deben componer
todos los datos insertados en la base de datos). Las bases de datos NoSQL se
hicieron populares a medida que las aplicaciones web se volvían más comunes y
complejas.

Bases de datos orientadas a grafos: Una base de datos orientada a grafos

almacena datos relacionados con entidades y las relaciones entre entidades.

Bases de datos OLTP: Una base de datos OLTP es una base de datos rápida y
analítica diseñada para que muchos usuarios realicen un gran número de
transacciones.

2.3.2 Ejemplos de gestores de base de datos

Oracle: Oracle Database es un sistema de gestión de base de datos de tipo
objeto-relacional, desarrollado por Oracle Corporation, la empresa estadounidense
de hardware y software. Este tipo de sistema mejora la gestión de grandes bases de
datos y también aumenta el nivel de seguridad.

MySQL: El gestor de base de datos MySQL es el más común en la actualidad al

estar basado en código abierto. Se trata de un sistema de gestión relacional, es
decir, utiliza tablas múltiples que se conectan entre sí para organizar y almacenar la
información de manera correcta. Además, hace uso del lenguaje de programación
PHP.

Microsoft SQL Server: Microsoft SQL Server es un sistema de gestión de bases de

datos relacionales (RDBMS) que admite una amplia variedad de aplicaciones de
procesamiento de transacciones, inteligencia empresarial y análisis en entornos
informáticos corporativos.

PostgreSQL: Es un servidor de base de datos objeto relacional libre, ya que incluye

características de la orientación a objetos, como puede ser la herencia, tipos de
datos, funciones, restricciones, disparadores, reglas e integridad transaccional,
liberado bajo la licencia BSD.

MongoDB: Es una base de datos NoSQL orientada a documentos que apareció a

mediados de la década de 2000. Se utiliza para almacenar volúmenes masivos de
datos. A diferencia de una base de datos relacional SQL tradicional, MongoDB no se
basa en tablas y columnas. Los datos se almacenan como colecciones y
documentos

Redis: Es un almacén de estructura de datos de valores de clave en memoria

rápida y de código abierto. Redis incorpora un conjunto de estructuras de datos en
memoria versátiles que le permiten crear con facilidad diversas aplicaciones
personalizadas.

14
 Easy POA
Elasticsearch MySQL: Es una base de datos distribuida que escala de manera
dinámica de forma horizontal, por lo que a mayor demanda podemos ir creciendo en
nodos. Llegando a poder almacenar petabytes de información. Elasticsearch se
organiza mediante nodos, los cuales son alojados dentro de un clúster.

2.4 Lenguaje de programación

En informática, se conoce como lenguaje de programación a un programa destinado
a la construcción de otros programas informáticos. Su nombre se debe a que
comprende un lenguaje formal que está diseñado para organizar algoritmos y
procesos lógicos que serán luego llevados a cabo por un ordenador o sistema
informático, permitiendo controlar así su comportamiento físico, lógico y su
comunicación con el usuario humano.

Dicho lenguaje está compuesto por símbolos y reglas sintácticas y semánticas,

expresadas en forma de instrucciones y relaciones lógicas, mediante las cuales se
construye el código fuente de una aplicación o pieza de software determinada. Así,
puede llamarse también lenguaje de programación al resultado final de estos
procesos creativos.

La implementación de lenguajes de programación permite el trabajo conjunto y

coordinado, a través de un conjunto afín y finito de instrucciones posibles, de
diversos programadores o arquitectos de software, para lo cual estos lenguajes
imitan, al menos formalmente, la lógica de los lenguajes humanos o naturales.

No deben confundirse, sin embargo, con los distintos tipos de lenguaje informático.
Estos últimos representan una categoría mucho más amplia, en donde están
contenidos los lenguajes de programación y muchos otros protocolos informáticos,
como el HTML de las páginas web.

2.4.1 Tipos de lenguaje de programación

Normalmente se distingue entre los siguientes tipos de lenguaje de programación:

Lenguajes de bajo nivel: Se trata de lenguajes de programación que están

diseñados para un hardware específico y que por lo tanto no pueden migrar o
exportarse a otros computadores. Sacan el mayor provecho posible al sistema para
el que fueron diseñados, pero no aplican para ningún otro.

Lenguajes de alto nivel: Se trata de lenguajes de programación que aspiran a ser

un lenguaje más universal, por lo que pueden emplearse indistintamente de la
arquitectura del hardware, es decir, en diversos tipos de sistemas. Los hay de
propósito general y de propósito específico.

Lenguajes de nivel medio: Este término no siempre es aceptado, que propone

lenguajes de programación que se ubican en un punto medio entre los dos

15
 Easy POA
anteriores, pues permite operaciones de alto nivel y a la vez la gestión local de la
arquitectura del sistema.

Otra forma de clasificación a menudo es la siguiente:

Lenguajes imperativos: Menos flexibles, dada la secuencialidad en que construyen

sus instrucciones, estos lenguajes se programan mediante órdenes condicionales y
un bloque de comandos al que retornan una vez llevada a cabo la función.

Lenguajes funcionales: También llamados procedimentales, estos lenguajes se

programan mediante funciones que son invocadas conforme a la entrada recibida,
que a su vez son resultado de otras funciones.

2.4.2 Ejemplos de lenguajes de programación

Algunos de los lenguajes de programación más conocidos son:

BASIC: Su nombre proviene de las siglas de Beginner’s All- purpose Symbolic

Instruction Code (Código simbólico de instrucciones de propósito general para
principiantes), y es una familia de lenguajes imperativos de alto nivel, aparecidos por
primera vez en 1964. Su versión más actual es Visual Basic .NET.

COBOL: Su nombre es un acrónimo para Common Business-Oriented Language

(Lenguaje común orientado a los negocios) y se trata de un lenguaje de
programación universal creado en 1959, orientado principalmente a la informática de
gestión, es decir, empresarial.

FORTRAN: Su nombre proviene de The IBM Mathematical Formula Translating

System (El sistema de traducción de fórmulas matemáticas de IBM), y es un
lenguaje de programación de alto nivel, propósito general y de tipo imperativo,
diseñado para aplicaciones científicas y de ingeniería.

Java: Un lenguaje de programación de propósito general, orientado a objetos, cuyo

espíritu se resume en las siglas WORA: Write Once, Run Anywhere, es decir:
Escrito una vez, funciona en cualquier parte. La idea era diseñar un lenguaje
universal empleando sintaxis derivada de los lenguajes C y C++, pero empleando
menos utilidades de bajo nivel que cualquiera de ambos.

Node.js: Sirve para crear sitios web dinámicos muy eficientes, escritos con el
lenguaje de programación JavaScript. Normalmente, los desarrolladores se
decantan por este entorno de ejecución cuando buscan que los procesos se
ejecuten de forma ágil y sin ningún tipo de bloqueo cuando las conexiones se
multiplican. Express es un framework web transigente, escrito en JavaScript y
alojado dentro del entorno de ejecución NodeJS. El módulo explica algunos de los
beneficios clave de este framework, como configurar tu entorno de desarrollo y
cómo realizar tareas comunes en desarrollo y publicación web.

16
 Easy POA

2.5 Etapas del desarrollo de software

Todo proceso de Ingenierıa de Software involucra las siguientes etapas de
desarrollo:

2.5.1 Análisis de requerimientos.

La captura, análisis y especificación de requerimientos es la primera etapa para la
creación de software, se conocen los requerimientos que debe cumplir el sistema a
través de la retroalimentación de parte del cliente y el conocimiento de las reglas de
negocio.

Para la captura de requisitos se utiliza el siguiente documento:

● SRS: El cual es un conjunto de recomendaciones para la especificación de

los requerimiento o requisitos de software el cuál tiene como producto final la
documentación de los acuerdos entre el cliente y el grupo de desarrollo

2.5.2 Diseño
Tras pasar el análisis, en esta etapa se proponen los módulos a desarrollar y se
deberán detallar cada uno de ellos. Es en esta fase cuando se definen aspectos
como la arquitectura del sistema, la forma en que se desarrollarán las aplicaciones,
el diseño de la base de datos y aquellas herramientas que se utilizaran para el
desarrollo, pruebas y liberación.

2.5.3 Construcción.
Se resume esta etapa en una palabra: codificación, se procede a codificar cada uno
de los módulos planteados en la etapa de diseño, respetando estándares de
codificación y de nombrado. Dentro de esta etapa, el equipo de desarrollo deberá
probar cada uno de los componentes que conforman el sistema, realizando pruebas
de caja negra y caja blanca.

2.5.4 Implementación
En esta fase se unen los módulos creados en la etapa de construcción de acuerdo a
las especificaciones obtenidas en la etapa de diseño, en cada integración de
módulos se comienza en parte con la etapa de pruebas, ya que cada integración
conlleva la necesidad de comprobar que en conjunto los módulos funcionan
correctamente.

17
 Easy POA
2.5.5 Pruebas.
Las pruebas pueden dividirse en dos partes, primeramente el equipo de desarrollo
deberá verificar que las funcionalidades implementadas trabajan de manera
correcta. Posteriormente, al haberse asegurado del buen funcionamiento del
sistema, se deberán realizar pruebas con usuarios finales del sistema para validar
que éste cumple con los requerimientos que inicialmente se establecieron. Durante
esta fase se recabarán sus comentarios sobre lo que se debe mejorar y las fallas
que se detectaron en el uso del sistema.

2.5.6 Liberación
Al concluir la fase de pruebas, el sistema se encuentra listo para su uso. Es por ello
que se entrega junto con la documentación al cliente, misma que servirá de
referencia para los usuarios y el equipo encargado de su administración, operación
y mantenimiento.

18
 Easy POA

Capítulo III Herramientas

Las herramientas de software nos ayudan a facilitar, optimizar y mejorar el
desempeño de la construcción del proyecto. A continuación se describirán las
herramientas que se utilizaran en el desarrollo del sistema:

3.1 Jira

La herramienta que utilizaremos será Jira ya que nos permitirá crear una hoja de
ruta asociada a cada proyecto. Esta hoja de ruta permite a los equipos definir la
visión a largo plazo de su trabajo, así como seguir y compartir el progreso de la hoja
de ruta.

3.2 GitHuB

Utilizaremos github para subir el repositorio de código para almacenarlo y tener un control
de versiones.

19
 Easy POA

3.3 Testim

Aprovecha el aprendizaje automático para la

creación, ejecución y mantenimiento de casos de prueba automatizados. Uso de
localizadores dinámicos y aprendizaje con cada ejecución.

20
 Easy POA

3.4 Sonarqube
Es software libre y usa diversas herramientas de
análisis estático de código fuente como Checkstyle, PMD o FindBugs para obtener
métricas que pueden ayudar a mejorar la calidad del código de un programa.

3.5 Jest
Fue diseñado con un enfoque en la simplicidad y el soporte para grandes
aplicaciones web. Funciona con proyectos que utilizan Babel, TypeScript, Node.js,
React, Angular, Vue.js y Svelte. Jest es una herramienta que nos ayuda a
automatizar nuestras pruebas. El entender el problema, es el 80% de la solución.

21
 Easy POA

Capítulo IV Metodología

4.1 Scrum
Para el desarrollo del presente proyecto utilizaremos Scrum que es un marco que
permite el trabajo colaborativo entre equipos. Al igual que un equipo de rugby (de
donde proviene su nombre) cuando entrena para un gran partido, scrum anima a los
equipos a aprender a través de las experiencias, a autoorganizarse mientras aborda
un problema y a reflexionar sobre sus victorias y derrotas para mejorar
continuamente.

Esta metodología, nos ayudará a agilizar el trabajo en equipo, utilizaremos los sprint
en un período de tiempo determinado el cual será semanalmente donde se realizará
todo el trabajo necesario para alcanzar las metas propuestas en la semana que se
esté cursando.

Para lo cual se utilizará la herramienta de jira para agilizar la asignación de

actividades y el control de las mismas como lo son actividades pendientes, en curso
y terminadas, al igual que las reuniones ya previamente planeadas.

4.2 SRS
Utilizaremos el documento SRS el cual nos ayudará a dar una descripción completa
de la aplicación web, donde se incluirá su propósito, las características, parámetros
clave de rendimiento y comportamiento. Como tal, esencialmente sirve como un
mapa que guía el proceso de desarrollo y mantiene a todos en el camino correcto.

Contiene requisitos funcionales y no funcionales. Los requisitos funcionales

describen la función de un sistema de software y sus componentes (como la reserva
previa de libros al describir un sistema de bibliotecas universitarias), mientras que
los requisitos no funcionales describen las características de rendimiento del
sistema de software y sus componentes (como la seguridad o la disponibilidad de
servicios).

En la siguiente URL se podrán encontrar el SRS correspondientes al presente

proyecto.

https://docs.google.com/document/d/1ppvLa6DLpsy775ZTkFqIjIGV5X42-8jwaOj37h
0OQtU/edit

22
 Easy POA

4.3 Historia de usuario

Se crearán historias de usuario como una explicación informal de una función de
software. Se realizan en base a los requisitos recabados en las reuniones
correspondientes con el cliente.

En la siguiente URL se podrán encontrar las historias de usuario correspondientes al

presente proyecto.

https://docs.google.com/document/d/18yT7h1iZQ6IZyQFXfKv9jDmtBgEVdJNzFxUz
EGUXq2g/edit

4.4 Sprint
Se utilizará el sprint que es un período breve de tiempo fijo en el que el equipo de
scrum trabaja para completar una cantidad de trabajo establecida. Los sprints se
encuentran en el corazón de las metodologías scrum y ágil, y hacer bien los sprints
ayudará al equipo ágil a lanzar mejor software con menos quebraderos de cabeza.

4.4.1 Sprints

Se crearon 5 sprints que iniciaron desde el 1 de noviembre hasta el 6 de diciembre.

23
 Easy POA
4.4.2 Lista de tareas de la iteración (Sprint Backlog)

En cada sprint se le asignó una actividad a cada miembro del equipo las cuales se
muestran a continuación.

4.4.2.1 Primer Sprint

4.4.2.2 Segundo Sprint

4.4.2.3 Tercero Sprint

4.4.2.4 Cuarto Sprint

4.4.2.5 Quinto Sprint

24
 Easy POA
4.4.3 El tablero de tareas (Scrum Taskboard)

4.5 PSP
El PSP es un conjunto de prácticas disciplinarias para la gestión del tiempo no
servirá porque no permite trabajar con cualquier lenguaje de programación y
metodología de diseño y contempla la mayoría de los aspectos de los trabajos de
desarrollo de software, la productividad personal de los programadores o ingenieros
de software mejorará, los defectos antes cometidos serán minimizados o eliminados
esto debido a su registro constante, las estimaciones serán más certeras pudiendo
cumplir con las fechas prometidas al líder de proyecto, mediante el seguimiento del
desempeño predicho frente al desempeño real.

En la siguiente URL podemos encontrar el PSP personal de cada miembro del

equipo.

https://docs.google.com/document/d/1fiUa9jPWwRFpAsWMU9J9D_TLPAg4xchc5U
45qmXlxBg/edit

25
 Easy POA

Capítulo V Arquitectura de software

5.1 Modelo de vistas 4+1
5.1.1 Vista Lógica:
En esta vista se representa la funcionalidad que el sistema proporcionará a los usuarios
finales.

5.1.1.1 Diagrama de clases

5.1.1.2 Diagrama de Secuencia

5.1.2 Vista de Despliegue:

En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de
la gestión del software. Cómo está dividido el sistema software en componentes y las
dependencias que hay entre esos componentes.

A continuación se presentan las diferentes vistas arquitectónicas correspondientes al diseño

del software.

5.1.2.1 Diagrama de componentes

5.1.3 Vista de Procesos:

En esta vista se muestran los procesos que hay en el sistema y la forma en la que se
comunican estos procesos; es decir, se representa desde la perspectiva de un integrador de
sistemas, el flujo de trabajo paso a paso de negocio y operacionales de los componentes
que conforman el sistema. Para completar la documentación de esta vista se puede incluir
el diagrama de actividad de UML.

5.1.3.1 Diagrama de actividad

5.1.4 Vista Física:

En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los
componentes físicos del sistema así como las conexiones físicas entre esos componentes
que conforman la solución (incluyendo los servicios).

26
 Easy POA
5.1.4.1 Diagrama de despliegue

5.1.5 “+1” Vista de Escenarios:

Esta vista va a ser representada por los casos de uso software y va a tener la función de
unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver
cómo se van ligando las otras 4 vistas.

27
 Easy POA
5.1.5.1 Diagrama de casos de uso

28
 Easy POA
5.1.5.2 Diagrama Entidad-Relación

5.2 Arquitectura cliente servidor

La arquitectura cliente-servidor es un modelo de diseño de software. Acá, las tareas
se reparten entre los proveedores de recursos o servicios, llamados servidores, y los
demandantes, llamados clientes.

29
 Easy POA

5.3 Arquitectura MVC

La arquitectura Modelo Vista Controlador es ocupado, que separa los datos y
principalmente lo que es la lógica de negocio de una aplicación de su
representación, el módulo encargado de gestionar los eventos y las comunicaciones

30
 Easy POA

Capítulo VI Patrones arquitectónicos

6.1 Maestro-esclavo
Este patrón consiste en dos partes; maestro y esclavos. El componente maestro
distribuye el trabajo entre componentes esclavos idénticos y calcula el resultado
final de los resultados que devuelven los esclavos.

6.2 Patrones de diseño

6.2.1 Creacional

Este tipo de patrones nos ayudan a crear instancias de objetos.

6.2.1.1Factory Method

Es un patrón de diseño creacional que proporciona una interfaz para crear objetos
en una superclase, mientras permite a las subclases alterar el tipo de objetos que se
crearán.

Al momento de que los usuarios ingresen a la aplicación web ellos mismos crearan diversos
objetos que a medida que avance el proceso estos mismo serán modificados por los
mismos y así nos permite tener un mejor manejo de la información

6.2.1.2 Patrón Constructor

Nos permite crear objetos en base a una clase. Es común en lenguajes de

programación orientados a objetos.
En javascript con ECMAScript 6 podemos aplicar este patrón con la palabra
reservada new. De esta manera podemos crear nuevas instancias de un objeto las
cuales tendrán las propiedades y funciones de la clase que estamos instanciando.

6.2.1.3 Patrón Constructor con prototipo

Difiere del patrón constructor anterior en que los métodos o propiedades que
asignemos al prototipo no se copiarán en los objetos que se instancian. Es decir los
métodos y propiedades se compartirán entre todas las instancias.

Una ventaja del patrón prototipo es que utiliza menos espacio en memoria.

6.2.1.4 Patrón Módulo

Se basa en los objetos literales de javascript ({}). Cada vez que definimos un objeto
con sus propiedades y métodos, estamos definiendo un módulo.

31
 Easy POA
6.2.1.5 Patrón Módulo Revelador

El patrón módulo revelador tiene una API pública y privada a diferencia del patrón
módulo en el que todo es público.

No utilizaremos la sintaxis ({}) de objetos literales para definir un módulo si no que lo

haremos con una función ejecutada inmediatamente (IIFE).

6.2.1.6 Patrón Prototipo

Se basa en que en base a un objeto definido podemos crear prototipos para otros
objetos. Con esto se elimina la duplicidad de código.

6.2.2 Estructural

Basados en la idea de construir bloques de objetos.

6.2.2.1 Bridge

Es un patrón de diseño estructural que te permite dividir una clase grande, o un

grupo de clases estrechamente relacionadas, en dos jerarquías separadas
(abstracción e implementación) que pueden desarrollarse independientemente la
una de la otra.

6.2.2.2 Patrón Mixin

Ayuda a añadir funcionalidades a una clase existente sin tener que alterar la clase.

6.2.2.3 Patrón Decorador

El patrón Decorador es similar al patrón Mixin salvo que en lugar de agregar

funcionalidades al prototipo lo hace con las instancias de clase.

6.2.3 Comportamiento

Nos ayudan a desacoplar el código para facilitar su mantenimiento.

6.2.3.1 Chain of Responsibility

Es un patrón de diseño de comportamiento que te permite pasar solicitudes a lo

largo de una cadena de manejadores. Al recibir una solicitud, cada manejador
decide si la procesa o si la pasa al siguiente manejador de la cadena.

32
 Easy POA
6.2.3.2 Patrón Observador

También conocido como publish/subscribe es una manera de comunicar dos

objetos. El objeto subscribe estará a la escucha de eventos y el otro objeto publish
será el que dispare dichos eventos.

6.2.3.3 Patrón Cadena de Responsabilidad

Nos permite encapsular un dato y agregar métodos que podemos ejecutar de forma
encadenada para modificar el estado o valor del dato.

6.2.3.4 Patrón Iterador

Nos proporciona una forma sencilla de acceder a los valores de una colección. Este
patrón nos ofrece el método next para acceder al siguiente valor de una colección.
Si hemos acabado de iterar nos lo indicará mediante la propiedad done.

33
 Easy POA

Capítulo VII Diseño de interfaces

A continuación se mostrarán los mockups propuestos para la aplicación web.

34
Easy POA

35
Easy POA

36
 Easy POA

Capítulo VIII Pruebas

La prueba de software es el proceso de evaluar y verificar que un producto o
aplicación de software hace lo que se supone que debe hacer. Los beneficios de las
pruebas incluyen la prevención de errores, la reducción de los costos de desarrollo y
la mejora del rendimiento.

8.1 Pruebas a realizar

● Pruebas de unidad: Valida que cada unidad de software funcione según lo
esperado. Una unidad es el componente de prueba más pequeño de una
aplicación.

● Pruebas de humo: Smoke testing en inglés, son una revisión rápida de un

producto de software para comprobar que funciona y no tiene defectos
evidentes que interrumpan la operación básica del mismo. Es una evaluación
inicial de la calidad previo a una recepción formal, ya sea al equipo de
pruebas o al usuario final.

● Pruebas de carga: Consisten en simular una serie de accesos sobre un

software y medir el resultado, estas pruebas se realizan bajo demanda
esperada y también en condiciones de sobrecarga. Ayudan a identificar la
máxima capacidad operativa de un software, identificando cuellos de botella y
las causas de posible degradación del desempeño o servicio.

● Pruebas de seguridad: Consiste en probar las características de seguridad,

si es seguro, si puede ser vulnerado, si existe control por medio de cuentas
de usuario y si son adecuados esos controles.

● Pruebas funcionales: Este tipo de pruebas se llevan a cabo mediante el

diseño de modelos de prueba que buscan evaluar cada una de las opciones
del software, son pruebas específicas, concretas y exhaustivas para verificar
y validar que el software hace lo que debe y sobre todo, para lo que se ha
especificado.

● Pruebas no funcionales:Se enfocan en validar que un software cumple con

los atributos de calidad, es decir, la forma en que funciona y no por medio de
comportamientos específicos. No realizar estas pruebas puede ocasionar
problemas graves y potencialmente catastróficos como lentitud, falta de
coordinación entre herramientas de terceros, bloqueos de BBDD y otros. Son
sumamente costosas, es necesario evaluar los riesgos antes de comprometer
los recursos previstos, pero siempre vamos a tener un ROI que hará que la
inversión merezca la pena.

37
 Easy POA
● Pruebas estáticas: Son el tipo de pruebas que se realizan sin ejecutar el
código, puede referirse a la revisión de documentos y se pueden realizar
"pruebas de escritorio" con el objetivo de seguir los flujos del software. Se
utilizan para comprobar si hay defectos en el rendimiento del software y
generalmente se realizan para evitar errores en una etapa temprana de su
desarrollo.

● Pruebas manuales: Son ejecutadas directamente por uno o más testers,

simulando las acciones del usuario final.

Estas pruebas son indispensables para cada proyecto, ya que por medio de
ellas se detectan la mayor parte de los defectos, y de esta forma se logra
estabilizar el sistema que se está probando. Debemos considerar que:

○ La repetición de pruebas manuales podría dejar pasar defectos.

○ Las pruebas de regresión manuales pueden llegar a consumir mayor

tiempo que las automatizadas.

○ Es necesario incluir pruebas de regresión cuando se está haciendo

una actualización o ampliación de la funcionalidad del software.

○ Las pruebas manuales permiten un análisis profundo por parte de un

humano, son muy recomendables cuando se quiere mejorar la
experiencia de usuario.

8.2 Versión del producto a probar

1.0

8.3 Hardware usado para las pruebas

● HP Laptop 14 Windows 11 Home Single Language

8.4 Ambiente de prueba

●

38
 Easy POA

8.5 Evidencia de pruebas

En el siguiente link podremos encontrar el documento

https://docs.google.com/spreadsheets/d/1s3se_RFL_1UabpR1aVYWJwBtpwjFXMM
O/edit#gid=16411318

39
 Easy POA

Capítulo IX Conclusiones
Se desarrolló una base de datos mejorando la calidad de trabajo en distintas áreas para
realizar anteproyectos presupuestales de manera remota, eliminando el proceso de papeleo
casi en su totalidad, además de automatizar los procesos de compras de productos
pertenecientes a las requisiciones de cada área, compartiendo información al departamento
de inventarios, teniendo el control de la altas y bajas de equipos o productos que estén en
estado activo o inactivo.

40
 Easy POA

Referencias

García, J. (n.d.). Plantilla Memoria DE Estadia SP 2022 - UNIVERSIDAD TECNOLÓGICA

DEL VALLE DE TOLUCA ####### DIRECCIÓN. StuDocu. Retrieved October 24,

2022, from

https://www.studocu.com/es-mx/document/universidad-tecnologica-del-valle-de-toluc

a/ingenieria-de-proyectos/plantilla-memoria-de-estadia-sp-2022/23433876

Ingeniería de software: Qué es, Objetivos y Funciones. (2021, April 6). UNIR México.

Retrieved November 4, 2022, from

https://mexico.unir.net/ingenieria/noticias/ingenieria-de-software-que-es-objetivos/

Ingeniería en Software- UPPachuca. (n.d.). Universidad Politécnica de Pachuca. Retrieved

November 4, 2022, from https://www.upp.edu.mx/ofertaeducativa/ing-software.php

Las 10 Bases de Datos más Populares – Octubre 2022 – Blog Nube Colectiva. (2022,

October 31). Blog Nube Colectiva. Retrieved November 5, 2022, from

https://blog.nubecolectiva.com/las-10-bases-de-datos-mas-populares-octubre-2022/

Lenguaje de Programación. (n.d.). Concepto. Retrieved November 5, 2022, from

https://concepto.de/lenguaje-de-programacion/

Matla Cruz, E. (2014). Tesis. TESIS: DESARROLLO DE SOFTWARE GUIADO POR LA

NORMA ISO/IEC 29110 y SCRUM: SIDEP V.2 .0. Retrieved November 4, 2022, from

http://132.248.9.195/ptd2014/enero/0707739/0707739.pdf

Patrones de diseño en JavaScript y Node JS. (2020, August 21). devseo. Retrieved

November 7, 2022, from

https://devseo.xyz/patrones-diseno-javascript-node/#Patrones_de_comportamiento

Qué es una base de datos. (n.d.). Oracle. Retrieved November 5, 2022, from

https://www.oracle.com/mx/database/what-is-database/

41
 Easy POA
Universidades, S. (2020, December 21). Metodologías de desarrollo software | Blog Becas

Santander. Becas Santander. Retrieved November 5, 2022, from

https://www.becas-santander.com/es/blog/metodologias-desarrollo-software.html

42