Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Edicion Memoria

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 49

MEMORIA DE ESTADÍA

PARA OBTENER EL TÍ TULO DE

INGENIERO
EN DESARROLLO Y GESTIÓN DE
SOFTWARE
NOMBRE DEL PROYECTO

ELÉCTRICA MEXICANA DE ANTEQUERA, S.A. DE


C.V
PRESENTA

Lucas Jiménez Hellen Guadalupe.

1
MEMORIA DE ESTADÍA
PARA OBTENER EL TÍ TULO DE

ING ENIERO
EN DESARROLLO Y GESTIÓN DE
SOFTWARE
ELÉCTRICA MEXICANA DE ANTEQUERA, S.A. DE
C.V
PRESENTA

Lucas Jiménez Hellen Guadalupe.

ASESOR ACADÉ MICO ASESOR EMPRESARIAL

M.D.G. Alejandro Jesús Mor ales


Pérez Ing. Emmanuel Vásquez Pérez
2
OFICIO DE DICTAMEN

3
AGRADECIMIENTOS

RECONOCIMIENTOS

4
RESUMEN

5
INDICE
Oficio de dictamen ................................................................................................ 3

Agradecimientos ................................................................................................... 4

Reconocimientos .................................................................................................. 5

Resumen ................................................................................................................ 6

6
Índice de Ilustraciones .......................................................................................... 8

Indice de tablas ................................................................................................... 10

I. Descripción de la empresa. .........................................................................


11

1.1 Datos Generales ...................................................................................... 11

1.2. Servicios que Ofrece. ............................................................................... 12

1.3. Antecedentes de la Empresa ................................................................... 13

1.4. Misión ....................................................................................................... 13

1.5. Visión ....................................................................................................... 13

II. DESCRIPCCIÓN DEl proyecto .....................................................................


14

2.1. Planteamiento del Problema .................................................................... 14

2.2. Justificación ..............................................................................................


16

2.2.1. Alcances ............................................................................................ 17

2.3. Objetivos del Proyecto. ............................................................................ 18

2.3.1. General. ............................................................................................. 18

2.4.2. Específicos. ....................................................................................... 18

III. Hipótesis. ................................................................................................... 19

3.1. Variable Dependiente .............................................................................


19

3.2. Variable Independiente ............................................................................ 19

3.3. Descripción .............................................................................................


19 IV.
desarrollo ...................................................................................................
20

4.1. Metodología. ........................................................................................... 20


7
4.2. Marco Teórico. ......................................................................................... 25

V. APLICACIÓN DEL MDR ................................................................................ 35

5.1. Requerimientos categorizados ................................................................. 35

5.2. Especificación de Requerimientos. .......................................................... 36

5.2.1. Especificación de requerimientos funcionales ................................... 36

5.2.2. Especificación de Requerimientos no Funcionales............................ 38

5.3. Cronograma de desarrollo y Priorización de Tareas ................................ 39

5.4. Usuarios del Sistema. .............................................................................. 40

5.4.1. Stakeholders Internos ........................................................................ 40

5.4.2. Stakeholders Externos. ...................................................................... 41

5.5. Descripción de software para el desarrollo del sistema. .......................... 43

5.5.1. Software utilizado en el Desarrollo y Codificación de la Base de datos.


43

5.5.2. Softwares utilizados en el Modelado del sistema. ............................. 43

5.6. Datos del sistema. .................................................................................... 44

5.6.1. Módulos ............................................................................................. 45

Referencias BIBLIOGRAFICAS. ......................................................................... 48

ÍNDICE DE ILUSTRACIONES

Ilustración 1 Localización Eléctrica Mexicana fuente: Google Maps ..................... 12


Ilustración 2 Diagrama de Ishikawa ....................................................................... 15
Ilustración 3 Tablero Kanban.................................... ¡Error! Marcador no definido.

8
INDICE DE TABLAS Tabla 1 Datos Generales de la Empresa......................11
Tabla 2 Requerimientos Funcionales.....................................................................35
Tabla 3 1er Especificación de Requerimientos......................................................36
Tabla 4 2da Especificación de requerimientos.......................................................37
Tabla 5 3ra Especificación de requerimientos.......................................................37
Tabla 6 Especificación de requerimientos no funcionales....................................37
Tabla 7 Especificación de requerimientos no funcionales....................................38
Tabla 8 Especificaciones de Requerimientos no Funcionales...............................39

I. DESCRIPCIÓN DE LA EMPRESA.

9
En el siguiente capítulo se describen aspectos relevantes de la empresa
Eléctrica Mexicana, así como su ubicación y sus antecedentes de como esta, fue
fundada.

1.1 Datos Generales

La empresa Donde se realizaron estadías en el cuatrimestre Enero- Abril 2023


es una empresa socialmente responsable, y que tiene más de 50 años en el
mercado ferretero. A continuación, se muestran los datos principales de la misma.

Datos Generales
Nombre de la empresa:
“ELÉCTRICA MEXICANA DE
ANTEQUERA”

Razón Social: “ELECTRICA MEXICANA DE


ANTEQUERA SA DE CV”

Ubicación: CARRETERA A GUELATAO #100, SAN


FRANCISCO TUTLA, OAXACA, CP.
71242
Sector al que pertenece: Ventas al por mayor de material eléctrico,
de plomería y de construcción.
Tabla 1 Datos Generales de la Empresa

La matriz de Eléctrica Mexicana se encuentra ubicada en la carretera principal a


Guelatao con número 100, San Francisco Tutla Oaxaca con código postal 71242.
10
Cuenta con 3 sucursales ubicadas en distintos puntos de la ciudad los cuales
son:
5 señores, Madero y sucursal centro.

Ilustración 1 Localización Eléctrica Mexicana fuente: Google Maps

1.2. Servicios que Ofrece.

Eléctrica Mexicana es una empresa que ofrece soluciones integrales desde hace
más de 50 años. En esta empresa se pueden encontrar todo el equipo necesario y
las mejores marcas del mercado del ramo ferretero. Además, otorgan asesoría
especializada en instalaciones para construcciones y proyectos, en los cuales se
pone en disposición un extenso catalogo de productos, pues tienen con objetivo
ser los más competitivos en toda la región. Al ser una empresa Socialmente
Responsable, están libres de trabajo infantil. Ofrece las mejores marcas del
mercado y otorgan atención especializada a municipios.

1.3. Antecedentes de la Empresa

(Mexico Patente nº 1, 1969) El 19 de mayo el C.P. Andrés Raúl Ruiz Méndez y


la Sra. Consuelo Susana Robles Arenas fundan la empresa Eléctrica Mexicana de
11
Antequera S.A. de C.V. en la ciudad de Oaxaca, ubicándola en la calle de Fray
Bartolomé de Las Casas N.º 308 en el centro de la ciudad y estableciéndose en el
ramo del material eléctrico, de plomería, construcción e instalación.

