UCM-ÁGORA

UCM-ÁGORA
SRS
Especificación de requisitos
GRUPO C
1
ÍNDICE
1. INTRODUCCIÓN................................................................................................. 3
1.1
1.2
1.3
1.4
1.5
Propósito ...................................................................................................................... 3
Alcance ......................................................................................................................... 3
Definiciones, abreviaturas y acrónimos ....................................................................... 3
Referencias ................................................................................................................... 4
Resumen / Organización del documento ..................................................................... 5
2. Descripción general ........................................................................................... 5
2.1
2.2
2.3
2.4
2.5
2.6
Perspectiva del producto.............................................................................................. 5
Funciones del producto ................................................................................................ 5
Características del usuario ........................................................................................... 6
Restricciones................................................................................................................. 7
Suspuestos y dependencias............................................ Error! Bookmark not defined.
Requisitos futuros......................................................................................................... 7
3. Requisitos específicos........................................................................................ 9
3.1
Interfaces externas ....................................................................................................... 9
3.2 Funciones (Requisitos funcionales) ....................................... Error! Bookmark not defined.
3.3
Requisitos de rendimiento ......................................................................................... 16
3.4
Requerimientos lógicos de la BBDD ........................................................................... 16
3.5
Restricciones de diseño: ............................................................................................. 16
3.5.1 Estándares de cumplimiento: ................................................................................. 16
3.6
Atributos del sistema software ...................................... Error! Bookmark not defined.
3.6.1 Fiabilidad .................................................................................................................... 17
3.6.2 Disponibilidad ............................................................................................................. 17
3.6.3 Seguridad ................................................................................................................... 17
3.6.4 Capacidad de mantenimiento .................................................................................... 18
3.6.5 Portabilidad ................................................................................................................ 18
2
1. INTRODUCCIÓN
1.1
Propósito
Este documento muestra la especificación de requisitos que utilizará el proyecto de
UCM-ÁGORA. En él se detalla todos los aspectos que hay que tener en cuenta para
crear la aplicación como también sus limitaciones y restricciones.
1.2
Alcance
El objetivo del proyecto es crear una red social específica que fomente el desarrollo
y la sociabilidad de todos los miembros de la comunidad universitaria de la
Universidad Complutense (alumnos, profesores y personal de administración y
servicios). La aplicación será un medio para compartir tanto temas académicos
como sociales.
También se ha decidido ofrecer distintas opciones de acceso a UCM-Ágora. Para ello
se ofrecerán, al menos una interfaz vía web, otra para dispositivos móviles y una
aplicación específica multiplataforma para acceder a la aplicación. Todo esto para
soportar distintas necesidades de acceso de los usuarios en cada momento y lugar.
1.3
Definiciones, abreviaturas y acrónimos
BDD: Base de datos.
SRS: Especificación de Requerimientos de Software (SRS) define de forma precisa el
producto de software que se va a construir. Las decisiones hechas escribiendo la SRS
están basados en información de los documentos de la propuesta del proyecto y
requerimientos del usuario. El conjunto de requerimientos de SRS deben ser
satisfechos en el diseño del sistema. La SRS es verificada y validada por las
actividades marcadas en el plan de QA.
IEEE: En español, Instituto de Ingenieros Eléctricos y Electrónicos, una asociación
técnico-profesional mundial dedicada a la estandarización. Es la mayor asociación
internacional sin ánimo de lucro formada por profesionales de las nuevas tecnologías
UCM: Universidad Complutense de Madrid.
XML: (Extensible Markup Language) es un metalenguaje, es decir, un lenguaje para
la definición de otros lenguajes. Es decir es una norma que define la sintaxis y las
reglas que tenemos que seguir para crear nuestro propio lenguaje de etiquetas.
3
JVM : (máquina virtual de Java) es únicamente un aspecto del software de Java,
específicamente utilizado para la interacción en la web.
JSP: es un acrónimo de Java Server Pages, que en castellano vendría a decir algo
como Páginas de Servidor Java. Es, pues, una tecnología orientada a crear páginas
web con programación en Java.
MySQL: Es un sistema de gestión de bases de datos relacional, multihilo y
multiusuario. Su popularidad como aplicación web está muy ligada a PHP, que a
menudo aparece en combinación con MySQL. Es una base de datos muy rápida en la
lectura lo que la hace ideal para este tipo de aplicaciones.
SSL: Secure Socket Layer. Protocolos criptográficos de la capa de
transporte que proporcionan comunicaciones seguras por una red.
HTTPS: (Hypertext Transfer Protocol Secure) En español: Protocolo seguro de
transferencia de hipertexto, más conocido por sus siglas HTTPS, es un protocolo de
aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos
de Hiper Texto, es decir, es la versión segura de HTTP.Es utilizado principalmente por
cualquier tipo de servicio que requiera el envío de datos personales o contraseñas.
Protocolo TCP/IP: Describe un conjunto de guías generales de diseño e
implementación de protocolos de red específicos para permitir que una
computadora pueda comunicarse en una red. TCP/IP provee conectividad de
extremo a extremo especificando como los datos deberían ser formateados,
direccionados, transmitidos, enrrutados y recibidos por el destinatario.
Backup: (copia de seguridad) Con el fin de que estas copias adicionales puedan
utilizarse para restaurar el original después de una eventual pérdida de datos.
Keepalive: es un mensaje enviado por un dispositivo a otro para comprobar que
el vínculo entre los dos está en funcionamiento, o para evitar que este vínculo se
rompa.
1.4 Referencias
IEEE Std 830 1998(R2009). (Ubicado en la carpeta /Estándares del repositorio)
Especificación de Requisitos según el estandar de IEEE 830.
4
1.5 Resumen / Organización del documento
Este documento de especificación de requisitos consta de tres secciones:



