SEMANA

ACTIVIDAD / TAREA
Implementa correctamente tecnologías acordes al patrón/arquitectura de desarrollo (MVC/WEB
API)

La base de datos es completamente funcional teniendo en cuenta los requisitos del proyecto. 
(Relacional, Restricciones, tipo de datos coherentes)

En la base de datos se respeta la integridad referencial de llave primaria, llave foránea (1-1 y/o 1-
N) y llave única.
El sistema de información cumple con las parametrizaciones básicas para cada módulo (CRUD).

Controla la integridad referencial de las llaves foráneas  y muestra los nombres en la vista. 

Se encuentran creadas las vistas, procedimientos almacenados y disparadores requeridos para la

funcionalidad del sistema de información.

Los formularios utilizan la etiqueta readonly para los campos de solo lectura.

Implementación completa de datatables.

En el sistema de información se implementan mensajes para confirmar o denegar acciones
importantes. (Sweet Alert)
El sistema de información cumple con las reglas de negocio(politicas) que se definieron en los
requisitos funcionales
Implementa reglas de negocio mediante el manejo de estados.
Los campos de fecha poseen la validación respectiva para evitar el envío de datos incoherentes en
la base de datos.
El Sistema de Información tiene validaciones  de campos vacíos, tipos de datos, longitud de datos,
formatos, extensión de archivos, peso, etc. (html5, js, css) expresiones regulares.

El sistema de información controla la longitud de los datos evitando desbordamiento en backend

y repositorio.

Presenta la información dinámica y rápidamente sin necesidad de recargas constantes de las

vistas. (Ajax)

Los formularios brindan mensajes de error visibles y específicos. nombreusuario@dominio.co

Controla las excepciones con mensajes coherentes y apropiados al error. 

Presenta bosquejo de reportes parametrizados.

El tiempo de respuesta para realizar funciones y procesos es apropiado  en el sistema de

información realizar.
Las reglas de negocio, condiciones y restricciones implementadas en el Sistema de información,
son coherentes con el "core business" o negocio principal del área donde se fuese a implementar.

Avances del dashboard  teniendo en cuenta los ítems de la pestaña "GUI- FRONTEND- UW" de la
lista de chequeo
Gestión de usuarios completa según lista de chequeo

El sistema de información cumple con las normas de seguridad, validación de roles y tareas.
El sistema de información cumple con la funcionalidad principal(Título) dando solución a la
problemática o necesidad identificada.

La información almacenada es pertinente y coherente con los requisitos del sistema de

información.

Implementación completa de la plantilla para la interfaz gráfica de usuario teniendo en cuenta los
ítems de la pestaña "GUI- FRONTEND- UW" de la lista de chequeo

Genera reportes parametrizados por rango de valores tales como fecha, estado o característica en
particular.

Implementa cargas masivas para entidades o módulos específicos que requieren registrar alto
volumen de datos. 
CHECK - ESTADO

TERMINADO

EN PROCESO

POR HACER
 ACCIONES BÁSICAS - CRUD

C --> CREATE --> INSERCIONES,

REGISTRAR

READ --> CONSULTAR

UPDATE --> ACTUALIZAR O

EDITAR
DELETE --> ELIMINAR
 SITUACIONES A TENER EN CUENTA EN LA CRUD
Cuando la PK de algunas tablas o entidades es autonúmerica, se debe establecer un atributo o campo de la
tabla o entidad que cumpla con el criterio de único para poder controlar la duplicidad de datos en las tablas.

Cuando se insertan datos a tablas que tiene llaves foráneas se debe tener en cuenta que el dato foráneo ya
debe existir en la tabla donde es PK, de lo contrario se generara un error desde la base de datos por
integridad referencial.

Cuando se insertan estos datos o valores de FK se debe tener en cuenta el tipo de relación o cardinalidad de
esa foránea (1-1 o 1-N), si la relación es 1-1, tenga en cuenta que solo se registrará ese valor de foránea una
única vez en la tabla, por ejemplo, usuario -empleado, en empleado estaría la foránea de usuario, por lo
tanto, solo se debe agregar a un solo empleado un único nombre de usuario, sería incorrecto que un mismo
usuario se le puede adicionar a más de un empleado.

Continuando con el punto anterior, si la relación es 1-N, no hay restricción en la foránea donde llega el N, por
ejemplo, usuario -rol , en usuario estaría la foránea de rol, por lo tanto, se puede agregar un mismo rol a más
de un usuario siempre y cuando no haya una politica de la empresa-cliente que determine lo contrario.

Finalmente, en la inserción de datos a tablas con FK, en la GUI, es incorrecto que el usuario ingrese un valor
cualquiera del campo foráneo, debe controlarse dandole al usuario la opción de elegir (lista o combo que este
alimentado desde la propia tabla de la base de datos donde es PK) se sugiere utilizar

Implementar mensajes para que el usuario confirme o deniege la acción antes de registrar.

En algunos casos, datos como fecha no se ingresan por el usuario sino se toman del sistema si es fecha actual.

Implementar validación de formato, tipo de datos y longitud en los campos del formulario para registrar.

Consultas básicas: cuando se consulta toda la información de una tabla o tablas por una unión (inner join)

Consultas con parámetros: cuando se consulta la información teniendo en cuenta un dato especifico por
ejemplo: por estado, por categoría, por rango de fechas
Cuando se muestre en la GUI la información general de la tabla consultada, evaluar en que casos es
conveniente reducir los campos a mostrar según el rol. Por ejemplo, una contraseña no se debe mostrar así
este encriptada.

Al igual que en la acción de registrar, en una modificación de datos, se deben tener en cuenta los campos o
valores a actualizar, generalmente, tienen llaves foráneas y en estos casos se debe cumplir los mismos
aspectos que al registrar.
Evaluar que datos se deben actualizar y cuales no, para estos últimos, se puede dejar en el formulario el
campo de solo lectura(readonly) para que el usuario no modifique nunca esos valores. Por ejemplo, el
número de documento de un empleado o cliente, es un dato que nunca cambia.

Implementar mensajes para que el usuario confirme o deniege la acción antes de actualizar datos
importantes.
Se deben tener argumentos válidos para considerar eliminar un registro de la base de datos, es importante,
recordar que al eliminar un solo registro, se altera la información de varias tablas y eso no es conveniente
para la empresa-cliente.

Se puede manejar el borrado o eliminación únicamente como algo "figurado" en la GUI, por ejemplo, cuando
a un carrito de compras se le elimina un producto que ya no se desea comprar, pero nunca se eliminaría un
producto de una venta ya realizada.
Analizar en que casos es más conveniente actualizar un estado que eliminar un registro completo en la base
de datos.
CHECK