Actualmente Eléctrica Mexicana de Antequera S.A. de C.V. cuenta con tres


sucursales, ubicados en puntos estratégicos de la ciudad de Oaxaca: Sucursal 5
Señores, Sucursal Madero, Sucursal Centro. Así mismo, se encuentra posicionada
como uno de los establecimientos en el ramo del material eléctrico, plomería,
construcción e instalación de mayor renombre en el estado, con más de 40 años
de permanencia en el mercado, ofrecemos Soluciones Integrales desde los
cimientos hasta los acabados, contamos con distribuciones de marcas del más
alto nivel como Schneider Electric, Condumex, Acuity Brands por mencionar
algunas.

El Centro de distribución de GRUPO BARETTE se encuentra ubicado en


Carretera a Guelatao #100, San Francisco Tutla, Oaxaca.

1.4. Misión

“Distribuimos productos y servicios de calidad del sector eléctrico y de plomería,


que permita bajo los valores de responsabilidad social tocar vidas”

1.5. Visión

“Ser el referente en el suministro de material eléctrico y de plomería, con una


propuesta de valor diferenciada y que permita mayor competitividad en el estado
de
Oaxaca”

II. DESCRIPCCIÓN DEL PROYECTO

12
En este capítulo trataremos sobre cuáles fueron los principales motivos que nos
llevaron al desarrollo de este proyecto y así poder aportar una mejora en la
empresa asignada a realizar el proyecto para titulación.

2.1. Planteamiento del Problema

Hoy en día la tecnología se ha vuelto parte de la vida rutinaria de muchas


personas, y por ende las empresas u organizaciones se han tenido que ir
modernizando en cada una de sus áreas para que sus tareas puedan realizarse
con más agilidad y llevar un control correcto de sus áreas de trabajo.

El principal problema con el que se enfrentan las empresas es con el correcto


monitoreo de cada uno de sus colaboradores y no tener la seguridad de que estos
son honesto a la hora de chequear su asistencia dentro de sus lugares de trabajo
y por ende implementan filtros adicionales de asistencia. Aunque estos se vuelven
tardados para la recopilación y corroboración entre filtros ya que puede atrasar los
pagos de las nóminas en casos muy extremos.

Otra necesidad que genera este tipo de problemas es el poder brindar incentivos
a los colaboradores que cumplen de manera puntual sus asistencias al lugar de
trabajo ya que no existen filtros de asistencia que muestren a las personas que
cumplen con su horario asignado y que puedan recibir algún beneficio y así ellas
sigan siendo eficaces en su desempeño laboral.

Eléctrica mexicana es una empresa con gran trayectoria en el mercado, con gran
presencia a nivel regional, su experiencia de más de 50 años en el mercado la ha
fortalecido en el sector de ventas, sin embargo, los procesos internos como es el
caso del control de personal, cada vez se ha vuelto un reto mayor, al carecer de
tecnologías que mejoren el control interno del personal, específicamente en las
asistencias.

Cabe mencionar que, al priorizar los procesos de forma manual omitiendo el uso
de herramientas tecnológicas, se produce mayor probabilidad de caer en el error

13
humano es por ello que es necesario implementar dichas mejoras en su control de
asistencias.

Ilustración 2 Diagrama de Ishikawa

2.2. Justificación

Ante la necesidad que presenta la empresa, se toma como tema importante


desarrollar un sistema de control de asistencias, para poder tener control de las
asistencias e inasistencias de los colaboradores.

14
El sistema tiene como tarea poder llevar un control que sea seguro y confiable
de los colaboradores que trabajan en las instalaciones y el cual este no pueda ser
alterado por ningún otro compañero de trabajo. Por tanto, los módulos con los que
contara el sistema ayudarán a que el control se lleve de forma eficaz y de esta
forma facilite el conteo final de asistencias e inasistencias.

Recopilación de datos no seguros.

Se valoró el poder actualizar el sistema con el que cuenta la empresa de control


de asistencias de los colaboradores, para que el usuario que administra estas
tareas pueda tener certeza de que cada persona realiza su registro sin que este
sea manipulado por ninguna otra persona que no sea el mismo.

Control

La información que se ingresa por parte de los colaboradores al entrar a las


instalaciones es con ayuda de un nip y contraseña, así que esta puede ser
manipulada por otro compañero y por ello no es 100% confiable. Derivado de esto
es importante que el nuevo sistema cuente con estándares de normalización, para
que cuando el usuario que recopila datos muestre información detallada y lo mas
confiable posible para que no haya problemas de veracidad.

Para poder concluir podemos decir que el desarrollo del sistema será de gran
ayuda para evitar estos incidentes al igual orden a la hora de extraer la
información de asistencias de los trabajadores.

2.2.1. Alcances

Cuando en un proyecto se definen los alcances, se emplean argumentos para


que este sea optimo a desarrollar durante el ciclo de desarrollo y que con ayuda
de este el producto a entregar sea de calidad y que pueda cumplir con las
necesidades que el cliente pida. También se dan a conocer los puntos hasta
15
donde el proyecto se entregará y que con dichos argumentos planteados entienda
la idea de lo que se pretende entregar y no divague en la idea del producto final.

• Desarrollar un software con el cual se pueda tener un control de asistencias


de cada trabajador y el cual permita agilizar el proceso de recolección de
datos de cada empleado.
• Generar reportes para llevar el control de forma ágil.
• Clasificar a los trabajadores por hora de entrada y días que laboran.

2.2.2. Limitaciones
• El sistema solo será para el control de asistencias.
• El sistema solo podrá instalarse si el ordenador cuenta con los programas
necesarios para su ejecución.
• El sistema Recopilara Información por sucursal.

2.3. Objetivos del Proyecto.

2.3.1. General.

Automatizar el proceso de control de asistencia de empleados de Eléctrica


Mexicana, mediante un sistema de control de registro, que pueda generar reportes
de datos reales y confiables.

2.4.2. Específicos.

16
• Modelar la propuesta de solución que permita sistematizar el proceso
haciendo uso de los estándares UML.
• Validar que la propuesta sea aprobada y realizar pruebas de funcionalidad.
• Analizar la información obtenida, con el objetivo de cubrir la necesidad de
Eléctrica Mexicana.

III. HIPÓTESIS.

La implementación de un sistema en cualquier institución laboral permite tener


un control fácil y automatizado. “Por ello en la Empresa Eléctrica Mexicana se
estima que, con este sistema a nivel departamental en el área de recursos
humanos, optimizara las tareas en un 40%, reduciendo el tiempo de recopilación
de información para poder hacer los pagos de nómina a los colaboradores”.

3.1. Variable Dependiente

Optimizar el proceso de control de asistencias en Eléctrica Mexicana.

3.2. Variable Independiente

17
Optimizar el proceso de recopilación de datos en un 40% para realizar los pagos
nominales.

Aumentar la confiabilidad de las asistencias, a través del acceso biométrico.

