Documento ERS 1

Especificaciones de Requerimientos del SoftwarePara Sistema de Reservación de local

DRASER.

Versión 1.4

Sistema de Reservación de Local (DRASER) Versión: 1.4Especificaciones de Requerimientos del Software Fecha: 09/05/2014RL-ERS

Historia de Revisiones

Fecha Versión Descripción Autor

24/04/2014 1.0 Este documento presenta la visión y planificación del proyecto

Equipo desarrollador

28/04/2014 1.1 Este documento presenta las correcciones de la visión y planificación del proyecto


02/05/2014 1.2 Entrega de documentación Equipo desarrollador

09/05/2014 1.3 Este documento presenta los requerimientos y caso de uso del aplicativo


07/06/2014 1.4 Este documento contiene las correcciones de la versión anterior


1


Tabla de Contenido

1. Introducción 4

1.1 Propósito 4

1.2 Alcance 41.3 Definiciones, Acrónimos y Abreviaturas 41.4 Referencias 4

2. Especificaciones Funcionales 4

3. Casos de Uso 7

3.1 Resumen de Casos de Uso y Actores 73.3 Diagrama de Caso de uso 32

4.1 Usabilidad 33

4.1.1 Fácil Usabilidad 33

4.2 Confiabilidad 33

4.2.1 Disponibilidad 334.2.2 Tiempo de Espera entre Fallas 33El tiempo mínimo entre falla y falla se tiene estipulado para 6 meses. 334.2.3 Recuperabilidad 33Aproximadamente 3 horas. 34

4.3 Desempeño 34

4.3.1 de usuarios 34

Razonablemente el sistema debería tardar 150 milisegundos en cada transacción, lo que se traduce en 10 transacciones cada 1,5 segundo. Soportando a 300 usuarios concurrentemente. 34

4.4 Mantenibilidad 34

4.4.1 Revisión periódica del sistema 34

4.5. Seguridad 34

4.5.1. Seguir los estándares de seguridad de la IEEE 34

4.6. Restricciones de Diseño 34

4.6.1. Seguir el diseño de los sistemas de la DII 34

4.7. Requerimientos de Documentación en Línea y de Sistemas de Ayuda 34

4.8. Componentes Comprados 34

4.9. Interfaces 35

4.9.1 <Interfaces de Usuario> 354.9.2 <Interfaces de Hardware> 35

2


4.9.3 <Interfaces de Software> 354.9.4 <Interfaces de Comunicaciones> 35

4.10 Requerimientos de Licenciamiento 35

4.11 Aspectos Legales, Derecho de Autor y otros Avisos 35

Para el desarrollo del sistema, se planea utilizar herramientas y lenguajes Open Source, de manera que no existan problemas con violaciones de Derecho de Autor. Como lenguaje de programación, la empresa ha seleccionado PHP, y como manejador de bases de datos Postgre SQL, ambos, herramientas de código libre.35

4.12 Estándares Aplicables 35

3


Especificaciones de Requerimientos del Software

1. IntroducciónEl establecimiento “Quinta San Juan” ha iniciado una nueva estrategia en el local y desea construir un sistema de reservación del local online. Dicho aplicativo mostrara a los usuarios información acerca del local como las promociones existentes, facilitando así a las personas al momento de adquirir información o hacer reservaciones.

El propósito principal de este aplicativo será la automatización del reservaciones del local en el establecimiento Quinta San Juan de esta manera se tendrá un mejor control de eventos que se han realizado o están por realizase mejorando a la administración del establecimiento en la gestión del tiempo y control de ingresos.

A demás, mediante las reservaciones que se realicen, los encargados del local (dueño/s) podrán observar dichas reservaciones mediante estadísticas y tendencias para determinar el número de reservaciones que se realizan cada semana, mes o año.

Una de las ideas es que el usuario pueda ingresar a la parte de la página web desde cualquier dispositivo con acceso a internet.