Sección 1: Introducción. Proporciona una visión general del objetivo de esta
aplicación.
Sección 2: Descripción de los factores generales que afectan al producto y los
requisitos principales que conforman su desarrollo.
Sección 3: Define específicamente los requisitos generales que satisfacen al
sistema, así como las funciones y restricciones que llevará a cabo.
2. Descripción general
.
2.1
Perspectiva del producto
UCM-ÁGORA es una red social orientada a alumnos, personal docente e
investigación y personal de administración y servicios de la Universidad Complutense
de Madrid. Al igual que otras redes sociales, pretende ser un punto de encuentro de
la comunidad educativa.
A diferencia de otras redes sociales no es totalmente abierta, sino que se restringe a
usuarios dados de alta en la base de datos de la UCM.
2.2
Funciones del producto
Funcionalidades iniciales del producto a desarrollar.
2.2.1 CONTACTOS. Gestión de contactos de cada usuario, permitiendo así
añadir, eliminar y bloquear temporalmente un usuario. Además se podrán
organizar en grupos para realizar acciones comunes a uno o varios grupos
de contactos.
2.2.2 MURO. Proporciona a cada usuario un lugar donde colgar sus
publicaciones y recibir publicaciones de sus contactos. Así mismo permite
eliminar las publicaciones o comentarios que se hayan realizado en su
muro o en el muro de otros.
2.2.3 FOTOS. Sección específica para subir fotos que, además estará
comunicada con el muro permitiendo que aparezcan fotos en él.
2.2.4 CHAT. Permite a los usuarios hablar en tiempo real con los contactos
conectados en ese momento.
5
2.2.5 CORREO. Se podrán enviar mensajes a los contactos, conectados o no, de
un usuario. La aplicación permitirá recibir, leer, borrar y contestar.
2.2.6 PERFIL. Cada usuario tendrá un perfil donde se mostrará su actividad
reciente en la red social, información que muestra a sus contactos,
notificaciones y avisos relevantes.
2.2.7 OPCIONES. Sección de opciones donde los usuarios podrá controlar todo
lo relativo a la configuración de la aplicación tales, como opciones de
privacidad, visualización, notificaciones, etc.
2.3
Características del usuario
UCM-ÁGORA va destinada en especial a dos sectores principales, el alumnado de la
UCM, ya que, sirve como herramienta social para su beneficio en los años de carrera
y al profesorado, el cual tendrá un medio de comunicación directo y global para
notificar cualquier dato relevante a sus alumnos o entre ellos mismos.
UCM-ÁGORA está estructurado de una manera clara para que el personal que lo
utilice no necesite una gran experiencia, aunque se espera un conocimiento básico
de Internet para poder darle el uso más óptimo a la aplicación.
El usuario preferiblemente debería estar familiarizado con redes sociales para su
mejor uso, aunque la aplicación tiene una interfaz gráfica amigable e intuitiva que no
resultará complicado al usuario sin experiencia.
El personal encargado de administrar y gestionar UCM-ÁGORA, sí que debe tener
conocimientos de administración de redes y sistemas para resolver cualquier
incidencia que pueda producirse.
6
2.4
Restricciones
2.4.1 Limitaciones de hardware
UCM-ÁGORA para su correcto funcionamiento deberá estar instalado en
servidores dedicados, con un ancho de banda y almacenamiento suficientes para
soportar el grueso de usuarios de la Universidad Complutense.
2.4.2 Limitaciones de software
Será necesario tener una versión adecuada de LINUX/UNIX con Apache2, PHP5 y
MySQL5
2.4.3 Funcionamiento paralelo.
La aplicación soportará el acceso concurrente de un número máximo de usuarios,.
De igual manera, la base de datos dará servicio a un máximo establecido de
consultas, prevemos 20.000. Esto dependerá de la capacidad contratada con nuestro
proveedor de servicios. Siempre con posibilidad de ampliación en caso de
conexiones fuera de lo previsto.
2.4.4 Limitaciones sobre seguridad.
Los datos que viajan desde los servidores de UCM-AGORA, la Universidad
Complutense y los dispositivos de los usuarios se realizará encriptada y de forma
segura mediante un certificado SSL.
2.4.5 Funciones de auditoría y de control
La realización de respaldos ( backups ) deberá hacerse periódicamente dada la
importancia de los datos alojados en UCM-AGORA y la necesidad legal de
mantenerlos seguros por la LOPD 15/1999
2.4.6 Protocolos de comunicación
Para realizar las conexiones que requieren un mínimo grado de seguridad
se utilizará la capa SSL (Protocolo de Capa de Conexión Segura), y el
protocolo HTTPS (Hypertext Transfer Protocol Secure).
Las comunicaciones que no requieran de ningún tipo de seguridad especial
se desarrollaran sobre el protocolo HTTP habitual.
2.5 Supuestos y dependecias
El correcto funcionamiento por parte del usuario de UCM-ÁGORA está vinculado a el
uso de navegadores que cumplan los estándares W3C.
2.6
Requisitos futuros
7
A continuación se enumeran las posibles funcionalidades que pudieran ser
implementadas en un futuro:
2.6.1 Contactos:


Incluido en el sistema de grupos, el sistema creara por defecto un grupo de
favoritos en el cual se incluirán los contactos con que más interactúa el
usuario.
Se implementará un sistema de etiquetas el cual permitirá facilitar la
identificación de contactos.
2.6.2- Muro


Marcar y desmarcar una publicación como favorita.
Ocultar publicaciones de un contacto específico.
2.6.3 Fotos


Modificar el título o la descripción de la foto.
Mover fotos de un álbum a otro.
2.6.4 Chat





Permitir el uso de emoticonos.
Chatear en grupo entre varios usuarios.
Introducir un servicio de videollamada y transferencia de archivos.
Se implementara un servicio de transferencia de archivos
Se desarrollaran varios juegos multijugador los cuales podrán ser jugados
por los contactos
2.6.5 Correo




Al crear e-mails, sugerir direcciones mediante concordancias con el historial
de direcciones a las que se ha enviado o de las que se ha recibido mensajes,
además de los contactos añadidos en el perfil.
Adjuntar archivos.
Filtro antispam.
Crear carpetas para la organización de los mensajes.
2.6.6 Perfil
2.6.7 Opciones
8
3. Requisitos específicos
En este apartado se proporcionará aspectos mas detallados para que la
implementación sea mas precisa.
3.1 Interfaces externas
Encaminador destino
No serán necesarias interfaces externas para el encaminador destino, su
configuración, de ser necesaria, se hará a través de un fichero de
configuración.
Servidor
El servidor tendrá instalado 2 aplicaciones distintas cómo mínimo:
• El sistema gestor de base datos Mysql.
• El servidor web Apache2 con soporte para PHP5
Resto de aplicaciones
Para el buen funcionamiento de la aplicación, es necesario utilizar
componentes externas al proyecto, como por ejemplo, el servidor web apache,
el sistema gestor de base de datos Mysql, etc.
Para el resto, al ser programas demonio, la configuración se hará
exclusivamente modificando los ficheros de configuración de cada uno de
ellos
Todas las componentes utilizadas, se distribuyen con su propia interfaz,
delegando la responsabilidad de la misma a los desarrolladores de la
componente.
3.2 FUNCIONES
3.2.1. Requisitos de función de opciones generales.
• Acceder a la interfaz general.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Permite al usuario ver la interfaz general con las distintas
opciones a escoger.
Ventana de interfaz general
Sistema
El usuario debe ser de la UCM y estar logueado en la
9
Postcondición:
aplicación.
Se visualiza la interfaz general.
• Acceder chat.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario entrar a la opción de chat.
Ventana de interfaz de chat.
Sistema.
El usuario debe haber accedido antes a la interfaz
general correctamente, y por tanto este debe ser de la
UCM y estar logueado en la aplicación.
Se visualiza la interfaz de chat.
• Crear eventos.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario acceder a la opción de creación de
eventos.
Nombre del evento.
Teclado
Interfaz de creación de evento.
Sistema.
El usuario debe haber accedido antes a la interfaz
general correctamente, y por tanto este debe ser de la
UCM y estar logueado en la aplicación.
Se crea el evento con las características descritas por el
usuario.
• Acceder al perfil.
Descripción:
Entrada:
Origen:
Permite al usuario entrar a la opción de perfil.
10
Salida:
Destino:
Precondición:
Postcondición:
Ventana de interfaz de perfil.
Sistema.
El usuario debe haber accedido antes a la interfaz
general correctamente, y por tanto este debe ser de la
UCM y estar logueado en la aplicación.
Se visualiza la interfaz de perfil.
• Acceder a videos.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario acceder a la interfaz de videos.
Ventana de interfaz de videos.
Sistema.
El usuario debe haber accedido antes a la interfaz
general correctamente, y por tanto este debe ser de la
UCM y estar logueado en la aplicación.
Se visualiza la interfaz de videos.
• Acceder a muro.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario entrar a la opción de muro.
Ventana de interfaz de muro.
Sistema.
El usuario debe haber accedido antes a la interfaz
general correctamente, y por tanto este debe ser de la
UCM y estar logueado en la aplicación.
Se visualiza la interfaz de muro.
• Acceder a ayuda.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al acceder entrar a la interfaz de ayuda.
Ventana de interfaz de ayuda.
Sistema.
El usuario debe haber accedido antes a la interfaz
general correctamente, y por tanto este debe ser de la
UCM y estar logueado en la aplicación.
Se visualiza la interfaz de ayuda o soporte técnico.
11
3.2.2. Requisitos de función de contactos.
• Añadir contacto.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario crear un contacto para añadirlo a una
lista y permitir la interacción entre ellos.
Nombre del contacto.
Teclado.
Mensaje verificando que el contacto ha sido creado.
Sistema.
El nombre del contacto que se va a escribir no estaba
previamente añadido a la lista del usuario.
El sistema añade el contacto a la lista del usuario.
• Eliminar contacto.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario eliminar un contacto perteneciente a
la lista.
Nombre del contacto.
Teclado.
Mensaje verificando que el contacto ha sido eliminado.
Sistema.
El nombre del contacto que se desea eliminar esta en la
lista de contactos del usuario.
El sistema elimina de la lista del usuario el contacto
introducido.
• Bloquear contacto.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Permite al usuario borrar un contacto perteneciente a la
lista.
Nombre del contacto.
Teclado.
Mensaje verificando que el contacto ha sido bloqueado.
Sistema.
El contacto que se desea borrar esta en la lista de
contactos del usuario.
12
Postcondición:
El sistema bloquea al contacto introducido por el usuario.
• Crear grupos.
Descripción:
Entrada:
Origen:
Salida:
Destino:
Precondición:
Postcondición:
Permite al usuario crear un grupo de contactos
Nombre de grupo que se desea crear.
Teclado.
Mensaje verificando que el grupo ha sido creado.
Sistema.
El usuario tiene mas de un contacto en su lista.
El sistema crea un grupo con el nombre introducido por
el usuario.
3.2.3. Requisitos de función de chat.
 Conexión de usuario