Agilizar e incrementar la confiabilidad de la recopilación de datos en el proceso


de toma de asistencia a través de un solo filtro.

3.3. Descripción

Se describe la optimización del sistema, por que con ayuda de este se agilizara
la obtención de datos de asistencia de los empleados ya que al no ser confiable se
tienen que realizar dos filtros de asistencia, uno manual y otro por ingreso de
usuario con NIP y el administrador o encargado de área tiene que corroborar que
ambos filtros coincidan a la hora de recolectar dichos datos y así validar que sean
compatibles para asignar sus pagos de nómina.

IV. DESARROLLO

4.1. Metodología.

Una metodología puede entenderse como una serie de métodos utilizadas para
le buen desarrollo de un proyecto. Es por eso que es importante decidir qué tipo
de metodología enfocar para el proyecto y así poder obtener un resultado
teóricamente válido. Es por ello que analizando los distintos factores que influyen
en el tiempo de entrega y factores de desarrollo del proyecto se tomó la decisión
de implementar la metodología Scrum (Takauchi & Nonaka, 1986)

1. ¿Scrum?

Scrum es una de las metodologías de desarrollo ágil de software que ha sido


reconocidas a nivel mundial, que data desde los años 80 que han sido análisis por

18
Ikujiro Nonaka e Hirotaka Takeuchi, quienes resaltaron el trabajo en equipo y la
autonomía que deben tener para desarrollar productos

(Abrahamsson, Salo, Ronkainen, & Warsta, 2002) sostienen que Scrum


representa un marco de trabajo que se basa en métodos ágiles, cuyo objetivo es el
control permanente del estado actual del software, donde el cliente establece las
prioridades; mientras que el equipo SCRUM se auto organiza a fin de determinar
la mejor forma de entregar los resultados.

2. ¿Qué es Scrum?

Scrum es un proceso en el que se aplican de manera regular un conjunto de


buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final,


priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum
está especialmente indicado para proyectos en entornos complejos, donde se
necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, la flexibilidad
y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando


al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la rotación
alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o

19
cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de
producto. (Albaladejo, 2021)

3. Equipo Scrum (Scrum Team).

3.1. Product Owner

Es responsable de maximizar el valor del producto resultante del trabajo del


equipo de Scrum. La forma en que esto se hace esto puede variar ampliamente
entre organizaciones, equipos Scrum e individuos. El Propietario del Producto
también es responsable de la gestión eficaz de la pila del producto (Product
Backlog), que incluye:

• Desarrollar y comunicar explícitamente el Objetivo del Producto;

• Creación y comunicación clara de elementos de trabajo pendiente del


producto;

• Pedido de artículos de trabajo pendiente del producto;

• Asegurarse de que el trabajo pendiente del producto sea transparente,


visible y comprendido.

El Propietario del Producto puede representar las necesidades de muchas partes


interesadas en el trabajo pendiente del producto. Aquellos que deseen cambiar el
trabajo pendiente del producto pueden hacerlo tratando de negociar con criterio
con el Product Owner. (Schwaber & Sutherland, 2020)

3.2. Scrum Master.

El Scrum Master tiene dos funciones principales dentro del marco de trabajo:
gestionar el proceso Scrum y ayudar a eliminar impedimentos que puedan afectar
a la entrega del producto. Además, se encarga de las labores de mentoring y

20
formación, coaching y de facilitar reuniones y eventos si es necesario. (Scrum:
roles y responsabilidades, 2019)

3.2.1. Responsabilidades.

Gestionar el proceso Scrum: el Scrum Master se encarga de gestionar y


asegurar que el proceso Scrum se lleva a cabo correctamente, así como de
facilitar la ejecución del proceso y sus mecánicas.

Eliminar impedimentos: esta función del Scrum Master indica la necesidad de


ayudar a eliminar progresiva y constantemente impedimentos que van surgiendo
en la organización y que afectan a su capacidad para entregar valor, así como a la
integridad de esta metodología. (Scrum: roles y responsabilidades, 2019)

3.3. Sprint

Los Sprints son el latido del corazón de Scrum, donde las ideas se convierten en
valor. Son eventos de longitud fija de un mes o menos para crear consistencia. Un
nuevo Sprint comienza inmediatamente después de la conclusión del Sprint
anterior.

Durante el Sprint:

• No se hacen cambios que pongan en peligro el Objetivo Sprint;

• La calidad no disminuye;

• El trabajo pendiente del producto se refina según sea necesario;

• El alcance se puede clarificar y renegociar con el Propietario del Producto a


medida que se aprende más.

21
Los Sprints permiten la previsibilidad al garantizar la inspección y adaptación del
progreso hacia un objetivo del Producto, como mínimo, una vez al mes en el
calendario. (Schwaber & Sutherland, 2020, págs. 9,10)

3.3.1. Planificación de Sprint.

(Schwaber & Sutherland, 2020, pág. 8) El Sprint Planning inicia el Sprint


estableciendo el trabajo que se realizará para el mismo. Este plan resultante es
creado por el trabajo colaborativo de todo el equipo de Scrum.

3.4. Scrum diario (Daily Scrum).

(Schwaber & Sutherland, 2020, pág. 9) El propósito del Daily Scrum es


inspeccionar el progreso hacia el Objetivo Sprint y adaptar el Sprint Backlog según
sea necesario, ajustando el próximo trabajo planeado.

3.4.1. Sprint Review.

(Schwaber & Sutherland, 2020, pág. 10) El propósito de la revisión del Sprint es
inspeccionar el resultado del Sprint y determinar futuras adaptaciones. El equipo de Scrum
presenta los resultados de su trabajo a las partes interesadas clave y se discute el progreso
hacia el Objetivo de Producto.
3.4.2. Sprint Retrospective.

El propósito de la retrospectiva Sprint es planificar formas de aumentar la calidad


y la eficacia.

El equipo de Scrum inspecciona cómo fue el último Sprint con respecto a


individuos, interacciones, procesos, herramientas y su definición de Hecho. Los
elementos inspeccionados a menudo varían según el dominio del trabajo. Las
suposiciones que los desviaron se identifican y se exploran sus orígenes.
(Schwaber & Sutherland, 2020, pág. 10)

22
4.2. Marco Teórico.

Es importante definir algunos significados de palabras que pueden ser muy


técnicas para personas que no están muy familiarizadas con los lenguajes de
programación y si se interesan por conocer el como se desarrolla un proyecto es
de suma importancia explicar y desglosar cada una de las herramientas, palabras
técnicas y demás factores que puedan influir para que la persona entienda lo que
sen encuentra en el proyecto.

Como ya se explicó; para entender bien el contexto se proveerá información de


diferentes fuentes bibliográficas que son necesarias utilizar para poder entender el
desarrollo del proyecto, obtenidas de diferentes autores.

1. Sistema