1.1 PropósitoEl propósito de este documento es recolectar, analizar y definir todos los requerimientos funcionales y no funcionales que contendrán el aplicativo, las necesidades de los usuarios y las características del sistema para control de eventos de la empresa.

Dado el papel de este sistema como impulsor de una nueva metodología de reservaciones, se debe tomar en cuenta las mejores prácticas:

1. Desarrollo iterativo del software. 2. Administración de requerimientos 3. Modelación visual del software. 4. Verificación de la calidad del software. 5. Administración y Control de cambios.

Debido a la falta de publicidad de la empresa y de elaboración de todas sus actividades de forma manual además de ser una empresa en crecimiento y necesita de nuevas innovaciones para facilitar todos los procesos y que mejor que realizar el aplicativo web el cual será de gran beneficio en varias áreas de la empresa.

1.2 AlcanceEl alcance de este documento es la Especificación de los Requerimientos de Software para el sistema de reservación de local, tanto funcionales como no funcionales (especificaciones suplementarias), las cuales se encuentran asociadas a todos los Casos de Uso definidos para el mismo.

1.3 Definiciones, Acrónimos y Abreviaturas UGB: Universidad Gerardo Barrios. ERS: Especificación de Requerimientos del Software.

4


RL: Reservación del local

1.4 Referencias

Documento Visión emitido por los estudiantes de la universidad Gerardo Barrios de Usulután

Característica Asociada:

Digitar la url en el navegador

ID requerimiento: RL-01

Nombre del Requerimiento:

Acceder al sitio

Permite digitar la url para acceder al sito.

Atributo: Prioridad(x )Alta ( )Media Alta ( )Media ( )Media Baja ( )Baja


Permite visualizar el sitio luego de digitar la url



Mostrar sitio

Consiste en mostrar el inicio del sitio donde el usuario podrá seleccionar las diferentes opciones.

Atributo: Prioridad(x ) Alta ( ) Media Alta ( ) Media ( ) Media Baja ( ) Baja


Mostrará en el sitio la información general de empresa.



Mostrar información general

Podrá, una vez cargado el sitio mostrar la información general de empresa en la opción inicio que es la primera en aparecer

Atributo: Prioridad( x ) Alta ( ) Media Alta ( ) Media ( ) Media Baja ( ) Baja

Característica Asociada: Mostrar por medio de cuadros


5


Permite la visualización de ofertas y promociones que la empresa posee en un determinado tiempo.

Atributo: Prioridad( ) Alta ( x ) Media Alta ( ) Media ( ) Media Baja ( ) Baja


Permitirá registrar usuarios para que posteriormente puedan reservar el local.



Registrar usuario

El sistema podrá registrar usuarios mediante este registro se podrán hacer reservaciones del local para un evento social.



Permitirá dar acceso al sitio a los usuarios que se han registrado.



Login

El sistema podrá dar acceso a los usuarios que se han registrado.



El usuario podrá enviar una petición al administrador para ser modificado.

ID requerimiento: RL -07


Modificar usuarios

6


El sistema podrá modificar usuarios mediante una petición de este, esta acción solo podrá hacerla el administrador.



el sistema tendrá la facilidad de eliminar usuarios mediante una petición de este



Eliminar usuarios

El administrador podrá eliminar usuarios si estos a si lo desean.



Una vez el usuario registrado podrá hacer reservaciones



Hacer reservación

El aplicativo podrá hacer reservaciones cuando un usuario llene la solicitud, siempre y cuando la fecha para el evento esté disponible



Mediante cuadros de dialogo se le confirmara al usuario si la reservación fue exitosa



Confirmar reservación

7


Permitir al usuario visualizar un cuadro de dialogo confirmándole si la reservación fue exitosa o no.

Atributo: Prioridad( ) Alta ( ) Media Alta ( x ) Media ( ) Media Baja ( ) Baja


