Título: <Documento de Especificación Funcional Control de Horas>

Compañía: <Samtel>
Proyecto: <Control de Horas>
Modulo <Administración>
Tipo: <FrontEnd - BackEnd>
Revisiones:

Fecha Versión Autor(es) Comentario Estado Fecha Autorizante

Aprobación
Migración
aplicación Borrador Alberto
Pedro Web Control Alvarez
15/08/2019 0.1 Rivera de Horas

Pedro Rivera
Desarrollador 1
Índice
Introducción ........................................................................................................................................ 3
Alcance del Desarrollo..................................................................................................................... 3
Necesidades de la Empresa ............................................................................................................. 3
Situación Actual............................................................................................................................... 3
Impacto ........................................................................................................................................... 3
Escenarios de Prueba .......................................................................................................................... 3
Análisis................................................................................................................................................. 3
Reglas del Negocio .......................................................................................................................... 3
Diseño de Arquitectura/Entidades/Proyectos .................................................................................... 4
Arquitectura del Proyecto ............................................................................................................... 4
Servicios Requeridos ....................................................................................................................... 4
Modelos............................................................................................................................................... 6
Procesos .............................................................................................................................................. 6
Reportes .............................................................................................................................................. 6
Consideraciones No Funcionales......................................................................................................... 6
Exclusiones del Alcance ....................................................................................................................... 6
Validación Técnica ............................................................................................................................... 6
Observaciones ..................................................................................................................................... 6
Referencias .......................................................................................................................................... 7
Glosario ............................................................................................................................................... 7
Punto de Control, Aprobaciones y/o Firmas ....................................................................................... 7

Pedro Rivera
Desarrollador 2
Introducción
Este documento contiene la definición funcional de la aplicación control de horas, se indicará los
módulos a emigrar, las funcionalidades a tomar en cuenta y las vistas a incluir, al igual que los
servicios requeridos para el funcionamiento del mismo.

Alcance del Desarrollo

Se requiere realizar una interfaz gráfica con las funcionalidades requeridas para la gestión de la
aplicación web “Control de Horas”, al igual que, exponer los servicios necesarios de la aplicación.

Necesidades de la Empresa
Migrar la aplicación “SAMTEL CONTROL” para asegurar la escalabilidad y sostenibilidad del mismo,
igualmente, mejorar la funcionalidad y la interacción usuario – Aplicación.

Situación Actual
La aplicación “SAMTEL CONTROL” presenta una funcionalidad limitada con algunas deficiencias,
debido a la tecnología que fue construida, su escalabilidad es limitada y es poco rentable.

Impacto
El impacto del desarrollo es alto.

Escenarios de Prueba

Detalle del Escenario Observaciones

 Poder Realizar la gestión del control de Se debe poder realizar la misma funcionalidad
horas. existente en la aplicación SAMTEL CONTROL,
con la mejora de la funcionalidad de registrar
los proyectos.

Análisis

Reglas del Negocio

 No puede registrar fechas futuras.
 Solo se podrá registrar fechas pasadas y día actual (Se conserva bloqueo de semanas).

Pedro Rivera
Desarrollador 3
Diseño de Arquitectura/Entidades/Proyectos

Arquitectura del Proyecto

Se plantea el desarrollo en N Capas para la aplicación de Control de horas.

 Capa API (Debe Contener):

o ConfigurationHeaderFilter: Las peticiones deben estar acompañadas de un Header
configurado para no permitir peticiones de otra índole.
o CustomExceptionFilterAttribute: Debe manejar excepciones en caso de peticiones
erróneas o en caso de error para ser interpretadas por el móvil.
o AuthenticateAttribute: Valida que el usuario que está realizando las peticiones, ya
se encuentra logeado.
o AuthorizationAttribute: Valida las autorizaciones atribuidas al usuario que está
realizando la petición.
o Services: Carpeta que contiene las clases de exposición de los servicios (Los
servicios deben ser referenciados por interfaz y no por clases heredadas, de fallar
un servicio, continuara el API arriba) a su vez, deben manejarse versiones de
Servicios v1.0,v1.1 etc.
 Capa Application (Debe Contener):
o ApplicationServices: Carpeta que contiene las clases que heredan la interfaz de los
servicios, estos servicios son los que realizan la persistencia a la BD.
o Interfaces: Carpeta que contiene las interfaces de los servicios expuestos en la
persistencia.
o Model: Carpeta que contiene los modelos y las entidades a utilizar, según las
tablas y los datos requeridos desde la aplicación móvil.
 Capa Infraestructura (Debe Contener):