23
La palabra sistema hasta el día de hoy se sigue redefiniendo y no es por que su
significado cambie con constancia, si no por que este cambia dependiendo de la
connotación del contexto en el que se encuentra y por eso tiene muchos
significados.

Cambe mencionar que en este proyecto la palabra sistema se centrara en el


ámbito tecnológico y en el cual se abarcaran distintos parámetros que engloban a
la palabra y los distintos tecnicismos utilizados en el mismo.

1.1. Tipos de sistemas.

Dentro del rubro engloba dos tipos de sistemas los cuales son los sistemas de
información (SI) y las tecnologías de la información (TI) las cuales ambas
engloban los mercados dentro del rubro competitivo y global, estas herramientas
están presentes en todos los tipos de organización, ya sea por su estructura de
tamaño o del campo en el que se especializan con el propósito de fomentar
mejoras en los procesos empresariales.

1.1.1. Sistemas de información (SI).

Este tipo de sistemas están categorizados dentro del sector industrial, comercial
de servicios públicos, privados o sociales y que son desarrolladas en cualquier
nivel dentro de la misma organización.

Para (Laudon, 2004) los SI, de acuerdo al nivel organizativo al cual brindan
servicios, se clasifican en sistemas a nivel operativo, a nivel de conocimiento, a
nivel administrativo y a nivel estratégico. Los primeros apoyan a los gerentes
operativos en el seguimiento de las actividades y transacciones elementales de la
organización como ventas, ingresos, flujo de materiales en una fábrica, entre otras
actividades. El objetivo principal de estos sistemas es dar respuesta a preguntas
de rutina y seguir el flujo de las transacciones.

1.1.2. Sistemas (TI).

24
El papel de los sistemas de información se entiende como enlace para el
intercambio de recursos entre los distintos subsistentes internos de la empresa, y
de estos con el entorno. Así pues, un sistema de información en la empresa debe
servir para captar la información que esta necesite y ponerla, con las
transformaciones necesarias, en poder de aquellos miembros de la empresa que
la requieran bien sea para la toma de decisiones, bien sea para el control
estratégico o para la puesta en practica de las decisiones adoptadas. (Alcamí,
Forés, Puig , & Martínez, 2021)

2. Componentes de los sistemas de información.

(C. J. A., 1999) “para estudiar los componentes de un sistema de información se


hace necesario clasificarlos previamente, de acuerdo a su naturaleza, en dos tipos
(1) componentes físicos, representados por las entidades que forman el sistema
de información, y (2) componentes funcionales, que agrupan una o más entidades
en torno a una función básica del sistema”.

• Físicos

En los sistemas informáticos se pueden tomar dos vertientes las cuales


pueden ser:

Los que están formados por el equipo de cómputo y por los programas de
apoyo que conforman la parte intangible (editores de texto, sistema operativo,
manejos de base de datos).

El subsistema de personal lo constituyen los usuarios del sistema, el


administrador de la base de datos, los operadores, el personal de entrada de
datos y el grupo de desarrollo y soporte (gerentes de procesamientos de datos,
ingenieros de sistemas, analistas y programadores). El número de requisitos
de los miembros de este subsistema depende del tamaño y complejidad del
sistema de información. (Arteaga, 2006)

25
El subsistema programado consiste en los programas de aplicación que
ejecutan el procesamiento en el computador y los procedimientos para realizar
las aplicaciones operativas. Las características de este subsistema dependen
del propósito y tipo de sistema de información. (Arteaga, 2006)

El subsistema de datos está constituido por los elementos de


almacenamiento de datos. Estos elementos pueden ser de dos tipos: (1)
archivos convencionales o (2) bases de datos. El tipo de elemento que se
utilice determina tanto los programas de aplicación como los programas de
apoyo del equipo. Tal es el caso de las bases de datos que requieren el uso de
sistemas de Manejo de Bases de Datos (SMBD). (Arteaga, 2006)

• Funcionales.

(McLeod, 2000) Los subsistemas funcionales se catalogan en función de las


actividades que se realizan en las distintas áreas funcionales (producción,
marketing, contabilidad, etc.) de la empresa.

3. Sistemas Control de asistencia.

Para poder ir contextualizando bien el proyecto es necesario el poder definir que


es un sistema de control y es por ello que a continuación se plasma el contexto de
un sistema.

Según (C. P. I., 2016) Explica que: Las empresas, según art 20 del ET (R.D
Legislativo 2/2015), en el ejercicio de sus facultades de dirección y control podrán
establecer las medidas que consideren oportunas sobre los trabajadores, con la
finalidad de: - Establecer un control de cumplimiento de las funciones y tareas

26
marcadas a los trabajadores, con el fin de velar por el cumplimiento de los
objetivos generales de la empresa y de no ser así, se buscaran los posibles
problemas de funcionamiento y sus casus, para establecer soluciones que
minimicen los mismos y permitan conseguir el cumplimiento de los objetivos.

- Llevar a cabo un control disciplinario, de forma que se compruebe que el


trabajador cumpla con las obligaciones y deberes nacidos de la relación laboral.

- Llevar un control de incidencias laborales que puedan tener implicaciones en la


elaboración de nóminas y en la cotización empresarial, como puede ser procesos
de incapacidad temporal, maternidad, paternidad, vacaciones, huelga, etc.

4. Herramientas de desarrollo.
4.1. Lenguajes de programación.

Según el Autor (Cedillo, 1993, pág. 75), un lenguaje de programación es un


idioma artificial diseñado para expresar computaciones que pueden ser llevadas a
cabo por máquinas como las computadoras. Pueden usarse para crear programas
que controlen el comportamiento físico y lógico de una 49 máquina, para expresar
algoritmos con precisión, o como modo de comunicación humana. Está formado
por un conjunto de símbolos y reglas sintácticas y semánticas que definen su
estructura y el significado de sus elementos y expresiones. Al proceso por el cual
se escribe, se prueba, se depura, se compila y se mantiene el código fuente de un
programa informático se le llama programación.

4.2. C#

27
C# es un lenguaje de programación orientado a componentes, orientado a
objetos. C# proporciona construcciones de lenguaje para admitir directamente
estos conceptos, por lo que se trata de un lenguaje natural en el que crear y usar
componentes de software. Desde su origen, C# ha agregado características para
admitir nuevas cargas de trabajo y prácticas de diseño de software emergentes.
En el fondo, C# es un lenguaje orientado a objetos. Defina los tipos y su
comportamiento. ((B.), 2022)

4.2.1. Características de C#

C# tiene un sistema de tipos unificado. Todos los tipos de C#, incluidos los tipos
primitivos como int y double, se heredan de un único tipo object raíz. Todos los
tipos comparten un conjunto de operaciones comunes. Los valores de cualquier
tipo se pueden almacenar, transportar y operar de forma coherente. ((B.), 2022)

4.2.2. Estructura de C#

Los conceptos organizativos clave de C# son programas, espacios de nombres,