Podrá eliminar reservaciones mediante la petición del usuario al administrador



Eliminar reservación

Permitirá eliminar una reservación que el usuario no realizara mediante una petición al administrador



El administrador podrá consultar el historial de reservaciones



Consultar reservación

permitirá consultar todas las reservaciones que se han realizado

Atributo: Prioridad( ) Alta ( ) Media Alta ( ) Media ( x) Media Baja ( ) Baja


El administrador podrá actualizar las promociones que posee la empresa



Actualizar promociones

8


Podrá actualizar las promociones que posee la empresa así no aparecerán las mismas ofertas o promociones.



El administrador podrá administrar el mobiliario que posee



Administrar inventario de mobiliario

Podrá administrar el mobiliario existente y el restante así se tendrá un mejor manejo de este


3. Casos de Uso

3.1 Resumen de Casos de Uso y Actores

Caso de Uso Actor

Acceder al sitio Usuario, sistema

9


Mostrar sitio Usuario, sistema

Mostrar información general Usuario, sistema.

Mostrar ofertas y promociones Usuario, sistema

Registrar usuarios Usuario, sistema

Login Usuario, sistema

Modificar usuarios Usuario, sistema, administrador

Eliminar usuarios Usuario, sistema, administrador

Hacer reservación Usuario, sistema

Confirmar reservación Usuario, sistema

Eliminar reservación Usuario, sistema, administrador

Consultar reservación Sistema, administrador

Actualizar promociones Sistema, administrador

Administrar inventario Sistema, administrador

3.2 Especificaciones de Casos de Uso

Caso de uso: Acceder al sitio

Descripción:

10


Este caso tiene como descripción que al digitar la url en el navegador el sitio deberá cargar y mostrar la información en ella

Requerimiento:

El sistema dará acceso a los usuarios al sitio

Precondición:

Ninguna

FLUJO BASICO:

El usuario introduce la URL en el navegador

ACTOR SISTEMA

1 El usuario introduce la URL del sistema en la barra navegadora

2 El sistema, desde el servidor, atiende al llamado.

FLUJOS ALTERNOS

El usuario introduce los datos erróneos en el sistema; el sistema no valida las credenciales y maneja la excepción con un mensaje gentil, advirtiéndole que ha introducido mal sus datos. Volviendo al estado inicial para la validación.

ACTOR SISTEMA

1 El usuario digita mal la url

2 El sistema no responde.

Poscondición:

Se digito mal la url

No se puede mostrar esta página web

Requerimientos especiales:

Ninguno

Puntos de extensión:

Ninguno

Caso de uso: Mostrar sitio

Descripción:

Este caso tiene como descripción que una vez digitada la url el sitio aparecerá en pantalla.

11


Requerimiento:

El sistema mostrara el sitioPrecondición:

Acceder al sitio

FLUJO BASICO:

El usuario estar activo en el sistema, desea terminar su visita entro del mismo, y va al link adecuado para salir del sistema

ACTOR SISTEMA

1 El usuario va a la va a la url del sitio

2 El sistema muestra el sitio

FLUJOS ALTERNOS

ACTOR SISTEMA

Poscondición:

NingunaRequerimientos especiales:

Ninguna


Ninguno

Caso de uso: Mostrar información general

Descripción:

Este caso tiene como descripción que una vez que el sitio aparezca en pantalla el usuario podrá

12


visualizar la información general de la empresa.

Requerimiento:

El sistema mostrara la información generalPrecondición:

Acceder al sitio

FLUJO BASICO: luego de digitar la url y acceder al sitio, este mostrara la información general.

ACTOR SISTEMA

1 el usuario una vez muestre el sitio esperara hasta que cargue todo el sitio

2 el sistema carga la información general

3 El usuario conocerá la información general de la empresa

Poscondición:

ningunaRequerimientos especiales:

Ninguno


ninguno