Descripción
Entrada
Origen
Salida
Destino
Precondición
Postcondición
Permite al usuario conectarse o desconectarse del
chat cuando desee
Ventana del chat
Sistema
El usuario debe ser de la UCM y estar logueado en la
aplicación
-
 Mostrar estado actual
Descripción
Entrada
Origen
Salida
Destino
Permite mostrar el estado actual del chat
Muestra el estado actual del usuario
Sistema
13
Precondición
Postcondición
El usuario debe ser de la UCM ,estar logueado en la
aplicación y estar conectado al chat
Muestra con distinto color el estado
 Mensaje de chat
Descripción
Entrada
Origen
Salida
Destino
Precondición
Postcondición
Permite escribir un mensaje instantáneo en la ventana
del chat
Caracteres introducidos
Teclado
Mensaje escrito
Otro usuario
El usuario debe ser de la UCM ,estar logueado en la
aplicación y estar conectado al chat
El mensaje enviado se muestra en la ventana
 Grupos de chat
Descripción
Entrada
Origen
Salida
Destino
Precondición
Postcondición
Permite crear un grupo de chat para mantener una
conversación entre varios usuarios
Ventana del chat común
Varios usuarios
El usuario debe ser de la UCM ,estar logueado en la
aplicación y estar conectado al chat
Se muestra ventana común donde se envían mensajes
instantáneos al a vez
3.2.2. Requisitos de función de correo.
 Enviar correo