o En caso que sea necesario, se incluirá encriptación de contraseñas, token de inicio
de sesión etc.
 Capa Persistencia (Debe Contener):
o Carpeta de ORM, internamente todas las clases con los métodos para consumir las
funcionalidades requeridas.
o Carpeta de Scripts (Si se requiere), separar funciones, StoredProcedures,
consultas.
 Capa Resources.

Servicios Requeridos
La nomenclatura de los servicios debe tener la siguiente estructura:

Funcionalidad – Clase (Plural o Singular) – (By) – Parámetro - Parámetros Adicionales.

Ej: getCarsByCarId

Ej: updateCarByCarIdPatente

Ej: createPassengerByCarIdSalesManIdPatente

Pedro Rivera
Desarrollador 4
Cuando son servicios compuestos, deben estar implícita estas clases en el nombre del método:

Ej: getCarUserByUserId. – Obtiene el carro del usuario por el id del usuario, no se debe replicar las
propiedades de la clase, se crea una nueva clase que herede de la otra.

Funcionalidades: Get – Update – Create – Delete.

Nro. Nombre - Parámetro Funcionalidad Validación Retorno Tipo

1 login(user) Iniciar sesión. Debe validar que el Retorna un objeto GET
usuario exista, que tipo user.
no esté inhabilitado,
expiración de sesión.
2 logout(user) Finalizar sesión. Retorna un PUT
RESPONSE.
3 getReportedHoursByUserId(userId) Obtener las horas Retorna un objeto GET
registradas del tipo reportedHour.
mes en curso.
4 getProjectsByDescription(description) Obtener los De no existir, debe Retorna una lista GET
proyectos según la retornar un mensaje de objetos tipo
descripción. indicando “No existe LIST.
el proyecto” – Con la
finalidad de no dejar
esperando al usuario.
5 getStageByProjectId(projectId) Obtiene las etapas De no existir, debe Retorna una lista GET
asociadas al retornar un mensaje de objetos tipo
proyecto. indicando “No existe GENERIC.
el proyecto.
6 createReportHour(reportedHour) Crea un registro Retorna un POST
de reporte de RESPONSE.
hora.
7 getUserProfileByUserId(userId) Obtiene la Retorna un Objeto GET
información tipo UserProfile
relacionada con el
usuario.
8 updatePassword(user) Actualiza la Debe validar que la Retorna un POST
contraseña del contraseña anterior RESPONSE.
usuario coincide con la
contraseña
almacenada en BD.
9 getProjectsByUserId(userId) Obtiene los Retorna una lista GET
proyectos y toda de Objetos de tipo
la información Projects
relacionada según
el id del usuario
10 getStageByTypeProject(typeProject) Obtiene las etapas Retorna una lista GET
según el tipo de de Objetos de tipo
proyecto GENERIC.
11 updateReportHour(reportedHour) Actualiza el Debe permitir Retorna un PUT
reporte de hora cambiar todos los RESPONSE.
modificado aspectos del registro
12 deleteReportByReportId(reportId) Elimina un reporte Retorna un POST
de hora RESPONSE.

Pedro Rivera
Desarrollador 5
*Los modelos RESPONSE y LIST tendrán propiedades fijas que podrán ser utilizadas por varios
servicios que requieren la misma estructura.

Modelos
Nombre Estructura
Response {result, success}
List {Description, Id}
User {Id, Name, LastName, IdentificationNumber,
Email}
Profile {ProfileTypeCode, Role, Position, Manager,
Leader, Supervisor1, Supervisor2, Enabled}
Report {Id, Description, ProjectType, EstimatedHours,
PlannedHours}
Project {ProjectCode, ProjectDescription}

Generic {Id, Description }

Procesos
No aplica

Reportes
No aplica

Consideraciones No Funcionales

Exclusiones del Alcance

 Inicialmente, se estima como alcance la gestión de las horas, consulta de información

basica.

Validación Técnica
No aplica

Observaciones
No aplica

Pedro Rivera
Desarrollador 6
Referencias
No aplica

Glosario
No aplica

Punto de Control, Aprobaciones y/o Firmas

Líder________________________________________

Firma______________________Fecha____________

Líder de Área_________________________________

Firma_______________________Fecha____________

Pedro Rivera
Desarrollador 7