tipos, miembros y ensamblados. Los programas declaran tipos, que contienen
miembros y pueden organizarse en espacios de nombres. Las clases, estructuras
e interfaces son ejemplos de tipos. Los campos, los métodos, las propiedades y
los eventos son ejemplos de miembros. Cuando se compilan programas de C#, se
empaquetan físicamente en ensamblados. Normalmente, los ensamblados tienen
las extensiones de archivo .exe o .dll, en función de si implementan aplicaciones o
bibliotecas, respectivamente. ((B.), 2022)

5. Gestor de Base de Datos

Se trata de un conjunto de programas no visibles al usuario final que se


encargan de la privacidad, la integridad, la seguridad de los datos y la interacción
con el sistema operativo. Proporciona una interfaz entre los datos, los programas
que los manejan y los usuarios finales. (Desarrollo Web, 2007)

5.1. Tipos de SGBD


28
Existes muchos tipos de gestores de base de datos, los cuales se centran en las
distintas necesidades de cada programador y el objetivo de este es poder
administrar de la mejor manera posible las necesidades del cliente, dentro de los
existentes se encuentran:

• Relacional
• Jerárquica
• De red
• Orientada a objetos
• Orientada a documentos

El más común y popular es el modelo de base de datos relacional, en el que los


datos se estructuran en filas de tabla. La ventaja de este modelo radica en la
posibilidad de crear diferentes relaciones entre las filas y presentarlas en
columnas. El procedimiento es diferente al del modelo de base de datos
jerárquico, donde los diferentes datos se organizan en relaciones padre-hijo, en
una estructura similar a la de un árbol. (IONOS Digital Guide, 2020).

5.2. MySQL

Según una nueva Investigación (Qué es MySQL: Características y ventajas,


2022) MySQL es un sistema de gestión de bases de datos que cuenta con una
doble licencia. Por una parte, es de código abierto, pero por otra, cuenta con una
versión comercial gestionada por la compañía Oracle.

5.2.1. Características de MySQL

Este al basarse en código abierto es fácilmente accesible y la inmensa mayoría


de programadores que trabajan en desarrollo web han pasado usar MySQL en
alguno de sus proyectos porque al estar ampliamente extendido cuenta además
con una ingente comunidad que ofrece soporte a otros usuarios.
(OpenWebinars.net, 2022)

29
5.2.2. Arquitectura Cliente y Servidor

MySQL basa su funcionamiento en un modelo cliente y servidor. Es decir,


clientes y servidores se comunican entre sí de manera diferenciada para un mejor
rendimiento. Cada cliente puede hacer consultas a través del sistema de registro
para obtener datos, modificarlos, guardar estos cambios o establecer nuevas
tablas de registros. (OpenWebinars.net, 2022)

5.2.3. Que es la Arquitectura Cliente-Servidor

Una arquitectura Cliente-Servidor tiene dos partes distintas, una es la parte del
servidor y la otra es la parte del cliente o grupo de clientes, donde un servidor
suele ser una pieza muy poderosa de hardware y software. Cierto software
funciona. Actúa como almacén de datos, base de datos o sistema de gestión de
aplicaciones.

En esta arquitectura, el servidor es una máquina que actúa como un almacén de


datos y actúa como un sistema de gestión, por lo que solo los clientes en las
estaciones de trabajo atraen, varios servicios al servidor de datos básicos, que
responde a las solicitudes de las clientes realizadas por una persona.
(Schíaffarino, 2019)

6. Desarrollo del software.


6.1. Ingeniería de Software.

(Bauer, 1972) Es el término que utilizó Fritz Bauer en la primera conferencia


sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN
celebrada en Garmisch (Alemania), en octubre de 1968, previamente había sido
utilizado por el holandés Edsger Dijkstra en su obra The Humble Programmer.

También (Davis, 1968) dijo que esta misma puede definirse según como "la
aplicación inteligente de principios probados, técnicas, lenguajes y herramientas
para la creación y mantenimiento, dentro de un coste razonable, de software que
satisfaga las necesidades de los usuarios".
30
6.1.2. Front end y Back end.

Frontend es la parte de un programa o dispositivo a la que un usuario puede


acceder directamente. Son todas las tecnologías de diseño y desarrollo web que
corren en el navegador y que se encargan de la interactividad con los usuarios.

Backend es la capa de acceso a datos de un software o cualquier dispositivo,


que no es directamente accesible por los usuarios. Además, contiene la lógica de
la aplicación que maneja dichos datos. El Backend también accede al servidor,
que es una aplicación especializada que entiende la forma en la que el navegador
hace solicitudes.

6.1.3. Requerimientos.

Los Requerimientos de Software son las necesidades de los Stakeholders que


requiere que el Sistema deba de cumplir de manera Satisfactoria. Son los que
definen las funciones que el sistema será capaz de realizar, describen las
transformaciones que el sistema realiza sobre las entradas para producir salidas.
(Rodriguez, 2023)

6.1.4. Requerimientos funcionales y no funcionales.

Requerimientos funcionales. - Son declaraciones de los servicios que proveerá


el sistema, de manera en que éste reaccionará en situaciones particulares.

31
Requerimientos no funcionales. - Son restricciones de los servicios o funciones
ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de
desarrollo, estándares, etc. (Sommerville, 2015).

6.1.5. Casos de Uso.

Un caso de uso representa una unidad funcional coherente de un sistema,


subsistema o clase.

En un caso de uso uno o más actores interaccionan con el sistema que realiza
algunas acciones. (Vega, 2010)

Elementos de un modelo de casos de uso:

• Actores
• Casos de uso
• Relaciones
6.1.6. Diagramas UML.

Un diagrama es la representación gráfica de un conjunto de elementos con sus


relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. (Booch, y otros,
2002)

UML incluye los siguientes diagramas:

• Diagrama de casos de uso.


• Diagrama de clases.
• Diagrama de objetos.
• Diagrama de secuencia.
• Diagrama de colaboración

32
V. APLICACIÓN DEL MDR

A continuación, se presenta la herramienta elaborada durante el diseño del


proyecto, el cual permite desarrollar y presentar la correlación entre los objetivos
del proyecto.

5.1. Requerimientos categorizados


Ingeniería de Requerimientos
Requerimientos Funcionales Requerimientos No Funcionales