Descripción
Entrada
Origen
Salida
Destino
Permite enviar un correo a otro usuario de la
aplicación
Nombre del contacto, asunto de mensaje y el mensaje
Teclado
Usuario
14
Precondición
Postcondición
El usuario debe ser de la UCM y estar logueado en la
aplicación.
El mensaje se envía y se muestra un mensaje de éxito.
 Contestar al correo
Descripción
Entrada
Origen
Salida
Destino
Precondición
Postcondición
Permite contestar un mensaje recibido
Asunto del mensaje y mensaje
Teclado
Usuario
El usuario debe ser de la UCM ,estar logueado en la
aplicación y tener un mensaje al que responder.
El mensaje es enviado
 Borrar correo
Descripción
Entrada
Origen
Salida
Destino
Precondición
Postcondición
Permite borrar un mensaje recibido
Sistema
El usuario debe ser de la UCM ,estar logueado en la
aplicación y tener un mensaje recibido.
El mensaje es borrado.
 Adjuntar archivo
Descripción
Entrada
Origen
Salida
Destino
Precondición
Postcondición
Permite enviar archivos a otro usuario
Archivo
Usuario
El usuario debe ser de la UCM ,estar logueado en la
aplicación y estar conectado al chat
El archivo se envía a otro usuario de la aplicación
15
3.3 Requisitos de rendimiento
La carga esperada para la aplicación en su conjunto es muy elevada debido al alto
número de usuarios de la red (aproximadamente 100.000) y a la posibilidad de
concurrencia de esos usuarios.
El sistema deberá soportar una carga de.50.000 usuarios conectados
simultáneamente .
UCM-ÁGORA deberá transcurrir sobre un servidor Intel Dual Xeon E5310, 4 GB RAM,
2X 500 GB HDD, 10 TB banda ancha, para que pueda soportar sin problemas la
conexión de muchos usuarios.
El tiempo de transacción por segundo de todas las operaciones se estimará en un
número inferior a 1 segundo para de esta manera hacer que la interacción del
usuario con la aplicación sea mucho más eficiente.
3.4 Requerimientos lógicos de la BBDD
El sistema accederá a una base de datos externa (UCM) de la que extraerá los datos
de los usuarios cada vez que se realiza un acceso a UCM-Ágora. Una vez logueado en
el sistema, todas las interacciones del usuario se guardarán en la base de datos
interna (UCM-Ágora).
El almacenamiento y la actualización de los datos de UCM-Ágora se procesará de una
manera periódica para evitar que en caso de caída del sistema se pierdan los datos.
En caso contrario, dispondremos de unas copias de seguridad que se generan
automáticamente si ocurre una caída inesperada del sistema recuperando los datos
perdidos.
Para el mantenimiento de este sistema de seguridad utilizaremos la tolerancia a
fallos de serie en MySQL.
3.5 Restricciones de diseño:
El almacemiento de los datos está sujeto a las restricciones de la Ley Orgánica de
Protección de datos XXXXXX, siguiendo el siguiente estándar de cumplimiento
3.5.1 Estándares de cumplimiento:
El fichero que almacena los datos de los usuarios debe seguir el siguiente estándar:
sistema de notificación basado en un formato estándar que permita el intercambio
de información entre diferentes plataformas (formato XML). De esta forma, tanto los
responsables que desarrollen sus propios programas como los desarrolladores de
paquetes ofimáticos de protección de datos para las PYME’s podrán comunicarse
con la AEPD para notificar sus ficheros, pudiendo presentar sus solicitudes con y sin
16
certificado de firma electrónica. Para ello se pueden consultar las normas que
deberán cumplir las aplicaciones desarrolladas por terceros para que puedan
presentar validamente las notificaciones al RGPD.
Estos mensajes en formato XML pueden ser presentados con y sin certificado
electrónico de firma reconocido. En el caso de que se presenten firmados
electrónicamente deberán utilizar el estándar de firma Xml Digital Signature, cuya
especificación de sintaxis y procesamiento se encuentra en
http://www.w3.org/2000/09/xmldsig# . En este caso, una vez enviadas las
notificaciones al Registro Telemático de la AEPD, éste devolverá un mensaje
confirmando la recepción del envío incluyendo, a su vez, los datos necesarios para
que el programa desarrollado por terceros configure el acuse de recibo de acuerdo
con el formato establecido en la Resolución de la Agencia Española de Protección de
Datos de 12 de julio de 2006 por la que se aprueban los formularios electrónicos a
través de los que deberán efectuarse las solicitudes de inscripción de ficheros en el
Registro General de Protección de Datos, así como los formatos y requerimientos a
los que deben ajustarse las notificaciones remitidas en soporte informático o
telemático
3.6.1 Fiabilidad
Se garantizará el correcto funcionamiento de todos los movimientos de los datos
tanto de la base de datos externa como de la interna para proteger a los usuarios.
También se preverá de una copia de seguridad (backups) para el caso de alguna
pérdida.
3.6.2 Disponibilidad
La disponibilidad de la aplicación estará relacionado con las garantías de seguridad y
operatividad de los sistemas de la UCM.
Nuestro sistema se mantendrá disponible durante las 24 horas del día. En caso de
modificación o revisión se efectuará en un horario nocturno para mantener al
usuario durante el tiempo diurno sin ningún problema en la aplicación.
3.6.3 Seguridad
Al ser una aplicación en la que se mandarán mensajes que
podrían leer terceras personas, es necesario idear un sistema que evite la
suplantación de identidad, y ataques por denegación de servicio.
Para ello, se asegurará que los mensajes que enviados entre
cliente y servidor, así como los mensajes enviados entre el servidor y el
encaminador destino, no puedan ser suplantados por terceras personas, de ahí
la necesidad de utilizar passwords y un mecanismo de cifrado.
Para poder cifrar mediante SSL, es necesario obtener un certificado de una
autoridad o firmarse un certificado uno mismo.
Muchos navegadores darán un aviso de seguridad si encuentran un
certificado firmado por uno mismo. Para el desarrollo de la aplicación se
utilizará este tipo de certificado a sabiendas de que no será válido para una
17
implantación real.
La comunicación entre el cliente y el encaminador destino no requiere
seguridad, si se desean enviar datos correrá por cuenta del usuario que vayan
cifrados.
El sistema deberá proporcionar la garantía de seguridad de los datos personales.
Estos datos de la aplicación deberán mantenerse a salvo en caso de alteración,
pérdida, uso o accesos no permitidos.
Los datos personales solo podrán ser comunicados a un tercero en caso de cumplir
los fines directamente relacionados con las funciones legítimas, como se fija en la
normativa de protección de datos LOPD xxxxx
Los usuarios obtendrán diferentes tipos de privilegios a la hora de tratar la
información según el usuario necesite proteger la información hacia accesos no
autorizados.
3.6.4 Capacidad de mantenimiento
La aplicación se dejará estructurada para poder acometer
en el futuro ampliaciones en la funcionalidad. La aplicación necesitará del
mantenimento que conlleve el servidor donde está ejecutándose.
Con el fin de facilitar el mantenimiento del software el sistema estará dividido en
diferentes módulos y así se agilizará el proceso de mantenimiento de los
desarrolladores. Asimismo, se le adjuntará la información necesaria sobre la
aplicación y el modo de su desarrollo para obtener de manera más concisa el
material para ajustarse de manera más próxima al sistema.
3.6.5 Portabilidad
El sistema está desarrollado en software libre, por lo que podrá ser migrado a otro
sistema que cumpla los requisitos mencionados en el punto 2.4.1 y 2.4.2.
18