Caso de uso: Mostrar ofertas y promociones

Descripción:

Es la acción que tiene como descripción que una vez que le sitio cargue, el usuario podrá visualizar

13


las ofertas y promociones mediante una pestaña.

Requerimiento: verificar erróneos

El sistema mostrara las ofertas y promociones

Precondición:

Acceder al sitio

Mostrar sitio

FLUJO BASICO: permite que el usuario visualice las ofertas y promociones que la empresa posee

ACTOR SISTEMA

1 Dara clic en ofertas y promociones

2 el sistema re direccionará al usuario hacia el formulario de ofertas y promociones

3 La vista de ofertas y promociones aparecerá en pantalla.

Poscondición:


Ninguno


Ninguno

Caso de uso: Registrar usuario

Descripción:

14


Es la acción de registrar usuarios que deseen hacer reservaciones.

Requerimiento:

El sistema podrá registrar usuarios

Precondición:

Acceder al sitio

Mostrar sitio

FLUJO BASICO:

El usuario podrá registrarse en el sitio cuando llene la solicitud de registro de forma correcta y de enviar la información.

ACTOR SISTEMA

1 El usuario ira al menú

2 El sistema mostrara el menú

3 El usuario ira al formulario registrar

4 El sistema mostrara el formulario.

5 El usuario llenara dará clic en el botón registrar

5 El sistema almacenara los datos en la tabla usuarios.

FLUJOS ALTERNOS

Que el usuario no llene correctamente el formulario

ACTOR SISTEMA

1 El usuario llena incorrectamente la solicitud

2 El sistema responde con un cuadro de dialogo notificando el error que el usuario cometió.

Poscondición:

ninguno


Ninguno


Ninguno

Caso de uso: Login

Descripción:

15


Es la acción de que permite dar acceso a los usuarios que se han registrado.

Requerimiento:

El sistema podrá dar acceso a usuarios mediante un login

Precondición:

Acceder al sitio

Mostrar sitio

Registrarse

FLUJO BASICO:

El usuario escribirá su usuario y contraseña para poder hacer reservaciones.

ACTOR SISTEMA

1 El usuario ira a la pestaña login

2 El sistema mostrara los campos de donde se ubicaran los datos de acceso

3 El usuario ingresara los datos

4 El sistema verificara los datos y si son correctos dará acceso si no mostrara un mensaje de error.

FLUJOS ALTERNOS

Ninguno

Poscondición:

ninguno


Ninguno


Ninguno

Caso de uso: Modificar usuario

Descripción:

16


Es la acción de modificar los usuarios que se han agregado a la base de datos esto solo lo podrá hacer el administrador con una petición del usuario.

Requerimiento:

El sistema podrá modificar usuarios.

Precondición:

El usuario debe estar registrado en el sistema.

FLUJO BASICO:

El usuario que desee modificar o actualizar sus datos deberá enviar una petición al administrador para que haga la actualización del registro.

ACTOR SISTEMA

1 el usuario envía la solicitud en la cual notificara que desea modificar su registro

2 El administrador recibe la petición del usuario y hace el cambio deseado y notifica al usuario

3 El usuario recibe la notificación de la modificación solicitada


Ninguno


Ninguno

Caso de uso: Eliminar usuarios

17


Descripción:

Es la acción que eliminar los usuarios que se han agregado a la base de datos esto solo lo `podrá hacer el administrador con una petición del usuario.

Requerimiento: El sistema podrá eliminar usuarios

Precondición:

Debe de hacer usuarios registrados

FLUJO BASICO:

El usuario envía una petición al administrador para ser eliminado del sistema

ACTOR SISTEMA

1 El usuario enviara una petición al administrador para ser eliminado

2 El administrador recibe la petición y elimina al usuario

3 el usuario recibe la notificación que fue eliminado del sistema

FLUJOS ALTERNOS

Ninguno

Poscondición:


Ninguno


Ninguno

Caso de uso: Hacer reservación

18


Descripción:

Es la acción que permite hacer las reservaciones que el usuario desee en las fechas disponibles.

Requerimiento:

El sistema podrá hacer reservaciones

Precondición:

Debe de hacer usuarios registrados

FLUJO BASICO:

El usuario llenara la solicitud en la cual especificara el tipo de evento y fecha de realización del evento

ACTOR SISTEMA

1 El usuario ingresara al formulario de reservación.

2 El sistema mostrara el formulario de reservación.

3 El vera las fechas disponibles

4 El sistema notificara sobre las fechas disponibles o no disponibles.

5 El usuario llenara el formulario y lo enviara

6 El sistema guardara la reservación el la tabla reservaciones

FLUJOS ALTERNOS

El usuario llene erróneamente el formulario

ACTOR SISTEMA

1 El usuario ingresara al formulario de reservación.

2 El sistema mostrara el formulario de reservación

3 El usuario llena incorrectamente la solicitud

4 El sistema no guardara la reservación y notificara al usuario que el la solicitud fue llenada incorrectamente.

Caso de uso: Modificar reservación

Descripción:

19


Es la acción que permite modificar la reservación mediante una petición del usuario.

Requerimiento:

El sistema podrá modificar la reservación

Precondición:

Debe de haber usuarios registrados

Debe de existir reservación

FLUJO BASICO:

El usuario debe de enviar una petición al administrador del sistema con los puntos que desea modificar.

ACTOR SISTEMA

1 El usuario enviara una petición al administrador.

2 El administrador recibirá la petición, modificara y notificara al usuario.

FLUJOS ALTERNOS

Ninguno

Poscondición:


Ninguno


Ninguno

Caso de uso: Eliminar reservación

Descripción:

20


Es la acción que permite eliminar la reservación mediante una petición del usuario.

Requerimiento:

El sistema podrá eliminar la reservaciones

Precondición:



FLUJO BASICO:

El usuario debe de enviar una petición al administrador del sistema solicitándole eliminar la reservación.

ACTOR SISTEMA


2 El administrador recibirá la petición, eliminara y notificara al usuario.

FLUJOS ALTERNOS

El usuario llene erróneamente el formulario

Poscondición:


Ninguno


Ninguno

Caso de uso: Eliminar reservación

Descripción:

21


Es la acción que permite eliminar la reservación mediante una petición del usuario.

Requerimiento:

El sistema podrá eliminar la reservaciones

Precondición:



FLUJO BASICO:

El usuario debe de enviar una petición al administrador del sistema en la cual desea eliminar la reservación.

ACTOR SISTEMA


2 El administrador recibirá la petición, eliminara y notificara al usuario.

Poscondición:


Ninguno


Ninguno

Caso de uso: Consultar reservación

Descripción:

22


Es la acción que permite consultar la reservación.

Requerimiento:

El sistema podrá consultar las reservaciones

Precondición:



FLUJO BASICO:

El administrador podrá consultar las reservaciones que se han realizado y las que están por realizarse.

ACTOR SISTEMA

1 El ingresara al formulario de reservaciones.

2 El sistema mostrara el formulario de reservaciones.

3 El administrador podrá consultar las reservaciones realizadas y las reservaciones pendientes

FLUJOS ALTERNOS

Ninguno

Poscondición:


Ninguno


Ninguno

Caso de uso: Actualizar promociones

Descripción:

23


Es la acción que permite actualizar las ofertas y promociones.

Requerimiento:

El sistema podrá actualizar las ofertas y promociones

Precondición:

Debe de existir una nueva oferta o promoción

FLUJO BASICO:

El administrador actualizara las ofertas o promociones del sitio.

ACTOR SISTEMA

1 El ingresara al sitio como administrador.

2 El sistema mostrara las opciones que poseerá el administrador.

3 El administrador ingresara al formulario de ofertas y promociones

4 El sistema mostrara el formulario de ofertas y promociones.

5 El administrador actualizará las ofertas y promociones

6 El sistema guardara los cambios y notificara al usuario

FLUJOS ALTERNOS

El administrador ingrese datos incorrectos al iniciar sección

ACTOR SISTEMA

1 El administrador ingresa al sistema con datos incorrectos.

2 El sistema notifica al administrador que sus datos son incorrectos

Poscondición:


Ninguno


Ninguno

Caso de uso: Administrar inventario del mobiliario

Descripción:

24


Es la acción que administrar el mobiliario que la empresa posee.

Requerimiento:

El sistema podrá administrar el inventario del mobiliario

Precondición:

Ninguna

FLUJO BASICO:

El administrador tendrá el control del mobiliario de la empresa.

ACTOR SISTEMA

1 El administrador accederá al sistema.

2 El sistema mostrar sus diferentes opciones.

3 El administrador ira al formulario inventario

3 El sistema mostrara el formulario inventario

4 El administrador podrá verificar el mobiliario disponible.

FLUJOS ALTERNOS

Ninguno

Poscondición:


Ninguno


Ninguno

25


3.3 Diagrama de Caso de uso

Caso 1:

Caso 2:

26


Caso 3:

Caso 4:

27


Caso 5:

Caso 6:

28


Caso 7:

Caso 8:

29


Caso 9:

Caso 10:

30


Caso 11:

Caso 12:

31


Caso 13:

Caso 14:

32


33


Especificaciones Suplementarias

Requerimientos no funcionales:

-El sistema deberá tener el logo de la empresa

-El sistema deberá contener los colores de la empresa

-El sistema será creado utilizando las tecnologías de HTML5, PHP, CSS3

-El sistema usara una base de datos creada en mySQL

-El sistema solo será instalado en el local Quinta San Juan

4.1 Usabilidad

4.1.1 Fácil UsabilidadEl sistema será diseñado simple y claro, para producir la menor cantidad de confusiones de parte del usuario. Estará estructurada de forma sencilla, intuitiva y elegante. Los usuario ya deberían conocer, por experiencia en otros sistema como email y el navegador de internet las funcionalidades generales del sistema. En el sistema sólo pudiera presentar dificultades de usabilidad a la hora de registrarse o hacer reservaciones sin embargo se hará la interfaz lo más auto explicativa y sencilla posible.

4.2 Confiabilidad

4.2.1 DisponibilidadEl sistema se debe encontrar disponible en todo momento, esto es muy importante para que sea un sistema confiable.

4.2.2 Tiempo de Espera entre Fallas

El tiempo mínimo entre falla y falla se tiene estipulado para 6 meses.

4.2.3 Recuperabilidad

Aproximadamente 3 horas.

4.3 Desempeño

4.3.1 De usuarios

Razonablemente el sistema debería tardar 3 segundos en cada opción que el usuario desee de clic.

34


4.4 Mantenibilidad

4.4.1 Revisión periódica del sistemaEl sistema será portable, robusto y modificable en lo posible sin mayores repercusiones para asegurarnos que el sistema se mantenga al día. El código del sistema deberá ser inteligible y sencillo para asegurar que futuras modificaciones se puedan hacer de manera rápida y con el menor número de repercusiones en los demás casos de uso que no se desea modificar. Se realizarán revisiones periódicas del sistema para evitar archivos corruptos y asegurar que las funcionalidades del sistema se mantienen a punto.

4.5. Seguridad

4.5.1. Seguir los estándares de seguridad de la IEEE

El sistema será adaptable a cualquier navegador que el usuario posea. Protegerá la información sensible del usuario, y la codificación en general de la página será codificada al usuario común. El sistema debe estar apegado a los estándares de seguridad más comunes de IEEE.

4.6. Restricciones de Diseño

4.6.1. Seguir el diseño de los sistemas de la DII

En primer lugar están los lineamientos referentes al diseño gráfico del sitio, la DII dispone de ciertos lineamientos que deben ser acatados para que un sistema sea utilizado en la USB, esto para mantener lineamientos en cuanto a la imagen de la universidad. Por otro lado tenemos los lineamientos referentes a las herramientas a utilizar las cuales deben ser Open Source. Por parte de la empresa se decidió brindar soporte en cualquier navegador web y mantener un diseño a tres capas.

4.7. Requerimientos de Documentación en Línea y de Sistemas de Ayuda Un requerimiento importante es el envío de notificaciones a los usuarios que emiten los documentos recibidos por el Departamento de Registro y ordenamiento de Pagos, esto permite que de alguna manera, el departamento pueda informar sobre el estatus en el que se encuentra la correspondencia que recibe.

Otro punto importante, son los reportes que debe generar el sistema, para informar al jefe de departamento sobre el progreso de los analistas encargados de procesar los documentos.

4.8. Componentes CompradosEl sistema entero será desarrollado utilizando componentes de libre distribución, puesto que lo que se requiere es manejar información y generar reportes.

4.9. Interfaces

4.9.1 <Interfaces de Usuario>La interfaz del usuario ha de ser sencilla e intuitiva, se pretende que el sistema facilite la clasificación, ubicación y seguimiento de documentos, para esto el usuario debe ser capaz de conseguir rápidamente y con exactitud el documento deseado. El orden de las páginas y botones debe ser intuitivo de forma

35


que el usuario no se sienta perdido en el flujo del trabajo.

4.9.2 <Interfaces de Hardware>No aplica para este sistema

4.9.3 <Interfaces de Software>El desarrollo del sistema se orienta hacia la multiplataforma, de manera que la interfaz pueda apreciarse sin importar el sistema operativo sobre el que se trabaja, o el navegador que utilice el usuario. Además, el sistema ofrecerá plantillas que hagan más fácil el ingreso y clasificación de la información por parte del usuario. Por otro lado el sistema va a tener una conexión con el sistema de resolución de casos que se está realizando en paralelo para el mismo departamento con la finalidad de que el analista pueda tomar una decisión respecto a un caso en cuestión y automáticamente se modifique el status del documento en nuestro sistema.

4.9.4 <Interfaces de Comunicaciones>Envío de notificaciones usando el sistema de correos de la Universidad Simón Bolívar de manera automática pero sin una interfaz de usuario.

4.10 Requerimientos de LicenciamientoNo hay ningún requerimiento de licenciamiento ya que se usará exclusivamente software libre para desarrollar el sistema.

4.11 Aspectos Legales, Derecho de Autor y otros Avisos

Para el desarrollo del sistema, se planea utilizar herramientas y lenguajes Open Source, de manera que no existan problemas con violaciones de Derecho de Autor. Como lenguaje de programación, la empresa ha seleccionado PHP, y como manejador de bases de datos Postgre SQL, ambos, herramientas de código libre.

4.12 Estándares Aplicables

Debido a que se requiere que la información almacenada en el sistema se pueda acceder por Internet, todos los aspectos vinculados con la interfaz del mismo se deben regir bajo los lineamientos establecidos por la DII. También es necesario ser cuidadosos con el manejo de toda esta información, ya que esta relacionada con el pago de prestaciones sociales y nómina, por lo tanto el sistema debe contribuir con el cumplimiento de ciertos aspectos legales por parte del Departamento de Registro y Ordenamiento de Pagos de la USB:

– Constitución de la República Bolivariana de Venezuela.– Ley de Simplificación de Trámites Administrativos.– LOPA– Ley Orgánica del Trabajo.– Ley Contra la Corrupción.– Ley Orgánica de la Contraloría General de la República y del Sistema Nacional del Control

Fiscal.

36

Documento ERS 1

Documents

Transcript of Documento ERS 1