33
Realizar un sistema para el control de • El sistema hará uso de una
asistencias en la empresa de Eléctrica base de datos relacional para
Mexicana. poder almacenar la información
• El sistema hará el recuento de de cada empleado.
las horas que un trabajador • El sistema contará con un
labora en la empresa. usuario administrador y este
• El usuario administrador podrá dará de alta y baja de usuarios
consultar datos de empleados empleados.
tales como: • El sistema será programado en
o Horas Laboradas, el lenguaje de programación
entrada/ salida. (C#).
o Días Justificados. o • El sistema debe
Retardos. o Total, Hrs. proveer seguridad y
Trabajadas. confiabilidad.
o Hrs. Adelantadas o • El usuario empleado podrá
hacer el registro de su
Identificador. asistencia por medio de
• El usuario empleado registrara sensores biométricos.
datos que permitan ser • El sistema realizara el proceso
visualizados por el administrador de asistencia de forma rápida.
como: • El sistema será claro
o Nombre. y manejable.
o Fecha de • El sistema deberá contar con
Nacimiento. o Sexo. o una tipografía clara y
Domicilio. o Correo. entendible.
o Celular.
• El usuario pondrá la razón o
motivos de sus inasistencias y
estas podrán ser aprobadas por
el administrador.
Tabla 2 Requerimientos Funcionales

5.2. Especificación de Requerimientos.

En este apartado se presenta las tablas que detallan el cómo se comportara el


sistema a desarrollar, mediante los siguientes formatos que harán mas entendible
el funcionamiento del mismo.

5.2.1. Especificación de requerimientos funcionales


Clave ERF001 Fecha 15/03/2023
Requerimiento. Para dar de alta a un nuevo empleado dentro del sistema se
34
deberán capturar sus datos personales.
Modulo. Usuarios Administrador
Descripción de Capacidad Funcional.
los procesos. Debe existir el campo para registro de nuevo empleado y así
poder ingresar los datos con opción de agregar datos
biométricos.
El sistema mediante un formulario permitirá al usuario
administrador dar de alta el registro del nuevo colaborador.
Proceso.
El sistema debe guardar la información capturada del nuevo
colaborador y mostrarla a la hora de ingresar sus entradas y
salidas.
Entrada. Datos del usuario empleado los cuales son:
Nombre,
Fecha de Nacimiento.
Sexo.
Domicilio.
Correo.
Celular.
Salida. Listado de los usuarios registrados en el sistema.
Tabla 3 1er Especificación de Requerimientos.
Clave ERF002 Fecha 15/03/2023
Requerimiento. El sistema debe permitir que el usuario administrador pueda
visualizar los días que el usuario empleado no asista a laborar
o llegue con retardos.
Modulo. Inasistencias
Descripción de Capacidad Funcional.
los procesos. El sistema listara las faltas que el usuario empleado pueda
justificar su inasistencia y también los días que no laboro.
Proceso.
El sistema debe guardar la información de los días que el
usuario empleado no se registró en el sistema. Y cuales
fueron los que llego tarde a laborar.
Entrada. Adjuntar justificaciones.
Salida. Listado del día donde muestre al personal que no laboro.
Tabla 4 2da Especificación de requerimientos.

Clave ERF 003 Fecha 15/03/2023


Requerimiento. Validar que el empleado registre su ingreso en el sistema
mediante su huelle dactilar.

35
Modulo. Asistencias
Descripción de Capacidad Funcional.
los procesos. el sistema debe permitir que registrar la asistencia del
personal mediante un lector Biométrico o NIP para registrar su
horario de entrada y salida.
Proceso.
el sistema permitirá visualizar la asistencia diaria del personal
y debe permitir verificar las asistencias del día.
Entrada. Permitir que el personal ingrese con un lector Biométrico o NIP
según prefiera el empleado
Salida. Hora de entrada y salida de cada empleado que laboro en el
día.
Tabla 5 3ra Especificación de requerimientos.

Clave ERNF0001 Fecha 15/03/2023


Requerimiento. El sistema debe permitir generar un reporte de asistencias
de los empleados.
Modulo. Reportes
Descripción de Capacidad Funcional.
los procesos. Debe existir la opción de poder generar y consultar reportes
de asistencia de los empleados Proceso.
El sistema debe guardar y procesar información de forma
rápida e independiente de la cantidad de asistencias
registradas.

Entrada. Fecha y Hora


Salida. Reporte de asistencias por semana
Tabla 6 4ta Especificación de requerimientos

5.2.2. Especificación de Requerimientos no Funcionales


Clave ERNF0001 Fecha 15/03/2023
Requerimiento. El sistema hará uso de una base de datos relacional la cual
almacenará la información de cada uno de los colaboradores
de Eléctrica Mexicana.
Modulo.
Descripción de Capacidad Funcional.
los procesos. El usuario administrador debe tener acceso a todos los
módulos del sistema para poder visualizar las actividades que
registra cada colaborador del área de trabajo.
Proceso.
El sistema permitirá la visualización y el acceso de cada
36
modulo con todos los privilegios al usuario administrador.
Entrada. Agregar/ modificar personal. Modificar la información y
visualizar las asistencias e inasistencias de los mismos.
Salida. Listado de asistencias e inasistencias del personal.
Tabla 7 Especificación de requerimientos no funcionales

Clave ERNF0002 Fecha 15/03/2023


Requerimiento. El sistema será realizado en el lenguaje de programación C#
Modulo.
Descripción de Capacidad Funcional.
los procesos.
Proceso.
El sistema debe programarse en ele lenguaje C# y así
poder establecer una conexión favorable entre el servidor y
las interfaces.
Entrada. Peticiones al servidor.
Salida. Mostrar las peticiones por interfaz de usuario.
Tabla 8 Especificación de requerimientos no funcionales.
Clave ERNF0003 Fecha 15/03/2023
Requerimiento. El sistema debe ser confiable
Modulo.
Descripción de Capacidad Funcional.
los procesos. El sistema debe ser confiable a la hora de recolectar los
datos de cada empleado gracias a su sistema de huella
Dactilar.
Proceso.
El sistema tiene que funcionar correctamente con el sensor
Biométrico para que la veracidad, del empleado que se
registra sea el mismo de los datos ingresados.
Entrada. Datos de usuarios, y del centro donde labora
Salida. Datos confiables de cada empleado.
Tabla 9 Especificaciones de Requerimientos no Funcionales

5.3. Cronograma de desarrollo y Priorización de Tareas

Con ayuda de las herramientas Kanban, los equipos tienen una forma de
visualizar el trabajo que avanza por etapas hasta que se finaliza. Es por ello que

37
en este proyecto se hizo uso de esa misma herramienta, para priorizar actividades
que están en proceso de realizar hasta las ya finalizadas.

Ilustración 3 Tablero Kanba

5.4. Usuarios del Sistema.

En este capítulo se encontrarán listados por los usuarios del sistema quienes se
distinguen por ser las personas que conectan al sistema y así poder hacer uso del
mismo, al igual de los servidores que este les pudiera proporcionar.

5.4.1. Stakeholders Internos


Stakeholders Internos
Desarrollador del Sistema: Lucas Jiménez Hellen Guadalupe
Fases Actividades a realizar

38
Análisis • Selección de técnica para recolección de información.
• Aplicación de la técnica de recolección de información.
• Identificación de necesidades o problema a resolver.
• Enlistado de los requerimientos.
• Especificación de requerimientos funcionales y no
funcionales.
• Modelado de la base de datos.
• Aplicación de los estándares a la base de datos.
• Estudios de costos.
Diseño • Diseño arquitectónico del sistema a partir del listamiento
de los requerimientos funcionales/ no funcionales.
• Prototipos de prueba.
• Prototipos modificados y aprobados.
• Verificación que el producto final funcione
correctamente.
Codificación • Elección del lenguaje en el que se codificara.
• Elección del entorno de desarrollo.
• Diseño y creación de los diagramas Entidad-Relación.
• Creación de interfaces del sistema.
• Creación de diseño detallado de los procesos a ejecutar.
• Codificación de cada uno de los módulos.
Gestión • Definición de los objetivos del proyecto.
• Creación de la Hipótesis.
• Cronograma de actividades. (Priorización de tareas.)
• Listado de requerimientos y listarlos por entrega o tipo de
urgencias.
• Elección de la metodología para gestionar el proyecto.
• Aprobación del desarrollo del proyecto a cargo de la
empresa.
• Planificación de las tareas.
• Reportes de avances del proyecto.

• Evaluación de Objetivos e Hipótesis.

• Conclusiones

• Entrega del producto


Tabla 10 Stakeholders internos (Creación propia)

5.4.2. Stakeholders Externos.


39
Tipo Usuario Empleado Puesto Personal que
labora dentro de la
empresa.
Información del desarrollo del • Inicio
sistema durante cada fase de los Aplicación de técnica de recolección de
sprint a desarrollar información.
o Observación •
Planificación. o No
aplica.
• Diseño
o Propuesta de
prototipo
• Pruebas o No aplica.
• Entrega
o Manual de
usuario.
o Demostración de
usabilidad.

Funciones del Sistema. • Acceso al sistema.


• Registro de asistencias
• Registro de justificación de
inasistencias.
• Ver faltas
• Ver asistencias
• Ver faltas y retardos
Tabla 11 Stakeholders externos del sistema (Usuario empleado)

Tipo Usuario Puesto


Administrador

40
Información del desarrollo del • Inicio o Aplicación de técnica
sistema durante cada fase de los de recolección de
sprint a desarrollar información
(Observación)
• Planificación del proyecto. o
No aplica.
• Diseño o Aprobación de
prototipo.
• Desarrollo o Informe de
avances.
• Pruebas.
o Verificación de
Funcionalidad.
• Entrega o Manual de
usuario.
Funciones del Sistema. • Dar de alta un nuevo
empleado.
• Editar empleado
• Dar de baja a empleados
• Listado de
justificaciones.
• Ver retardos / faltas.
• Configurar hora de
entrada de empleados
• Configurar tolerancia /
límite de entradas y hora
de salida.
• Acceso a reportes de
asistencias del personal
Tabla 12 Stakeholders externos del sistema (Usuario Administrador)

5.5. Descripción de software para el desarrollo del sistema.

En este apartado se justifican los softwares para poder llevar a cabo el desarrollo
del sistema que se esta desarrollando para la empresa Eléctrica Mexicana.

41
5.5.1. Software utilizado en el Desarrollo y Codificación de la Base de
datos.

Lenguaje: C#

Se tomó la decisión de utilizar este lenguaje ya que es moderno, y esta basado


en objetos y también por que está orientado a componentes. Además de que se
orienta a objetos y así este puede permitir al programador desarrollar aplicaciones
solidad y duraderas.

Sistema de gestor de base de datos: MYSQL Workbench

Al permitir modelar la base de datos y poder ejecutarse en diferentes sistemas


operativos como lo son Windows, Linux y Mac OS x, nos permite almacenar datos
de tipos relacionales y listar cada uno de los módulos a desarrollar en tablas bien
estructuradas.

5.5.2. Softwares utilizados en el Modelado del sistema.

Plataforma para los diagramas: ZENFLOWCHART

Es el software en línea más simple para crear diagramas de flujo, mapas


mentales, organigramas, esquemas, pizarras en línea y más. Con una interfaz de
usuario mínima e intuitiva, en la cual se crean diagramas de flujo y diagramas
profesionales.

Se tomó la decisión de usar este software gratuito para poder realizar los
diseños del modelado del sistema y las partes que integran a este sistema, de
forma grafica y así mostrar las funcionalidades del como funcionara el sistema
final.

Herramientas de diseño y prototipo: Adobe XD

42
Es una herramienta de plataforma para diseño, la cual se basa en vectores y
ofrece herramientas para crear experiencias de usuarios mediante la creación de
prototipos que se asemejan a lo que se le entregara al cliente.

Para poder mostrar una idea de lo que puede ser el desarrollo del sistema y el
cómo el usuario podrá navegar dentro del sistema, se utilizo esta herramienta para
poder crear una idea clara al cliente de lo que será el producto entregable.

5.6. Datos del sistema.

En este siguiente punto se detalla más a fondo, el sistema y cada uno de los
módulos que lo componen.

Los módulos se enlistan acorde a las tareas que realizara el usuario en cada uno
de ellos. También las entradas y salidas que se diseñaron acorde a lo que el
sistema registrara en datos y mostrara al usuario.

Para poder entender bien los procesos que realizara el sistema, podemos decir
que las entradas son definidas por todos los datos que la computadora ocupa oara
resolver un problema o en este caso los datos que el usuario brinda al sistema.
Mientras que las salidas son los parámetros o resultados del proceso que realizo
el usuario al ingresar datos.

5.6.1. Módulos

Un modulo se entiende como una porción de un programa a desarrollar. Es por


ello que enseguida se enlistan las tareas a realizar en el proceso de desarrollo del
sistema.
43
Todos los Módulos

Módulos Procesos

Modulo Administrador • Agregar empleados.


• Editar empleados.
• Eliminar empleados.
• Ver empleados
Modulo Reportes • Buscar reportes de la semana
• Buscar reportes por mes
• Imprimir reportes
Modulo Asistencias • Registrar asistencias por
empleado
• Registrar por medio de Huella
dactilar
• Código de Barras
• Consulta de asistencias
Modulo Inasistencias • Generar registro Inasistencias.
• Registro de Justificaciones
• Consulta de inasistencias

5.6.2. Entradas

En este subcapítulo se presentan todas las entradas de datos que forman parte
del sistema, y que permite que se logre la comunicación entre Usuario- Sistema.
Clave Método Nombre Usuario
E1M1 Teclado Registrar Nuevo empleado Administrador
Datos Descripción Codificación o Validación
disposición
Nombre Nombre completo del Nombre, Apellido Entrada de
empleado que se Paterno, Apellido datos
44
desea dar de alta en el Materno. personales
sistema (Obligatorio)
Fecha de Fecha de nacimiento 00-00-0000 Entrada de
Nacimiento para recabar datos
información de cuando personales
nació. (Obligatorio)
Sexo Sexo de la persona Femenino. Entradas de
Masculino. datos
personales
(Obligatorio)
Domicilio Dirección del Colonia + localidad Entrada de
empleado para saber datos de datos
en donde reside personal
(Obligatorio)
Correo Correo que personal texto@texto.com Entrada de
que proporcione a la datos personal
empresa (Obligatorio)
Celular Teléfono personal del 000 000 0000 Entrada de
trabajador datos personal
(Obligatorio)
Tabla 13 Entrada Núm.1 del Módulo 1. Fuente: Elaboración propia

Validación Condición Contingencia


Entrada de datos Se debe verificar que los Mandar alerta de error
Personales (E1M1) datos ingresados solo cuando los campos no
sean letras sean rellenados de forma
correcta
Entrada de datos Se debe verificar que los Mandar alerta de error
Personales (E1M1) datos ingresados cuando los campos no
correspondan a números sean rellenados de forma
correcta
Entrada de datos Se debe verificar que el Mandar alerta “El campo
Personales (E1M1) dato ingresado debe ser requisitado de
corresponda a Masculino/ forma obligatoria”
Femenino
Entrada de datos Se debe de verificar que Mandar el mensaje de
Personales (E1M1) los datos ingresados alerta en caso de no ser
correspondan a letras y rellenado “este campo es
núm. Respectivamente requerido.”
Entrada de datos El sistema debe aceptar Si el campo no esta
45
Personales (E1M1) los datos que el usuario
requerido mandar alerta
registre de “el campo es
necesario”
Entrada de datos Los datos a ingresar Mandar el error de “el
Personales (E1M1) deben corresponder a número de teléfono debe
máximo 11 números contener 10 números
favor de verificar”
Tabla 14 Validación de la E1M1
Clave Método Nombre Usuarios
EIM2 Mouse Seleccionar el usuario que se desea Usuario
verificar sus inasistencias Administrador y
normal
Datos Descripción Codificación o Validación
disposición
Fecha Fecha en que el Día + mes + año Debe desplegar los
empleado tuvo la datos del empleado
incidencia
Hora Hora en la que el 00+00+000 Si aplica debe
empleado llego tarde si mostrar el tiempo que
aplica. el empleado llegó
tarde a laborar
retardos Si el empleado llega 00+00+000 Debe aparecer en
tarde, se registrará en otro color la hora en
el sistema que el empleado
llego tarde.
Nombre En la pantalla debe Nombre + Apellidos Con un filtrado el
mostrar los datos administrador podrá
básicos del empleado ver los retardos de
cualquier empleado
con solo poner su
nombre
Id El administrador tiene 000 Ingresando el ID el
la opción de buscar administrador podrá
con ayuda del ID ver la información del
empleado.

Clave Método Nombre Usuarios

EIM1

Datos Descripción Codificación o Validación


disposición

46
Clave Método Nombre Usuarios

EIM2

Datos Descripción Codificación o Validación


disposición

REFERENCIAS BIBLIOGRAFICAS.

(B.), B. (22 de Septiembre de 2022). Microsoft Learn. Obtenido de Microsoft Learn:


https://learn.microsoft.com/es-es/dotnet/csharp/tour-of-csharp/

Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile software
development. En Agile software development (pág. 478). Espoo: VTT
Publications.

Albaladejo, X. (20 de Septiembre de 2021). Qué es SCRUM. Obtenido de


Proyectos
Ágiles: https://proyectosagiles.org/que-es-scrum/

Alcamí, R. L., Forés, J. B., Puig , D. A., & Martínez, C. L. (2021). Introducción a la
gestión de sistemas de información en las empresas (2ª edición). En
Introducción a la gestión de sistemas de información en las empresas (2ª
edición) (pág. 108). españa: Publicacions de la Universitat Jaume I.servei.

47
Arteaga, G. y. (2006). Sistema de información bajo plataforma Web para el control
de. Obtenido de Tesis : https://virtual.urbe.edu/tesispub/0093361/cap02.pdf

Bauer, F. L. (1972). Procesamiento Informatico. Garmisch (Alemania): OTAN.

Booch, G., Rumbaugh, Jacobson, Molina, Martínez, & Sánchez. (2002). UML.
Addison Wesley.

C., J. A. (1999). Desarrollo de sistemas de información. En J. A. C., Desarrollo de


sistemas de información. Los Angeles California: Universidad de los
Angeles.

C., P. I. (2016). “Gestión auxiliar de personal. ADGG0308”. España: IC Editorial.

C.V., M. d. (1969). Mexico Patente nº 1.

Cedillo, I. W. (1993). Programación en lenguajes estructurados (1 ed.).


Recuperado el 30 de 01 de 2023

Davis, A. M. (1968). Ingenieria de Software. Alemania: Comité de Ciencia de la


OTAN.

Desarrollo Web. (31 de Julio de 2007). Obtenido de Sistemas gestores de bases


de datos: https://desarrolloweb.com/articulos/sistemas-gestores-
basesdatos.html

IONOS Digital Guide. (12 de Myo de 2020). Obtenido de Introducción al sistema


gestor de base de datos (SGBD):
https://www.ionos.mx/digitalguide/hosting/cuestiones-tecnicas/
sistemagestor-de-base-de-datos-sgbd/

Laudon, K. C. (2004). Sistemas de Información Gerencial. México: Octava Edición.


Prentice Hall Latinoamericana, S.A.

McLeod. (2000). Sistemas de Información. California.

48
OpenWebinars.net. (3 de Noviembre de 2022). Obtenido de Qué es MySQL:
Características y ventajas: https://openwebinars.net/blog/que-es-mysql/

OpenWebinars.net. (3 de Noviembre de 2022). Obtenido de Qué es MySQL:


Características y ventajas: https://openwebinars.net/blog/que-es-mysql/

Rodriguez, G. G. (31 de enero de 2023). Técnicas efectivas para la toma de


requerimientos. Obtenido de Northware:
https://www.northware.mx/blog/tecnicas-efectivas-para-la-toma-
derequerimientos/

Schíaffarino, A. (. (7 de Agosto de 2019). Infranetworking. Obtenido de


https://blog.infranetworking.com/modelo-cliente-servidor/

Schwaber, K., & Sutherland, J. (2020). La Guía Scrum. En K. Schwaber, & J.


Sutherland, La Guía Definitiva de Scrum: Las Reglas del Juego (pág. 7).

Scrum: roles y responsabilidades. (14 de enero de 2019). Obtenido de Deloitte


Spain: https://www2.deloitte.com/es/es/pages/technology/articles/roles-
yresponsabilidades-scrum.html

Sommerville, I. (2015). Requerimientos del Software. castaneda.

Takauchi, H., & Nonaka, I. (1986). The new New Product Development Game.
Harvard Business Review.

Valor, A.-r. y. (2011). Sistema de información como apoyo al departamento de


control escolar en una. Revista Administracion y Finanzas, 6.

Vega, M. (2010). Casos de Uso. Granada.

49

También podría gustarte