View
0
Download
0
Category
Preview:
Citation preview
Anexos
Diseño e implementación de una aplicación
informática de administración y gestión de los
procesos y documentación de Prevención de
Riesgos Laborales (PRL) integrada con gestor
documental.
Autor: Miguel Ángel Catalán Va
Director: Fernando Cortés Franco
Ponente: Santiago Velilla Marco
Escuela de Ingeniería y Arquitectura
2012
Endalia
Estudio de mercado
Versión 1.0 – Fecha: 28/12/2012
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 2 de 12
REVISIONES
Fecha Versión Descripción Autor
28/12/2012 1.0 Versión inicial del documento de estudio
de mercado
Miguel Ángel Catalán
Copyright © 2007, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Plaza Roma F-1 7ºE 50010, Zaragoza • España
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 3 de 12
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 ACRÓNIMOS 4 1.4 DEFINICIONES 4 1.5 REFERENCIAS 4 1.6 RESUMEN 4
2. SISTEMA DE GESTIÓN EN PRL ¡ERROR! MARCADOR NO DEFINIDO.
3. SISTEMAS GESTORES EN PRL ¡ERROR! MARCADOR NO DEFINIDO.
3.1 GPREVENCION ¡ERROR! MARCADOR NO DEFINIDO. 3.1.1 PRINCIPALES CARACTERÍSTICAS: 6 3.2 PREVGES 4.0 ¡ERROR! MARCADOR NO DEFINIDO. 3.2.1 PRINCIPALES CARACTERÍSTICAS 8 3.3 PROSAFETY ¡ERROR! MARCADOR NO DEFINIDO. 3.3.1 PRINCIPALES CARACTERÍSTICAS 10
4. CONCLUSIONES 11
5. BIBLIOGRAFÍA 12
5.1 REFERENCIAS 12 5.2 REFERENCIAS WEB 12
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 4 de 12
1. INTRODUCCIÓN
1.1 Propósito del documento
En este documento se realiza el estudio de mercado de este proyecto. Se ha llevado a cabo un
análisis de otros sistemas para la gestión de la Prevención de Riesgos Laborales.
1.2 Alcance del documento
En este documento se describen los resultados obtenidos durante la fase de planificación del
proyecto.
1.3 Acrónimos
EPI: Equipo de Protección Individual
PRL: Prevención de Riesgos Laborales
1.4 Definiciones
Interfaz gráfico: Conjunto de imágenes, objetos pictóricos y texto que componen la
capa con la que interactúa un usuario con un sistema computacional.
1.5 Referencias
En este documento no se realizan referencias a otros documentos del proyecto.
1.6 Resumen
Este documento describe el estudio de mercado del proyecto. Se compone de seis apartados:
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: Definición del concepto de Sistema de Gestión y Control de PRL
Apartado 3: Descripción de algunos sistemas de Gestión y Control de PRL existentes
en el mercado.
Apartado 4: Conclusiones obtenidas en la realización del estudio de mercado.
Apartado 5: Bibliografía y referencias Web utilizadas para la realización de este
documento.
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 5 de 12
2. SISTEMA DE GESTIÓN EN PRL
Un Sistema de Gestión en PRL es una aplicación que nos ofrece funcionalidades para el
control y gestión de todas las entidades relacionadas o que son objeto del área de PRL en una
empresa. Entre estas podemos destacar los EPIs, reconocimientos médicos, Riesgos
detectados y cursos formativos en materia de PRL.
En algunos sistemas, además de ofrecer la automatización y registro de los ítems
anteriormente mencionados se dota al sistema de un módulo de Monitorización el cual se
encarga de buscar las anomalías o deficiencias y las muestra al administrador-usuario del
sistema para que tome las medidas oportunas.
El principal objetivo de estos sistemas es alcanzar o aproximarse lo más posible a la meta de
“cero accidentes”. De esta forma proveemos de un alto nivel de seguridad a un recurso
productivo tan importante como es la mano de obra y nos diferenciamos en calidad pudiendo
obtener certificaciones que lo acrediten.
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 6 de 12
3. SISTEMAS GESTORES EN PRL
A continuación se muestran algunos ejemplos de Sistemas Gestores en PRL que hay
actualmente en funcionamiento, especificando sus características principales, diferencias entre
ellas.
3.1 GPrevencion
Figura 1. Página de inicio de GPrevencion
GPREVENCION es una aplicación para automatizar todas las labores administrativas que son necesarias para el cumplimiento de las Leyes y R.D. de Prevención de riesgos laborales, basado en las especificaciones de OHSAS 18001 y UNE 81900 para los sistemas de gestión.
GPREVENCION garantiza que los departamentos de Prevención de nuestros Clientes no tengan que realizar todas las labores administrativas, que son necesarias para cumplir la ley, ya que nuestro sistema se ocupa automáticamente de esa actividad y se puedan centrar en las realmente críticas y necesarias para garantizar la seguridad de los trabajadores.
Nuestros clientes mantienen todos sus centros y puestos de trabajo interconectados, permitiendo el acceso simultáneo a todos los coordinadores de seguridad, técnicos de prevención, directores facultativos, contratas /subcontatas, y en resumen a todas las personas que tienen que realizar alguna acción, que demuestre la implicación total de la empresa en la prevención de accidentes laborales.
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 7 de 12
3.1.1 Principales características:
ENVIO AUTOMATICO DE AVISOS POR MEDIO DE CORREO ELECTRONICO a todos los Usuarios que tienen que realizar alguna acción para el cumplimiento de los requisitos de las normas del sistema de gestión, en todos los módulos.
REALIZACION AUTOMATICO DEL 100% DE LAS ACTIVIDADES ADMINISTRATIVAS en materia de gestión documental de la Prevención, GPREVENCION se encarga generar automáticamente todos los aspectos necesarios para el sistema de gestión, sustituyendo multitud de recursos organizativos.
SUSTITUCION DE LOS DOCUMENTOS EN PAPEL una vez implantado nuestros Clientes, reducen su documentación en soporte papel, en más del 90%, quedando únicamente aquellos registros que deben ir impresos.
ACCESOS EXTERNOS PARA PROVEEDORES Y CONTRATISTAS , que pueden introducir todo tipo de documentos y archivos en la plataforma, permitiendo liberar al departamento de Prevención de todas las tareas de revisión de documentos entregados, justificantes de formación, entrega de EPI´S, reconocimientos médicos, etc.
PARAMETRIZACION DE ROLES Y ACCESOS DE CADA USUARIO, que permite que cada persona que acceda al sistema, sólo tendrá acceso a la información y acciones, para la cuál este autorizado por los administradores. El resto de documentos, información y botones de acciones no son visibles por los usuarios no autorizados previamente.
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 8 de 12
3.2 PrevGes 4.0
Figura 2: Página de inicio de PrevGes 4.0
PrevGes 4.0 es otro Software o Programa de Gestión de Prevención de Riesgos Laborales
compuesto de los módulos Agenda (para la anotación personalizada de cada incidente),
Personal, Evaluación de riesgos, Productos peligrosos, Incidentes (donde anotar altas y
bajas), Estadísticas, Preventivo, Consultas (espacio para anotación de antecedentes y
diagnósticos) y Archivo.
A su favor juega que se trata de un sistema ligero y no requiere de muchos requisitos en al
máquina donde va a ejecutarse. Solo se ofrece su uso tras su instalación y no se ofrece el
servicio a través del navegador.
Destaca negativamente su interfaz gráfica con mucha información sin orden aparente y con
colores poco saludables para la vista.
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 9 de 12
3.2.1 Principales características
VERSIONES 1.0 Y 2.0 GRATUiTAS. Por otro lado se ofrece un Servicio Técnico de pago.
MULTIUSUARIO. Posibilidad de trabajar simultáneamente con los mismos datos.
MÓDULOS DIFERENCIADOS POR COLORES
POSIBILIDAD DE IMPORTAR INFORMACIÓN DE DISTINTAS BASES DE DATOS.
INTEGRAMENTE EN ESPAÑOL.
PERMITE LA REALIZACIÓN DE COPIAS DE SEGURIDAD AUTOMATICA.
3.3 ProSafety
Figura 3: Página de inicio de ProSafety
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 10 de 12
ProSafety es un completo sistema software para la gestión de la seguridad laboral que facilita
la implantación de la filosofía CERO ACCIDENTES. Sus herramientas incorporan prácticas
actualmente disponibles en seguridad, como la seguridad compartida, el trabajo en grupo y la
seguridad basada en el comportamiento.
Este sistema también ayuda a certificarse según OHSAS 18000.
3.3.1 Principales características
Dispone de uno de los Interfaces gráficos más atractivos de los sistemas en Prevención de
Riesgos Laborales evaluados.
Se trata de un sistema muy amplio y completo en materia de seguridad.
Dispone de un gran número de módulos:
- INVESTIGACION DE ACCIDENTES E INCIDENTES
- (+) EVALUACION DE RIESGOS
- (+) COMUNICACION DE RIESGOS
- (+) OBSERVACIONES DE SEGURIDAD
- (+) INSPECCIONES DE SEGURIDAD
- (+) AUDITORIAS DE SEGURIDAD
- (+) NO CONFORMIDADES
- (+) REGISTRO DE FORMACION
- (+) EMERGENCIAS Y SIMULACROS
- (+) SEGURIDAD DE CONTRATISTAS
- (+) UTILIDADES TRANSVERSALES DEL SISTEMA
(+) CUADRO DE MANDO
(+) PORTAL DE SEGURIDAD
(+) SEGUIMIENTO DE TAREAS Y ACCIONES
(+) ROLES Y PERMISOS
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 11 de 12
4. CONCLUSIONES
El objetivo de este estudio de mercado, era analizar el funcionamiento y prestaciones que
ofrecen diferentes Sistemas de Gestión en materia de Prevención de Riesgos Laborales.
Solamente se ha podido visualizar y analizar aquellos módulos/características que me han
facilitado tras solicitar una demo gratuita, el resto de la información disponible se facilitaba
previo pago de una cantidad de dinero.
Una vez analizados cada una de estos sistemas de PRL, se ha llegado a la conclusión de que
el mayor problema que se tiene actualmente es ofrecer al usuario una interfaz intuitiva con un
equilibrio de cantidad de información y facilidad de acceso.
Por otro lado también se ha visto deficiencias a la hora de almacenar y organizar toda la
documentación asociada al proceso de gestión de PRL: Certificados de cursos,
reconocimientos médicos, documentos de evaluación de riesgos han de estar debidamente
organizados y localizados para su fácil búsqueda en caso de ser necesario.
Por lo tanto, en el desarrollo del proyecto se desarrollará una interfaz intuitiva y un gestor
documental que cubra las deficiencias anteriormente mencionadas.
Endalia Versión: 1.0
Estudio de mercado Fecha: 28/12/2012
ESTUDIOMERCADO
CONFIDENCIAL 2007 Endalia Página 12 de 12
5. BIBLIOGRAFÍA
5.1 Referencias
[HUT] Edward J Huth Scientific Style and Format: The CBE Manual for Authors, Editors, and
Publishers Cambridge University Press 1994
Estándar de documentación de Formación y Perfeccionamiento S.L.
5.2 Referencias Web
[Ref. Web 1] http://www.wikipedia.org
[Ref. Web 2] http://www.e-rem.net/prevges.html
[Ref. Web 3] http://www.grupogpyme.com/gprevencion.html
[Ref. Web 4] http://www.prosafety.es/
Endalia
Especificación de requisitos
Versión 1.0 – Fecha: 11/12/2011
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 2 de 40
REVISIONES
Fecha Versión Descripción Autor
11/12/2011 1.0 Especificación de requisitos Miguel Ángel Catalán Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 3 de 40
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 ACRÓNIMOS 4 1.4 DEFINICIONES 4 1.5 REFERENCIAS 4 1.6 RESUMEN 4
2. DESCRIPCIÓN DEL PROCESO 6
2.1 FUNCION PRINCIPAL DEL SISTEMA 6 2.2 CARACTERÍSTICAS 7 2.2.1 TIPOS DE USUARIOS 7 2.2.2 ESTADOS DE UN EPI 7 2.2.3 ESTADOS DE UN RECONOCIMIENTO MÉDICO 7 2.2.4 TIPOS DE RECONOCIMIENTO MÉDICO 8 2.2.5 TIPOS DE FICHEROS GESTIONADOS 8
3. ESPECIFICACIÓN DE REQUISITOS 9
4. REQUISITOS FUNCIONALES 10
4.1 MÓDULO PRL 10 4.1.1 GESTIÓN DE EPIS 10 4.1.2 GESTIÓN DE RECONOCIMIENTOS MÉDICOS 12 4.1.3 REGISTRO DE LA ACTIVIDAD EN PRL POR EMPLEADO 13 4.1.4 GESTIÓN DE REQUERIMIENTOS EN PRL POR PUESTO 18 4.1.5 MONITORIZACIÓN 22 4.2 GESTOR DOCUMENTAL 34
5. REQUISITOS NO FUNCIONALES 37
6. BIBLIOGRAFÍA 40
6.1 REFERENCIAS 40 6.2 REFERENCIAS WEB 40
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 4 de 40
1. INTRODUCCIÓN
1.1 Propósito del documento
En este documento se detallan los aspectos y especificaciones funcionales y técnicas que el
sistema a desarrollar debe cumplir, por lo que debe tomarse como referencia para su
realización. Contiene una descripción de los requisitos del sistema lo más específica posible
para poder cumplirlos adecuadamente. La especificación de requisitos guiará el desarrollo del
resto de fases del proyecto.
1.2 Alcance del documento
El alcance del documento, comprende todo el periodo temporal del proyecto, ya que sus
contenidos pueden ser modificados en cualquier momento conforme a variaciones en las
especificaciones y necesidades del sistema.
1.3 Acrónimos
PRL: Prevención de Riesgos Laborales
SGPRL: Sistema de Gestión en Prevención de Riesgos Laborales.
EPI: Equipo de Protección Individual.
SQL: Structured Query Language.
GUI: interfaz gráfica de usuario (Graphic User Interface).
1.4 Definiciones
Interfaz gráfico de usuario: Conjunto de imágenes, objetos pictóricos y texto que
componen la capa con la que interactúa un usuario con un sistema computacional.
Plug-ins: módulo hardware o software que añade una característica o servicio
específico a un sistema más grande.
1.5 Referencias
En este documento no se han realizado referencias a otros documentos del proyecto.
1.6 Resumen
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: Función principal del sistema y sus características fundamentales.
Apartado 3: Introducción a la especificación de requisitos.
Apartado 4: Requisitos funcionales.
Apartado 5: requisitos no funcionales.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 5 de 40
Apartado 6: Bibliografía y referencias Web utilizadas para realizar este documento.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 6 de 40
2. DESCRIPCIÓN DEL PROCESO
2.1 FUNCION PRINCIPAL DEL SISTEMA
Se ha desarrollado sistema gestor de PRL integrado con gestor documental genérico, llamado
SGPRL, cuyo propósito es adaptarlo a medianas empresas para gestionar sus recursos en
materia de PRL. Este proyecto se centra en la gestión de EPIs y reconocimientos médicos,
requerimientos de cada puesto de trabajo, registro de la actividad en PRL asociada a cada
empleado y monitorización de esta actividad para evitar irregularidades que comprometan la
seguridad de la organización. Además se ha desarrollado un gestor de documentos que nos
permite tener localizada y correctamente gestionada toda la documentación asociada a los
procesos mencionados con anterioridad.
De esta forma, todas las funcionalidades desarrolladas se estructuran y localizan en los
siguientes módulos:
Módulo PRL:
o Gestión EPIs.
Gestor documental (especificaciones del EPI).
o Gestión Reconocimientos médicos.
o Monitorización.
Dentro del módulo de empleados:
o Gestión de registro de actividad en PRL:
EPIs:
Gestor documental (Entrega de EPIs)
Reconocimientos médicos
Gestor documental (Justificantes médicos)
Ficheros de Riesgos
Gestor documental (riesgos del empleado)
Formación recibida
Gestor documental (certificados de asistencia)
Dentro del módulo de estructura organizativa (puestos):
o Gestión requerimientos en PRL:
EPIs.
Reconocimientos médicos.
Riesgos laborales:
Gestor documental (análisis de riesgos del puesto)
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 7 de 40
Formación requerida.
2.2 CARACTERÍSTICAS
2.2.1 TIPOS DE USUARIOS
USUARIOS DEL MÓDULO DE PRL
o Usuario Administrador de PRL: se encarga de definir y registrar los EPIs y los
tipos de reconocimientos médicos manejados en la organización. Sus
funciones principales son añadir, eliminar o modificar los EPIs y tipos de
reconocimientos médicos que la empresa emplea para gestionarse en materia
de prevención de Riesgos Laborales. Así mismo también puede acceder a la
Monitorización de la actividad en PRL y a toda la información relacionada con
PRL de todos los empleados y puestos de la organización.
o Usuario Gestor de PRL: Tiene acceso a toda la información relacionada con
PRL de todos los empleados y puestos de la organización de los cuales es
gestor (dependen de él).
o Usuario de PRL: Solo tiene acceso a la información relacionada con PRL
relativa a él mismo.
USUARIOS DEL GESTOR DOCUMENTAL
o Usuario administrador de documentos: este usuario tiene la capacidad de
explotar todas las funcionalidades que nos brinda el gestor de documentos:
añadir, eliminar, editar documentos/carpetas, gestionar las versiones de los
documentos, envío por email, vista explorador, etc.
o Usuario escritor de documentos: tiene la capacidad de visualizar, añadir,
eliminar y editar documentos así como a las versiones de los mimos.
o Usuario lector de documentos: usuario que sólo puede visualizar los
documentos y carpetas. Las ediciones de los documentos se guardan en su
ordenador y los demás integrantes de la organización no pueden ver sus
cambios realizados.
2.2.2 ESTADOS DE UN EPI
Activo: EPIs registrados por el responsable de PRL y listos para su gestión tanto en
empleados como en puestos.
Histórico: EPIs que en el pasado se han usado/requerido en la organización pero
actualmente no se usan.
2.2.3 ESTADOS DE UN RECONOCIMIENTO MÉDICO
Activo: Reconocimientos médicos registrados por el responsable de PRL y listos para
su gestión tanto en empleados como en puestos.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 8 de 40
Histórico: Reconocimientos médicos que en el pasado se han gestionado pero
actualmente no se realizan.
2.2.4 TIPOS DE RECONOCIMIENTO MÉDICO
Los tipos de reconocimiento médico gestionados se diferencian por los protocolos
inspeccionados en la revisión médica pertinente:
- Básico.
- Trabajos en alturas.
- Posturas forzadas.
- Ruido.
- Manipulación de cargas.
- Materia particulada.
2.2.5 TIPOS DE FICHEROS GESTIONADOS
- Ficheros de EPI: Documentos en los que se especifican las características técnicas
relevantes del EPI en cuestión.
- Ficheros de certificado médico: Documentos que certifican que un cierto empleado
es APTO o NO APTO tras haberle realizado un cierto reconocimiento médico.
- Ficheros de certificado de asistencia a curso PRL: Documentos acreditativos de
que un cierto empleado ha asistido satisfactoriamente a la realización de un
determinado curso de Prevención de Riesgos Laborales.
- Ficheros de Riesgos:
o Ficheros del puesto: Estos documentos son elaborados por entidades
competentes y contiene el estudio y análisis de los riesgos que el puesto
de trabajo conlleva.
o Ficheros del empleado: Documento que se hace entrega a un empleado
con la relación de riesgos del puesto y el cual debe de ser firmado por el
empleado para certificar que conoce los riesgos del puesto que va a
ocupar.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 9 de 40
3. ESPECIFICACIÓN DE REQUISITOS
Los requisitos van a estar divididos en dos grupos:
Requisitos funcionales. Describen lo que debe hacer el sistema en cuanto a:
o Funciones de actualización de datos.
o Funciones de consulta.
o Informes proporcionados.
o Datos manejados.
o Interacción con otros sistemas.
Requisitos no funcionales. Describen las facilidades que debe proporcionar el sistema
en cuanto a:
o Rendimiento. Volumen y tamaño de datos.
o Frecuencia de tratamiento.
o Requisitos de seguridad:
Control de accesos.
Procedimientos de copias de respaldo y recuperación.
Integridad de la información.
o Requisitos especiales de comunicaciones.
o Requisitos organizacionales:
Directrices técnicas y de gestión.
Requisitos generales a cumplir en cuanto a necesidades futuras de
información.
Tendencias de evolución de la empresa.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 10 de 40
4. REQUISITOS FUNCIONALES
4.1 MÓDULO PRL
4.1.1 Gestión de EPIs
Nombre RF1 Listado de EPIs ya existentes
Descripción Puede visualizarse un listado de EPIs de acuerdo al estado que los clasifica. Dentro de este listado se pueden realizar las siguientes funcionalidades:
1. Añadir un nuevo EPI. Independientemente de la vista de EPI en la que se encuentra el usuario, al añadir un nuevo EPI, este será añadido como EPI en estado “Activo”.
2. Añadir una categoría de EPI.
3. Eliminar uno o varios EPIs: esto sólo es posible si es un EPI en estado “Histórico”.
4. Editar EPI: se abre la ficha del EPI que se desea editar.
5. Cambiar de estado el EPI.
6. Asignar masivamente EPIs a puestos.
7. Exportar en Excel el listado.
8. Enviar por correo el listado.
Información que se visualiza en el listado para cada EPI: nombre, código, categoría, estado, creación, normativa y descripción.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 11 de 40
Nombre RF2 Gestión de información de un EPI
Descripción Se detalla la información de un determinado EPI. Es un formulario que consta de los datos básicos de un EPI y de las siguientes pestañas:
1. General: información de un EPI.
2. Ficheros: estructura de carpetas y documentos asociados al EPI.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RF3 Información de un EPI
Descripción 1. Información básica: nombre, código, categoría, estado y meses hasta la próxima revisión.
2. Descripción
3. Normativa.
4. Observaciones
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF2
Comentarios
Nombre RF4 Ficheros de un EPI
Descripción 1. Listado y estructura de carpetas y documentos relacionados con el EPI en cuestión.
2. Funcionalidades: las que nos permite el gestor documental (definidas en RF 11)
Criticidad Alta
Implicaciones Técnicas
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 12 de 40
Coste y planificación medio
Riesgos
Dependencias RF2
Comentarios
4.1.2 Gestión de Reconocimientos Médicos
Nombre RF5 Listado de reconocimientos médicos ya existentes
Descripción Puede visualizarse un listado de reconocimientos médicos de acuerdo al estado que los clasifica. Dentro de este listado se pueden realizar las siguientes funcionalidades:
1. Añadir un nuevo reconocimiento médico. Independientemente de la vista de reconocimiento médico en la que se encuentra el usuario, al añadir un nuevo reconocimiento médico, este será añadido como reconocimiento médico en estado “Activo”.
2. Eliminar uno o varios reconocimientos médicos: esto sólo es posible si es un reconocimiento médico en estado “Histórico”.
3. Editar reconocimiento médico: se abre la ficha del reconocimiento médico que se desea editar.
4. Cambiar de estado el reconocimiento médico.
5. Asignar masivamente reconocimientos médicos a puestos.
6. Exportar en Excel el listado.
7. Enviar el listado por correo.
Información que se visualiza en el listado para cada reconocimiento médico: nombre, periodicidad y protocolos.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 13 de 40
Nombre RF6 Gestión de información de un reconocimiento médico
Descripción Se detalla la información de un determinado reconocimiento médico. Es un pop-up que consta de los siguientes datos:
1. Nombre de un reconocimiento médico.
2. Periodicidad del reconocimiento en meses.
3. Protocolos.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
4.1.3 Registro de la actividad en PRL por empleado
Nombre RF6 Gestión y registro en PRL por empleado
Descripción Se detalla el listado las actividades en materia de PRL en la ficha de cada empleado. Las funcionalidades se organizan en las siguientes pestañas:
1. EPIs: Listado de los EPIs entregados y documentos acreditativos de la entrega.
2. Reconocimientos médicos: Listado de todos los reconocimientos médicos realizados al empleado y gestión de certificados médicos.
3. Ficheros de Riesgos: Ficheros entregados al empleado con la relación de riesgos del puesto que ocupa firmado por él.
4. Formación recibida: listado de cursos de PRL realizados por le empleado.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 14 de 40
Comentarios
Nombre RF7 Listado de los EPIs entregados y documentos acreditativos de la entrega.
Descripción Se detalla el listado de los EPIs entregados y documentos acreditativos de la entrega. Las funcionalidades son:
1. Añadir EPI: Entrega de un EPI al empleado
2. Eliminar EPI: Retirada de un EPI a un empleado.
3. Exportar: Exportar a un fichero Excel el listado de EPIs entregados al empleado.
4. Historial de revisiones para cada EPI entregado.
Información que se visualiza en el listado para cada EPI entregado:
- Nombre del EPI
- Código de EPI
- Cantidad de EPI entregado en unidades
- Talla del EPI
- Fecha de entrega
- Fecha de la última revisión del EPI
- Estado del EPI en la última revisión (apto o no
apto)
- Fecha de la próxima revisión programada.
- Fecha de devolución del EPI
- Revisiones de cada EPI entregado
- Comentarios
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF6
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 15 de 40
Nombre RF8 Listado del historial de las revisiones para cada EPI entregado al empleado.
Descripción Se detalla el listado revisiones realizadas para cada EPI entregado al empleado. Las funcionalidades son:
1. Añadir Revisión al EPI.
2. Eliminar revisión del EPI.
3. Exportar: Exportar a un fichero Excel el listado de revisiones realizadas.
Información que se visualiza en el listado de revisiones para cada revisión realizada:
- Fecha de la revisión
- Estado (apto o no apto aunque es parametrizable)
- Comentarios de la revisión.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF7
Comentarios
Nombre RF9 Listado de los reconocimientos médicos realizados por el empleado y gestión de certificados médicos.
Descripción Se detalla el listado de los reconocimientos médicos realizados por el empleado. Las funcionalidades son:
1. Añadir reconocimiento médico.
2. Eliminar reconocimiento médico.
3. Exportar: Exportar a un fichero Excel el listado de reconocimientos médicos llevados a cabo por el empleado.
4. Gestión de los documentos de certificados médicos
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 16 de 40
para cada reconocimiento médico.
Información que se visualiza en el listado para cada reconocimiento médico realizado:
- Nombre del reconocimiento.
- Fecha de realización por el empleado.
- Estado del reconocimiento (apto o no apto aunque es parametrizable).
- Número de certificados almacenados.
- Comentarios.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF6
Comentarios
Nombre RF10 Gestión de los documentos de certificados médicos para cada reconocimiento
Descripción Funcionalidades: las que nos permite el gestor documental (definidas en RF 15) dirigidas a los documentos de certificados médicos.
Criticidad Alta
Implicaciones Técnicas
Coste y planificación medio
Riesgos
Dependencias RF9
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 17 de 40
Nombre RF11 Gestión de los documentos de conocimiento de los riesgos del puesto que ocupa un empleado
Descripción Funcionalidades: las que nos permite el gestor documental (definidas en RF 15) dirigidas a los documentos de aceptación de riesgos del puesto por parte del empleado.
Criticidad Alta
Implicaciones Técnicas
Coste y planificación Alto
Riesgos
Dependencias RF6
Comentarios
Nombre RF12 Listado de los cursos de PRL realizados por el empleado y gestión de los certificados de asistencia.
Descripción Se detalla el listado de los cursos en los que está matriculado el empleado y gestión de certificados de asistencia para cada curso. Las funcionalidades son:
1. Añadir curso.
2. Añadir, visualizar el certificado de asistencia en el caso de que exista.
3. Exportar: Exportar a un fichero Excel el listado de cursos realizados por el empleado.
Información que se visualiza en el listado para cada curso realizado:
- Nombre del curso
- Código de curso
- Duración en horas del curso
- Fecha de fin de curso
- Calificación obtenida en el curso
- Nombre del fichero del certificado de asistencia.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF6
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 18 de 40
Comentarios
4.1.4 Gestión de requerimientos en PRL por puesto
Nombre RF13 Gestión requerimientos en PRL por puesto
Descripción Se detalla el listado de requerimientos en materia de PRL en la ficha de cada puesto. Las funcionalidades se organizan en las siguientes pestañas:
1. EPIs: Listado de los EPIs requeridos para su uso en el puesto de trabajo.
2. Reconocimientos médicos: Listado de los reconocimientos médicos necesarios para certificar la aptitud en el puesto.
3. Riesgos: Listado de los riesgos del puesto definidos por una autoridad competente y los documentos donde se plasma el estudio de riesgos del puesto.
4. Formación recibida: Listado de cursos de PRL necesarios para el puesto.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RF14 Listado de los EPIs requeridos para el puesto.
Descripción Se detalla el listado de los EPIs requeridos para su uso obligatorio en el puesto. Las funcionalidades son:
1. Añadir EPI: Es necesario el uso de un nuevo EPI en el puesto.
2. Eliminar EPI: Un EPI deja de ser necesario para el puesto.
3. Exportar: Exportar a un fichero Excel el listado de EPIs necesarios para el puesto.
Información que se visualiza en el listado para cada EPI requerido:
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 19 de 40
- Nombre del EPI.
- Código de EPI.
- Categoría.
- Cantidad de EPI necesario en unidades.
- Comentarios.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF13
Comentarios
Nombre RF15 Listado de los reconocimientos médicos necesarios para el puesto.
Descripción Se detalla el listado de los reconocimientos médicos necesarios por el puesto actual y en caso de que existan también se muestran los del puesto genérico. Las funcionalidades son:
1. Añadir reconocimiento médico.
2. Eliminar reconocimiento médico (si el reconocimiento médico pertenece al genérico solo puede eliminarse desde el puesto genérico)
3. Exportar: Exportar a un fichero Excel el listado de reconocimientos médicos llevados a cabo por el empleado.
Información que se visualiza en el listado para cada reconocimiento médico necesario:
- Nombre del reconocimiento.
- Periodicidad del reconocimiento
- Comentarios.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 20 de 40
Riesgos
Dependencias RF13
Comentarios
Nombre RF16 Listado de los riesgos Laborales registrados para el puesto y documentos asociados.
Descripción Se detalla el listado de los riesgos registrados para el puesto y toda la documentación que lo acredita. Este registro lo elabora una autoridad competente. Las funcionalidades son:
1. Añadir riesgo al puesto.
2. Eliminar riesgo del puesto.
3. Exportar: Exportar a un fichero Excel el listado de los riesgos registrados para el puesto.
4. Gestionar la documentación relativa a los riesgos.
Información que se visualiza en el listado para cada riesgo registrado:
- Categoría del riesgo.
- Riesgo general.
- Riesgo específico.
- Gravedad del riesgo.
- Probabilidad del riesgo.
- Severidad del riesgo.
- Acciones preventivas del riesgo
- Observaciones.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF13
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 21 de 40
Nombre RF17 Gestionar la documentación relativa a los riesgos
Descripción 1. Listado y estructura de carpetas y documentos relacionados con los riesgos en cuestión.
2. Funcionalidades: las que nos permite el gestor documental (definidas en RF 11).
Criticidad Alta
Implicaciones Técnicas
Coste y planificación Medio
Riesgos
Dependencias RF13
Comentarios
Nombre RF18 Listado de los cursos de PRL necesarios para el puesto.
Descripción Se detalla el listado de los cursos necesarios para desempeñar el puesto. Las funcionalidades son:
1. Añadir curso.
2. Eliminar curso.
3. Exportar: Exportar a un fichero Excel el listado de cursos necesarios para el puesto.
Información que se visualiza en el listado para cada curso necesario:
- Nombre del curso.
- Código de curso.
- Duración en horas del curso.
- Comentarios.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF13
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 22 de 40
4.1.5 Monitorización
Nombre RF19 Monitorización de la actividad en PRL
Descripción Por defecto se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de las anomalías o aspectos a tener en cuenta en materia de PRL. Las funcionalidades se organizan en las siguientes pestañas y vistas:
1. Monitorización de EPIs:
- Vista Estructura (Todos): A la izquierda tenemos el árbol de puesto de la organización y a la derecha el listado de todos los EPIS en posesión de todos los empleados por debajo del puesto seleccionado en el árbol.
- Vista Estructura (Pendientes). A la izquierda tenemos el árbol de puesto de la organización y a la derecha el listado de todos los EPIS en posesión de todos los empleados que tienen algo pendiente de revisar:
- Fecha de la revisión excedida.
- EPI requerido por el puesto y el empleado no lo
tiene.
- EPIs que en su última revisión han sido
calificados como NO APTO
- Vista empleados: A la izquierda tenemos el árbol de empleados de la organización y a la derecha el listado de todos los EPIS en posesión de todos los empleados por debajo del puesto seleccionado en el árbol.
2. Monitorización de Reconocimientos médicos:
- Vista Estructura (Todos): A la izquierda tenemos el árbol de puesto de la organización y a la derecha el listado de todos los reconocimientos médicos realizados por los empleados por debajo del puesto seleccionado.
- Vista Estructura (Pendientes): A la izquierda tenemos el árbol de puesto de la organización y a la derecha el listado de todos los reconocimientos médicos realizados por los empleados por debajo del puesto seleccionado que tienen algún aspecto que revisar:
-Fecha programada del reconocimiento excedida.
- Reconocimiento requerido por el puesto y el
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 23 de 40
empleado no lo tiene.
- Reconocimiento que ha sido calificado como NO
APTO
- Vista empleados: A la izquierda tenemos el árbol de
empleados de la organización y a la derecha el
listado de todos los reconocimientos médicos
realizados por los empleados seleccionados en el
árbol.
3. Monitorización de Ficheros de Riesgos:
- Vista Estructura (Ficheros de puestos). A la izquierda tenemos el árbol de puestos de la organización y a la derecha el listado de todos los ficheros de riesgos de los puestos seleccionados en el árbol.
- Vista Estructura (Ficheros de empleados): A la izquierda tenemos el árbol de puestos de la organización y a la derecha el listado de todos los ficheros de riesgos de los empleados seleccionados en el árbol.
- Vista empleados (Ficheros de empleados): A la izquierda tenemos el árbol de empleados de la organización y a la derecha el listado de todos los ficheros de riesgos de los empleados seleccionados en el árbol.
4. Monitorización de Formación:
-Vista Estructura (Todos): A la izquierda tenemos el árbol de puesto de la organización y a la derecha el listado de todos los cursos realizados por los empleados por debajo del puesto seleccionado.
- Vista Estructura (Pendientes): A la izquierda tenemos el árbol de puesto de la organización y a la derecha el listado de todos los cursos realizados por los empleados por debajo del puesto seleccionado que tienen algún aspecto que revisar:
-Fecha programada del curso excedida.
- Curso requerido por el puesto y el empleado no
lo tiene.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 24 de 40
- Curso que ha sido calificado como NO APTO
- Vista empleados: A la izquierda tenemos el árbol
de empleados de la organización y a la derecha
el listado de todos los cursos realizados por los
empleados seleccionados en el árbol
Dependiendo de la vista y pestaña seleccionada se mostrará la información especificada en los respectivos RF enumerados a continuación.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RF20 Monitorización de EPIs en vista Estructura (Todos):
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con EPIs en posesión a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Código de empleado.
- Nombre del EPI.
- Código EPI.
- Cantidad en unidades de EPI.
- Fecha de entrega de EPI al empleado.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 25 de 40
- Fecha de la última revisión del EPI.
- Estado de la última revisión.
- Nombre del puesto.
- Código del puesto.
- Nombre del puesto genérico.
- Código del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF21 Monitorización de EPIs en vista Estructura (Pendientes):
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con EPIs en posesión con algún aspecto pendiente de revisar a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Nombre del EPI.
- Código EPI.
- Motivo por el cual es necesario revisarla
- Nombre del puesto.
- Nombre del puesto genérico.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 26 de 40
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF22 Monitorización de EPIs en vista Empleados (Todos):
Descripción Se detalla el árbol con la estructura de empleados de la organización a la izquierda y listado de todos los empleados con EPIs en posesión a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Código de empleado.
- Nombre del EPI.
- Código EPI.
- Cantidad en unidades de EPI.
- Fecha de entrega de EPI al empleado.
- Fecha de la última revisión del EPI.
- Estado de la última revisión.
- Nombre del puesto.
- Código del puesto.
- Nombre del puesto genérico.
- Código del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 27 de 40
para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF23 Monitorización de reconocimientos médicos en vista Estructura (Todos):
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con reconocimientos médicos realizados a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Código de empleado.
- Nombre del reconocimiento médico.
- Código reconocimiento médico.
- Fecha realización del reconocimiento.
- Estado del reconocimiento (apto o no apto).
- Nombre del puesto.
- Código del puesto.
- Nombre del puesto genérico.
- Código del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 28 de 40
Comentarios
Nombre RF24 Monitorización de reconocimientos médicos en vista Estructura (Pendientes):
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con reconocimientos realizados con algún aspecto pendiente de revisar a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Nombre del reconocimiento médico.
- Motivo por el cual es necesario revisar el
reconocimiento médico.
- Nombre del puesto.
- Nombre del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF25 Monitorización de reconocimientos médicos en vista Empleados (Todos):
Descripción Se detalla el árbol con la estructura de empleados de la organización a la izquierda y listado de todos los empleados con reconocimientos médicos a la derecha. Las
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 29 de 40
funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Código de empleado.
- Nombre del reconocimiento médico.
- Fecha de realización del reconocimiento.
- Calificación del reconocimiento (apto / no apto)
- Comentarios.
- Nombre del puesto.
- Código del puesto.
- Nombre del puesto genérico.
- Código del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF26 Monitorización de cursos en vista Estructura (Todos):
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con cursos realizados a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 30 de 40
el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Código de empleado.
- Nombre del curso.
- Código del curso.
- Fecha inicio del curso.
- Duración en horas.
- Fecha fin del curso.
- Lugar de impartición.
- Calificación del empleado en el curso
- Certificado de asistencia.
- Nombre del puesto.
- Código del puesto.
- Nombre del puesto genérico.
- Código del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF27 Monitorización de cursos PRL en vista Estructura (Pendientes):
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con cursos en PRL con algún aspecto pendiente de revisar a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 31 de 40
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre empleado.
- Nombre del curso.
- Motivo por el cual es necesario revisar el
curso en PRL.
- Nombre del puesto.
- Nombre del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF28 Monitorización de cursos en vista Empleados (Todos):
Descripción Se detalla el árbol con la estructura de empleados de la organización a la izquierda y listado de todos los empleados con sus cursos en PRL a la derecha. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre Empleado.
- Código de empleado.
- Nombre del curso.
- Código del curso.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 32 de 40
- Fecha inicio del curso.
- Duración del curso en horas.
- Fecha fin del curso.
- Lugar de impartición del curso.
- Calificación del curso.
- Certificado de asistencia.
- Nombre del puesto.
- Código del puesto.
- Nombre del puesto genérico.
- Código del puesto genérico.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF29 Monitorización de ficheros de puestos en vista Estructura:
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los puestos con ficheros de riesgos resultado del análisis del puesto por una autoridad competente. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada puesto:
- Nombre del puesto.
- Código de puesto.
- Nombre del fichero.
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 33 de 40
- Tipo.
- Fecha de última actualización del fichero.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
Nombre RF30 Monitorización de ficheros de empleados en vista Estructura:
Descripción Se detalla el árbol con la estructura de puestos de la organización a la izquierda y listado de todos los empleados con ficheros de aceptación de riesgos del puesto que ocupa. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre del puesto.
- Código de puesto.
- Nombre del fichero.
- Tipo.
- Fecha de última actualización del fichero.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 34 de 40
Comentarios
Nombre RF31 Monitorización de ficheros de empleados en vista Empleados:
Descripción Se detalla el árbol con la estructura de empleados de la organización a la izquierda y listado de todos los empleados con ficheros de aceptación de riesgos del puesto que ocupa. Las funcionalidades son:
1. Editar el puesto seleccionado del árbol de la izquierda.
2. Exportar a Excel tanto el listado de la derecha como el árbol de la izquierda.
3. Enviar por correo el listado de la derecha en Excel.
Información que se visualiza en el listado para cada empleado:
- Nombre del empleado.
- Código de empleado.
- Nombre del fichero.
- Tipo.
- Fecha de última actualización del fichero.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante consultas SQL al máximo para no ralentizar el sistema
Coste y planificación Alto
Riesgos
Dependencias RF19
Comentarios
4.2 GESTOR DOCUMENTAL
Nombre RF15 Gestión de documentos con posibilidad de organizarlos en carpetas.
Descripción Puede gestionarse documentación y organizarse en carpetas según preferencias. Se ofrecen las siguientes funcionalidades:
1. Listado de estructura de documentos y su
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 35 de 40
organización en carpetas.
2. Añadir un nuevo documento/carpeta.
3. Eliminar uno o varios documentos o carpetas.
4. Editar documentos o carpetas.
5. Mover documentos y carpetas a otra ubicación.
6. Gestionar las versiones de documentos.
7. Exportar en Excel el listado.
8. Enviar por email documentos.
Información que se visualiza en el listado para cada documento gestionado:
- Nombre documento/carpeta.
- Icono formato del documento
- Versión del documento.
- Fecha última modificación del documento.
- Autor de la última modificación.
- Tamaño en KB del fichero.
- Comentarios.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante la correcta organización de las bibliotecas de documentos en SharePoint.
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RF16 Gestión de versiones de un documento.
Descripción Listado de las versiones de un determinado documento ordenadas de la más reciente a la más antigua. Se ofrecen las siguientes funcionalidades:
1. Añadir versión.
2. Eliminar versión (la más reciente no se puede eliminar).
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 36 de 40
3. Visualizar versión
4. Restaurar versión.
5. Exportar el listado de versiones.
Información que se visualiza en el listado para cada versión del documento gestionado:
- Número de versión.
- Fecha creación de la versión.
- Autor de la versión.
- Tamaño en KB de la versión.
- Comentarios de la versión.
Criticidad Alta
Implicaciones Técnicas Optimizar las búsquedas mediante la correcta organización de las bibliotecas de documentos en SharePoint.
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 37 de 40
5. REQUISITOS NO FUNCIONALES
Nombre RNF1 Entorno tecnológico
Descripción Tecnología: NET Lenguaje de programación: C# y XML. Entorno de programación. Visual Studio 2008. Generación de modelo de datos: SQL Server. Herramientas de seguimiento, control de versiones
del código fuente e historial: Team System Studio. Pruebas unitaria y de manejo de elementos de
interfaz de usuario: NUnit Mapeo Objeto-Relacional (ORM): NHibernate. Sharepoint 2010 para desarrollo del gestor
documental.
Criticidad Alta
Implicaciones Técnicas
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RNF2 Configuración de equipos
Descripción Los equipos clientes en donde se va a implantar el sistema desarrollado deben cumplir las siguientes características básicas:
512MB de memoria RAM
1GHz de procesador
200MB de espacio en disco duro
Microsoft .Net Framework 2.0
Criticidad Alta
Implicaciones Técnicas
Coste y planificación
Riesgos
Dependencias
Comentarios
Nombre RNF3 Rendimiento
Descripción Ninguna operación o interacción con el sistema debe de superar los 4 segundos de espera por parte del usuario.
Criticidad Alta
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 38 de 40
Implicaciones Técnicas
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RNF4 Aplicación intuitiva
Descripción La aplicación deberá ser intuitiva y fácil de usar, incluso por personas poco familiarizadas con el entorno.
Criticidad Alta
Implicaciones Técnicas
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Nombre RNF5 Interacción de la aplicación a través de GUI
Descripción La interacción con el sistema desarrollado será a través de GUI y no a través de línea de comandos.
Criticidad Media
Implicaciones Técnicas
Coste y planificación Medio
Riesgos
Dependencias
Comentarios
Nombre RNF6 Aplicación escalable
Descripción El sistema desarrollado será fácilmente escalable. Se podrán añadir nuevos módulos y plug-ins con facilidad.
Criticidad Alta
Implicaciones Técnicas
Coste y planificación Alto
Riesgos
Dependencias
Comentarios
Endalia Versión: 1.0
Especificación de requisitos Fecha:
11/12/2011
ESPECIFICACIÓN DE REQUISITOS
CONFIDENCIAL 2011 Endalia Página 40 de 40
6. BIBLIOGRAFÍA
6.1 Referencias
[IGJ, 2000] - I. Jacobson, G. Booch, J. Rumbaugh. 2000. El Proceso Unificado de Desarrollo de
Software. Pearson Education
6.2 Referencias web
[Ref. Web 1] http://es.wikipedia.org
[Ref. Web 2] http://www.monografias.com
[Ref. Web 3] http://www.infor.uva.es/~descuder/proyectos/ipo/requi.htm
Endalia
Modelo de negocio
Versión 1.0 – Fecha: 03/05/2012
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 2 de 13
REVISIONES
Fecha Versión Descripción Autor
03/05/2012 1.0 Realización del documento del modelo de
negocio Miguel Catalán Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 3 de 13
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 ACRÓNIMOS 4 1.4 DEFINICIONES 4 1.5 REFERENCIAS 4 1.6 RESUMEN 4
2. OBJETIVO 6
3. LA EMPRESA CLIENTE 7
4. EL PROBLEMA 8
5. EPIS GESTIONADOS POR LA EC 9
5.1 INTRODUCCIÓN 9 5.2 LISTADO DE EPIS POR CATEGORÍAS 9 5.3 LISTADO DE RECONOCIMIENTOS MÉDICOS 10 5.4 LISTADO DE CURSOS EN PRL 10 5.5 TIPOS DE FICHEROS A GESTIONAR 10
6. OBJETIVO DE DESARROLLO DEL SISTEMA 12
7. BIBLIOGRAFÍA 13
7.1 REFERENCIAS 13 7.2 REFERENCIAS WEB 13
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 4 de 13
1. INTRODUCCIÓN
1.1 Propósito del documento
El presente documento describe el entorno de la empresa industrial en donde se ha desarrollado el
sistema SGPRL.
1.2 Alcance del documento
Este documento comprende la descripción del problema a resolver y los compromisos adoptados, según
la política de desarrollo de Endalia SL, para la futura reutilización del sistema desarrollado. Es un
complemento del estudio del mercado, especificación de requisitos y análisis del sistema a desarrollar.
1.3 Acrónimos
SGPRL: Sistema de Gestión y Prevención en Riesgos Laborales
EC: Empresa Cliente.
1.4 Definiciones
1.5 Referencias
En este documento se referencian los siguientes documentos del proyecto:
ESTUDIO DEL MERCADO.doc: Documento en el que se detallan las alternativas existentes en
el mercado y se definen algunas características que debe tener el sistema a desarrollar.
ESPECIFICACIÓN DE REQUISITOS.doc: Documento en el que se especifican los requisitos del
sistema.
1.6 Resumen
Este documento describe el modelo de negocio en que está incluido en proyecto de desarrollo del
sistema SGPRL. Se compone de los siguientes apartados:
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: Objetivo del documento. Conocer el modelo de negocio en el que está incluido el
SGPRL.
Apartado 3: La empresa cliente.
Apartado 4: El problema.
Apartado 5: Listado de Elementos PRL gestionados por el SGPRL
Apartado 6: Objetivo de desarrollo del sistema.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 5 de 13
Apartado 7: Bibliografía y referencias web utilizadas para la realización de este documento.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 6 de 13
2. OBJETIVO
Como ya se ha detallado en el documento de estudio del mercado, el objetivo principal era desarrollar
parte de un sistema ERP que se encargara de la gestión de la Prevención de los Riesgos Laborales de
la empresa. El sistema SGPRL se ha desarrollado bajo ciertos compromisos de reutilización, pero dentro
de un entorno industrial particular.
En este documento se describen las características específicas del problema a resolver y cómo se ha
adaptado el sistema para cumplirlas, sin alejarse del compromiso de reutilización buscado.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 7 de 13
3. LA EMPRESA CLIENTE
El sistema SGPRL es una parte dentro de un proyecto de desarrollo para una EC de Endalia SL. En
particular, la EC es un centro de investigación fundado en 1993 con el apoyo de la Universidad de
Zaragoza, para crear, desarrollar y transferir soluciones innovadoras y conocimiento científico-técnico al
sector empresarial en el ámbito energético. Su misión es impulsar la mejora de la eficiencia energética y
el despliegue de energías renovables mediante el desarrollo de actividades de I+D+i y acciones
formativas que respondan a las necesidades de los sectores productivos nacionales e internacionales,
contribuyendo a un desarrollo sostenible.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 8 de 13
4. EL PROBLEMA
El problema actual de la EC es que no tiene un sistema informático que gestione toda la información en
materia de Prevención de Riesgos Laborales. Su forma de trabajar hasta el momento en cuanto a PRL
está basado en documentación en formato papel y ficheros sin una rigurosa ubicación y localización de
los mismos. La EC necesita tener gestionada esta información de forma adecuada para de esta forma
mejorar los resultados en una futura evaluación y certificación según la norma OHSAS.
Por otro lado la EC necesita poder monitorizar la actividad PRL para poder localizar y prevenir un posible
accidente laboral.
Finalmente, y dada la importancia, sensibilidad y volumen de toda la documentación generada (partes de
entrega de EPIs, Rec. Médicos de los empleados, etc etc) la EC quiere gestionar toda esta
documentación de manera precisa.
Para resolver este problema, se ha decidido actualizar su ERP integrando el SGPRL. Con esta solución
tendremos gestionada y localizada, ya sea por puesto o empleado de la organización, toda la
información relativa a PRL. Además se dota de un sistema de monitorización para prevenir posibles
accidentes y localizar anomalías. Por último se integra todo lo anterior con un gestor documental para
manejar los documentos de PRL.
En cuanto a la gestión comercial el problema radica en que, poseen datos repetidos, no tiene control de
históricos ni de pedidos asociados de una forma organizada e intuitiva.
El desarrollo del sistema SGPC permite resolver dos de los problemas: el primero comprende la gestión
comercial referente a clientes, proveedores y productos, y el segundo abarca la gestión de almacén e
inventario.
A continuación se enumeran las entidades o elementos particulares de la EC en materia de Prevención
de Riesgos Laborales a gestionar por el SGPRL.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 9 de 13
5. ELEMENTOS PRL GESTIONADOS POR LA EC
5.1 Introducción
El catálogo de elementos que gestiona la EC para asegurar el objetivo de “0 accidentes” son los
enumerados a continuación:
5.2 Listado de EPIs por categorías
Como se puede observar, los EPIs se clasifican en categorías. Esta clasificación les permite diferenciar y
agrupar los distintos EPIs que gestionan. Las categorías son configurables pudiendo organizar los EPIs
según mejor convenga.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 10 de 13
5.3 Listado de Reconocimientos médicos
Los reconocimientos médicos que se efectúan según los requerimientos de los puestos de trabajo son
los siguientes:
5.4 Listado de Cursos en PRL
Los cursos en materia de PRL que se van a gestionar son los siguientes:
5.5 Tipos de ficheros a gestionar
Los tipos de ficheros que el gestor documental del SGPRL va a gestionar son los siguientes:
- Documentos de especificación de EPIs.
- Partes de entrega de EPIs a empleados.
- Certificados de asistencia a cursos PRL de los empleados.
- Documentos acreditativos de la aceptación por parte del empleado de los Riesgos que su
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 11 de 13
puesto conlleva.
- Documentos donde se detalla o ilustra un análisis de riesgos de cada uno de los puestos de
la EC (realizados por una entidad competente en materia de auditoría PRL).
- Certificados médicos con el resultado de una exploración médica requerida por el puesto.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 12 de 13
6. OBJETIVO DE DESARROLLO DEL SISTEMA
En el presente documento se han detallado las características específicas del entorno en el que se ha
desarrollado el sistema SGPC. Sin embargo, como se mencionado antes, el modelo debe cumplir un
compromiso de reutilización.
Este compromiso consiste en que el sistema desarrollado, pueda ser fácilmente adaptado en un futuro a
otras ECs de Endalia. Esta es una de las razones por la que, el modelo de base de datos y la GUI del
sistema, se han modelado e implementado abstrayendo al máximo las particularidades del entorno.
El objetivo es cumplir con las necesidades de la EC pero a la vez desarrollar un nuevo producto con el
que Endalia pueda ofrecer un nuevo servicio dentro del mercado al que pertenece.
Endalia Versión: 1.0
Modelo de negocio Fecha:
3/05/2012
MODELO DE NEGOCIO
CONFIDENCIAL 2011 Endalia Página 13 de 13
7. BIBLIOGRAFÍA
7.1 Referencias
[DAC 2010] Documentos de Análisis del proyecto CONSIST de Endalia, 2010.
7.2 Referencias web
[Ref. Web 1] http://www.grupoconsist.com/esp/
Endalia
Análisis
Versión 1.0 – Fecha: 19/12/2011
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 2 de 37
REVISIONES
Fecha Versión Descripción Autor
19/12/2011 1.0 Documento de análisis Miguel Catalán Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 3 de 37
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4
1.2 ALCANCE DEL DOCUMENTO 4
1.3 ACRÓNIMOS 4
1.4 DEFINICIONES 4
1.5 REFERENCIAS 5
1.6 RESUMEN 5
2. DESCRIPCIÓN DEL PROCESO 6
3. ANÁLISIS DE LOS CASOS DE USO 7
3.1 INTRODUCCIÓN 7
3.2 ACTORES DE LOS CASOS DE USO 7
3.3 CASOS DE USO 8
3.3.1 ESQUEMA GENERAL DE LOS CASOS DE USO 8
3.4 DIAGRAMAS DE SECUENCIA Y ACTIVIDAD 24
3.4.1 ACCESO AL SISTEMA 24
3.4.2 CONSULTAR PARÁMETROS DEL SISTEMA 25
3.4.3 AÑADIR PARÁMETRO DEL SISTEMA 27
3.4.4 EDITAR PARÁMETRO DEL SISTEMA 28
3.4.5 ELIMINAR PARÁMETROS DEL SISTEMA 30
4. ANÁLISIS DE GESTIÓN DE FICHEROS CON SHAREPOINT 32
5. ESTRUCTURA ESTÁTICA 34
5.1 INTRODUCCIÓN 34
5.2 IDENTIFICACIÓN DE PAQUETES DE ANÁLISIS GENERAL 34
6. REQUERIMIENTOS ESPECIALES 36
6.1 PERSISTENCIA 36
6.2 GESTIÓN DE TRANSACCIONES 36
6.3 TOLERANCIA A FALLOS 36
6.4 SEGURIDAD 36
6.5 CONCURRENCIA 36
6.6 INTERNACIONALIZACIÓN 36
7. REFERENCIAS 37
7.1 REFERENCIAS WEB 37
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 4 de 37
1. INTRODUCCIÓN
1.1 Propósito del documento
El propósito del presente documento es describir la fase de análisis del proyecto de desarrollo
de una aplicación para la gestión y administración de los procesos y documentación en
Prevención de Riesgos Laborales, según los requisitos del documento de especificación de
requisitos.
Se analiza la arquitectura del sistema, definiendo casos de uso, estructura de paquetes y
clases identificadas.
1.2 Alcance del documento
El Alcance del documento comprende todas las fases de análisis del proyecto SGPC.
1.3 Acrónimos
PRL: Prevención de Riesgos Laborales.
Interfaz: Medio de comunicación entre dos entidades ya sean físicas o lógicas.
API: Interfaz para la programación de aplicaciones.
SGPRL: Sistema de Gestión en PRL
EPI: Equipo de Protección Individual.
RUP: Rational Unified Process.
GUI: Graphic User Interface.
BD: Base de Datos.
APRL: Administrador de PRL.
GPRL: Gestor de PRL
UPRL: Usuario de PRL
MGEPI: Módulo de Gestión de EPIs.
MGRM: Módulo de Gestión de Reconocimientos Médicos.
MM: Módulo de Monitorización.
MRAPRLE: Módulo de Registro de la Actividad en PRL por Empleado.
MRPRLP: Módulo de Requerimientos en PRL por Puesto.
1.4 Definiciones
Caso de uso: Técnica para describir la interacción entre un usuario del sistema y éste.
Diagrama de casos de uso: Notación gráfica que describe un caso de uso.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 5 de 37
Diagrama de actividades: Notación gráfica que representa los flujos de trabajo paso a
paso de los componentes en un sistema. Muestra el flujo de control general del
sistema.
Diagrama de secuencia: Notación gráfica que muestra la interacción de un conjunto de
objetos en una aplicación a través del tiempo
UML: Es un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema desarrollado por Rational de uso extendido.
1.5 Referencias
En este documento se realizan referencias a los siguientes documentos del proyecto:
ESPECIFICACION DE REQUISITOS.doc: Documento en el que se especifican los
requisitos del sistema.
1.6 Resumen
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: descripción del proceso de análisis.
Apartado 3: Análisis de casos de uso, diagramas de casos de uso, diagramas de
secuencia y diagramas de actividad.
Apartado 4: estructura estática del sistema.
Apartado 5: requerimientos especiales del sistema.
Apartado 6: Bibliografía y referencias Web utilizadas para la realización de este
documento.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 6 de 37
2. DESCRIPCIÓN DEL PROCESO
Tomando como base, los requisitos descritos en el documento de especificación de requisitos,
se pasa a identificar los actores del sistema y su interacción con éste, mediante la utilización de
casos de uso.
Una vez detallado el funcionamiento del sistema, se identifican los componentes de la
estructura estática del sistema, separándose en módulos de análisis que faciliten su manejo.
También se describen las relaciones existentes entre las entidades y los módulos de análisis.
Por último, se analizan requisitos especiales que pueden ser necesarios, identificando
restricciones y particularidades que puedan surgir en diferentes fases del proyecto.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 7 de 37
3. ANÁLISIS DE LOS CASOS DE USO
3.1 Introducción
Los casos de uso son una forma esquemática de identificar la interacción entre los diferentes
usuarios y el sistema desarrollado (SGPRL).
3.2 Actores de los casos de uso
Un actor es un rol que un usuario juega con respecto al sistema. Es importante destacar que un
actor es un rol, porque no necesariamente representa a una persona en particular, sino más
bien la labor que realiza frente al sistema. Los tipos de usuarios que interactúan con el sistema
y que han sido definidos en el documento de especificación de requisitos, son los siguientes:
Usuario Administrador de PRL: Se encarga de definir y manejar todos los parámetros
del módulo de PRL. Tiene acceso a toda la información en materia de PRL para todos
los empleados y puestos de la organización.
Usuario Gestor de PRL: No tiene acceso a los parámetros del módulo de PRL. Tiene
acceso a toda la información en materia de PRL para aquellos empleados y puestos
de los cuales es gestor (empleados y puestos dependientes de él).
Usuario del módulo de PRL: No tiene acceso a los parámetros del módulo de PRL.
Tiene acceso a toda la información en materia de PRL relativa a él mismo. No puede
tener acceso a información de otros empleados de la organización ni tampoco a
aquellos puestos en los cuales no esté ocupando.
Existe un rol por cada tipo de usuario:
Rol Administrador de PRL. Por brevedad, en el resto del documento, nos referiremos a
este rol como “APRL”.
Rol Gestor de PRL. Por brevedad, en el resto del documento, nos referiremos a este rol
como “GPRL”.
Rol Usuario de PRL. Por brevedad, en el resto del documento, nos referiremos a este
rol como “UPRL”.
Cada rol interviene en uno de los siguientes módulos del sistema:
Módulo de Gestión de EPIs: es el sistema en donde solo interviene el usuario APRL.
Por brevedad, en el resto del documento, nos referiremos a este sistema como
“MGEPI”.
Módulo de Gestión de Reconocimientos Médicos: es el sistema en donde solo
interviene el usuario APRL. Por brevedad, en el resto del documento, nos referiremos a
este sistema como “MGRM”.
Módulo de Monitorización: en este sistema intervienen los tres usuarios (APRL, GPRL
y UPRL). Por brevedad, en el resto del documento, nos referiremos a este sistema
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 8 de 37
como “MM”.
Módulo Registro de Actividad PRL por Empleado: en este sistema intervienen los tres
usuarios (APRL, GPRL y UPRL). Por brevedad, en el resto del documento, nos
referiremos a este sistema como “MRAPRLE”.
Módulo Requerimientos en PRL por Puesto: en este sistema intervienen los tres
usuarios (APRL, GPRL y UPRL). Por brevedad, en el resto del documento, nos
referiremos a este sistema como “MRPRLP”.
3.3 Casos de uso
3.3.1 Esquema general de los casos de uso
A continuación se detallan los casos de uso correspondientes a cada uno de los roles definidos
3.3.1.1 Acceso al sistema
Para acceder al sistema es obligatorio introducir los datos de acceso (usuario y contraseña).
Esto permite identificar qué tipo de usuario está accediendo y qué permisos posee.
Diagrama de caso de uso
Figura 1. Casos de uso: Acceso al sistema
3.3.1.2 Administrador de PRL
Configurar módulo MGEPI:
El usuario APRL puede configurar el módulo del sistema MGEPI.
o Diagrama de casos de uso
Nivel 0
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 9 de 37
Figura 2. Casos de uso: Configuración de sistema MGEPI. Nivel0
Nivel 1
Figura 3. Configuración de sistema MGEPI. Nivel1
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 10 de 37
Nivel 2
Figura 4. Configuración de sistema MGEPI. Nivel2
Como se puede observar en el diagrama de casos de uso de nivel 2, los casos de uso en
los que interviene este usuario son los siguientes:
o Consultar listado de categorías y EPIs.
o Consultar Categoría.
o Consultar EPI.
o Modificar categoría.
o Modificar EPI
o Añadir categoría.
o Añadir EPI.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 11 de 37
Configurar módulo MGRM:
El usuario APRL puede configurar el módulo del sistema MGRM.
o Diagrama de casos de uso
Nivel 0
Figura 5. Configuración de sistema MGRM. Nivel 0
Nivel 1
Figura 6. Configuración de sistema MGRM. Nivel 1
Como se puede observar en el diagrama de casos de uso de nivel 1, los casos de uso en
los que interviene este usuario son los siguientes:
o Consultar listado de Reconocimientos Médicos.
o Consultar Reconocimiento Médico.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 12 de 37
o Modificar Reconocimiento Médico.
o Añadir Reconocimiento Médico.
Módulo de Monitorización:
El usuario APRL puede visualizar el MM.
o Diagrama de casos de uso
Nivel 0
Figura 7. Monitorización del sistema MM. Nivel 0
Figura 8. Monitorización del sistema MM. Nivel 1
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 13 de 37
Figura 9. Monitorización del sistema MM. Nivel 2
Como se puede observar en el diagrama de casos de uso de nivel 2, los casos de uso en
los que interviene este usuario son los siguientes:
o Visualizar listado de EPIs requeridos.
o Visualizar listado de EPIs caducados.
o Visualizar listado de EPIs defectuosos.
o Visualizar listado de Reconocimientos Médicos requeridos.
o Visualizar listado de Reconocimientos Médicos caducados.
o Visualizar listado de Reconocimientos Médicos no superados.
o Visualizar cursos de PRL necesarios.
o Visualizar cursos de PRL no superados.
o Visualizar cursos de PRL caducados.
o Visualizar ficheros PRL de empleados.
o Visualizar ficheros PRL de empleados.
o Visualizar ficheros PRL de puestos.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 14 de 37
Configuración del MRPRLP:
El usuario APRL puede configurar el MRPRLP.
o Diagrama de casos de uso
Nivel 0
Figura 10. Configuración de sistema MRPRLP. Nivel 0
Nivel 1
Figura 11. Configuración de sistema MRPRLP. Nivel 1
Nivel 2
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 15 de 37
Figura 12. Configuración de sistema MRPRLP. Nivel 2
Como se puede observar en el diagrama de casos de uso de nivel 2, los casos de uso en
los que interviene este usuario son los siguientes:
o Añadir Rec. Médico necesario.
o Eliminar Rec. Médico necesario.
o Generar informe del listado de Rec. Médicos necesarios.
o Añadir EPI necesario.
o Eliminar EPI necesario.
o Generar informe del listado de EPIs necesarios.
o Añadir curso necesario.
o Eliminar curso necesario.
o Generar informe del listado de cursos necesarios.
o Añadir riesgo al puesto.
o Eliminar riesgo del puesto.
o Gestionar los documentos de riesgos del puesto.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 16 de 37
Configuración del MRAPRLE
El usuario APRL puede configurar el MRAPRLE.
o Diagrama de casos de uso
Nivel 0
Figura 13. Configuración de sistema MRAPRLE. Nivel 0
Nivel 1
Figura 14. Configuración de sistema MRAPRLE. Nivel 1
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 17 de 37
Nivel 2
Figura 15. Configuración de sistema MRAPRLE. Nivel 2
Nivel 3
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 18 de 37
Figura 16. Configuración de sistema MRAPRLE. Nivel 3
3.3.1.3 Gestor de PRL
Módulo de monitorización:
El usuario GPRL puede visualizar el MM.
o Diagrama de casos de uso
Nivel 0
Figura 17. Monitorización del sistema MM. Nivel 0
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 19 de 37
Nivel 1
Figura 18. Monitorización del sistema MM. Nivel 1
Nivel 2
Figura 19. Monitorización del sistema MM. Nivel 2
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 20 de 37
Configuración del MRPRLP:
El usuario GPRL puede configurar el MRPRLP.
o Diagrama de casos de uso
Nivel 0
Figura 20. Configuración del sistema MRPRLP. Nivel 0
Nivel 1
Figura 21. Configuración del sistema MRPRLP. Nivel 1
Nivel 2
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 21 de 37
Figura 22. Configuración del sistema MRPRLP. Nivel 2
Configuración del MRAPRLE:
El usuario GPRL puede configurar el MRAPRLE.
o Diagrama de casos de uso
Nivel 0
Figura 23. Configuración del sistema MRAPRLE. Nivel 0
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 22 de 37
Nivel 1
Figura 24. Configuración del sistema MRAPRLE. Nivel 1
Nivel 2
Figura 25. Configuración del sistema MRAPRLE. Nivel 2
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 23 de 37
Nivel 3
Figura 26. Configuración del sistema MRAPRLE. Nivel 3
3.3.1.4 Usuario de PRL
Para el usuario UPRL los casos de uso son exactamente los mismos que para el usuario GPRL
explicados anteriormente, ya que el usuario UPRL es un caso particular del GPRL en el que
solo puede visualizar la información en materia de PRL relativa a él.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 24 de 37
3.4 Diagramas de secuencia y actividad
3.4.1 Acceso al sistema
Diagrama de secuencia
El usuario accede al sistema introduciendo su usuario y contraseña correspondiente.
Figura 27. Diagrama de secuencia: Acceso al sistema.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 25 de 37
Diagrama de actividades
Figura 28. Diagrama de actividades: Acceso al sistema.
3.4.2 Consultar parámetros del sistema
Los usuarios interactúan con la GUI del sistema, accediendo mediante formularios a los
distintos parámetros que desean consultar. Se usa el término “parámetros” para denotar
cualquier entidad o listado de entidades que intervengan en el sistema. Por ejemplo: un
producto, un listado de materiales, un material, etc.
Cada usuario tiene acceso a diferentes parámetros según sus intereses dentro del sistema,
pero los diagramas de secuencia y actividad para la consulta son equivalentes.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 26 de 37
Diagrama de secuencia
Figura 29. Diagrama de secuencia: Consultar parámetros.
Diagrama de actividades
Figura 30. Diagrama de actividades: Consultar parámetros.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 27 de 37
3.4.3 Añadir parámetro del sistema
Los usuarios interactúan con la GUI del sistema, introduciendo mediante un formulario los
datos del parámetro a añadir. Antes de crear y almacenar los datos, el propio formulario realiza
un control de datos en donde se asegura su validez. Por último, la capa de acceso a datos se
encarga de la creación y almacenaje del nuevo parámetro en el sistema. Se usa el término
“parámetro” para denotar cualquier entidad que intervenga en el sistema. Por ejemplo: un
producto, un material, etc.
Cada usuario tiene acceso a la creación de distintos parámetros, pero los diagramas de
secuencia y actividad para la inserción son equivalentes.
Diagrama de secuencia
Figura 31. Diagrama de secuencia: Añadir parámetro.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 28 de 37
Diagrama de actividades
Figura 32. Diagrama de actividades: Añadir parámetro.
3.4.4 Editar parámetro del sistema
Los usuarios interactúan con la GUI del sistema, introduciendo mediante un formulario los
datos del parámetro a editar. Antes de actualizar y almacenar los datos, el propio formulario
realiza un control de datos modificados en donde se asegura su validez. Por último, la capa de
acceso a datos se encarga de la actualización del parámetro en el sistema. Se usa el término
“parámetro” para denotar cualquier entidad que intervenga en el sistema. Por ejemplo: un
producto, un material, etc.
Cada usuario tiene acceso para la actualizar distintos parámetros, pero los diagramas de
secuencia y actividad para la modificación son equivalentes.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 29 de 37
Diagrama de secuencia
Figura 33. Diagrama de secuencia: Editar parámetro.
Diagrama de actividades
Figura 34. Diagrama de actividades: Editar parámetro.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 30 de 37
3.4.5 Eliminar parámetros del sistema
Los usuarios interactúan con la GUI del sistema, seleccionando a través de un formulario los
parámetros a eliminar. Antes de borrar los datos, el propio formulario realiza una validación de
la operación (Por ejemplo, no permitir eliminar parámetros que se encuentran en uso
actualmente). Por último, la capa de acceso a datos se encarga de la actualización del
parámetro en el sistema. Se usa el término “parámetro” para denotar cualquier entidad que
intervenga en el sistema. Por ejemplo: un producto, un material, etc.
Cada usuario tiene permisos para eliminar distintos parámetros, pero los diagramas de
secuencia y actividad para borrar datos son equivalentes.
Diagrama de secuencia
Figura 35. Diagrama de secuencia: Eliminar parámetros.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 31 de 37
Diagrama de actividades
Figura 36. Diagrama de actividades: Eliminar parámetros.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 32 de 37
4. ANÁLISIS DE GESTIÓN DE FICHEROS CON SHAREPOINT
En este apartado se van a indicar los pasos y las decisiones tomadas a la hora de analizar el
problema de gestionar los ficheros en SharePoint.
Desde un primer momento se tuvo muy en cuenta las ideas de genericidad y reutilización, es
decir, el gestor documental nos tendría que servir para gestionar toda la documentación
asociada a los procesos relacionados con el SGPRL pero a la vez tendría que servir para la
gestión de ficheros de otras entidades con el mínimo esfuerzo posible. De esta forma se
decidió construir una biblioteca de datos y métodos que contendría todo lo necesario para
comunicarse con el servidor SharePoint y poder gestionar los documentos. Por otro lado se
pensó en desarrollar un control: pieza de software o interfaz visual que usase la biblioteca
anteriormente citada para fácilmente poder colocarlo en aquellas ubicaciones de nuestro
sistema donde se requería gestionar documentación:
GESTOR DOCUMENTAL
Figura 37. Esquema comunicación Control-Biblioteca-SharePoint
Como se puede observar en al Figura 37 nuestro control de documentos (parte visual) hará uso
de la biblioteca de métodos para acceder al modelo de datos de SharePoint y realizar todas las
operaciones necesarias para administrar los documentos del SGPRL.
El siguiente paso en el análisis fue decidir cual de las opciones posibles para comunicar
nuestra biblioteca de métodos con el modelo de datos de SharePoint. A continuación se detalla
el análisis de las distintas alternativas:
- Modelo de Objetos Servidor: Este es API más completo. Nos permite el acceso a todos
los datos habidos en SharePoint. Para usar esta API es necesario tener instalado en la
máquina donde se va a ejecutar el Gestor Documental el servidor SharePoint.
- Modelo de Objetos Cliente: Es un subconjunto del Modelo de Objetos Servidor y no
requiere tener instalado SharePoint en la máquina donde se va a ejecutar el Gestor de
Documentos. Necesita tener instalado .NET FrameWork al menos en su versión 3.5.
Control de documentos
Biblioteca
de métodos
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 33 de 37
- Servicios Web: Es un subconjunto del Modelo de Objetos Servidor (mayor que el del
Modelo de Objetos Cliente). No necesita tener instalado SharePoint y no tiene
restricción de .NET FrameWork. Por otro lado tiene la desventaja de tener un menor
rendimiento puesto que requiere transformar para cada petición la información a XML y
viceversa. Otra desventaja es que no soporta manejo de Excepciones.
Una vez analizados los tres casos, en primer lugar se desechó el Modelo de Objetos Servidor
debido a que no es viable que cada uno de los usuarios del Gestor de Documentos tengan
instalado el servidor SharePoint puesto que se trata de un sistema muy amplio, denso y que
consume muchos recursos. En segundo lugar se descartó el Modelo de Objetos Cliente debido
a que en el entorno de la compañía se desarrolla en .NET FrameWork 2.0 y sería necesario la
versión 3.5 o superior.
Por las razones anteriores se decidió desarrollar la Biblioteca de métodos usando los Servicios
Web como vía de comunicación con SharePoint:
Figura 38. Esquema Comunicación Biblioteca de métodos-SharePoint
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 34 de 37
5. ESTRUCTURA ESTÁTICA
5.1 Introducción
Tras explicar y detallar los casos de uso, se procede a identificar las entidades de mayor
relevancia y sus relaciones. Se definirán paquetes de análisis para organizar las entidades y
funcionalidades del sistema en partes más manejables.
5.2 Identificación de paquetes de análisis general
Figura 39. Diagrama de paquetes.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 35 de 37
Cada paquete de los representados en la figura 38 es un conjunto de clases e interfaces a
través de las cuales se acceden a las distintas entidades que participan en el sistema.
Cabe destacar que, si bien los paquetes PRL y ficheros SharePoint se han desarrollado en su
totalidad dentro de este proyecto, en los paquetes Puestos y Empleados solo se ha
desarrollado la parte relacionada con incrustar el paquete de PRL en ellos.
Si bien el paquete de Ficheros SharePoint se podría haber ubicado dentro del paquete de PRL
puesto que los documentos de PRL son parte del paquete PRL , se ha tomado la decisión de
representarlo fuera para remarcar la idea de que se trata de un módulo reutilizable y no
obligatoriamente ligado a la gestión documental PRL únicamente.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 36 de 37
6. REQUERIMIENTOS ESPECIALES
En esta sección se describen requerimientos especiales identificados durante la fase de
análisis, de importancia para el sistema. Este tipo de requerimientos especiales, normalmente
no están referidos a funcionalidad de cara al usuario, sino que son restricciones o necesidades
propias del sistema.
6.1 Persistencia
El sistema debe garantizar la persistencia de los datos tratados, almacenando la información
para posteriores consultas o modificaciones. El medio que se debe usar para implementar la
persistencia será definido durante el diseño del sistema.
6.2 Gestión de transacciones
El sistema debe ser multiusuario, y además, debe acceder a un repositorio de información, por
lo que se debe controlar el acceso de cada usuario a la información almacenada, evitando
escrituras simultáneas en el repositorio de datos.
6.3 Tolerancia a fallos
El sistema debe ser capaz de recuperarse de una acción no permitida, y volver a un estado
estable y válido.
6.4 Seguridad
En cualquier proyecto software es un requisito fundamental que el sistema garantice la
seguridad de las comunicaciones entre el GUI y el repositorio de almacenamiento, así como la
privacidad de los datos.
6.5 Concurrencia
Como ya se ha mencionado, el sistema debe ser multiusuario, por lo que se debe garantizar la
concurrencia en las interacciones de los usuarios con el mismo, sin que se esto represente un
impacto en el rendimiento. Este es un factor de gran importancia por el elevado número de
usuarios que se prevé que accedan simultáneamente al servicio.
6.6 Internacionalización
El sistema debe permitir la internacionalización del mismo, esto es, que todos los textos que
muestra permitan ser fácilmente modificados en función del idioma del usuario.
Endalia Versión: 1.0
Análisis Fecha:
19/12/2011
ANALISIS
CONFIDENCIAL 2011 Endalia Página 37 de 37
7. REFERENCIAS
7.1 Referencias web
[Ref. Web. 1] http://docs.kde.org/development/es/kdesdk/umbrello/uml-basics.html
[Ref. Web. 2] http://www.programacion.com
[Ref. Web. 3] http://www.humbertocervantes.net/cursos/tutoriales/main.html
[Ref. Web. 4] http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html
[Ref. Web. 5] http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
[Ref. Web. 6] http://www.uml.org
[Ref. Web. 7] http://staruml.sourceforge.net/en/
Endalia
Diseño
Versión 1.0 – Fecha: 02/05/2012
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 2 de 29
REVISIONES
Fecha Versión Descripción Autor
02/05/2012 1.0 Documento de diseño Miguel Ángel Catalán
Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 3 de 29
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 5
1.1 PROPÓSITO DEL DOCUMENTO 5
1.2 ALCANCE DEL DOCUMENTO 5
1.3 ACRÓNIMOS 5
1.4 DEFINICIONES 5
1.5 REFERENCIAS 6
1.6 RESUMEN 7
2. DESCRIPCIÓN DEL PROCESO 8
3. CONSIDERACIONES INICIALES 9
3.1 INTRODUCCIÓN 9
3.2 ESPECIFICACIONES TECNOLÓGICAS 9
3.3 ESPECIFICACIONES DE DISEÑO 9
3.4 PLATAFORMA .NET 9
3.5 COMMON LANGUAGE RUNTIME (CLR) 10
3.6 BASE CLASS LIBRARY (BCL) 11
3.6.1 ACTIVEX DATA OBJECT (ADO) 11
3.6.2 WINFORMS 13
3.7 SQL SERVER 13
3.8 NHIBERNATE 14
3.9 SHAREPOINT 2010 15
4. DISEÑO DE LA ARQUITECTURA 16
4.1 INTRODUCCIÓN 16
4.2 ESTRUCTURA GENERAL DEL SISTEMA 16
4.3 ESTRUCTURA DE CAPAS DEL SISTEMA 16
4.4 ESTRUCTURA DE SUBSISTEMAS 17
4.4.1 SUBSISTEMA DE GESTIÓN DE PRL 17
4.4.2 SUBSISTEMA DE GESTIÓN Y REGISTRO DE LA ACTIVIDAD EN PRL POR EMPLEADO 17
4.4.3 SUBSISTEMA DE GESTIÓN DE REQUERIMIENTOS EN PRL POR PUESTO DE TRABAJO. 17
4.4.4 SUBSISTEMA DE GESTIÓN DE DOCUMENTOS SHAREPOINT 17
5. DISEÑO DE LA BASE DE DATOS 18
5.1 INTRODUCCIÓN 18
5.2 DISEÑO GENERAL DE LA BASE DE DATOS 18
5.2.1 EN DETALLE: 19
6. PROTOTIPADO DE LA INTERFAZ 20
6.1 INTRODUCCIÓN 20
6.2 ESTÁNDAR DE DISEÑO DE ENDALIA 20
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 4 de 29
6.2.1 DIMENSIONES 20
6.2.2 ALINEACIÓN DE CAMPOS DE TEXTO 20
6.2.3 ETIQUETAS DE CAMPOS 20
6.2.4 LISTADOS 21
6.2.5 MÁSCARAS 21
6.2.6 CAMPOS OBLIGATORIOS 21
6.2.7 CAMPOS EDITABLES 21
6.2.8 COLORES 21
6.3 PROTOTIPOS 23
6.3.1 INTERFAZ DE INICIO DEL SISTEMA 23
6.3.2 INTERFAZ DE LISTADOS Y ESTRUCTURAS DE ÁRBOL 24
6.3.3 INTERFAZ DE FICHAS DE ENTIDADES DEL SISTEMA TIPO PESTAÑA 25
6.3.4 INTERFAZ DE FICHAS DE ENTIDADES DEL SISTEMA TIPO POP-UP 27
7. BIBLIOGRAFÍA 29
7.1 REFERENCIAS 29
7.2 REFERENCIAS WEB 29
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 5 de 29
1. INTRODUCCIÓN
1.1 Propósito del documento
El presente documento describe la fase de diseño del proyecto de desarrollo del SGPRL. A
partir del documento de análisis, se obtienen los interfaces, estructuras y objetos necesarios
para la implementación.
1.2 Alcance del documento
Este documento comprende la fase de diseño del sistema, y describe los resultados obtenidos
durante esta fase, detallando cada uno de los artefactos y actividades que son necesarios para
llevar a cabo esta fase de desarrollo.
1.3 Acrónimos
API: Application Programming Interface.
ASP: Active Server Pages.
CIL: Common Intermediate Language.
CLI: Common Language Infrastructure.
CLR: Common Language Runtime.
CTS: Common Type System.
DDL: Data Definition Language.
DML: Data Manipulation Language.
GNU LGPL :GNU Lesser General Public License
GUI: Graphic User Interface.
ORM: Object Relational Mapping
SGBD: Sistema Gestor de Bases de Datos.
SGPRL: Sistema de Gestión en PRL.
PX: pixels.
PRL: Prevención de Riesgos Laborales
1.4 Definiciones
Principio ACID: Es el conjunto de propiedades de una base de datos que aseguran la
realización de transacciones seguras. En concreto, ACID es un acrónimo de Atomicity,
Consistency, Isolation and Durability (Indivisibilidad, Consistencia, Aislamiento y
Durabilidad en castellano). Indivisibilidad es la propiedad que asegura que todas las
tareas incluidas en la transacción han sido realizadas, o bien que ninguna de ellas lo ha
sido. Consistencia es la propiedad que asegura que la base de datos está en un estado
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 6 de 29
coherente antes del comienzo de la transacción, y que queda en otro estado coherente
(sea el mismo u otro) después de la finalización de la transacción. Aislamiento es la
propiedad que asegura que una externa a la transacción no puede acceder a un estado
intermedio de los producidos durante la misma. Durabilidad es la propiedad que
asegura que una vez realizada la transacción con éxito, ésta persistirá y no se podrá
deshacer aunque falle el sistema.
Framework: En el contexto de desarrollo de software, es una estructura de soporte
definida, mediante la cual otro proyecto de software puede ser organizado y
desarrollado.
Mapeo objeto-relacional (ORM): El mapeo objeto-relacional, más conocido por su
nombre en inglés, Object-Relational mapping (ORM), es una técnica de programación
para convertir datos entre el sistema de tipos utilizado en un lenguaje de programación
orientado a objetos y el utilizado en una base de datos relacional. En la práctica esto
crea una base de datos orientada a objetos virtual, sobre la base de datos relacional.
Esto posibilita el uso de las características propias de la orientación a objetos
(básicamente herencia y polimorfismo).
ToolTip: Es una herramienta de ayuda, que funciona al situar o pulsar con el ratón
sobre algún elemento gráfico, mostrando una ayuda adicional para informar al usuario
de la finalidad del elemento sobre el que se encuentra. Los tooltip son una variación de
los globos de ayuda y es un complemento muy usado en programación, dado que
proporcionan información adicional sin necesidad de que el usuario la solicite.
Integración o estrategia horizontal o Enterprise Service Bus (ESB): Es un método de
integración de sistemas, en el que se dedica un subsistema especializado para la
comunicación entre los otros subsistemas. Esto permite reducir el número de
conexiones (interfaces) a un solo subsistema al que se conectará directamente a la
ESB. El ESB es capaz de traducir la interfaz a otra interfaz. Esto permite reducir los
costos de integración y proporciona una flexibilidad extrema. Con los sistemas
integrados de uso de este método, es posible sustituir por completo un subsistema a
otro subsistema que proporciona una funcionalidad similar, pero las exportaciones de
diferentes interfaces, todo esto completamente transparente para el resto de los
subsistemas. La única acción que se requiere para implementar la nueva interfaz entre
el ESB y el nuevo subsistema.
1.5 Referencias
En este documento se hace referencia a los siguientes documentos del proyecto:
ESPECIFICACIÓN DE REQUISITOS.doc: Documento en el que se especifican los
requisitos del sistema.
ANÁLISIS.doc: Documento de análisis del sistema.
ESTUDIO DEL MERCADO.doc: Documento en el que se detallan las alternativas
existentes en el marcado y se definen algunas características que debe tener el
sistema a desarrollar.
MODELO DE NEGOCIO.doc: Documento en el que se detallan las características
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 7 de 29
específicas en el cual se enmarca en sistema SGPRL.
1.6 Resumen
El presente documento describe el diseño del proyecto del SGPRL. Se compone de los
siguientes apartados:
Apartado 1. Muestra el propósito del documento y se define su alcance.
Apartado 2.: Describe el proceso de diseño llevado a cabo para la realización de este
documento.
Apartado 3: Describe las decisiones, restricciones y entorno tecnológico inicial del
diseño.
Apartado 4: Diseño de la arquitectura de subsitemas.
Apartado 5: Detalla el diseño de la base de datos adoptado.
Apartado 6: Muestra un prototipo del interfaz con el que el usuario tiene que
interactuar.
Apartado 7. Bibliografía y referencias Web utilizadas en la confección de este
documento.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 8 de 29
2. DESCRIPCIÓN DEL PROCESO
Tomando como partida los documentos de análisis y especificación de requisitos, en este
documento se describe la arquitectura del sistema, para su posterior implementación.
Para la realización del diseño del sistema, se han recopilado las características y restricciones
existentes por el marco en el que debe integrarse el sistema. Partiendo de los casos de uso
detallados en el documento de análisis y del estudio del mercado realizado, se identifican las
necesidades de interacción entre los diferentes tipos de usuarios y el sistema, y se define la
estructura que debe tener la interfaz, así como sus prototipos.
A partir de las entidades, se describen las tablas que van a ser necesarias en la base de datos,
junto con sus clases de acceso a datos.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 9 de 29
3. CONSIDERACIONES INICIALES
3.1 Introducción
En esta sección se describen las primeras decisiones y especificaciones del diseño del
sistema, se servirán como base para el conjunto del diseño del sistema. También se describen
las principales características de las tecnologías utilizadas.
3.2 Especificaciones tecnológicas
El proyecto que nos ocupa se lleva a cabo en el marco de la empresa Endalia. Este hecho
condiciona la tecnología a utilizar que, evidentemente, debe ser la misma usada en el resto de
aplicaciones llevadas a cabo en dicha empresa, con el objeto de hacerlas compatibles y
fácilmente integrables.
Es por ello que el SGPRL se va a desarrollar en la plataforma .NET de Microsoft, usando el
lenguaje de programación C# y el gestor de base de datos Microsoft SQL Server.
3.3 Especificaciones de diseño
A partir de los requisitos identificados en el documento de análisis de requisitos, podemos
definir como características necesarias del sistema las siguientes:
Escalabilidad: el sistema debe soportar más carga de trabajo sin necesidad de
modificar el software.
Extensibilidad: el sistema debe soportar la adición de nuevos componentes y
funcionalidades sin que ello afecte al resto de componentes.
Usabilidad: el sistema debe poder ser manejado de forma intuitiva.
Rendimiento: El sistema debe soportar un incremento en la carga de trabajo sin que
ello repercuta notablemente en el usuario.
3.4 Plataforma .NET
La tecnología .NET es un componente software que representa un estándar de Microsoft para
proporcionar una independencia hardware y que permite realizar una estrategia horizontal que
agiliza el desarrollo de aplicaciones. Esto permite integrar la aplicación y la información de
cualquier tipo de dispositivo.
El desarrollo .NET se hace a través de marcos de trabajo (Frameworks). Un marco de trabajo
está dividido en dos componentes fundamentales: el entorno de ejecución y la biblioteca de
clases, que a su vez, está dividida de forma jerárquica en 4 conjuntos denominados
namespaces.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 10 de 29
Figura 1. Plataforma .NET
3.5 Common Language Runtime (CLR)
Es el entorno común de ejecución, encargado de convertir un código de cualquiera de los
lenguajes soportados por .NET, en un código intermedio (CIL), el cual será ensamblado
(compilación DLL) y posteriormente ejecutado.
El código que se ejecuta en CLR se conoce como código administrado. El CLR proporciona
diversas funciones y servicios necesarios para la ejecución de los programas, como
compilación just-in-time (JIT), asignación y administración de memoria, aplicación de la
seguridad de tipos, control de excepciones, administración de subprocesos y seguridad.
Con el CLR hospedado en Microsoft SQL Server (lo que se denomina integración con CLR),
puede crear procedimientos almacenados, desencadenadores, funciones definidas por el
usuario, tipos definidos por el usuario y agregados definidos por el usuario en código
administrado. Como el código administrado se compila a código ensamblador antes de su
ejecución, en algunas situaciones puede conseguir aumentos significativos del rendimiento.
El código administrado utiliza seguridad de acceso del código (CAS), vínculos a código y
dominios de aplicación para impedir que los ensamblados realicen determinadas
operaciones. SQL Server utiliza CAS para ayudar a proteger el código administrado e impedir
que el sistema operativo o el servidor de bases de datos se pongan en peligro.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 11 de 29
Figura 2. Arquitectura ADO.NET
3.6 Base Class Library (BCL)
La BCL es una biblioteca incluida en el .NET Framework formada por clases, interfaces y tipos
de valor que permiten acceder a los servicios ofrecidos por el CLR y a las funcionalidades más
frecuentemente usadas a la hora de escribir programas. Además, a partir de estas clases
prefabricadas el programador puede crear nuevas clases que mediante herencia extiendan su
funcionalidad y se integren a la perfección con el resto de clases de la BCL.
Dentro de la biblioteca se encuentran 4 conjuntos de clases: el conjunto de clases que permiten
el acceso a datos (ADO.NET), el conjunto para el desarrollo de aplicaciones Web (ASP.NET) y
el conjunto para el desarrollo de aplicaciones de escritorio (WinForm).
Cabe destacar que, para el desarrollo del SGPC, no se ha utilizado el conjunto relacionado con
el desarrollo de aplicaciones Web.
3.6.1 ActiveX Data Object (ADO)
ADO.NET es una parte integral de .NET Framework formada por un conjunto de clases que
proporcionan los servicios de acceso a datos relacionales, XML y de aplicaciones para el uso
compartido de datos distribuidos.
La arquitectura de ADO.NET esta formada por dos componentes que se pueden utilizar para
obtener acceso a datos y manipularlos:
Proveedores de datos de .NET Framework.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 12 de 29
El DataSet.
Figura 3. Arquitectura ADO.NET
3.6.1.1 Proveedores de datos de .NET Framework
Son los componentes diseñados para establecer la conexión con la base de datos y tener
acceso a diversos comandos de SQL que nos permitan manipular sus datos:
El objetoConnection permite establecer la conexión con la base de datos.
El objeto Command permite tener acceso a comandos de base de datos para devolver
datos, modificar datos, ejecutar procedimientos almacenados y enviar o recuperar
información sobre parámetros
El objeto DataReader nos permite obtener una secuencia de datos a un alto
rendimiento. Los resultados que se buscan se devuelven a medida que se ejecuta la
consulta y se almacenan en un buffer, con lo cual se puede aumentar el rendimiento de
la aplicación tanto al recuperar datos en cuanto están disponibles como al almacenar
(de forma predeterminada) una fila cada vez en memoria, lo que reduce la sobrecarga
del sistema. Dependiendo de la funcionalidad que se desee obtener en una consulta a
base de datos, será interesante usar este objeto o el DataSet.
El objeto DataAdapter proporciona el puente entre el objeto DataSet y la base de datos.
Utiliza objetos Command para ejecutar comandos SQL tanto para cargar
el DataSet con datos como para modificar en la base de datos los cambios aplicados a
los datos incluidos en el DataSet.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 13 de 29
3.6.1.2 DataSet
Es una representación en memoria de los datos a través de tablas, restricciones y relaciones
entre las tablas. La particularidad que posee es que es coherente e independiente con el origen
de datos. Esto permite incluir datos locales de la aplicación y diversos orígenes de datos a la
vez. La interacción con varios orígenes de datos se controla mediante el DataAdapter. Un
origen de datos puede ser un archivo de secuencias XML o una base de datos.
Esta representación en memoria resulta útil a la hora de realizar interacciones de datos
dinámicas, procesamientos exhaustivos o se desee almacenar datos de forma temporal para su
posterior manipulación.
3.6.2 WinForms
Es la parte del Framework que hace referencia al conjunto de componentes que permiten crear
interfaces gráficas de programación (API). Un formulario no es más que una hoja en blanco que
el desarrollador rellena con controles, para crear una interfaz de usuario, y con código, para
procesar los datos.
La arquitectura de las aplicaciones de Windows Forms se desarrollan bajo el paradigma de
programación dirigida por eventos, es decir, durante la ejecución siempre se esta esperando a
que el usuario haga “algo”, como por ejemplo hacer click sobre un botón o cambiar el valor de
un campo de texto.
3.7 SQL Server
Es un SGBD, para bases de datos relacionales, desarrollado por Microsoft. Sus principales
características son:
Soporte para transacciones (bajo el principio ACID).
Escalabilidad.
Estabilidad.
Seguridad.
Soporta procedimientos almacenados.
Entorno gráfico que permite ejecutar comandos DDL y DML.
Permite administrar información de otros servidores de datos.
T-SQL como lenguaje de consultas nativo.
Una base de datos de SQL Server, es una colección de tablas con columnas con tipo definido,
más otros objetos como restricciones, vistas, procedimientos almacenados o índices.
Puede contener un máximo de 231
objetos. El espacio de almacenamiento está dividido en
páginas de 8KB, que es la unidad básica de entrada-salida para una operación de SQL Server.
Las filas de cada tabla se almacenan físicamente en fichero o bien en un montículo (heap) o en
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 14 de 29
un árbol-B.
Los índices (que son estructuras para acelerar el acceso a datos en las consultas) definidos
son almacenados siempre en árboles-B. Hay dos tipos de índices en SQL Server:
Índices agregados: Son los índices en los que se almacena los datos de la fila
indexada en las hojas del árbol.
Índices no agregados: Son los índices que en las hojas del árbol-B almacenan una
referencia a la hoja del índice agregado correspondiente, o bien una referencia a la
página correspondiente. Sólo puede haber un índice agregado por tabla, y éste
habitualmente es la clave primaria de ésta.
3.8 NHibernate
NHibernate es un Framework de O/RM (Object/Relational Mapping), un port de Hibernate de
Java, que tiene como función principal mapear los objetos desde una aplicación .NET a una
base de datos Relacional.
A través de NHibernate se establece la conversión entre la base de datos a un código fuente
C# implementado en el Visual. Dicha conversión consiste en generar una clase en C# que
simula la entidad en base de datos y un XML que permite establecer una conexión entre la
clase generada para la entidad y la entidad en sí.
Además, soporta “persistencia transparente”, es decir, las clases objeto no tienen que seguir un
modelo de programación restrictivo. Las clases de persistencia no necesitan implementar
ninguna interfaz o heredar características de una clase base determinada. Esto hace posible
diseñar la lógica de negocio usando objetos .NET planos, y un lenguaje orientado a objetos.
Las características más destacadas de NHibernate son:
Modelo de programación natural. NHibernate soporta lenguajes orientados a objetos:
herencia, polimorfismo, composición y colecciones de .NET, incluyendo colecciones
genéricas.
.NET nativo. La API de NHibernate usa las convenciones y lenguajes de .NET.
Permite especificar el código SQL que NHibernate debe usar para persistir los objetos.
Soporta procedimientos almacenados para Microsoft SQL Server.
Para el desarrollo de clases se han seguido dos patrones de diseño:
Singleton: Patrón de diseño utilizado para controlar la gestión de la sesión. Está
diseñado para restringir la creación de objetos de una clase, o el valor de un tipo a un
único objeto, garantizando que una clase tenga una única instancia, y proporcionando
un punto de acceso global a ella.
Factory: Patrón de diseño utilizado para la creación de las clases de acceso a datos,
que define la estructura de los ficheros pertenecientes a la misma familia.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 15 de 29
3.9 SharePoint 2010
Desde el punto de vista del usuario, SharePoint 2010 es una plataforma de colaboración web
segura y administrable. Desde el punto de vista del desarrollador, una plataforma de desarrollo
de aplicaciones y servicios.
Figura 4. Funcionalidades y servicios ofrecidos por SharePoint 2010.
Como se puede observar en la figura 4 SharePoint 2010 nos ofrece multitud de servicios. En
este proyecto se han usado aquellos que de forma directa o indirecta tenían que ver con la
gestión documental puesto que se ha apoyado en ellos para desarrollar la gestión de ficheros
en cada uno de las partes del SGPRL donde se requerían.
Partiendo de la base de que se ha decidido usar Servicios Web para comunicar nuestra
biblioteca de métodos con el servidor SharePoint y de esta forma poder hacer uso de sus
objetos, (para más detalle acerca de esta decisión consultar el documento de Análisis en los
anexos del proyecto) las distintas tecnologías y aspectos de diseño usados han sido los
siguientes:
- El control de documentos (componente visual) se ha codificado íntegramente en
lenguaje C# (incluido dentro de la plataforma .NET explicada anteriormente).
- Para la biblioteca de métodos se ha codificado tanto en C# como en código CALM
y XML necesario para interactuar con los Servicios Web que a su vez encapsulan
el mensaje bajo el protocolo SOAP para comunicarse con el servidor SharePoint e
intercambiar información.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 16 de 29
4. DISEÑO DE LA ARQUITECTURA
4.1 Introducción
En esta sección se describe la estructura del sistema SGPRL, tanto desde el punto de vista
físico como lógico, detallando las decisiones tomadas en cada momento y sus motivos o
restricciones que llevan a tomar esas decisiones.
4.2 Estructura general del sistema
La estructura general del sistema está compuesta por dos partes claramente diferenciadas:
La aplicación de Gestión de Prevención de Riesgos laborales (SGPRL). Los usuarios
acceden al sistema, que estará instalado localmente en su equipo.
La base de datos. Es un repositorio de datos de la aplicación, implementado desde el
sistema gestor de bases de datos SQL Server 2008.
Modelo de datos del servidor SharePoint: Es el repositorio de datos de la aplicación
que almacena todos aquellos datos que tienen que ver con la gestión documental. Este
repositorio está implementado desde un sistema gestor de bases de datos SQL Server
propio del servidor SharePoint.
4.3 Estructura de capas del sistema
Una forma de organizar sistemas de tamaño considerable, es mediante la agrupación de
funcionalidades por su naturaleza o funcionalidad, en capas. De este modo se consigue que
modificaciones en una de las capas, no afecten a todo el sistema. Esto proporciona una óptima
escalabilidad, y una mejora en el rendimiento.
Este sistema está basado en una arquitectura multicapa típica:
Capa de presentación: Es la capa que se encarga de crear el interfaz gráfico y de
gestionar las interacciones del usuario con el sistema. Esto se consigue mediante
formularios en C# y controles de usuario.
Capa lógica: Contiene los objetos que representan los datos almacenados en el
repositorio de datos, así como la lógica necesaria para procesarlos. En nuestro sistema
se corresponde con las clases de acceso a datos.
Capa de integración: Contiene objetos que automatizan el acceso a datos. Esto se
corresponde con los procedimientos almacenados de la base de datos y con el modo
de acceso a ellos a través de ADO .NET.
Capa de datos: Contiene los sistemas de información de la aplicación, habitualmente,
una base de datos. Esto se corresponde con la base de datos de nuestro sistema.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 17 de 29
4.4 Estructura de subsistemas
Estructurar mediante subsistemas, es una forma de organizar el modelo en partes más
pequeñas y manejables. A continuación se exponen los diferentes subsistemas del proyecto de
desarrollo del SGPRL.
4.4.1 Subsistema de Gestión de PRL
De acuerdo a la especificación de requisitos y al análisis del sistema, en la fase de diseño se
ha decidido manejar las entidades y demás componentes que hacen referencia EPIs y Rec.
Médicos así como un subsistema de Monitorización de estos y otros elementos relacionados
con PRL.
4.4.2 Subsistema de Gestión y Registro de la actividad en PRL por empleado
Este sistema abarca todas las funcionalidades necesarias para gestionar la actividad en
materia de Prevención de Riesgos Laborales por empleado de la organización.
4.4.3 Subsistema de Gestión de Requerimientos en PRL por puesto de trabajo.
Este sistema abarca todas las funcionalidades necesarias para gestionar todos los
requerimientos en PRL por puesto de trabajo estudiados e indicados en el documento de
Análisis del proyecto.
4.4.4 Subsistema de Gestión de Documentos SharePoint
Es el que abarca todas las funcionalidades referidas a la gestión documental de todos los
ficheros del sistema. Se ha diseñado sobre la plataforma de servicios SharePoint 2010
explicado anteriormente usando los objetos de su base de datos comunicándonos vía Web
Services.
Es importante destacar que este subsistema se ha diseñado de forma que gozara de un alto
grado de genericidad puesto que la idea desde el principio no fue otra que con este subsistema
se fuera capaz de gestionar cualquier tipo de documento con unas mínimas modificaciones.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 18 de 29
5. DISEÑO DE LA BASE DE DATOS
5.1 Introducción
En esta sección, se presenta una vista global del diseño de la base de datos, resultante de las
entidades identificadas en el análisis, adecuando al repositorio de datos que utiliza la
aplicación. Como ya se ha comentado anteriormente, el repositorio de datos a utilizar, es una
base de datos relacional gestionada desde el SGBD MSSQL Server 2008.
También se describen las tablas de la base de datos junto con sus atributos y las relaciones
existentes entre ellas. SQL Server gestiona las claves primarias de una tabla, como índices
agregados, lo que significa que incluyen todos los datos en las hojas del árbol-B
correspondiente. Por ello, para optimizar el acceso a datos, se ha decidido la utilización de
claves primarias de tipo numérico, aunque el análisis indique que es mejor la utilización de otro
tipo de datos.
5.2 Diseño general de la base de datos
En primer lugar se va a mostrar el esquema general de la base de datos para después mostrar
en más detalle las tablas que componen la base de datos:
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 19 de 29
5.2.1 En detalle:
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 20 de 29
6. PROTOTIPADO DE LA INTERFAZ
6.1 Introducción
En este apartado se muestran los prototipos de interfaz de pantalla diseñados para el sistema.
Los prototipos elegidos cumplen un compromiso entre las conclusiones obtenidas del estudio
del mercado y el estándar de diseño de la empresa Endalia.
Los objetivos y decisiones tomadas en este punto son:
La resolución mínima para la que se diseñará la aplicación es 1024x768.
Primar la claridad y la usabilidad por encima de otros aspectos, es decir, proporcionar
un entorno claro e intuitivo para los usuarios.
Los elementos tendrán siempre que sea posible diseño líquido, es decir, adaptarán sus
dimensiones dependiendo de la resolución de la pantalla en que se visualicen.
Evitar la aparición de barras de desplazamiento horizontal, y limitar dentro de lo posible
el uso de la barra de desplazamiento vertical, ocupando a poder ser únicamente la
pantalla visible.
6.2 Estándar de diseño de Endalia
El sistema SGPRL debe adaptarse a las necesidades del cliente que lo adquiera y debe
cumplir los objetivos identificados en el estudio del mercado, sin salirse del estándar de diseño
que posee Endalia. A continuación se describen en detalle las pautas de diseño más relevantes
que se han tenido en cuenta en la GUI del sistema SGPRL.
6.2.1 Dimensiones
Todo componente dentro de un formulario debe respetar una distancia de 10px a la derecha,
izquierda, arriba y abajo.
6.2.2 Alineación de campos de texto
La alineación de campos de texto se hace hacia la izquierda y el espacio para la etiqueta
asociada al campo de texto debe ser el mismo para todo el conjunto
6.2.3 Etiquetas de campos
Los nombres de los campos de texto y celdas de mallados tienen el siguiente formato
Fuente Tamaño Color Color Estilo
Tahoma 11px Negro Normal
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 21 de 29
6.2.4 Listados
Los listados se representan dentro de un mallado (Grid en inglés) que esta compuesto por una
fila cabecera, y un conjunto de filas y columnas con los datos a mostrar. Para la representación
de listados en el sistema se deben tener las siguientes consideraciones de diseño:
Las columnas con datos numéricos y fechas deben estar alineados, tanto cabecera
como datos, hacia la derecha.
Las columnas con datos de texto deben estar alineadas, tanto cabecera como datos,
hacia la izquierda.
Los datos dentro de una celda deben mostrarse de forma completa.
Se debe dimensionar la columna de acuerdo a los datos que se van a mostrar en ella,
si es necesario se abreviará el nombre de la cabecera correspondiente a la columna.
6.2.5 Máscaras
Todo campo numérico debe tener un rango de valores. Para ello es necesario definir en el
diseño los valores máximos y mínimos, así como también una máscara que identifique las
unidades y decimales que se desean mostrar. Por lo general se suelen mostrar 2 decimales.
6.2.6 Campos obligatorios
Los campos obligatorios tienen un fondo amarillo. Esta regla se aplica para campos de texto y
celdas dentro de listados.
Excepción: si todos los campos o celdas de un mallado son obligatorios, se deja el color de
fondo por defecto.
6.2.7 Campos editables
Los campos de texto editables tiene el color de fondo blanco por defecto.
Las columnas editables dentro de un mallado poseen la cabecera de color azul claro y
el fondo blanco por defecto en las celdas de datos.
6.2.8 Colores
Campos obligatorios
Color RGB Tono
Color
Amarillo 250; 250; 210
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 22 de 29
Color de fondo blanco por defecto
Color RGB Tono
Color
Blanco 255; 255; 255
Campos editables: blanco por defecto
Campos no editables
Color RGB Tono
Color
Blanco
humo
245; 245; 245
Fondo de un formulario de tipo pop-up
Color RGB Tono
Color
Azul claro 239; 245; 254
Fondo de un formulario de tipo ficha: blanco por defecto
Color de barra de herramientas
Color RGB Tono
Color
Azul 178; 207; 234
Cabeceras de mallados
o Color de cabeceras
Color RGB Tono
Color
Azul
oscuro
48: 98; 186
o Color de cabecera para campos editables
Color RGB Tono
Color
Azul cielo 117; 178; 236
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 23 de 29
Color de error: cuando existe un error en los datos de un campo o celda, o bien se ha
dejado de asignar valor aun campo obligatorio, el color de fondo utilizado para informar
al usuario es el siguiente:
Color RGB Tono
Color
Rojo coral 240; 128; 128
Color de “cajas” para agrupar datos:
o Cabecera: degradado vertical de claro a oscuro, de dos tonos de azul:
Color RGB Tono
Color
Azul claro 216; 232; 255
Azul
oscuro
141; 176; 218
o Fondo: blanco por defecto.
6.3 Prototipos
El sistema SGPRL posee 4 tipos de prototipos básicos, según las necesidades de visualización
de información que se necesiten en cada componente del sistema.
6.3.1 Interfaz de inicio del sistema
Como se puede observar en la figura siguiente, la pantalla de inicio del sistema SGPRL se
divide en 5 partes:
Barra de maximizar, minimizar y cerrar la ventana.
Menú principal en donde se encuentran los módulos del sistema SGPRL.
Pestañas abiertas.
Formulario seleccionado: dentro de este espacio se situarán los formularios de las
entidades que participan dentro del sistema SGPRL.
Usuario y fecha actual.
Este prototipo corresponde con el formulario principal MDIMain.cs
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 24 de 29
Figura 5. Prototipo de interfaz para iniciar el sistema.
6.3.2 Interfaz de listados y estructuras de árbol
Dentro de esta categoría existen 3 posibilidades: que sólo te interese el listado de datos y no la
estructura, que te interese un listado y la estructura, que te interesen dos listados y la
estructura. Según la información que se desee visualizar se activarán o no los componente de
este prototipo. En la siguiente figura se muestra el esquema general del prototipo.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 25 de 29
Figura 6. Prototipo de interfaz para listados en el sistema.
6.3.3 Interfaz de fichas de entidades del sistema tipo pestaña
Dentro de esta categoría existes dos prototipos:
Ficha con pestañas: este prototipo posee 5 partes:
o Barra de herramientas.
o Cabecera de datos generales.
o Pestañas de información.
o Información de la pestaña seleccionada.
o Fecha y usuario de creación, y fecha y usuario de última modificación.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 26 de 29
Figura 7. Prototipo de interfaz para fichas con pestañas en el sistema.
Ficha simple, con información agrupada por “cajas”: este prototipo posee 5 partes:
o Barra de herramientas.
o Cabecera de datos generales.
o Pestañas de información: como máximo serán dos la última de ellas para
observaciones relevantes.
o Información de la pestaña seleccionada: está dividida en dos “cajas”, la primera
corresponde con las características principales de la entidad afectada en la
ficha, y la otra son características secundarias, relacionadas con dicha entidad.
Si la ficha no posee la pestaña de observaciones, estas irán dentro de las
características secundarias.
o Fecha y usuario de creación, y fecha y usuario de última modificación.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 27 de 29
Figura 8. Prototipo de interfaz para fichas simples sin pestaña de observaciones en el sistema.
6.3.4 Interfaz de fichas de entidades del sistema tipo pop-up
Dentro de esta categoría existes dos prototipos:
Pop-up simple en donde se muestra información muy concreta. Este prototipo esta
dividido en 4 partes:
o Barra de cerrar la ventana.
o Cabecera de Endalia. Además del logo de la empresa, posee un comentario
ilustrativo de lo que se puede hacer en el pop-up.
o Información.
o Franja de botones guardar/aceptar y cancelar.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 28 de 29
Figura 9. Prototipo de interfaz para pop-ups simples del sistema.
Endalia Versión: 1.0
Diseño Fecha:
27/12/2011
DISEÑO
CONFIDENCIAL 2011 Endalia Página 29 de 29
7. BIBLIOGRAFÍA
7.1 Referencias
[IGJ, 2000] I. Jacobson, G. Booch, J. Rumbaugh. 2000. El Proceso Unificado de Desarrollo de
Software. Pearson Education.
[IGJ, 1999] I. Jacobson, G. Booch, J. Rumbaugh. 1999. El lenguaje unificado de modelado.
Manual de referencia. Ed. Addison Wesley.
[RUM, 1991] J. Rumbaugh 1991. Modelado y Diseño Orientado a Objetos Ed. Prentice Hall,
1991.
[HIA 2004] Hibernate in Action: Practical object/relational mapping. Christian Bauer and Gavin
King 2004.
[HHBK 2008] P. Henri Kuaté, T. Harris, C. Bauer, G. King. “NHibernate in Action”. Manning
Publications 2008.
7.2 Referencias Web
[Ref. Web 1] http://www.wikipedia.org
[Ref. Web 2] http://www.uml.org
[Ref. Web 3] http://www.rational.com
[Ref. Web 4] http://www.hibernate.org
[Ref. Web 5] http://nhforge.org
[Ref. Web 6] http://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.80).aspx
[Ref. Web 7] http://www.nhibernate.com/
[Ref. Web 8] http://darioquintana.com.ar/articles/tutorial-de-nhibernate-primeros-pasos
Endalia
Implementación
Versión 1.0 – Fecha: 29/12/2011
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 2 de 31
REVISIONES
Fecha Versión Descripción Autor
29/1/2012 1.0 Realización del documento de
implementación Miguel Catalán Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 3 de 31
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 5
1.1 PROPÓSITO 5 1.2 ALCANCE 5 1.3 ACRÓNIMOS 5 1.4 DEFINICIONES 5 1.5 REFERENCIAS 5 1.6 RESUMEN 5
2. DESCRIPCIÓN DEL PROCESO 7
3. TECNOLOGÍAS, HERRAMIENTAS Y LENGUAJES 8
4. IMPLEMENTACIÓN DE LA INTERNACIONALIZACIÓN 9
4.1 DEFINICIÓN 9 4.2 OBJETIVOS DE LA INTERNACIONALIZACIÓN 9 4.3 ELEMENTOS A INTERNACIONALIZAR 9 4.4 PROCESO DE IMPLEMENTACIÓN DE LA INTERNACIONALIZACIÓN 9
5. IMPLEMENTACIÓN DE LA GESTIÓN DE INCIDENCIAS 11
6. IMPLEMENTACIÓN DEL ACCESO A BASE DE DATOS 12
6.1 INTRODUCCIÓN 12 6.2 T-SQL 12 6.3 TRANSACCIONES 12 6.4 PROCEDIMIENTOS ALMACENADOS 13 6.4.1 EJEMPLO DE EJECUCIÓN DE UN PROCEDIMIENTO ALMACENADO 14 6.5 DESENCADENADORES 16 6.6 HIBERNATE 17 6.6.1 GENERICDAO.CS 17 6.6.2 OTRAS CLASES DE ACCESO A DATOS 17
7. IMPLEMENTACIÓN DE LA INTERFAZ DE USUARIO 19
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 4 de 31
7.1 INTRODUCCIÓN 19 7.2 ELEMENTOS DE INTERFAZ 19 7.2.1 ÍCONOS E IMÁGENES 19 7.2.2 TABLAS 19 7.2.3 ÁRBOLES 20 7.2.4 PESTAÑAS 20 7.2.5 EDITORES DE FECHAS 20 7.3 PANTALLAS DEL SISTEMA 21 7.3.1 INICIO 21 7.3.2 CONFIGURACIÓN DEL SERVICIO DE PREVENCIÓN 22 7.3.3 MONITORIZACIÓN EN PRL 25 7.3.4 GESTIÓN DE REQUERIMIENTOS PRL POR PUESTO 26 7.3.5 GESTIÓN DE LA ACTIVIDAD EN PRL POR EMPLEADO 29
8. BIBLIOGRAFÍA 31
8.1 REFERENCIAS 31 8.2 REFERENCIAS WEB 31
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 5 de 31
1. INTRODUCCIÓN
1.1 Propósito
El presente documento describe la fase de implementación del proyecto de desarrollo del sistema SGPC.
A partir de las bases obtenidas mediante el análisis y el diseño, se obtienen los archivos de código
fuente, librerías y recursos necesarios para la ejecución del sistema.
1.2 Alcance
El alcance del documento comprende la fase de implementación del proyecto comprendida en la fase
final del desarrollo del mismo.
1.3 Acrónimos
DAO: Data Access Objetct.
SGBD: Sistema Gestor de Bases de Datos.
SGPC: Sistema de Gestión y Planificación Comercial.
SQL: Structured Query Language.
T-SQL: Transact Structured Query Language.
WPF: Windows Presentation Foundation.
XML: Extensible Markup Language.
API: Application Programming Interface
1.4 Definiciones
Control de versiones: Gestión de los diversos cambios que se realizan sobre los elementos de
algún producto o una configuración del mismo.
Hoja de estilo: Lenguaje formal usado para definir la presentación de un documento descrito en
HTML o XML.
1.5 Referencias
En este documento se referencian los siguientes documentos del proyecto:
DISEÑO.doc: Documento de diseño del sistema.
PRUEBAS.doc: Documento de plan de pruebas del sistema.
1.6 Resumen
Este documento describe el proceso de implementación del sistema SGPC. Se compone de los
siguientes apartados:
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 6 de 31
Apartado 2: Se describe el proceso de implementación seguido para la confección de este
documento.
Apartado 3: Se describen las tecnologías, herramientas y lenguajes empleados durante la
implementación del sistema.
Apartado 4: Descripción del proceso seguido para la implementación de la internacionalización
de la aplicación.
Apartado 5: Descripción del proceso seguido para la gestión de incidencias ocurridas en el
sistema.
Apartado 6: Detalle de las consideraciones necesarias para la implementación del acceso a
datos.
Apartado 7: Descripción del proceso seguido para la implementación definitiva del interfaz de
usuario.
Apartado 8: Bibliografía y referencias web utilizadas para la realización de este documento.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 7 de 31
2. DESCRIPCIÓN DEL PROCESO
A partir de los subsistemas, clases y estructuras identificados en el diseño del sistema, se comienza el
proceso de implementación del mismo. El proceso de implementación es un proceso iterativo, junto con
la fase de pruebas del sistema. El objetivo principal del proceso de implementación y la fase de pruebas
es conseguir el desarrollo del sistema con la calidad necesaria.
Se trata de un proceso iterativo, ya que una vez realizada la implementación, se procede a llevar a cabo
la fase de pruebas. En esta fase de pruebas se identifica funcionalidad incorrecta, y todas aquellas
partes del proceso de implementación que sea necesario repetir.
Dentro del proceso de implementación, se pueden identificar las siguientes fases:
Implementación de la Base de datos: Creación de las tablas y las relaciones necesarias para el
nuevo sistema, especificadas en el documento de diseño.
Implementación de los subsistemas identificados en el diseño, teniendo en cuentas los prototipos
de interfaz definidos en el documento de diseño.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 8 de 31
3. TECNOLOGÍAS, HERRAMIENTAS Y LENGUAJES
Para el desarrollo del presente proyecto, se han utilizado las siguientes tecnologías, lenguajes y
herramientas:
Microsoft .NET Framework. Plataforma de desarrollo descrita en el Documento de Diseño en el
apartado 3.4.
Microsoft SQL Server 2008. SGDB utilizado para la gestión de la base de datos del sistema y
descrito en el Documento de Diseño en el apartado 3.7.
C#. Lenguaje de programación de propósito general nativo de la plataforma .NET.
T-SQL. Lenguaje de acceso a datos basado en SQL. Está descrito en el apartado 6.2 del
presente documento.
Infragistics NetAdvantage 9.1. Librería para .NET, que contiene controles para diversos entornos
de desarrollo dentro de dicha plataforma, como ASP .NET, Winforms o WPF.
Log4Net. Herramienta para ayudar en la generación de ficheros de registro. Está descrito en la
sección 5 del presente documento.
Microsoft Visual Studio 2010. Entorno de programación y depuración de código de la plataforma
.NET.
Microsoft SQL Management Studio 2008. Herramienta gráfica que permite realizar tareas de
mantenimiento de la base de datos sobre SQL Server 2008.
Microsoft Team Foundation Server 2010. Herramienta que permite, entre otras funcionalidades,
la gestión del control de versiones de un proyecto sobre Visual Studio 2010.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 9 de 31
4. IMPLEMENTACIÓN DE LA INTERNACIONALIZACIÓN
4.1 Definición
La internacionalización de la aplicación consiste en implementarla de tal modo que pueda ser adaptada a
distintos idiomas y culturas sin necesidad de realizar cambios estructurales en ella.
4.2 Objetivos de la internacionalización
Un sistema internacionalizado debe presentar las siguientes características:
El sistema debe poder ser ejecutado en cualquier lugar del mundo.
El texto mostrado por el sistema debe estar en el idioma del usuario.
El texto mostrado por el sistema no debe estar codificado dentro del sistema, sino que debe ser
almacenado de forma externa, y ser recuperable de forma dinámica en ejecución.
Otros aspectos culturales como números, fechas u horas, deben aparecer en el formato e idioma
del usuario.
4.3 Elementos a internacionalizar
Los elementos susceptibles de ser internacionalizados en el sistema SGPRL son:
Textos.
Números: Pueden variar por el carácter delimitador de decimales, o el separador de miles, por
ejemplo.
Fechas y horas: Pueden variar de muchas formas, por ejemplo, el orden en que se indican los
días y los meses de una fecha.
4.4 Proceso de implementación de la internacionalización
Para la implementación de la internacionalización de la aplicación se ha seguido el siguiente proceso:
1) Identificar los elementos dependientes de la cultura: El ejemplo más claro son los textos de la
aplicación, pero también hay que tener en cuenta números o fechas.
2) Aislar el texto traducible: Todo el texto del sistema, será agrupado y separado en archivos de
recursos, evitando la asignación directa de los mismos.
Ej. nTBName.Text = “Nombre”;
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 10 de 31
Se deben tener en cuenta las siguientes consideraciones:
a. Tratamiento de texto compuesto. Puede haber texto en la aplicación que deba ser
separado por datos, siempre que sea posible se debe mantener en el mismo recurso,
utilizando ‘expresiones de reemplazo’ para reemplazar por su valor correcto en
ejecución, estas expresiones de reemplazo deben comenzar por el carácter ‘$’, por
ejemplo:
message = GetLabel(Labels.Messages.ConfirmDeleteMaterial).Replace("$1", material.Name);
b. Formatear fechas y horas. Hay que usar los métodos de fechas del sistema, evitando:
int day = 1; int month = 4; int year = 2004; lblDate.Text = day + "/" + month + "/" + year; c. Utilizar atributos de caracteres Unicode. Evitando:
char character; if(((character >= 'a') && (character <= 'z')) || ((character >= 'A') && (character <= 'Z')))
d. En su lugar hay que emplear:
if(char.IsLetter(character))
3) Reservar espacio suficiente en el GUI. La longitud del texto puede variar en función del idioma
del usuario.
Para llevar a cabo la gestión de las diferentes etiquetas del sistema y poder realizar su
internacionalización fácilmente, se ha utilizado una herramienta desarrollada en “Endalia”, llamada
“Endalia LabelsManagement”.
Endalia LabelsManagement es una aplicación de escritorio que gestiona los recursos de
internacionalización de otra aplicación almacenando dichos recursos en una base de datos
independiente. Permite la asociación de los valores de las etiquetas a diferentes conjuntos de éstas. De
este modo se pueden gestionar etiquetas para distintas culturas.
Sólo es necesario indicar el nombre de la etiqueta y su valor mediante el siguiente formato, y puede
generar los archivos DLL necesarios para su utilización.
<nombre_de_etiqueta>=<valor_de_etiqueta>
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 11 de 31
5. IMPLEMENTACIÓN DE LA GESTIÓN DE INCIDENCIAS
El sistema de gestión de incidencias, o Log de la aplicación, se encarga de registrar secuencialmente los
eventos del sistema en un fichero, guardando información acerca del tipo de evento, de cuándo ocurrió y
qué lo causó. Dicho fichero puede posteriormente ser consultado, auditado y analizado para conocer el
uso, funcionamiento y posibles problemas del sistema.
La siguiente información es registrada siempre, independientemente del resto del contenido del registro
de log:
Fecha y hora de registro del evento.
Sistema gestor del log (clase que provoca la llamada).
Etiqueta con el tipo de mensaje según la siguiente clasificación:
o DEBUG: mensaje informativo para depuración de la ejecución del sistema.
o INFO: mensaje informativo sobre algún suceso acaecido en el sistema.
o WARM: mensaje de aviso sobre intento de alguna ejecución peligrosa para el sistema.
o ERROR: mensaje acerca de una ejecución fallida pero controlada del sistema.
o FATAL: mensaje de interrupción total de la ejecución del sistema.
La siguiente información variará dependiendo del tipo de registro:
Mensaje de error generado en caso de error de ejecución (por ejemplo en caso de fallo de
ejecución de una instrucción SQL escribiría el mensaje devuelto por SQL Server).
Cualquier mensaje informativo que necesite ser registrado por el sistema en un momento dado.
Para registrar en el fichero de Log las interacciones del usuario con la aplicación, se emplea la librería
log4net, pero es necesario que en cada evento de la aplicación se escriba explícitamente en él, por
ejemplo:
Se escribe en la clase correspondiente lo siguiente:
Log.Write("I_Erp_Man_Products_GetProductProposedCode: productID: " + prodID + " " + e.ToString(),
Log.ERROR);
En el Log aparecerá la siguiente línea de texto:
19/12/2011 [15:59:31] ERROR OSUser: mcatalan; AppUser: unknown;
I_Erp_Man_Products_GetProductProposedCode: productID: 19719 Asignación de NULL a campo no
nulable
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 12 de 31
6. IMPLEMENTACIÓN DEL ACCESO A BASE DE DATOS
6.1 Introducción
La base de datos, como ya se ha indicado en el documento de diseño, está implementada sobre el
SGBD Microsoft SQL Server 2008. A continuación, se describen las principales características que
influyen en el sistema SGPC de este SGBD.
6.2 T-SQL
Transact-SQL o T-SQL es una extensión a SQL propietaria de Microsoft y Sybase, con las siguientes
características.
Lenguaje de control de flujo. Instrucciones para permitir ejecución de bloques condicionados,
iterativos.
IF-THEN-ELSE, CASE-WHEN, WHILE,… Variables locales.
DECLARE @Error int Funciones nativas para procesado de cadenas, gestión de fechas, funciones matemáticas,
etcétera.
Mejoras en sentencias DELETE y UPDATE, para permitir uniones en la cláusula FROM.
6.3 Transacciones
Una transacción es un conjunto de operaciones que debe ejecutarse como una sola unidad, según el
principio ACID expuesto en el documento de Diseño.
En SQL Server, las sentencias SQL son tratadas como transacciones, y si ocurre cualquier tipo de
incidencia durante su ejecución, el sistema es capaz de volver al estado anterior a su ejecución.
En ocasiones en que se requiere ejecutar un conjunto de sentencias SQL de forma transaccional, para lo
que el lenguaje proporciona las sentencias de gestión de transacciones:
BEGIN TRAN. Indica el comienzo de una transacción.
ROLLBACK TRAN. Deshace todos los cambios realizados por la transacción activa.
COMMIT TRAN. Una vez que las operaciones de la transacción se han completado con éxito, se
indica a la base de datos que vuelva a un estado consistente.
DECLARE @Error int BEGIN TRANSACTION INSERT INTO NombreTabla ( Campo1, Campo2 )
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 13 de 31
VALUES ( @Valor1, @Valor2 ) SET @Error = @@ERROR IF @Error != 0 GOTO ERROR_HANDLER SELECT SCOPE_IDENTITY() AS 'Identity' SET @Error = @@ERROR IF @Error != 0 GOTO ERROR_HANDLER COMMIT TRANSACTION RETURN SCOPE_IDENTITY() ERROR_HANDLER: IF @@TRANCOUNT != 0 ROLLBACK TRANSACTION RETURN @Error
6.4 Procedimientos almacenados
Un procedimiento almacenado (Stored Procedure) de Microsoft SQL SERVER, es un conjunto de
instrucciones T-SQL que residen físicamente en la base de datos. Las principales características de los
procedimientos almacenados son las siguientes:
Ejecución directamente en el motor de base de datos que suele estar en un servidor separado,
evitando tráfico de datos entre el SGBD y la aplicación cliente
Posibilidad de almacenamiento del plan de ejecución por parte del SGBD, lo que repercute
positivamente en la eficiencia de la consulta.
Encapsula la lógica de negocio, de tal modo que permiten que varios programas cliente puedan
usarla, reduciendo el coste de mantenimiento de los mismos.
Versatilidad. Al estar desarrollados en T-SQL, permiten realizar funciones del mismo nivel de
complejidad que las que se puede realizar en código de aplicación.
CREATE PROCEDURE [NombreProcedimiento] ( @parametro1 int, @parametro2 int ) AS SELECT SUM(EnvPollLevelValue) AS IndicatorSUM FROM NombreTabla1,
NombreTabla2 WHERE <condicion booleana>
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 14 de 31
6.4.1 Ejemplo de ejecución de un procedimiento almacenado
En la clase Dao correspondiente se define el siguiente método:
public DataTable ListByFamilyAllDescendantsSummaryPrices(int familyID)
{
DataTable resultTable = new DataTable();
try
{
DataSet dsData = SqlHelper.ExecuteDataset(
System.Configuration.ConfigurationManager.AppSettings["conn"],
"I_Erp_MasterMaterial_ListByFamilyAllDescendantsSummaryPrices",familyID,
RijndaelMethod.PK_DES);
if (dsData.Tables[0] != null)
{
Log.Write("Erp_Com_CustomerDao.ListByFamilyAllDescendantsSummaryPrices
familyID=" + familyID, Log.DEBUG);
return dsData.Tables[0];
}
}
catch (SqlException e)
{
Log.Write("Erp_Com_CustomerDao.ListByFamilyAllDescendantsSummaryPrices
familyID=" + familyID + " " + e.ToString(), Log.ERROR);
}
return null;
}
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 15 de 31
El procedimiento almacenado correspondiente es:
USE [111211_CONSIST_ANA] GO /****** Object: StoredProcedure [dbo].[I_Erp_MasterMaterial_ListByFamilyAllDescendantsSummaryPrices] Script Date: 12/11/2011 16:28:25 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER PROCEDURE [dbo].[I_Erp_MasterMaterial_ListByFamilyAllDescendantsSummaryPrices] ( @familyID int, @pass as nvarchar(200) ) AS DECLARE @isEncrypt nvarchar(1) SET @isEncrypt = (SELECT SysOptionValue FROM Gen_SystemOptions WHERE pk_SysOptionName='COM_ADMIN_ENCRYPTION') ;WITH Families(familyID, familyParentID) AS ( SELECT pk_MasterMaterialFamilyID, fk_MasterMaterialFamilyParentID FROM Erp_Sup_MasterMaterialFamilies WHERE pk_MasterMaterialFamilyID= @familyID UNION ALL SELECT MF.pk_MasterMaterialFamilyID, MF.fk_MasterMaterialFamilyParentID FROM Erp_Sup_MasterMaterialFamilies as MF INNER JOIN Families as F ON (MF.fk_MasterMaterialFamilyParentID = F.familyID ) ) SELECT pk_MasterMaterialID as ID ,MasterMaterialName as Name ,MasterMaterialCode as Code ,Family.pk_MasterMaterialFamilyID as typeID ,Family.MasterMaterialFamilyName as typeName ,PurchaseUnit.pk_AdmID as PurchaseUnitID ,CASE @isEncrypt
WHEN 'Y' THEN CONVERT(NVARCHAR,DecryptByPassPhrase(@pass, PurchaseUnit.AdmName))
ELSE PurchaseUnit.AdmName END as PurchaseUnitName
,MasterMaterialPriceBeginDate as BeginDate ,priceEmployee.pk_EmpID as EmployeeID
,priceEmployee.EmpName + ' ' + priceEmployee.EmpSurname as EmployeeName
,MasterMaterialPricePrice as Price ,MasterMaterialPriceValidity as PriceDays
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 16 de 31
,dateadd (d, MasterMaterialPriceValidity, MasterMaterialPriceBeginDate)as PriceValidity
FROM Erp_Sup_MasterMaterials JOIN Erp_Sup_MasterMaterialFamilies Family ON (Family.pk_MasterMaterialFamilyID = fk_MasterMaterialFamilyID) LEFT JOIN Gen_AdministrationItems PurchaseUnit ON (PurchaseUnit.pk_AdmID = Family.fk_MasterMaterialFamilyPurchaseUnitID) LEFT JOIN dbo.Erp_Sup_MasterMaterialsPrices ON (fk_MasterMaterialPriceMasterMaterialID=pk_MasterMaterialID AND MasterMaterialPriceBeginDate = (SELECT MAX(MasterMaterialPriceBeginDate) FROM dbo.Erp_Sup_MasterMaterialsPrices WHERE fk_MasterMaterialPriceMasterMaterialID=pk_MasterMaterialID)) LEFT JOIN Orh_Emp_Employees priceEmployee ON (pk_EmpID = fk_MasterMaterialPriceEmployee)
INNER JOIN Families ON (fk_MasterMaterialFamilyID=familyID) LEFT JOIN Erp_Sup_MasterMaterialFamilies Family1 ON (fk_MasterMaterialFamilyID=Family1.pk_MasterMaterialFamilyID)
ORDER BY MasterMaterialName
6.5 Desencadenadores
Los desencadenadores (o triggers) son, al igual que los procedimientos almacenados, un conjunto de
sentencias T-SQL almacenadas en base de datos, pero con la particularidad de ser ejecutadas
automáticamente cuando un usuario realiza una acción en la tabla de la base de datos que lleva
asociado el desencadenador.
Su principal utilidad en el sistema SGPC, es el control de actualizaciones y borrados en cascada, que no
pueden ser controlados por el SGBD debido a ciclos múltiples.
Se pueden crear desencadenadores para los siguientes tipos de instrucciones:
INSERT: Inserción de información en la base de datos.
UPDATE: Actualización de información de la base de datos.
DELETE: Eliminación de información de la base de dato.
A continuación se muestra un ejemplo de un triger que controla que al eliminar una entrada de la tabla 1,
se elimine una entrada asociada a esa tabla, en la tabla 2.
CREATE TRIGGER [NombreTrigger] ON [NombreTabla1] FOR DELETE AS DELETE FROM NombreTabla2 WHERE <condición booleana>
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 17 de 31
6.6 HIBERNATE
Como ya se ha comentado en el documento de diseño, el acceso a base de datos, se realiza a través de
clases de acceso a datos de Hibernate. Sin embargo, se han explicado los procedimientos almacenados,
porque en algunas ocasiones en que la complejidad de las consultas lo requiere, se han utilizado
llamadas a procedimientos almacenados.
Una vez indicada la estructura de cada una de las tablas en sus correspondientes ficheros, como se
explica en el documento de diseño, ya es posible la carga, inserción, actualización y eliminación de datos
de la base de datos, sin necesidad de crear ningún procedimiento almacenado, ni ninguna función. Esto
es posible gracias a la clase genérica de Hibernate “GenericDao”.
6.6.1 GenericDao.cs
La clase GenericDao es un interfaz genérico para todas las operaciones de actualización, consulta
inserción y eliminación de datos, heredado por todas las clases DAO.
Esta clase contiene todos los métodos necesarios para interactuar con la base de datos, y pueden ser
utilizados por todas las clases de acceso a datos del sistema. Esto es una gran ventaja, ya que los
primeros pasos al crear nuevas tablas en la base de datos, son la creación de todas estas
funcionalidades de inserción, actualización etc, y mediante este sistema no son necesarios.
Otra gran ventaja de la utilización de esta clase genérica, es que modificar algún campo en una de las
tablas de las base de datos, no supone revisar todos los procedimientos almacenados del sistema, con
el consiguiente riesgo de olvido de alguno de ellos.
Algunos métodos dentro de la clase GenericDao.cs son:
Load()
Insert(object newObj)
Update(object updObj)
List()
Delete(object obj)
6.6.2 Otras clases de acceso a datos
Como se ha comentado, GenericDao proporciona los accesos básicos a base de datos, pero en casos
más concretos, existen otras clases DAO asociadas a cada una de las tablas de la base de datos, que
contienen métodos más específicos.
Estos métodos pueden ser de actualización, consulta, eliminación o inserción de datos, al igual que los
que contiene el GenericDao, pero adaptados a nuevas necesidades.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 18 de 31
A continuación se muestran ejemplos de métodos específicos de las distintas clases.
Utilizando la API ICriteria de consultas por criterios:
public Erp_Sup_Material GetByCode(string code)
{
ICriteria criteria =
new BurrowFramework().GetSession().
CreateCriteria(typeof(Erp_Sup_Material));
criteria.Add(
Expression.Like(
Erp_Sup_Material.Properties.Code, code));
return criteria.UniqueResult<Erp_Sup_Material>()
as Erp_Sup_Material;
}
Creando la consulta como una cadena de texto:
public void DeleteByIds(List<int> idsLIst)
{
string Ids = String.Join(",", idsLIst.ConvertAll(a => a.ToString()).ToArray());
string sqlQuery = @"DELETE FROM " + GetTableName() + " WHERE " +
GetColumnFromProperty(Erp_Com_CustomerAddress.Properties.ID) + " IN (" + Ids + ")";
new BurrowFramework().GetSession()
.CreateSQLQuery(sqlQuery)
.ExecuteUpdate();
}
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 19 de 31
7. IMPLEMENTACIÓN DE LA INTERFAZ DE USUARIO
7.1 Introducción
La interfaz de usuario implementada está descrita en los esquemas definidos en el documento de diseño
al que se hará referencia en varias ocasiones.
La interfaz de usuario se ha implementado de acuerdo a un compromiso entre el estándar de diseño de
Endalia y las conclusiones obtenidas en el documento de estudio de mercado.
7.2 Elementos de interfaz
7.2.1 Íconos e imágenes
La utilización de imágenes e iconos ha sido destinada siempre a facilitar al usuario la utilidad y
funcionamiento de los diferentes elementos y partes del sistema, acompañándolos siempre
preferiblemente de una etiqueta textual que especifica la funcionalidad o el destino del elemento
representado por la imagen.
Se ha utilizado una línea estética de tamaño y aspecto similar para todos los iconos utilizados, con el
objetivo de uniformizar el diseño, usando dos tamaños de iconos: 32 píxeles de alto para los iconos
grandes, utilizados en el menú principal de la aplicación, y 16 para los elementos pequeños, utilizados
para barras de herramientas y otros elementos gráficos como botones o títulos.
7.2.2 Tablas
Se han utilizado tablas siempre que ha sido necesario mostrar relaciones de datos.
Las tablas que aparecen en la aplicación son configurables, otorgando gran flexibilidad al usuario para
visualizar en cada momento la información que realmente le interesa. Algunas de las posibilidades más
destacadas que ofrecen son:
Ordenación por campos: el usuario puede ordenar los datos de la tabla en función de un campo
determinado con tan sólo hacer click sobre dicha columna.
Selección de campos a visualizar: en algunas tablas se permite selecciona qué campos se
desea mostrar en las columnas.
Agrupación por columnas: es posible agrupar los resultados de cualquier tabla por determinados
campos (por ejemplo, agrupar los empleados existentes en función de su centro de trabajo).
Selección múltiple.
Filtrado. En los informes, además de lo anteriormente citado, también es posible filtrar los
resultados por uno o varios campos. Las opciones disponibles incluyen: “es igual a”, “distinto a”,
“menor que”, mayor que”, “comienza con”, “contiene”, “termina en”, etc. Según la opción elegida,
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 20 de 31
se visualizarán sólo las filas que cumplan la condición elegida. Por ejemplo: “Es igual a”
comparará letra a letra y solo mostrará campos exactamente iguales al filtro, sin embargo,
“Contiene”, mostrará los elementos de la tabla que contengan (en la columna filtrada) en
cualquier posición del campo el filtro fijado.
Exportación a Excel. En todas las tablas aparecerá un botón en la esquina superior derecha que
permitirá la exportación de su contenido a Excel (Microsoft Office). Pulsando este botón, el
sistema mostrará una ventana en la que se solicitará la ruta de su equipo en el que desea
guardar el archivo que se generará para Excel (extensión .xls) y en la que podrá definir un
nombre para ese archivo. Una vez guardado en el equipo el archivo, podremos abrirlo para ver
su contenido.
7.2.3 Árboles
Se han utilizado vistas en forma de árbol siempre que ha sido necesario mostrar estructuras, tales como
la estructura de EPIs o la estructura de carpetas en el gestor de documentos. De este modo, se facilita al
usuario una identificación rápida de los diferentes elementos de la estructura y una navegación eficiente
y clara a través de los mismos.
7.2.4 Pestañas
Se ha utilizado la navegación y estructuración de una ventana mediante pestañas siempre que ha sido
necesario mostrar al usuario un número extenso de datos o campos que podían agruparse entre sí en
diferentes bloques por algún concepto, pero que compartían un origen común.
7.2.5 Editores de fechas
Se han utilizado, siempre que ha sido posible, editores de fechas que permiten una navegación gráfica a
través de diferentes fechas mediante la visualización de un calendario.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 21 de 31
7.3 Pantallas del sistema
7.3.1 Inicio
Figura 1. Implementación pantalla de inicio.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 22 de 31
7.3.2 Configuración del servicio de Prevención
Figura 2. Implementación pantalla listado de EPIS
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 23 de 31
Figura 3. Implementación pantalla de ficha de EPI
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 24 de 31
Figura 4. Implementación listado de Reconocimientos médicos y ficha de Reconocimiento médico.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 25 de 31
7.3.3 Monitorización en PRL
Figura 5. Implementación pantalla de monitorización de la Prevención de Riesgos
Como se puede observar en la Figura 5, se muestra la pantalla de monitorización en Reconocimientos
Médicos. Indicar que para evitar redundancias (tienen el mismo diseño) no se han incluido las pantallas
de monitorización relativas a EPIs, formación y ficheros de Riesgos puesto que son similares.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 26 de 31
7.3.4 Gestión de requerimientos PRL por puesto
Figura 6. Implementación pestaña requerimientos de EPIs por puesto
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 27 de 31
Figura 7. Implementación pestaña requerimientos de Rec. Médicos por puesto.
Figura 8. Implementación pestaña requerimientos de Riesgos por puesto.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 28 de 31
Figura 9. Implementación pestaña requerimientos de cursos por puesto.
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 29 de 31
7.3.5 Gestión de la actividad en PRL por Empleado
Figura 10. Implementación pestaña actividad en EPIs por empleado.
Figura 11. Implementación pestaña actividad en Rec. Médicos por empleado
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 30 de 31
Figura 12. Implementación pestaña actividad en Ficheros de Riesgos por empleado
Figura 13. Implementación pestaña actividad en formación PRL por empleado
Endalia Versión: 1.0
Implementación Fecha:
29/12/2011
IMPLEMENTACION
CONFIDENCIAL 2011 Endalia Página 31 de 31
8. BIBLIOGRAFÍA
8.1 Referencias
[LOW 2004] Juval Lowy 2003. C# Coding Standard. Idesign Inc 2004.
[RBJ 2002] Ray Rankins, Paul Bertucci, Paul Jensen. Microsoft SQL Server 2000 Unleashed. Sams
Publishing 2002.
[IGJ, 2000] I. Jacobson, G. Booch, J. Rambaugh. 2000. El Proceso Unificado de Desarrollo de Software.
Pearson Education
[HHBK 2008] P. Henri Kuaté, T. Harris, C. Bauer, G. King. “NHibernate in Action”. Manning Publications
2008.
8.2 Referencias web
[Ref. Web 1] http://www.wikipedia.org
[Ref. Web 2] http://msdn.microsoft.com
[Ref. Web 3] http://www.infragistics.com
Endalia
Plan de pruebas
Versión 1.0 – Fecha: 03/05/2012
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 2 de 24
REVISIONES
Fecha Versión Descripción Autor
03/05/2012 1.0 Realización del documento de plan de
pruebas
Miguel Ángel Catalán
Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 3 de 24
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 ACRÓNIMOS 4 1.4 DEFINICIONES 4 1.5 REFERENCIAS 4 1.6 RESUMEN 4
2. DESCRIPCIÓN DEL PROCESO 5
3. GUÍA DE VERIFICACIÓN Y DE CÓDIGO Y PRUEBAS DE ENDALIA 6
3.1 LISTA DE VERIFICACIONES Y PROCESOS DE PRUEBA 6 FORMULARIOS 6
4. PRUEBAS UNITARIAS Y DE INTEGRACIÓN 8
5. PRUEBAS DE SISTEMA 10
6. BIBLIOGRAFÍA 24
6.1 REFERENCIAS 24 6.2 REFERENCIAS WEB 24
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 4 de 24
1. INTRODUCCIÓN
1.1 Propósito del documento
El presente documento describe la fase de pruebas del proyecto de desarrollo del sistema SGPC. Esta
fase está entrelazada con la fase de implementación del sistema. La implementación debe cumplir los
requisitos indicados en el documento de especificación de requisitos y funcionar correctamente.
El objetivo de la fase de pruebas consiste en la certificación del correcto funcionamiento del sistema,
asegurando la calidad del producto.
1.2 Alcance del documento
En este documento se describen los resultados obtenidos durante la fase de pruebas del sistema SGPC.
1.3 Acrónimos
1.4 Definiciones
Caso de prueba: Conjunto de condiciones o variables bajo las cuales se determina si el requisito
de una aplicación es parcial o completamente satisfactorio.
Tooltip: También llamada descripción emergente, es una herramienta de ayuda visual, que
funciona al situar el cursor sobre algún elemento gráfico, mostrando una ayuda adicional para
informar al usuario de la finalidad del elemento sobre el que se encuentra.
1.5 Referencias
En este documento se referencian los siguientes documentos del proyecto:
ESPECIFICACION DE REQUISITOS.doc: Documento en el que se especifican los requisitos mínimos
del sistema.
IMPLEMENTACION.doc: Documento de implementación del sistema.
1.6 Resumen
Este documento describe el proceso de pruebas del sistema SGPC. Se compone de los siguientes
apartados:
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: Se describe el proceso de diseño seguido para la confección de este documento.
Apartado 3: Descripción de la guía de verificación y pruebas de Endalia.
Apartado 4: Se describen las pruebas unitarias y de integración realizadas.
Apartado 5: Se describen las pruebas de sistema realizadas.
Apartado 6: Se describen pruebas de usuario del sistema
Apartado 7: Bibliografía y referencias web utilizadas para la realización de este documento.
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 5 de 24
2. DESCRIPCIÓN DEL PROCESO
El objetivo del plan de pruebas, como ya se ha comentado, es comprobar el correcto funcionamiento del
sistema, y por lo tanto, su calidad.
La fase de pruebas, no tiene por qué ser la fase final del proyecto. De hecho, es una fase de
retroalimentación de la fase de implementación, ya que los errores detectados, se pasan a la fase de
implementación de nuevo, para solventarlos, y una vez resueltos, deben volver a verificarse. Se trata de
un proceso circular.
Los tipos de pruebas llevados a cabo durante la realización de este proyecto son los siguientes:
Pruebas unitarias: Verifica el correcto funcionamiento de un componente individual del sistema.
Pruebas de integración: Verificación de la correcta interconexión entre diferentes componentes
del sistema.
Pruebas de sistema: Verificación global del funcionamiento correcto del sistema.
Pruebas de usuario: Evaluación del sistema ante usuarios reales del mismo.
Los casos de uso que se han tenido en cuenta, tienen una estructura de caja negra. El objetivo de estos
casos de uso es obtener ciertos resultados a partir de parámetros de entrada desconocidos. Para cada
caso de prueba se determinan los siguientes campos:
Identificador:
Título:
Descripción
Resultados esperados
Resultados obtenidos
Es recomendable que las pruebas no sean llevadas por el desarrollador, ya que se da por supuesto que
durante la implementación del sistema ha ido comprobando que lo implementado funcionaba, y si esa
persona realiza las pruebas, es muy probable que siga los mismos pasos que realizó durante la
implementación, y no encuentre algunos errores.
Debido al carácter académico de este proyecto, el proyectando será el encargado de la realización de las
pruebas del sistema aunque también haya sido el desarrollador.
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 6 de 24
3. GUÍA DE VERIFICACIÓN Y DE CÓDIGO Y PRUEBAS DE ENDALIA
A continuación se muestra el contenido principal del documento de verificación de código y pruebas
seguido en Endalia.
Esta guía describe una relación de pruebas a realizar para la verificación de funcionamiento de sistemas.
3.1 LISTA DE VERIFICACIONES Y PROCESOS DE PRUEBA
FORMULARIOS
1) Tooltips aparecen correctamente y en una sola línea (salvo casos claros de texto muy largo o
con formato necesario de varias líneas)
2) Mensaje de confirmación aparecen correctamente en todos aquellos botones que impliquen
actualización de datos. Esta regla solo deberá obviarse para aquellos casos muy concretos en
los que prime la flexibilidad de manipulación de los datos involucrados sobre la integridad de los
mismos.
3) En el caso de que el formulario implique introducción de datos, hay que verificar que todo el ciclo
de funcionamiento es correcto.
Típicamente habrá tres caminos en este ciclo
a. Sin datos:
i. Introducir datos
ii. Guardar datos.
b. Sin datos:
i. Introducir datos
ii. Modificar datos
iii. Guardar datos
c. Con datos:
i. Modificar datos
ii. Guardar datos
Este proceso será previsiblemente diferente dependiendo de la naturaleza del formulario.
4) Verificar que todos los datos introducidos en el ejercicio se guardan correctamente. Verificar
especialmente el comportamiento de los botones ‘guardar’ cuando los campos están vacíos.
5) Verificar el funcionamiento de todos los botones
6) Verificar que no es posible efectuar ningún cambio en un formulario de solo lectura
7) Verificar que no es posible guardar los datos del formulario si no se ha completado
correctamente.
8) Probar el comportamiento al introducir datos exageradamente largos y o no validos (Caracteres
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 7 de 24
no comunes o en otros idiomas). Comprobar que las restricciones de longitud de datos se
verifican correctamente.
9) Comprobar a nivel de BD que los valores se guardan correctamente.
10) Verificar la apariencia del formulario al reducir la dimensión de la ventana (Hasta unos límites se
debería mantener una apariencia coherente). El diseño debe realizarse siempre para adaptarse
de manera dinámica a la ventana.
11) Repasar la estructura del formulario y verificar que queda muy claro cómo hay que rellenarlo.
12) Repasar textos y faltas de ortografía. Comentar entre todos aquellos textos de cuya redacción
tengamos dudas. Ser coherentes en los textos con todo el resto de la aplicación. Aquellos textos
que sean repetidos en varios sitios, típicamente p.ej ‘¿Quieres guardar los datos?’ deberán ser
iguales para toda la plataforma.
13) La transición liquida debe estar colocada en el formulario.
14) Verificar que todas las acciones del usuario son registradas en el log.
15) Verificar que la apariencia del formulario sin datos es correcta
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 8 de 24
4. PRUEBAS UNITARIAS Y DE INTEGRACIÓN
Las pruebas unitarias deben ser realizadas por le programador. Cada método que no sea trivial, debe ser
probado individualmente y en el conjunto de su módulo. Como ya se ha comentado, cada uno de estos
casos de uso se debe hacer a modo de caja negra.
Debido a la cantidad de casos de uso unitarios, y a que son muy parecidos entre si, se detalla a
continuación 4 de ellos, a modo de ejemplo.
IDENTIFICADOR PU01
TÍTULO Modificación de campo de texto. Ejemplo: Modificación nombre de EPI.
DESCRIPCIÓN Modificación del nombre del cliente desde el formulario de EPI.
RESULTADOS ESPERADOS Sustitución del nombre del EPI por el nuevo nombre.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PU02
TÍTULO Carga de un campo no editable. Ejemplo: Carga del código de un EPI
ya existente
DESCRIPCIÓN Es un campo no editable que debe tener valor al abrir un EPI ya
existente.
RESULTADOS ESPERADOS Aparece el campo con el formato no editable y con el valor definido en
el momento de su creación.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PU03
TÍTULO Modificación de un campo numérico. Ejemplo: Modificación de meses
de caducidad de un EPI.
DESCRIPCIÓN Modificación de meses de caducidad de un EPI.
RESULTADOS ESPERADOS Sustituir el valor de los meses por el nuevo valor teniendo en cuenta el
rango definido para el campo numérico.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PU04
TÍTULO Carga de un campo de tipo desplegable. Ejemplo: Carga de los ítems
monitorizados en el módulo de monitorización.
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 9 de 24
DESCRIPCIÓN Los campos de tipos desplegables poseen varias opciones cargadas
previamente para elegir entre una de ellas, la opción que nos interese.
RESULTADOS ESPERADOS Al hacer click sobre el campo desplegable deben aparecer los valores
predefinidos.
RESULTADOS OBTENIDOS Correcto
Las pruebas de integración, deben realizarse al finalizar cada módulo, para comprobar que todo funciona
correctamente, en los diferentes módulos del sistema. Para cada interfaz se debe comprobar que su
aspecto es adecuado con respecto al resto de la aplicación. Si el módulo tiene que interactuar con base
de datos, debe comprobarse su correcta comunicación con la base de datos y el resto de los módulos.
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 10 de 24
5. PRUEBAS DE SISTEMA
Las pruebas de sistema tienen por objeto verificar el correcto funcionamiento de la aplicación en su
conjunto, y comprobar que se cumplen los requisitos especificados.
Además de los casos de prueba que se detallan a continuación, se han tenido en cuenta las siguientes
consideraciones:
Rendimiento. Se he comprobado que el sistema se comporta de forma aceptable con diversas
cargas de trabajo.
Integración con el entorno. Se ha verificado que cada módulo por separado, y el sistema en su
conjunto son coherentes tanto en interfaz como en sensación visual con el resto de la plataforma
Integra donde está contenido.
Seguridad. Se ha comprobado que el sistema de control de usuarios cumple con las
especificaciones definidas en documento de requisitos.
Facilidad de uso. Se he evaluado la interfaz del sistema de modo que el usuario final la perciba
de la forma más intuitiva posible.
IDENTIFICADOR PS01
TÍTULO Añadir nuevo EPI/Reconocimiento médico
DESCRIPCIÓN Creación en el sistema de un nuevo EPI/Reconocimiento médico.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos. En caso contrario se informa al usuario.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS02
TÍTULO Comprobar la carga correcta del listado EPIs/Reconocimientos
médicos existentes.
DESCRIPCIÓN Al entrar en el módulo de EPIs/Reconocimientos médicos, la pantalla
inicial muestra el listado de todos los EPIs/Reconocimientos médicos
existentes dentro del sistema. Además, se debe comprobar la correcta
funcionalidad de las opciones de la barra de herramientas.
RESULTADOS ESPERADOS Se deben cargar todos los EPIs/Reconocimientos médicos existentes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS03
TÍTULO Editar EPI/Reconocimiento médico.
DESCRIPCIÓN Editar algún campo de la ficha de un EPI/Reconocimiento médico
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 11 de 24
determinado.
RESULTADOS ESPERADOS Comprobar la carga correcta de los elementos PRL asociados a un
Empleado/Puesto. En concreto, se debe comprobar:
Carga correcta de listado de EPIs/Rec. Médicos asociados a
un Empleado/Puesto dentro del formulario de
Empleado/Puesto.
Carga correcta de listado de cursos PRL/Riesgos asociados a
un Empleado/Puesto.
Carga correcta de documentos asociados.
Al editar algún campo de la ficha de Empleado/Puesto del módulo de
PRL se debe comprobar:
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
Se guardan correctamente los cambios realizados.
Además, dentro de la edición de datos de PRL en un Empleado/Puesto
a través de su ficha, se encuentran las operaciones de añadir, editar o
eliminar documentos. Se debe comprobar que dichas operaciones se
realizan de forma correcta.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS04
TÍTULO Eliminar EPI/Reconocimiento médico.
DESCRIPCIÓN Eliminar desde el listado, uno o varios EPIs/Reconocimientos médicos.
Si los EPIs/Reconocimientos médicos a eliminar, están siendo
utilizados se debe avisar al usuario que debe esperar para eliminarlos.
RESULTADOS ESPERADOS Los EPIs/Reconocimientos médicos eliminados desaparecen del
sistema.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS05
TÍTULO Comprobar la carga correcta de los documentos asociados a
Empleados/Puestos existentes.
DESCRIPCIÓN En todos aquellos lugares donde se visualiza el control de documentos
SharePoint comprobación de que se muestra el listado de todos los
documentos asociados a los Empleados/Puestos existentes dentro del
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 12 de 24
sistema. Además se debe comprobar la correcta funcionalidad de las
opciones de la barra de herramientas del control de documentos.
RESULTADOS ESPERADOS Se deben cargar todos los documentos asociados a
Empleados/Puestos existentes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS06
TÍTULO Añadir nuevo documento.
DESCRIPCIÓN Creación en el sistema de un nuevo documento.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos y que el documento se sube correctamente al
servidor SharePoint. En caso contrario se informa al usuario.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS07
TÍTULO Editar documento.
DESCRIPCIÓN Editar algún campo columna de una fila correspondiente a un
documento dentro del listado.
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados a cada
documento del listado. En concreto, se debe comprobar:
Se carga el nombre del fichero, versión, fechas de última
actualización, autor de la actualización, tamaño y comentarios.
Correcta funcionalidad de las opciones de la barra de
herramientas
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS08
TÍTULO Eliminar documento.
DESCRIPCIÓN Eliminar desde el listado, uno o varios documentos. Si los documentos
a eliminar, están siendo utilizados se debe avisar al usuario que debe
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 13 de 24
esperar para eliminarlos.
RESULTADOS ESPERADOS Los documentos eliminados desaparecen del sistema.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS09
TÍTULO Comprobar la carga correcta del listado productos.
DESCRIPCIÓN Al entrar en el módulo de artículos, la pantalla inicial muestra el listado
de todos los productos existentes dentro del sistema. Además, se debe
comprobar la correcta funcionalidad de las opciones de la barra de
herramientas.
RESULTADOS ESPERADOS Se deben cargar todos los productos existentes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS10
TÍTULO Añadir nuevo producto.
DESCRIPCIÓN Creación en el sistema de un nuevo producto.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos. En caso contrario se informa al usuario. Además,
dependiendo de la línea y tipo de producto a la que pertenece, se debe
comprobar que se cargan las características correspondientes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS11
TÍTULO Editar producto.
DESCRIPCIÓN Editar algún campo de la ficha de un producto determinado.
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados al producto
correspondiente. En concreto, se debe comprobar:
Carga correcta de datos generales y características principales
del producto. Las características varían según el tipo y línea de
producto a la que pertenezca el articulo a modificar.
Carga correcta de las características de impresión del producto
Carga correcta de las características de embalaje del producto
Carga correcto de la cadena de producción del producto.
Carga correcta de la información comercial del producto
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 14 de 24
Carga correcta de las observaciones asociadas al producto.
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS12
TÍTULO Eliminar producto.
DESCRIPCIÓN Eliminar desde el listado, uno o varios productos. Si los productos a
eliminar, están siendo utilizados se debe avisar al usuario que debe
esperar para eliminarlos.
RESULTADOS ESPERADOS Los productos eliminados desaparecen del sistema.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS13
TÍTULO Comprobar la carga correcta del listado de líneas y tipos de producto.
DESCRIPCIÓN Al entrar en el módulo de clientes/proveedores, la pantalla inicial
muestra a la izquierda una estructura con las líneas y tipos de
productos de forma jerárquica, y a la derecha el listado de todas las
líneas y tipos de productos existentes dentro del sistema. Se debe
comprobar:
Si cambias de nodo seleccionado en el árbol, la información
del listado se modifica mostrando las líneas y tipos
correspondientes a la selección.
La jerarquía del árbol debe coincidir con lo definido en la base
de datos.
Correcta funcionalidad de las opciones de la barra de
herramientas.
RESULTADOS ESPERADOS Se deben cargar todas las líneas y tipos de producto existentes. Tanto
en la estructura de árbol como en el listado.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS14
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 15 de 24
TÍTULO Añadir nuevo tipo de producto.
DESCRIPCIÓN Creación en el sistema de un nuevo tipo de producto dentro de una
familia determinada.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos. En caso contrario se informa al usuario.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS15
TÍTULO Editar líneas y tipos de producto.
DESCRIPCIÓN Editar algún campo de la ficha de la línea o tipo de producto
correspondiente.
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados a una línea o
tipo de producto. En concreto, se debe comprobar:
Como es un único formulario, se debe comprobar que se
cargan las características correspondientes a una línea o tipo
de producto según la entidad que se haya seleccionado para
editar.
Carga correcta de sus campos característicos.
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS16
TÍTULO Comprobar la carga correcta del listado de familias y materiales del
master dentro del módulo de master de materiales.
DESCRIPCIÓN Al entrar en el módulo del master de materiales, la pantalla inicial
muestra a la izquierda una estructura con las familias y materiales del
master de forma jerárquica, y a la derecha el listado de todos los
materiales y familias del master. Se debe comprobar:
Si cambias de nodo seleccionado en el árbol, la información
del listado se modifica mostrando las familias y materiales del
master correspondientes a la selección.
La jerarquía del árbol debe coincidir con lo definido en la base
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 16 de 24
de datos.
Correcta funcionalidad de las opciones de la barra de
herramientas.
RESULTADOS ESPERADOS Se deben cargar todas las familias y sus respectivos materiales del
master en la estructura de árbol. En el listado deben aparecer todos
los materiales del master correspondientes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS17
TÍTULO Añadir nueva familia.
DESCRIPCIÓN Creación en el sistema de una nueva familia de materiales.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos. En caso contrario se informa al usuario.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS18
TÍTULO Editar familia.
DESCRIPCIÓN Editar algún campo de la ficha de una familia de materiales
determinada.
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados a una familia
de materiales del master. En concreto, se debe comprobar:
Carga correcta de sus campos característicos.
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS19
TÍTULO Añadir nuevo material del master.
DESCRIPCIÓN Creación en el sistema de un nuevo material del master dentro de una
familia determinada.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos. En caso contrario se informa al usuario. Además,
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 17 de 24
dependiendo de la familia a la que está asociado, se debe comprobar
que se cargan las características correspondientes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS20
TÍTULO Editar material del master.
DESCRIPCIÓN Editar algún campo de la ficha de un material del master determinado.
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados a un material
del master. En concreto, se debe comprobar:
Como es un único formulario para materiales del master y
materiales reales, se debe comprobar que se cargan las
características correspondientes al material del master
seleccionado para editar.
Carga correcta de sus campos característicos.
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS21
TÍTULO Comprobar la carga correcta del listado de precios de materiales del
master.
DESCRIPCIÓN Al entrar en el módulo de precios de materiales, la pantalla inicial
muestra a la izquierda una estructura con las familias y materiales del
master de forma jerárquica, y a la derecha el listado de todos los
materiales y familias del master. Se debe comprobar:
Si cambias de nodo seleccionado en el árbol, la información
del listado se modifica mostrando las familias y materiales del
master correspondientes a la selección.
La jerarquía del árbol debe coincidir con lo definido en la base
de datos.
Si cambias de vista deben aparecer los precios
correspondientes a la vista elegida.
Correcta funcionalidad de las opciones de la barra de
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 18 de 24
herramientas.
RESULTADOS ESPERADOS Se deben cargar todos los precios actuales asociados a los materiales
del master existentes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS22
TÍTULO Editar precio de un material del master.
DESCRIPCIÓN Editar algún campo columna de una fila correspondiente a un precio,
dentro del listado.
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados a cada
precio del listado. En concreto, se debe comprobar:
Se carga el material del master o la familia a la que esta
asociado.
Si se cambia de vista deben cargarse los precios
correspondientes a la vista elegida.
Correcta funcionalidad de las opciones d ela barra de
herramientas.
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS23
TÍTULO Comprobar la carga correcta de los listados y estructuras de árbol del
inventario.
DESCRIPCIÓN Al entrar en el módulo de inventario, la pantalla inicial muestra a la
izquierda una estructura cuyos nodos dependen de la vista elegida.
Pueden ser familias y materiales del master, o bien, líneas y tipos de
producto, en ambos casos la estructura esta organizada de forma
jerárquica. A la derecha puede tener dos tipos de listados, uno de
resumen de inventario y otro de materiales reales, según la pestaña
inferior elegida. Se debe comprobar:
Si cambias de nodo seleccionado en el árbol, la información
del listado debe corresponder con lo seleccionado.
Si cambias de vista se debe cargar la estructura y el listado
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 19 de 24
correspondiente a la vista elegida.
Si cambias de listado se deben cargar los datos
correspondientes.
La jerarquía del árbol debe coincidir con lo definido en la base
de datos.
Correcta funcionalidad de las opciones de la barra de
herramientas.
RESULTADOS ESPERADOS Se deben cargar los listados de resumen y materiales reales. En la
estructura de árbol deberán aparecer los nodos correspondientes a la
vista elegida.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS24
TÍTULO Comprobar la carga correcta de los listados y estructuras de árbol de
almacén.
DESCRIPCIÓN Al entrar en el módulo de almacén, la pantalla inicial muestra a la
izquierda una estructura de secciones de almacén de forma jerárquica,
y a la derecha, puede tener dos tipos de listados, uno de secciones de
almacén y otro de materiales reales, según la pestaña inferior elegida.
Se debe comprobar:
Si cambias de nodo seleccionado en el árbol, la información
del listado debe corresponder con lo seleccionado.
Si cambias de listado se deben cargar los datos
correspondientes.
La jerarquía del árbol debe coincidir con lo definido en la base
de datos.
Correcta funcionalidad de las opciones de la barra de
herramientas.
RESULTADOS ESPERADOS Se deben cargar los listados de secciones y materiales reales
correspondientes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS25
TÍTULO Añadir nueva sección de almacén.
DESCRIPCIÓN Creación en el sistema de una nueva sección de almacén.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 20 de 24
valores correctos. En caso contrario se informa al usuario.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS26
TÍTULO Editar sección de almacén.
DESCRIPCIÓN Editar algún campo de la ficha de una sección de almacén
determinada.
RESULTADOS ESPERADOS
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS27
TÍTULO Eliminar sección de almacén.
DESCRIPCIÓN Eliminar desde el listado, uno o varios productos. En caso de eliminar
desde la estructura de árbol, solo se podrá eliminar una sección cada
vez. Si las secciones a eliminar, están siendo utilizados se debe avisar
al usuario que debe esperar para eliminarlos.
RESULTADOS ESPERADOS Las secciones eliminadas desaparecen del sistema. Es decir, no se
visualizan ni en el árbol ni en el listado correspondiente.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS28
TÍTULO Añadir nuevo material real desde inventario.
DESCRIPCIÓN Creación en el sistema de un nuevo material real asociado a un master
de material o tipo de producto según su tipo.
RESULTADOS ESPERADOS Debe comprobar que se introducen todos los datos obligatorios con
valores correctos. En caso contrario se informa al usuario. Además,
dependiendo del material del master y/o del tipo de producto al que
pertenece, se debe comprobar que se cargan las características
correspondientes.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS29
TÍTULO Editar material real.
DESCRIPCIÓN Editar algún campo de la ficha de un material real determinado.
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 21 de 24
RESULTADOS ESPERADOS Comprobar la carga correcta del los elementos asociados a un material
real. En concreto, se debe comprobar:
Como es un único formulario para materiales del master y
materiales reales, se debe comprobar que se cargan las
características correspondientes al material real seleccionado
para editar.
Carga correcta de sus campos característicos.
Al editar se verifica que los datos obligatorios han sido
rellenados. En caso contrario se informa al usuario.
El formulario cambia a estado modificado (aparece un
asterisco en el nombre del formulario).
Se guardan correctamente los cambios realizados.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS30
TÍTULO Eliminar material real.
DESCRIPCIÓN Eliminar desde el listado, uno o varios materiales reales. Si los
materiales reales a eliminar, están siendo utilizados se debe avisar al
usuario que debe esperar para eliminarlos.
RESULTADOS ESPERADOS Los materiales eliminados desaparecen del sistema.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS31
TÍTULO Rendimiento en la carga de listados del sistema
DESCRIPCIÓN Los listados de clientes, proveedores, productos, materiales del
master, materiales reales y resumen de inventario se realizan a través
de consultas complejas a la base de datos. Se debe comprobar que el
tiempo de esperar para que los datos correspondiente se carguen de
forma correcta, no excedan de un segundo. Para realizar esta prueba
es necesario probar la carga con distintos tamaños de datos y teniendo
en cuenta valores nulos.
RESULTADOS ESPERADOS La carga de datos en los listados se realiza de forma correcta en
menos de un segundo.
RESULTADOS OBTENIDOS Correcto
ss
IDENTIFICADOR PS32
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 22 de 24
TÍTULO Evento de doble click sobre un listado
DESCRIPCIÓN Al hacer doble click sobre una fila perteneciente a un listado de una
entidad determinada, se debe abrir la ficha correspondiente a dicha
entidad.
RESULTADOS ESPERADOS Se abre la ficha correspondiente al elemento del listado que recibe el
evento.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS33
TÍTULO Evengto doble click sobre un nodo del arbol
DESCRIPCIÓN Al hacer doble click sobre un nodo asociado a una entidad
determinada, se debe abrir la ficha correspondiente a dicha entidad.
Esto se debe cumplir para todos los listados salvo en el de precios de
materiales del master.
RESULTADOS ESPERADOS Se abre la ficha correspondiente al elemento del listado que recibe el
evento.
RESULTADOS OBTENIDOS Correcto
IDENTIFICADOR PS34
TÍTULO Tooltips
DESCRIPCIÓN Cuando no quede claro el comportamiento de una funcionalidad del
sistema asociada a un botón, se debe asociar a éste una tooltip de
ayuda. Ejemplo: añadir una sección desde los listados del modulo de
almacén.
RESULTADOS ESPERADOS Al colocar el ratón sobre el botón correspondiente debe aparecer un
mensaje que ayuda al usuario a identificar la funcionalidad de dicho
botón.
RESULTADOS OBTENIDOS Correcto
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 23 de 24
IDENTIFICADOR PS35
TÍTULO Submenú Emergente al hacer click con el botón derecho del ratón, en
el listado de materiales reales en el módulo de inventario
DESCRIPCIÓN Al seleccionar una fila del listado y hacer click con el botón derecho,
debe aparecer un submenú con varias opciones dependiendo del tipo
de material real seleccionado.
RESULTADOS ESPERADOS Si el material real es de tipo materia prima, deben aparecer las
opciones de: orden de compra y material real.
Si el material real es de tipo semielaborado, deben aparecer
las opciones de: orden de trabajo, orden de fabricación,
material real y producto asociados.
Si el material real es de tipo acabado, deben aparecer las
opciones de: orden de trabajo, orden de fabricación y producto
asociado.
Para todos los casos el funcionamiento es el siguiente: al elegir una de
las opciones del submenú se debe abrir la ficha correspondiente a la
entidad seleccionada.
RESULTADOS OBTENIDOS Correcto
Endalia Versión: 1.0
Plan de pruebas Fecha:
29/12/2011
PLAN DE PLAN DE PRUEBAS
CONFIDENCIAL 2011 Endalia Página 24 de 24
6. BIBLIOGRAFÍA
6.1 Referencias
[DUS 2002] Elfriede Dustin 2002. Effective Software Testing. Ed. Addison Wesley.
6.2 Referencias web
[Ref. Web 1] http://www.wikipedia.org
[Ref. Web 2] http://www.ergoestudio.com
[Ref. Web 3] http://www.lab.dit.upm.es/~lprg/material/apuntes/pruebas/testing.htm
Endalia
Manual de usuario
Versión 1.0 – Fecha: 16/02/2012
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 2 de 24
REVISIONES
Fecha Versión Descripción Autor
16/02/2012 1.0 Realización del documento de manual de
usuario
Miguel Ángel Catalán
Va
Copyright © 2011, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Carretera del Aeropuerto, 4. Edificio San Lamberto. E-50.011, Zaragoza • España
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 3 de 24
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 ACRÓNIMOS 4 1.4 DEFINICIONES 4 1.5 REFERENCIAS 4 1.6 RESUMEN 4
2. ACCESO AL SISTEMA 5
2.1 USUARIO Y CONTRASEÑA 5 2.2 PANTALLA DE INICIO 5
3. GESTIÓN DE PRL (EPIS, RECONOCIMIENTOS MÉDICOS Y MONITORIZACIÓN 6
3.1 MÓDULO DE GESTIÓN DE EPIS 6 3.2 MÓDULO DE GESTIÓN DE RECONOCIMIENTOS MÉDICOS 8 3.3 MÓDULO DE GESTIÓN DE LA MONITORIZACIÓN 9
4. GESTIÓN Y REGISTRO DE LA ACTIVIDAD EN PRL POR EMPLEADO 12
4.1 REGISTRO DE ACTIVIDAD PRL EN EPIS. 13 4.2 REGISTRO DE ACTIVIDAD PRL EN REC. MÉDICOS 14 4.3 REGISTRO DE ACTIVIDAD PRL EN FICHEROS DE RIESGOS 15 4.4 REGISTRO DE ACTIVIDAD PRL EN FORMACIÓN RECIBIDA 15
5. GESTIÓN EN REQUERIMIENTOS EN PRL POR PUESTO DE TRABAJO 17
5.1 GESTIÓN EN REQUERIMIENTOS EN PRL POR PUESTO EN EPIS 18 5.2 GESTIÓN EN REQUERIMIENTOS EN PRL POR PUESTO EN REC MÉDICOS 19 5.3 GESTIÓN EN REQUERIMIENTOS EN PRL POR PUESTO EN RIESGOS LABORALES 20 5.4 GESTIÓN EN REQUERIMIENTOS EN PRL POR PUESTO EN FORMACIÓN REQUERIDA. 21
6. GESTOR DE DOCUMENTOS SHAREPOINT 22
7. BIBLIOGRAFÍA 24
7.1 REFERENCIAS 24 7.2 REFERENCIAS WEB 24
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 4 de 24
1. INTRODUCCIÓN
1.1 Propósito del documento
El propósito de este documento es la realización de una guía rápida de ayuda al usuario, mediante
capturas de pantalla y breves descripciones, para que resulte lo más gráfico e intuitivo posible. No se
pretende detallar cada una de las funciones realizables desde el sistema de manera detallada, ya que se
convertiría en un documento demasiado extenso y menos útil para el usuario.
1.2 Alcance del documento
En este documento se describen el manual de usuario para los diferentes tipos de usuarios del sistema.
1.3 Acrónimos
PRL: Prevención de Riesgos Laborales.
EPI: Equipo de Protección Individual.
1.4 Definiciones
Tooltip: también llamada descripción emergente es una herramienta de ayuda visual, que
funciona al situar el cursor sobre algún elemento gráfico, mostrando una ayuda adicional para
informar al usuario de la finalidad del elemento sobre el que se encuentra.
Ventana Pop-up: Un pop-up o ventana pop-up o ventana emergente, es una ventana nueva que
aparece después de realizar alguna acción, por ejemplo pulsar un botón.
1.5 Referencias
En este documento no se referencian otros documentos del proyecto.
1.6 Resumen
Este documento describe el proceso de pruebas del Sistema de Gestión en PRL. Se compone de siete
apartados:
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: Se describe la forma de acceder al sistema.
Apartado 3: Se describen las funcionalidades del modulo de gestión PRL (EPIs,
Reconocimientos Médicos y Monitorización).
Apartado 4: Se describen las funcionalidades del módulo de gestión y registro de la actividad en
PRL por empleado.
Apartado 5: Se describen las funcionalidades del modulo de gestión de requerimientos de PRL
por puesto.
Apartado 6: Se describen las funcionalidades del gestor de documentos SharePoint.
Apartado 7: Bibliografía y referencias Web utilizadas para la realización de este documento.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 5 de 24
2. ACCESO AL SISTEMA
2.1 Usuario y contraseña
Para entrar en el sistema es obligatorio introducir en la pantalla de acceso las credenciales: nombre de
usuario y contraseña.
Figura 1. Ventana de acceso.
2.2 Pantalla de inicio
Si tus datos de autentificación son correctos, se cargará la pantalla de inicio del sistema. En la parte
superior de esta pantalla, están los distintos módulos de los que consta el sistema. El Sistema de
Gestión en PRL interviene en algunos de estos módulos.
Figura 2. Pantalla de inicio.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 6 de 24
3. GESTIÓN DE PRL (EPIS, RECONOCIMIENTOS MÉDICOS Y MONITORIZACIÓN
En este apartado se muestra cómo acceder y navegar por el módulo de gestión de PRL para llegar a las
funcionalidades que nos brinda dicho módulo.
El módulo de gestión de PRL se encuentra en la pestaña superior “O+RH” de la pantalla de inicio
Figura 3. Acceso al módulo de PRL
3.1 Módulo de gestión de EPIS
En módulo de gestión de EPIs pertenece a la pestaña superior “O+RH”, de la pantalla de inicio (dentro
del módulo de gestión de PRL visualizado en la Figura 3).
Figura 4. Módulo de gestión de EPIs
Para acceder al módulo haremos click sobre el botón mostrado en al Figura 4. Tras pulsar nos aparece a la izquierda el árbol de la estructura de los EPIS y a la derecha el listado de los EPIs según lo seleccionado en el árbol.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 7 de 24
Figura 5. Módulo de gestión de EPIs
En la barra de herramientas de la pantalla del listado tenemos acceso a las siguientes funcionalidades:
Añadir EPI /categoría.
Editar EPI/categoría: podemos editar de dos formas: la primera es seleccionando una fila del listado o un ítem del árbol y haciendo click sobre el botón “Editar” de la barra de herramientas y la segunda es hacer doble click sobre una fila del listado o ítem del árbol de la izquierda.
Menú de “Acciones”: Al pulsar este botón tenemos acceso a las funcionalidades de Eliminar, enviar por correo el listado adjuntado como un documento Excel, cambiar de estado y la asignación masiva a puestos.
o Sólo se puede eliminar un EPI seleccionando una fila del listado o item del árbol si el EPI
seleccionado está en estado histórico. Por otro lado solo se puede eliminar una
categoría seleccionando el ítem del árbol y si ésta no contiene EPIs. Si no se cumple
ninguna de las condiciones anteriores, la opción estará desactivada.
o Al hacer click sobre la opción de “Asignación masiva a puestos” nos aparece un pop-up
en el cual nos aparecen primero los reconocimientos médicos (paso 1) y después los
puestos de nuestra organización (paso 2), de esta forma hacemos que los
reconocimientos médicos seleccionados en el paso 1 sean necesarios para los puestos
seleccionados en el paso 2.
Exportar el listado de la derecha de la pantalla a Excel.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 8 de 24
Exportar el árbol de la izquierda de la pantalla a Excel.
Vistas: este botón nos permite cambiar de vistas tanto en el árbol como en el listado. Las
opciones de vistas en estas pantallas son de acuerdo a los estados de los EPIs.
3.2 Módulo de gestión de Reconocimientos Médicos
En módulo de gestión de Reconocimientos Médicos pertenece a la pestaña superior “O+RH”, de la
pantalla de inicio (dentro del módulo de gestión de PRL visualizado en la Figura 3).
Figura 6. Módulo de gestión de Reconocimientos Médicos
La organización de las funcionalidades de este módulo es similar al módulo de gestión de EPIs
anteriormente explicado. Esta uniformidad hace que el usuario pueda situarse en las funcionalidades de
forma muy intuitiva.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 9 de 24
3.3 Módulo de gestión de la Monitorización
En módulo de gestión de la Monitorización pertenece a la pestaña superior “O+RH”, de la pantalla de
inicio (dentro del módulo de gestión de PRL visualizado en la Figura 3).
Figura 7. Módulo de gestión de la Monitorización
Podemos acceder a la funcionalidad del módulo de gestión de la Monitorización pulsando sobre el botón de “Monitorización” de la Figura 7.
Indicar que este módulo nos permite visualizar todas aquellas deficiencias o aspectos críticos en materia de PRL dentro de nuestra empresa que requieran acción por parte del servicio de PRL.
Al acceder al módulo de Monitorización nos aparece la siguiente pantalla:
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 10 de 24
Figura 8. Módulo de gestión de la Monitorización
A la izquierda de la pantalla tenemos el árbol de puestos de la empresa y a la derecha el listado de las deficiencias relativas a todos los puestos por debajo del puesto seleccionado en el árbol de puestos.
Por defecto aparece la Monitorización de EPIs pero podemos cambiar a Reconocimientos Médicos, Formación o Ficheros de Riesgos simplemente haciendo click sobre la pestañas que se encuentran en la parte inferior de la pantalla como se indica en la Figura 9:
Figura 9: Pestañas entidades monitorizadas
Las funcionalidades que se nos ofrece al hacer click sobre las pestañas de la Figura 9 son:
o Visualización de Equipos de Protección Individual (EPI) entregados al personal, EPIs requeridos por el puesto que el empleado no tiene, aquellos cuya fecha de revisión ha sido excedida y Equipos de Protección calificados en su última revisión como NO APTOS.
o Visualización de reconocimientos médicos realizados por cada empleado, aquellos requeridos por
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 11 de 24
el puesto que el empleado no tiene, aquellos cuya fecha de revisión ha sido excedida y reconocimientos médicos en los que el empleado ha sido evaluado como NO APTO.
o Control de formación en materia de prevención: visualización de cursos de prevención realizados,
caducados y calificados como NO APTO dentro de la organización.
o Visualización de los documentos relacionados con los Riesgos Laborales.
Por otro lado, las funcionalidades que tenemos en al barra de herramientas son:
Editar: podemos editar de dos formas: la primera es seleccionando una fila del listado o un ítem del árbol y haciendo click sobre el botón “Editar” de la barra de herramientas y la segunda es hacer doble click sobre una fila del listado o ítem del árbol de la izquierda.
De esta forma depende si lo seleccionado es un puesto o bien un empleado, al editarlo se visualizará los requerimientos en PRL por puesto o el registro de la actividad en PRL por empleado respectivamente.
Menú Acciones: Al pulsar este botón tenemos acceso a la funcionalidad de enviar por correo el listado adjuntado como un documento Excel.
Exportar: Al pulsar este botón tenemos acceso a la funcionalidad de crear un fichero EXCEL bien con los datos del árbol o bien con los datos del listado.
Vistas: Al pulsar sobre este menú nos aparecen las siguientes opciones para filtrar la información a visualizar.
o Estructura (pendientes): Filtro para visualizar únicamente las deficiencias (lo pendiente de ser manejado por el servicio de PRL). Esta información se muestra en color rojo para mejorar su localización visual.
o Estructura (Todos): Con esta vista seleccionada visualizaremos tanto lo deficiente como lo que esta correcto.
o Empleados: Con esta vista seleccionada en el árbol de la izquierda de la pantalla (antes era de puestos) tenemos los empleados de nuestra organización agrupados por la primera letra de su primer apellido.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 12 de 24
4. GESTIÓN Y REGISTRO DE LA ACTIVIDAD EN PRL POR EMPLEADO
En este apartado se muestra cómo navegar en el módulo de gestión y registro de actividad en materia de
Prevención de Riesgos Laborales para cada empleado. Este módulo está situado en la pestaña O+RH
dentro del módulo Personas, como se indica en la figura 10:
Figura 10: Localización del módulo desde la ventana principal del sistema
.
Tras pulsar en el botón indicado en al Figura 10 nos aparece un listado de los empleados de nuestra
empresa. Para acceder al módulo basta con hacer doble click sobre el empleado del cual queremos ver
su actividad en PRL y tras esto seleccionar la pestaña PRL como se muestra en al Figura 11:
Figura 11: Ubicación módulo de gestión y registro de la actividad en PRL por empleado.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 13 de 24
4.1 Registro de actividad PRL en EPIs.
Figura 12: Registro de la actividad PRL en EPIS
Como se puede observar en la figura 12, en la pestaña de EPIs hay dos zonas claramente diferenciadas:
en al zona superior se encuentran las funcionalidades relativas a la gestión de EPIs entregados:
Añadir: Al pulsar este botón se nos muestra un pop-up con los EPIs gestionados
en el módulo de gestión de EPIs. En este pop-up seleccionaremos aquellos EPIs
que hayan sido entregados al empleado.
Eliminar: Funcionalidad para eliminar Rec. EPIs que se han seleccionado
previamente de la lista.
Exportar: Nos permite exportar en un fichero EXCEL la relación de EPIs
entregados al empleado.
Como se puede observar en la Figura 13, por cada Reconocimiento Médico de la lista tenemos un botón
llamado Revisiones en el que nos aparece el número de revisiones de ese EPI que están registradas.
Figura 13 Registro de las revisiones de un EPI determinado.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 14 de 24
Al pulsar sobre el botón de revisiones de un EPI nos aparece un pop-up con el listado de las revisiones
registradas (fecha y descripción de las mismas). Las funcionalidades referentes a estas revisiones son:
- Añadir, eliminar una determinada revisión.
- Modificar los datos de las revisiones (su fecha o su descripción).
En al zona inferior de la Figura 12 podemos observar que se encuentra la parte relativa al gestor
documental de los documentos de entrega de EPIs. Las funcionalidades que tenemos son las que nos
brinda el gestor documental explicado en el apartado 6.
4.2 Registro de actividad PRL en Rec. Médicos
Figura 14 Registro de la actividad PRL en Rec. Médicos.
En la barra de herramientas tenemos las funcionalidades de:
Añadir: Al pulsar este botón se nos muestra un pop-up con los reconocimientos
médicos gestionados en el módulo de gestión de Reconocimientos Médicos. En
este pop-up seleccionaremos aquellos reconocimientos que el empleado haya
realizado.
Eliminar: Funcionalidad para eliminar Rec. Médicos que se han seleccionado
previamente de la lista.
Exportar: Nos permite exportar en un fichero EXCEL los Reconocimientos
Médicos realizados por el empleado.
Como se puede observar en la Figura 13, por cada Reconocimiento Médico de la lista tenemos un botón
llamado Documentos en el que nos aparece el número de estos que están almacenados.
Figura 13: Botón de Documentos de Rec. Médicos.
Al pulsar este botón se nos da la funcionalidad de añadir un documento, editarlo, eliminar alguno ya
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 15 de 24
añadido o visualizarlo (funcionalidades que nos brinda en gestor de documentos y explicadas en el
apartado 6.
4.3 Registro de actividad PRL en ficheros de Riesgos
Figura 14: Gestión de los ficheros de Riesgos de un empleado
Como se puede observar en la figura 14, en este módulo se pueden encontrar las funcionalidades que
nos brinda en gestor de documentos (explicadas en el apartado 6) en referencia a documentos de
riesgos laborales aceptados por un empleado.
4.4 Registro de actividad PRL en formación recibida
Figura 15: Gestión de la formación recibida por un empleado.
Las funcionalidades relativas a la gestión de formación recibida por un determinado empleado son:
Añadir: Al pulsar este botón se nos muestra un pop-up con los cursos de PRL
gestionados por la organización. En este pop-up seleccionaremos aquellos
cursos que hayan sido realizados por el empleado.
Exportar: Nos permite exportar en un fichero EXCEL la relación de cursos
realizados por un empleado.
Visualizar el certificado de asistencia: Nos permite visualizar y editar en línea el
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 16 de 24
documento de certificado de asistencia del empleado al citado curso en PRL.
Añadir certificado de asistencia del empleado a un determinado curso:
Figura 16: Asistente para añadir el documento de certificado de asistencia
Como se puede observar en la figura 16, para añadir el certificado de asistencia
se tiene que pulsar el botón indicado y seleccionar el documento deseado.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 17 de 24
5. GESTIÓN EN REQUERIMIENTOS EN PRL POR PUESTO DE TRABAJO
En este apartado se muestra cómo navegar en el módulo de gestión en requerimientos en materia de
Prevención de Riesgos Laborales para cada puesto de trabajo. Este módulo está situado en la pestaña
O+RH dentro del módulo Puestos, como se indica en la figura 16:
Figura 16: Localización del módulo desde la ventana principal del sistema.
Tras pulsar en el botón indicado en al Figura 16 nos aparece un listado de los puestos de nuestra
empresa. Para acceder al módulo basta con hacer doble click sobre el puesto del cual queremos ver sus
requerimientos en PRL y tras esto seleccionar la pestaña PRL como se muestra en al Figura 17:
Figura 17: Localización del módulo de gestión en requerimientos en PRL por puesto de trabajo.
A continuación se detallan las funcionalidades de los diferentes módulos de gestión en PRL relativos a
puestos de trabajo.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 18 de 24
5.1 Gestión en requerimientos en PRL por puesto en EPIs
Figura 18: Gestión de requerimientos en PRL por puesto en EPIs.
Las diferentes funcionalidades de este módulo son:
Añadir: Al pulsar este botón se nos muestra un pop-up con los EPIs gestionados
en el módulo de gestión de EPIs. En este pop-up seleccionaremos aquellos EPIs
que sean requeridos por el puesto para asegurar la prevención de sus riesgos
asociados.
Eliminar: Funcionalidad para eliminar EPIs que se han seleccionado
previamente de la lista.
Exportar: Nos permite exportar en un fichero EXCEL el listado de los EPIs
requeridos por el puesto de trabajo.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 19 de 24
5.2 Gestión en requerimientos en PRL por puesto en Rec Médicos
Figura 19: Gestión de requerimientos en PRL por puesto en Rec. Médicos
Las diferentes funcionalidades de este módulo son:
Añadir: Al pulsar este botón se nos muestra un pop-up con los Rec. Médicos
gestionados en el módulo de gestión de Rec. Médicos. En este pop-up
seleccionaremos aquellos Rec. Médicos que sean requeridos por el puesto para
asegurar la prevención de sus riesgos asociados por parte del empleado que
ocupe el puesto.
Eliminar: Funcionalidad para eliminar Rec. Médicos que se han seleccionado
previamente de la lista.
Exportar: Nos permite exportar en un fichero EXCEL el listado de los Rec.
Médicos requeridos por el puesto de trabajo.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 20 de 24
5.3 Gestión en requerimientos en PRL por puesto en Riesgos Laborales
Figura 20: Gestión de requerimientos en PRL por puesto en Riesgos Laborales
Como se puede observar en la figura 20, en la pestaña de Riesgos Laborales hay dos zonas claramente
diferenciadas: en al zona superior se encuentran las funcionalidades relativas a la gestión de Riesgos:
Las diferentes funcionalidades de este módulo son:
Añadir: Al pulsar este botón se nos crea una nueva línea para insertar los datos
relativos o que definen el riesgo encontrado en el puesto (categoría, Riesgo
general, riesgo específico, gravedad, probabilidad, severidad, acciones
preventivas y observaciones).
Eliminar: Funcionalidad para eliminar Riesgos que se han introducido
previamente.
Exportar: Nos permite exportar en un fichero EXCEL el listado de los Riesgos.
detectados en el puesto de trabajo.
En al zona inferior de la Figura 20 podemos observar que se encuentra la parte relativa al gestor
documental de los documentos de análisis de los riesgos Laborales del puesto. Las funcionalidades que
tenemos son las que nos brinda el gestor documental explicado en el apartado 6.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 21 de 24
5.4 Gestión en requerimientos en PRL por puesto en formación requerida.
Figura 21: Gestión de requerimientos en PRL por puesto en cursos PRL
Las funcionalidades relativas a la gestión de formación requerida por un determinado puesto son:
Añadir: Al pulsar este botón se nos muestra un pop-up con los cursos de PRL
gestionados por la organización. En este pop-up seleccionaremos aquellos
cursos que sean necesarios por el puesto.
Exportar: Nos permite exportar en un fichero EXCEL la relación de cursos
requeridos por un puesto determinado.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 22 de 24
6. GESTOR DE DOCUMENTOS SHAREPOINT
En este apartado se muestra cómo localizar todas las funcionalidades que nos brinda el gestor de
documentos visualizado en la Figura 22.
Figura 22: Gestor de documentos.
En la barra de herramientas del gestor tenemos las funcionalidades de:
Añadir: Al pulsar este botón se nos muestra un menú desplegable donde
podemos elegir entre añadir un documento o crear una carpeta. Si hacemos
click sobre Añadir documento nos aparece un pop-up dónde podemos
seleccionar el documento a añadir. Si hacemos click sobre Añadir carpeta nos
aparece un pop-up donde se nos solicita el nombre de la carpeta que queremos
crear.
Eliminar: Funcionalidad para eliminar los elementos seleccionados en la lista de
documentos y carpetas.
Editar: Nos permite abrir los documentos seleccionados en la lista de
documentos y carpetas para su visualización o edición. Esta misma
funcionalidad se nos brinda si hacemos doble click sobre un documento de la
lista de documentos y carpetas.
Versiones: Al pulsar este botón se nos muestra un menú desplegable donde
podemos Listado de versiones o generar una nueva versión. Si hacemos click
sobre Listado de versiones nos aparece un pop-up dónde nos aparecen las
diferentes versiones del documento. En este pop-up podemos Generar una
nueva versión, eliminar una versión (siempre que no sea la más reciente),
restaurar una versión (hacer que una versión antigüa se tome como la más
reciente) y visualizar una versión seleccionada.
Si hacemos click sobre Generar nueva versión se nos creará una nueva versión
de los documentos seleccionados de la lista de documentos.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 23 de 24
Exportar: Al hacer click sobre este botón se genera un fichero Excel con el
contenido del listado de documentos y carpetas.
Enviar email: Al hacer click sobre este botón se nos abre un nuevo mensaje en
el Outlook y un pop-up con el contenido (carpetas y documentos). De esta forma
podemos adjuntar ficheros al mensaje arrastrándolos desde el pop-up del
contenido.
Para navegar por el contenido de las carpetas: nos movemos al contenido de una carpeta haciendo
doble click sobre la carpeta. Volvemos a la carpeta padre haciendo doble click sobre la primera fila de la
lista marcada con “…”
Otra forma de navegar es pulsar sobre el combo con lo que se nos visualiza el árbol de carpetas. Nos
movemos dentro de una de ellas seleccionando la carpeta elegida.
Además de todo lo anterior tenemos dos botones indicados en la Figura 23:
Figura 23: Botones situados esquina superior izquierda
Si pulsamos sobre el primero de ellos (el de la izquierda) se nos abre un pop-up con toda la estructura de
carpetas y documentos. En este pop-up tenemos las funcionalidades de añadir-eliminar carpeta además
de mover el documentos y carpetas arrastrándolos con el ratón (drag & drop).
Pulsando sobre el segundo (el de la derecha) se nos abrirá un pop-up en el cual se nos abre la
estructura de carpetas en un explorador de Windows. Esto es muy útil para mover documentos y
carpetas hacia/desde nuestro sistema hacia/desde/ el exterior. Desde este pop-up también podemos
añadir y eliminar carpetas/documentos.
Endalia Versión: 1.0
Manual de usuario Fecha: 16/02/2012
MANUALDEUSUARIO
CONFIDENCIAL 2012 Endalia Página 24 de 24
7. BIBLIOGRAFÍA
7.1 Referencias
En este documento no se han utilizado referencias a otros documentos.
7.2 Referencias web
[Ref. Web 1] http://www.wikipedia.org
Endalia
Estándar de codificación
Versión 1.2 – Fecha: 22/12/2011
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 2 de 30
REVISIONES
Fecha Versión Descripción Autor
21/03/2005 1.0 Creación de documento Diego Calvo Estaún
11/07/2011 1.1 Revisión y actualización a
procedimientos de 2011
Diego Calvo Estaún
22/12/2011 1.2 Actualización del estándar de
codificación
Miguel Ángel Catalán
Va
Copyright © 2007, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Plaza Roma F-1 7ºE 50010, Zaragoza • España
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 3 de 30
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 5
1.1 PROPÓSITO DEL DOCUMENTO 5 1.2 ALCANCE DEL DOCUMENTO 5 1.3 ACRÓNIMOS 5 1.4 DEFINICIONES 6 1.5 REFERENCIAS 6 1.6 RESUMEN 6
2. ESTRUCTURA DE LOS FICHEROS 7
2.1 INTRODUCCIÓN 7 2.2 CODIFICACIÓN DE ARCHIVOS DE CÓDIGO FUENTE 7 2.2.1 CODIFICACIÓN DE ARCHIVOS DE CÓDIGO FUENTE 8 2.2.2 REGIÓN DIRECTIVAS USING 8 2.2.3 REGIÓN DECLARACIÓN NAMESPACE Y CLASS 8 2.2.4 REGIÓN DECLARACIÓN DE VARIABLES 8 2.3 CODIFICACIÓN DE ARCHIVOS DE CLASE Y ACCESO A DATOS 9 2.3.1 REGIÓN DIRECTIVAS USING 9 2.3.2 REGIÓN DECLARACIÓN NAMESPACE Y CLASS. 10 2.3.3 REGIÓN CONSTANTES 10 2.3.4 REGIÓN ATRIBUTOS 10 2.3.5 REGIÓN CONSTRUCTORES 10 2.3.6 REGIÓN PROPIEDADES 10 2.4 CODIFICACIÓN DE ARCHIVOS DE RECURSOS DE INTERNACIONALIZACIÓN 10
3. REGLAS DE CODIFICACIÓN 12
3.1 IDENTACIÓN 12 3.1.1 LONGITUD DE LÍNEA 12 3.1.2 RUPTURA DE LÍNEAS 12 3.2 COMENTARIOS 12 3.2.1 APLICACIÓN DE LOS COMENTARIOS 13 3.2.2 FORMATOS DE IMPLEMENTACIÓN DE COMENTARIOS 14 3.3 DECLARACIONES 15 3.3.1 NÚMERO DE DECLARACIONES POR LÍNEA 15 3.3.2 INICIALIZACIÓN 15 3.3.3 SITUACIÓN 16 3.4 SENTENCIAS 16 3.4.1 SENTENCIAS SIMPLES 16 3.4.2 SENTENCIAS COMPUESTAS 17 3.4.3 SENTENCIAS DE RETORNO 17
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 4 de 30
3.4.4 SENTENCIAS IF, IF-ELSE, IF ELSE- IF ELSE 18 3.4.5 SENTENCIAS FOR 18 3.4.6 SENTENCIAS WHILE 19 3.4.7 SENTENCIAS DO-WHILE 19 3.4.8 SENTENCIAS SWITCH 19 3.4.9 SENTENCIAS TRY-CATCH 20 3.5 ESPACIOS EN BLANCO 21 3.5.1 LÍNEAS EN BLANCO 21 3.5.2 ESPACIOS EN BLANCO 21 3.6 CONVENCIONES DE NOMBRES 22 3.6.1 CLASES 22 3.6.2 MÉTODOS 22 3.6.3 VARIABLES Y PARÁMETROS 22 3.6.4 CONSTANTES 23 3.7 HÁBITOS DE PROGRAMACIÓN 23 3.7.1 REFERENCIAS A VARIABLES Y MÉTODOS DE CLASE 23 3.7.2 CONSTANTES 24 3.7.3 ASIGNACIONES DE VARIABLES 24 3.7.4 PARÉNTESIS 24 3.7.5 VARIABLES DE RETORNO 25 3.7.6 EXPRESIONES ANTES DE ‘?’ EN EL OPERADOR CONDICIONAL 25 3.7.7 COMENTARIOS ESPECIALES 26
4. ESTÁNDAR DE NOMBRADO DE BASE DE DATOS 27
4.1 IDIOMA A UTILIZAR 27 4.2 CONVENCIONES DE NOMBRADO DE TABLAS 27 4.2.1 NOMBRADO DE TABLAS DE ENTIDAD 27 4.2.2 NOMBRADO DE TABLAS DE RELACIÓN 28 4.2.3 NOMBRES DE TABLAS PREDEFINIDOS 28 4.2.4 CONVENCIONES DE NOMBRADO DE CAMPOS 28 4.2.5 NOMBRADO DE CAMPOS DE TABLAS DE ENTIDAD 28 4.2.6 NOMBRADO DE CAMPOS DE TABLAS DE RELACIÓN 29
5. BIBLIOGRAFÍA 30
5.1 REFERENCIAS 30 5.2 REFERENCIAS WEB 30
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 5 de 30
1. INTRODUCCIÓN
1.1 Propósito del documento
El presente documento describe las normas que deben seguirse en el desarrollo de cualquier
tipo de elemento de codificación realizado en este proyecto. El objetivo primordial de la
confección de un estándar de codificación se basa en homogeneizar el proceso de
implementación y codificación, para lograr obtener beneficios en la comprensión del código, en
la verificación y validación del mismo, y en posibles modificaciones posteriores.
Existen un gran número de razones por las que definir las convenciones de código son
importantes para los programadores:
El 80% del coste del código de un programa se invierte en su mantenimiento.
Casi ningún software lo mantiene toda su vida el auto original.
Las convenciones de código mejoran la lectura del software, permitiendo entender
código nuevo mucho más rápidamente y más a fondo.
La distribución de código fuente como producto exige su presentación de manera
adecuada.
De este modo, el presente documento pretende ser una colección de reglas que deben
aplicarse a todo el código generado, con el propósito de que sea homogéneo. Esta
homogeneidad permitirá una comprensión más efectiva del código tanto para su autor como
para otros programadores, facilitando su distribución y mantenimiento.
1.2 Alcance del documento
Este documento se ubica dentro de la fase inicial de desarrollo del proyecto de desarrollo del
Sistema de Gestión y Planificación de Endalia, como elemento necesario previo a la realización
de cualquier tipo de código fuente del proyecto, y será utilizado como guía durante toda la fase
de implementación.
1.3 Acrónimos
ANSI: American National Standards Institute.
HTML: Hypertext Markup Language.
ID: Identificador.
O+RH: Organización y Recursos Humanos.
URL: Uniform Resource Locator.
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 6 de 30
1.4 Definiciones
Pascal-Casing: Notación en la que los identificadores y nombres de variables, métodos
y funciones están compuestos por múltiples palabras juntas, iniciando cada palabra con
letra mayúscula.
Camel-Casing: Notación similar a la Pascal-Casing con la excepción que la letra inicial
del identificador no debe estar en mayúscula.
1.5 Referencias
En este documento no se realiza ninguna referencia a otros documentos del proyecto:
1.6 Resumen
El presente documento describe las normas que deben seguirse en el desarrollo de cualquier
tipo de elemento de codificación realizada en este proyecto. Se compone de 5 apartados:
Apartado 1: Se muestra el propósito del documento y se define su alcance. Se
proporciona una lista de acrónimos y definiciones útiles para la comprensión del
documento, así como una lista de los documentos del proyecto referenciados y el
presente resumen.
Apartado 2: Se muestra la estructura de codificación de los diferentes tipos de archivos
de código fuente desarrollados en el proyecto.
Apartado 3: Se muestran reglas, recomendaciones y buenas prácticas para el
desarrollo del código fuente del proyecto.
Apartado 4: Se muestra el estándar de nombrado de los elementos de base de datos.
Apartado 5: Bibliografía y referencias Web utilizadas en la confección de este
documento.
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 7 de 30
2. ESTRUCTURA DE LOS FICHEROS
2.1 Introducción
En este apartado se define la estructura y organización de los archivos de código fuente del
proyecto. Asimismo se especifica la codificación para los archivos de clases y acceso a datos
(.cs) y para los archivos de recursos de internacionalización (.txt que son posteriormente
compilados a .resx)
2.2 Codificación de archivos de código fuente
A continuación se muestra la estructura de codificación de los archivos de código subyacente
que será comentada posteriormente. Para una comprensión más sencilla se muestra mediante
una tabla con dos columnas. En la columna de la izquierda aparece un índice para facilitar la
posterior descripción de la región de la estructura definida en la columna de la derecha.
<1>Directivas
using
using System;
<directivas using>
<2>Declaración
namespace y
class
namespace MyNamespace1
{
public class MyClass
{
<3> Región
variables
#region variables
#region Variables I18N
<declaraciones de variables de internacionalización>
#endregion Variables I18N
#region Variables globales
<declaraciones de variables globales>
#endregion Variables globales
#endregion variables
<4> Región
I18N
#region I18N
<Código InitializeLabels>
<Código LoadI18N>
#endregion I18N
}
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 8 de 30
}
2.2.1 Codificación de Archivos de Código Fuente
Como se ha visto en el apartado 3.2 y para facilitar la organización y estructuración del código
fuente se utilizan las directivas #region y #endregion. Las regiones que se especifican en el
apartado 3.2 son las obligatorias en el caso de que aparezcan los elementos para los que han
sido definidas. En caso de que aparezcan elementos no especificados en las regiones del
apartado anterior podrán definirse nuevas regiones para especificar la sección de código
referida a los eventos y métodos del elemento o control. En cualquier caso, no se permitirán
eventos o métodos que no estén incluidos dentro de alguna región.
2.2.2 Región Directivas Using
En esta región se colocarán, por orden alfabético creciente, las directivas que especifiquen las
clases utilizadas en el código fuente definido en la clase actual.
2.2.3 Región Declaración Namespace y Class
En esta región se colocarán las cabeceras que especifican el espacio de nombres en los que
se integra el código y el nombre de la clase.
2.2.4 Región Declaración de Variables
Esta región estará integrada por cuatro subregiones que se especifican a continuación:
Región variables I18N: en esta región aparecen las declaraciones de cadenas de
internacionalización que son obtenidas del archivo de recursos y que se utilizan para definir
todos los textos que son presentados al usuario.
Región variables globales: en esta región aparecen las declaraciones de variables globales
utilizadas acompañadas de una descripción de su funcionalidad.
Región I18N: En esta región se colocan dos métodos:
o Método InitializeLabels: Realiza la lectura del fichero de recursos en el que se
almacenan las cadenas de internacionalización, cargando éstas en variables
de cadena.
o Método LoadI18N(): Carga en los campos de texto del formulario las variables
de cadenas obtenidas en el método InitializeLabels.
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 9 de 30
2.3 Codificación de Archivos de Clase y Acceso a Datos
A continuación se muestra la estructura de codificación de los archivos de acceso a datos y
definición de clase. De la misma manera que en el apartado se muestra mediante una tabla con
dos columnas. En la columna de la izquierda aparece un índice para facilitar la posterior
descripción de la región de la estructura definida en la columna de la derecha.
<1>Directivas
using
using System;
<directivas using>
<2>Declaración
namespace y
class
namespace MyNamespace1
{
public class MyClass
{
<3> Región
constants
#region constantes
<Declaración atributos>
#endregion atributos
<3> Región
atributos
#region atributos
<Declaración atributos>
#endregion atributos
<4> Región
constructores
#region constructores
<Métodos constructores clase>
#endregion constructors
<5> Región
propiedades
#region propiedades
<declaración propiedades>
#endregion propiedades
}
}
2.3.1 Región Directivas using
En esta región se coloca, por orden alfabético creciente, las directivas que especifiquen las
clases utilizadas en el código fuente definido en la clase actual.
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 10 de 30
2.3.2 Región declaración namespace y class.
En esta región se coloca las cabeceras que especifican el espacio de nombres en los que se
integra el código y el nombre de la clase.
2.3.3 Región constantes
En esta región se colocan las constantes de clase, internas utilizadas por nhibernate o
definidas manualmente
2.3.4 Región atributos
En esta región se colocará la declaración de los atributos de una clase. Los atributos se
nombrarán mediante Pascal-Casing exceptuando la primera letra, que será en minúscula y
precedida por un guión bajo de este modo:
private int _actionPlanItemID;
Asimismo en esta región se declararán las constantes de la clase, que se nombrarán con
mayúsculas.
2.3.5 Región constructores
En esta región se colocará la declaración de los métodos constructores de la clase.
2.3.6 Región propiedades
En esta región se coloca la declaración de las propiedades públicas de la clase. Las
propiedades se nombran con Pascal-Casing y en el caso de que representen el acceso al valor
de un atributo de la clase su nombre es el mismo del atributo sin el guión bajo y con la primera
letra en mayúscula, especificando el acceso a los métodos get y set de este modo:
public int ActionPlanItemID
{
get{ return _actionPlanItemID; }
set{ _actionPlanItemID = value; }
}
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 11 de 30
2.4 Codificación de archivos de recursos de internacionalización
Los archivos txt a partir de los cuales se generan los archivos de recursos de
internacionalización se construirán del siguiente modo:
Para cada una de las secciones del programa que tengan una entidad lo suficientemente
importante como para ser diferenciada se colocará un comentario y a continuación la relación
de las etiquetas. El nombrado de las etiquetas se hace del siguiente modo:
La parte inicial del nombre de la etiqueta será la misma que el nombre del archivo .cs
en el que se utilizará la etiqueta. A continuación se colocará un guión bajo seguido de
un prefijo que indicará la utilización de la etiqueta seguida de un guión bajo siguiendo
esta convención:
o etiqueta o campo de texto: _lbl_
o etiqueta de hyperlink: _lnk_
o texto de botón : _btn_
En el caso de que la etiqueta sea un tooltip se colocará al final el prefijo Tip_
A continuación se colocará un nombre descriptivo de la función de la etiqueta que
utilizará Pascal-Casing. No se especifica una norma rígida para este nombrado pero a
continuación se muestran unos ejemplos que muestran buenas prácticas del mismo.
ProjectActionPlan_lbl_TitleTree
ProjectActionPlan_btn_SaveActionPlan
ProjectTask_btn_EditActionPlanTip
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 12 de 30
3. REGLAS DE CODIFICACIÓN
3.1 Identación
Dada la actual uniformidad y estandarización de los editores utilizados para el desarrollo de
código C# en .NET se utilizará el tabulador como unidad de identación estándar. Los
comentarios se identarán al mismo nivel de identación que el código que se este
documentando.
3.1.1 Longitud de Línea
Se recomienda no escribir líneas con más de 80 caracteres, ya que no son bien manejadas por
muchos terminales y herramientas.
3.1.2 Ruptura de Líneas
Cuando una expresión no entre en una sola línea, se debe romper de acuerdo a estos
principios generales:
Romper después de una coma.
Romper antes de un operador.
Preferir las rupturas de alto nivel a las de bajo nivel.
Alinear la nueva línea con el principio de la expresión al mismo nivel de la línea
anterior.
3.2 Comentarios
En C# hay tres formas de escribir comentarios:
La primera consiste en encerrar todo el texto que se desee comentar entre caracteres
/* y */ siguiendo la siguiente sintaxis:
/*<texto>*/
o Estos comentarios pueden abarcar tantas líneas como sea necesario. No es
posible anidar comentarios de este tipo.
En la segunda se considera como indicador del comienzo del comentario la pareja de
caracteres // y como indicador de su final el fin de línea. Por tanto, la sintaxis que
siguen estos comentarios es:
// <texto>
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 13 de 30
La tercera manera es utilizando el trío de caracteres ///. Este tipo de comentario tiene la
particularidad de ser reconocido y utilizado por las herramientas de generación
automática de documentación y será el utilizado para la descripción de métodos y
clases, ya que en el caso de los primeros genera la estructura de tags de
documentación de nombres, parámetros y valores de retorno utilizados para la
documentación automatizada.
3.2.1 Aplicación de los Comentarios
Como se ha comentado en el punto anterior, el tercer tipo de comentario (el que va precedido
de los caracteres ///) se utiliza para crear de manera automática los tags que permiten la
generación automática de documentación.
Aparte de este punto los comentarios deberían usarse para una introducción del código y
proporcionar información adicional que no está disponible en el propio código. Los comentarios
sólo deberían tener información que sea relevante para leer y entender el programa. Por
ejemplo, información sobre cómo está construido la clase correspondiente o en qué directorio
reside, no debería ser incluida como comentarios.
Las discusiones no triviales o decisiones de diseño no obvias son apropiadas, pero debemos
evitar la duplicidad de información que esté presente en el código. Es demasiado fácil que los
comentarios redundantes se queden anticuados. En general, debemos evitar cualquier
comentario que se pueda quedar anticuado cuando el código evolucione.
La frecuencia en los comentarios algunas veces refleja una pobre calidad de código. Cuando
nos sintamos obligados a llenarlo de comentarios, debemos considerar la reescritura del código
para hacerlo más claro. Los comentarios no deben encerrarse en grandes cajas dibujadas con
asteriscos u otros caracteres. Los comentarios nunca deberían incluir caracteres especiales
como saltos de página, etc.
Los siguientes puntos son técnicas de comentarios recomendadas.
Cuando se modifica el código, se mantienen siempre actualizados los comentarios
circundantes.
Evitar los comentarios recargados, como las líneas enteras de asteriscos. En su lugar
se utilizan espacios para separar los comentarios y el código.
Evitar rodear un bloque de comentarios con un marco tipográfico. Puede resultar
agradable, pero es difícil de mantener.
Antes de la implementación, quitar todos los comentarios temporales o innecesarios,
para evitar cualquier confusión en la futura fase de mantenimiento.
Si se necesita realizar comentarios para explicar una sección de código compleja,
examinar el código para decidir si se debería volver a escribir. Siempre que sea
posible, no documentar un código malo, volver a escribirlo. Aunque, por regla general,
no debe sacrificarse el rendimiento para hacer un código más simple para el usuario,
es indispensable un equilibrio entre rendimiento y mantenibilidad.
Usar frases completas al escribir comentarios. Los comentarios deben aclarar el
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 14 de 30
código, no añadirle ambigüedad.
Ir comentando al mismo tiempo que se programa, porque probablemente no habrá
tiempo de hacerlo más tarde. Por otro lado, aunque se tuviera oportunidad de revisar el
código que se ha escrito, lo que parece obvio hoy es posible que seis semanas
después no lo sea.
Evitar comentarios superfluos o inapropiados, como comentarios divertidos al margen.
Usar los comentarios para explicar el propósito del código como si fueran traducciones
interlineales.
Comentar cualquier cosa que no sea legible de forma obvia en el código.
Para evitar problemas recurrentes, hacer siempre comentarios al depurar errores y
solucionar problemas de codificación, especialmente cuando se trabaje en equipo.
Hacer comentarios en el código que esté formado por bucles o bifurcaciones lógicas.
Se trata en estos casos de áreas clave que ayudarán a los lectores del código fuente.
Realizar los comentarios en un estilo uniforme, respetando una puntuación y estructura
coherentes a lo largo de toda la aplicación.
Separar los comentarios de sus delimitadores mediante espacios. Si se respeta esta
norma, los comentarios serán más claros y fáciles de localizar si trabaja sin
indicaciones de color.
3.2.2 Formatos de Implementación de Comentarios
Los programas pueden tener cuatro estilos de implementación de comentarios:
Bloque de comentarios: Los bloques de comentarios se usan para proporcionar
descripciones de ficheros, métodos, estructuras de datos y algoritmos. Los bloques de
comentarios podrían usarse al principio de cada fichero y antes de cada método.
También pueden usarse en otros lugares, como dentro de los métodos. Para este tipo
de comentario se preferirá la estructura /* - */. Un bloque de comentario debería ir
precedido por una línea en blanco para configurar un apartado del resto del código:
/*
* Esto es un bloque de comentarios.
*/
Comentarios de una línea: Los comentarios cortos pueden aparecer como una sola
línea identada al nivel del código que la sigue. Si un comentario no se puede escribir en
una sola línea, debería seguir el formato de los bloques de comentario. Un comentario
de una sola línea debería ir precedido de una sola línea en blanco. Para este tipo de
comentario se preferirá utilizar los caracteres ‘//’ . A continuación se muestra un
ejemplo:
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 15 de 30
if (condition) { // Código de la condición. ... }
Comentarios finales: Los comentarios muy cortos pueden aparecer en la misma línea
que el código que describen, pero deberían separarse lo suficiente de las sentencias.
Si aparece más de un comentario en el mismo trozo de código, deberían estar
identados a la misma altura. Para este tipo de comentario se preferirá utilizar los
caracteres ‘//’. Aquí tenemos un ejemplo utilizando estos caracteres y la estructura /* -
*/:
if (a == 2)
{
return TRUE; // caso especial
}
else
{
return isPrime(a); /* otro comentario */
}
3.3 Declaraciones
3.3.1 Número de Declaraciones por Línea
Se recomienda una declaración por línea ya que mejora los comentarios. En otras palabras:
int level; // nivel de identación int size; // tamaño se prefiere sobre:
int level, size; No debemos poner diferentes tipos en la misma línea. Por ejemplo:
int foo, fooarray[]; //Evitar
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 16 de 30
3.3.2 Inicialización
Debemos intentar inicializar las variables locales donde son declaradas. La única razón para no
inicializar una variable donde es declarada es si el valor inicial depende de algún cálculo que
tiene que ocurrir antes.
3.3.3 Situación
Ponemos las declaraciones sólo al principio de los bloques. No debemos esperar a declarar
variables hasta que son usadas por primera vez; puede confundir al programador y estorbar la
portabilidad del código dentro del ámbito.
void myMethod() { int int1 = 0; // comienzo de bloque if (condition) { int int2 = 0; // comienzo de bloque if ... } } La única excepción a esta regla son los indexados para los bucles, que en C# pueden ser
declarados en la sentencia for:
for (int i = 0; i < maxLoops; i++) { ... } Debemos evitar las declaraciones locales que oculten las declaraciones de nivel superior. Por
ejemplo, no debemos declarar el mismo nombre de variable en un bloque interno:
int count;
myMethod() {
if (condition) {
int count; // Evitar
...
}
}
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 17 de 30
3.4 Sentencias
3.4.1 Sentencias Simples
Cada línea debe contener como máximo una sentencia. Por ejemplo:
argv++; // Correcto argc++; // Correcto argv++; argc--; // Evitar
3.4.2 Sentencias Compuestas
Las sentencias compuestas son sentencias que contienen listas de sentencias encerradas
entre llaves “{sentencias}”. Se ilustrarán ejemplos en las siguientes secciones.
Las sentencias encerradas deben identarse uno o más niveles que la sentencia
compuesta.
La llave (‘{‘) de apertura debe empezar una nueva línea a continuación de la que
empieza la sentencia compuesta; la llave de cierre (‘}’) debe empezar una nueva línea
y estar identada con el principio de la sentencia compuesta.
Las llaves se usan alrededor de todas las sentencias, incluso para sentencias simples,
cuando éstas forman parte de una estructura de control como una sentencia if-else o
for. Esto hace más fácil la adición de sentencias sin introducir errores debido al olvido
de las llaves.
Las únicas excepciones a esta regla serán para los métodos get y set de las clases de acceso
a datos descritos en el apartado 2.3.5
3.4.3 Sentencias de Retorno
Una sentencia de retorno no deberá usar paréntesis a menos que el valor de retorno sea más
obvio de esta forma. Por ejemplo:
return; return myDisk.size(); return (size ? size : defaultSize);
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 18 de 30
3.4.4 Sentencias if, if-else, if else- if else
Las sentencias de tipo if-else deberán tener la siguiente forma:
if (condition) { statements; } if (condition) { statements; } else { statements; } if (condition) { statements; } else if (condition) { statements; } else { statements; }
Las sentencias if siempre usan llaves. Debemos evitar el siguiente caso:
if (condition) //Evitar, se han omitido las llaves {}! statement;
3.4.5 Sentencias for
Una sentencia for deberá tener la siguiente forma:
for (initialization; condition; update) { statements; }
Una sentencia for vacía, en la cual todo el trabajo se hace en las cláusulas de inicialización,
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 19 de 30
condición y actualización, deberá tener la siguiente forma:
for (initialization; condition; update); Cuando usamos el operador como en las cláusulas de inicialización o actualización de una
sentencia for, debemos evitar la complejidad de usar más de tres variables. Si es necesario,
debemos usar sentencias separadas antes del bucle for, para la cláusula de inicialización, o al
final del bucle, para la cláusula de actualización.
3.4.6 Sentencias while
Una sentencia while deberá tener la siguiente forma:
while (condition) { statements; } Una sentencia while vacía deberá tener la siguiente forma:
while (condition);
3.4.7 Sentencias do-while
Una sentencia do-while deberá tener la siguiente forma:
do { statements; } while (condition);
3.4.8 Sentencias switch
Una sentencia switch deberá tener la siguiente forma:
switch (expression)
{
case constant-expression:
statement
break;
case constant-expression:
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 20 de 30
statement
/* continúa sin salto */
[default:
statement
jump-statement]
}
Cada vez que un case no incluye una sentencia break, debemos añadir un comentario donde
normalmente iría la sentencia break. Esto se ve en el ejemplo de código anterior con el
comentario “/* continúa sin salto */”. En cualquier caso se deberá evitar este tipo de
construcción.
Toda sentencia switch deberá incluir un valor default. El break en el case por defecto es
redundante, pero evita un error de caída si añadimos después otro case.
3.4.9 Sentencias try-catch
Una sentencia try-catch deberá tener la siguiente forma:
try { statements; } catch (Exception e) { statements; } Una sentencia try-catch también puede ir seguida de un bloque finally, que se ejecuta sin
importar si se ha completado con éxito o no el bloque try.
try { statements; } catch (Exception e) { statements; } finally { statements;
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 21 de 30
}
3.5 Espacios en Blanco
3.5.1 Líneas en blanco
Las líneas en blanco mejoran la lectura separando secciones de código que están relacionadas
lógicamente.
Siempre se deberán usar dos líneas en blanco en las siguientes circunstancias:
Entre secciones de un fichero fuente.
Entre definiciones de clases e interfaces.
Siempre se deberá usar una línea en blanco en las siguientes circunstancias:
Entre métodos.
Entre las variables locales de un método y su primera sentencia.
Antes de un bloque de comentarios o un comentario simple.
Entre secciones lógicas dentro de un método para mejorar su lectura.
3.5.2 Espacios en Blanco
Los espacios en blanco deberán usarse en las siguientes circunstancias:
Una palabra clave seguida por un paréntesis deberían estar separados por un espacio
en blanco:
while (true)
{
...
}
No se deberá usar un espacio en blanco entre un nombre de método y su paréntesis
de apertura. Esto ayuda a distinguir las palabras clave de las llamadas a métodos.
Después de las comas en una lista de argumentos debe aparecer un espacio en
blanco.
Todos los operadores binarios excepto “.” Deberían estar separados de sus operandos
por espacios. Los espacios en blanco nunca deben separar los operadores unarios
como incremento (“++”), y decremento (“—“) de sus operadores. Por ejemplo:
a += c + d;
a = (a + b) / (c * d);
while (d++ = s++)
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 22 de 30
{
n++;
}
Las expresiones de una sentencia deberán estar separadas por espacio. Por ejemplo:
for (expr1; expr2; expr3)
3.6 Convenciones de Nombres
3.6.1 Clases
Se deberá usar pascal-casing para el nombrado de clases. Debemos intentar mantener los
nombres de clases simples y descriptivos. Debemos usar palabras completas y evitar
acrónimos y abreviaturas (a menos que la abreviatura se use muy ampliamente como URL o
HTML). Ejemplo:
public class HelloWorld
{
...
}
3.6.2 Métodos
Los métodos deberán ser verbos. Se deberá usar pascal-casing para su nombrado. Ejemplo:
public class HelloWorld
{
void SayHello(string name)
{
...
}
}
3.6.3 Variables y Parámetros
Se usará camel-casing para el nombrado de variables y parámetos. Los nombres de variables
deberán ser cortos y llenos de significado. La elección de una variable debería ser mnemónica-
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 23 de 30
es decir, diseñada para indicar al observador casual su utilización. Se deben evitar los nombres
de variable de un sólo caracter, excepto para variables temporales. Algunos nombres comunes
de este tipo de variables son: i, j, k, m, y n para enteros. Ejemplo:
public class HelloWorld
{
int totalCount = 0;
void SayHello(string name)
{
string fullMessage = "Hello " + name;
}
}
3.6.4 Constantes
Los nombres de variables constantes de clases y las constantes ANSI deberán escribirse todo
en mayúsculas con las palabras separadas por subrayados (“_”). Se deberían evitar las
constantes ANSI para facilitar la depuración. Ejemplo:
public static int MIN_WIDTH = 4;
public static int MAX_WIDTH = 999;
public static int GET_THE_CPU = 1;
3.7 Hábitos de Programación
No debemos hacer públicas ninguna variable de instancia o de clase sin una buena razón. A
menudo las variables de instancia no necesitan ser asignadas/consultadas explícitamente.
Normalmente, esto sucede como efecto lateral de llamadas a métodos. Un ejemplo apropiado
de una variable de instancia pública es el caso en que la clase es esencialmente una estructura
de datos, sin comportamiento.
3.7.1 Referencias a variables y métodos de clase
Evitar usar un objeto para acceder a una variable o método de clase (static). Usar el nombre de
la clase en su lugar. Por ejemplo:
classMethod(); //correcto
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 24 de 30
AClass.classMethod(); //correcto
anObject.classMethod(); //Evitar
3.7.2 Constantes
Las constantes numéricas (literales) no se deben codificar directamente, excepto -1, 0 y 1, que
pueden aparecer en un bucle for como contadores.
3.7.3 Asignaciones de variables
Evitar asignar el mismo valor a varias variables en la misma sentencia. Es difícil de leer.
Ejemplo:
fooBar.fChar = barFoo.lchar = 'c'; // AVOID!
No usar el operador de asignación en un lugar donde se pueda confundir con el de igualdad.
Ejemplo:
if (c++ = d++) { // AVOID!
...
}
se debe escribir:
if ((c++ = d++) != 0)
{
...
}
No debemos usar asignaciones embebidas como un intento de mejorar el rendimiento en
tiempo de ejecución. Ese es el trabajo del compilador. Ejemplo:
d = (a = b + c) + r; // ¡EVITAR!
Debería escribirse como:
a = b + c;
d = a + r;
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 25 de 30
3.7.4 Paréntesis
En general es una buena idea usar paréntesis en expresiones que implican distintos
operadores para evitar problemas con el orden de precedencia de los operadores. Incluso si
parece claro el orden de precedencia de los operadores, podría no ser así para otros. No se
debe asumir que otros programadores conozcan el orden de precedencia.
if (a == b && c == d) // Evitar
if ((a == b) && (c == d)) // Correcto
3.7.5 Variables de retorno
Debemos intentar hacer que la estructura de nuestro programa se corresponda con nuestra
intención. Por ejemplo:
if ( booleanExpression)
{
return true;
}
else
{
return false;
}
debería escribirse:
return booleanExpression;
De forma similar,
if (condition)
{
return x;
}
return y;
debería escribirse como:
return (condition ? x : y);
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 26 de 30
3.7.6 Expresiones antes de ‘?’ en el operador condicional
Si una expresión contiene un operador binario antes de ? en el operador ternario ?:, se debe
colocar entre paréntesis. Ejemplo:
(x >= 0) ? x : -x;
3.7.7 Comentarios Especiales
Debemos usar XXX, en un comentario para indicar que algo tiene algún error pero funciona.
Usar la etiqueta FIXME para marcar algo que tiene algún error y no funciona.
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 27 de 30
4. ESTÁNDAR DE NOMBRADO DE BASE DE DATOS
4.1 Idioma a Utilizar
Para el nombrado de todos los elementos de la base de datos el idioma a utilizar será el inglés,
salvo que se especifique de manera explicita lo contrario.
4.2 Convenciones de Nombrado de Tablas
4.2.1 Nombrado de Tablas de Entidad
El nombrado de las tablas de entidad dentro de la base de datos seguirá la siguiente
codificación:
Todos los nombres comenzarán por tres letras descriptivas del módulo o ámbito de
aplicación de la tabla. La primera de estas tres letras será mayúscula y las otras dos
restantes serán minúsculas. Los prefijos generales predefinidos con una descripción de
los mismos se encuentran en el apartado 2.3 de este documento. En el caso de que el
ámbito de aplicación de la tabla a nombrar difiera de los que aparecen en este
apartado se definirá un nuevo prefijo y se añadirá a los existentes.
En el caso de que la tabla forme parte del desarrollo de una sección en concreto dentro
de un módulo, o forme parte de un conjunto de tablas relacionadas entre sí dentro de
un ámbito de aplicación de la base de datos, se colocarán después del prefijo anterior y
separadas por un guión bajo ‘_’ tres letras descriptivas de la sección. La primera de
estas letras será mayúscula y las otras dos restantes serán minúsculas. Si la tabla no
tuviese relación con otras dentro del ámbito definido por el prefijo inicial estas tres
letras no son necesarias.
A continuación y separado por un guión bajo ‘_’ se colocará un nombre descriptivo en
plural del contenido de la tabla. Se deberá usar pascal-casing para este el nombrado.
Se deberá intentar mantener los nombres simples y descriptivos. Se deberán usar
palabras completas y evitar acrónimos y abreviaturas (a menos que la abreviatura se
use muy ampliamente como ID, URL o HTML, en cuyo caso puede escribirse en
mayúsculas).
Ejemplos:
Gen_SystemOptions
Orh_Eva_Developments
Orh_Tra_GenericAreas
Orh_Tra_GenericCourses
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 28 de 30
4.2.2 Nombrado de Tablas de Relación
Las tablas de relación comenzarán con un prefijo ‘R_’.
A continuación, y en singular, se colocarán utilizando pascal-casing el nombre descriptivo de
las tablas de entidad que relaciona, pudiendo reducirse si es muy largo alguno de ellos.
De este modo, para relacionar las tablas ‘Prj_Projects_And_Tasks’ y ‘Orh_Emp_Employees’ se
creará la tabla ‘R_ProjectEmployee’
4.2.3 Nombres de Tablas Predefinidos
R : Relación. Tablas de relación.
Gen : Generic. Tablas relativas a la organización general de la base de datos.
Orh : Organización y recursos humanos.
Prj : Projects. Tablas relativas a proyectos.
Pro : Tablas relativas a procesos.
4.2.4 Convenciones de Nombrado de Campos
Una norma establecida es que no puede haber dos campos dentro de una misma base de
datos con el mismo nombre. Asimismo, el orden de los campos de una tabla de be seguir un
orden lógico, (no tiene sentido colocar, <nombre, teléfono, apellidos, fax...>, sino <nombre,
apellidos, teléfono, fax…>) Los nombres de los campos, dependiendo de si pertenecen a una
tabla de entidad o de relación, se construyen siguiendo las normas de los siguientes apartados:
4.2.5 Nombrado de Campos de Tablas de Entidad
Nombrado de claves primarias: Las claves primarias comenzaran con el prefijo ‘pk_’ y a
continuación seguirán las convenciones de nombrado del apartado 3.1.3. Como
finalización del nombre tendrán la terminación ‘ID’.
Nombrado de claves ajenas: Las claves ajenas comenzaran con el prefijo ‘fk_’ y a
continuación seguirán las convenciones de nombrado del apartado 3.1.3. Si la clave
ajena apunta a una clave primaria de otra tabla como finalización del nombre tendrá la
terminación ‘ID’.
Nombrado de campos: Todos los campos de una misma tabla tendrán un mismo prefijo
que resumirá el nombre descriptivo de la tabla. La primera de estas letras será
mayúscula y las restantes serán minúsculas. Por ejemplo, si la tabla es
‘Orh_Reg_DataBind’ todos los campos de la tabla en este punto empezarían por ‘Dbn’
o ‘Dbind’. Otro ejemplo: Si la tabla es ‘Prj_Diary_Notes’ los campos de la tabla
empezarían por ‘Diary’ o ‘Dia’.
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 29 de 30
A continuación se colocará el nombre del campo. Para nombrar los campos de la tabla
se utilizarán nombres descriptivos de su significado. Se deberá usar pascal-casing para
este nombrado. Se deberá intentar mantener los nombres simples y descriptivos. Se
deberán usar palabras completas y evitar acrónimos y abreviaturas (a menos que la
abreviatura se use muy ampliamente como ID, URL o HTML, en cuyo caso puede
escribirse en mayúsculas).
Ejemplos:
fk_AppEndDate
pk_AppDate
AppRol
AppGender
4.2.6 Nombrado de Campos de Tablas de Relación
Nombrado de claves ajenas: Las claves ajenas comenzarán por ‘fk_’, a continuación
aparecerán, utilizando Pascal casing, los nombres descriptivos de la tablas de entidad
que se relacionan (pudiendo resumirse si son muy largos), y se finalizarán con el
nombre descriptivo de la tabla a la que apuntan seguido de ID.
Ejemplo:
En la tabla ‘R_ProjectEmployee’ que relaciona las tablas
‘Prj_Projects_And_Tasks’ y ‘Orh_Emp_Employees’ se nombrarán de esta
manera las claves ajenas:
fk_ProjEmpEmployeeID
fk_ProjEmpProjectID
Nombrado de campos: Los campos en las tablas de relación se nombrarán mediante
pascal-casing. Comenzaran con los nombres descriptivos de la tablas de entidad que
se relacionan (pudiendo resumirse si son muy largos). A continuación se colocará el
nombre del campo. Para nombrar los campos de la tabla se utilizarán nombres
descriptivos de su significado. Se deberá intentar mantener los nombres simples y
descriptivos. Se deberán usar palabras completas y evitar acrónimos y abreviaturas (a
menos que la abreviatura se use muy ampliamente como ID, URL o HTML, en cuyo
caso puede escribirse en mayúsculas)
Ejemplos:
En la tabla ‘R_ProjectEmployee’ que relaciona las tablas
‘Prj_Projects_And_Tasks’ y ‘Orh_Emp_Employees’ los nombres de los campos
podrían ser:
ProjEmpRemarks
ProjEmpDuration
Endalia Versión: 1.32
Estándar de codificación Fecha:
28/07/200711
ESTANDAR DE CODIFICACIÓN
CONFIDENCIAL 2007 Endalia Página 30 de 30
5. BIBLIOGRAFÍA
5.1 Referencias
[LOW, 2004] Juval Lowy 2003. C# Coding Standard. Idesign Inc 2004.
5.2 Referencias Web
[Ref. Web 1] http://www.dotnetspider.com/technology/tutorials/BestPractices.aspx
[Ref. Web 2] http://msdn.microsoft.com/
[Ref. Web 3] http://www.idesign.net/idesign/
[Ref. Web. 4] http://vyaskn.tripod.com/object_naming.htm
Endalia
Estándar de documentación
Versión 1.1 – Fecha: 22/12/2011
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 2 de 15
REVISIONES
Fecha Versión Descripción Autor
03/09/2007 1.0 Estándar de documentación Alfonso Romay
22/12/2011 1.1
Adecuación de estándar de
documentación para documentación del
PFC
Miguel Ángel Catalán
Va
Copyright © 2007, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Plaza Roma F-1 7ºE 50010, Zaragoza • España
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 3 de 15
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 DEFINICIONES 4 1.4 REFERENCIAS 4 1.5 RESUMEN 4
2. FORMATO DE DOCUMENTACIÓN 5
2.1 SOFTWARE UTILIZADO EN DOCUMENTACIÓN 5 2.2 MAQUETACIÓN 5 2.2.1 FORMATO DE LAS HOJAS 5 2.3 ORDEN DE CONTENIDOS 7 2.3.1 PORTADA: 7 2.3.2 REVISIONES Y COPYRIGHT: 7 2.3.3 ÍNDICE: 7 2.3.4 CONTENIDOS 7 2.4 FUENTES Y ESTILOS 8 2.5 INTERLINEADO Y FORMATO DE PÁRRAFOS 8 2.6 IMÁGENES Y DIAGRAMAS 9 2.7 GUÍA DE ESTILOS 9
3. PLANTILLAS DE DOCUMENTACIÓN 11
3.1 PLANTILLA DE DOCUMENTO 11 3.1.1 HOJA 1. PORTADA 11 3.1.2 HOJA 2. INFORMACIÓN DE DOCUMENTO 12 3.1.3 HOJA 3 Y SIGUIENTES. ÍNDICE 13 3.2 PLANTILLA DE ACTA DE REUNIÓN 14
4. BIBLIOGRAFÍA 15
4.1 REFERENCIAS 15 4.2 REFERENCIAS WEB 15
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 4 de 15
1. INTRODUCCIÓN
1.1 Propósito del documento
El propósito del presente documento es establecer las normas de documentación de los
documentos que serán mantenidos durante el desarrollo de la aplicación del proyecto de
desarrollo de la bolsa de empleo.
Este documento recoge las normas de maquetación, así como la metodología de
documentación a la hora de exponer los distintos aspectos que pueda abarcar la
documentación software, y un conjunto de guías para que la exposición de los distintos
aspectos de la documentación sean claros y estén recogidos de una forma homogénea.
1.2 Alcance del documento
El Alcance del documento son todos aquellos documentos realizados durante y para el
desarrollo del proyecto de bolsa de empleo web. Por supuesto, este documento ha sido creado
de acuerdo a las normas que define.
1.3 Definiciones
Fuente: Un miembro de una familia de tipo de letra.
1.4 Referencias
En este documento no se realizan referencias a otros documentos del proyecto.
1.5 Resumen
El presente documento es el estándar de documentación de Endalia. Se compone de los
siguientes apartados:
Apartado 1. Muestra el propósito del documento y se define su alcance.
Apartado 2. Especifica el formato de documentación del proyecto, indicando el orden
de sus contenidos. Incluye una guía de Estilo, donde se marca una línea de estilo a
seguir a la hora de redactar los documentos, y se aconseja sobre el uso de los distintos
elementos de formato.
Apartado 3: Plantillas de los principales documentos a utilizar durante la realización de
la documentación del proyecto, para en caso de ser necesarias, tenerlas a mano y
modificarlas de forma rápida.
Apartado 4. Bibliografía y referencias web utilizadas en la confección de este
documento.
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 5 de 15
2. FORMATO DE DOCUMENTACIÓN
2.1 Software utilizado en documentación
Para la elaboración de la documentación de este proyecto se utiliza el siguiente software:
Microsoft Office Word Professional Edition 2007 para la edición de texto. Dado que
este software no está instalado en todos los equipos de la empresa, el formato de
guardado de todos los documentos, deberá ser el compatible con la versión del 2003.
Microsoft Office Visio Proffesional Edition 2003 para la elaboración de diagramas.
Adobe Photoshop CS2 para la edición de imágenes.
2.2 Maquetación
Los documentos deberán seguir las siguientes normas de maquetación:
2.2.1 Formato de las hojas
2.2.1.1 Márgenes
Las hojas utilizadas serán A4 con los márgenes que se encuentran marcados en el diagrama
de la hoja que se presenta a continuación:
Figura 1. Diseño de los márgenes de las páginas
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 6 de 15
2.2.1.2 Encabezados y pies de página
Los encabezados y pies de página ocupan respectivamente las medidas indicadas en el
siguiente esquema:
Figura 2. Diseño del encabezado y el pie de página
El logotipo del encabezado está alineado a la izquierda y sus dimensiones son de alto 0,53cm y
de ancho 2.85cm, proporcional al tamaño original de la imagen.
El tipo de letra para el encabezado y el cierre de página es Arial a tamaño 8. El encabezado es
una tabla de tres columnas. En la primera columna, se encuentra el logo anteriormente
descrito. En la columna central, el nombre de la empresa, titulo del documento, y nombre del
documento. Una fila y tres columnas, en la primera celda se encuentran el nombre del
documento. En la columna de la derecha, se indicará la versión del documento, y su fecha de
creación. Las celdas de la columna central serán alineadas a la izquierda, y las de la columna
de la derecha, a la derecha.
En el pie de página se indicará a la derecha el número de página con el formato “Página 1 de
10”.
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 7 de 15
2.3 Orden de contenidos
Un documento presenta sus contenidos en el siguiente orden:
2.3.1 Portada:
Contiene el nombre del cliente, el título del documento, su versión y fecha de creación. Es la
única página que no presenta numeración de página, cabecera y pie de página. ( Ver Figura 4)
2.3.2 Revisiones y copyright:
Incluye información de copyright y de control de distribución y autorización, además del control
de versiones del documento. (Ver Figura 5)
2.3.3 Índice:
El índice se realiza a partir de una tabla de contenidos lo que significa que se debe de realizar
al final del documento o ir actualizándose conforme se va agregando información. El estilo es
Sofisticado y de tres niveles de profundidad.
El índice se desarrolla a partir de los títulos de las secciones de forma que el título de la
sección más general va subrayado y los demás van disminuyendo el tamaño según la
profundidad a la que se encuentren. Estos tres niveles de profundidad son correlativos con los
estilos de título empleados en los documentos, es decir, que existen tres niveles de índice
correspondientes a los diferentes estilos de título de los documentos, desde el de mayor
importancia o Título 1, hasta el de menor importancia incluido dentro del índice Título 3.
Quedan exentos de incluirse en el índice la página de Portada y de Identificación del
documento, así como el índice. No se incluyen puesto que no se consideran contenido del
documento en si, si no que son meta datos del mismo. Para que no queden incluidos dentro del
mismo ha sido necesario definir otro estilo de título, del mismo nivel jerárquico que Titulo 1,
pero sin numeración ni inclusión en la tabla de contenidos del índice. Este estilo está detallado
en la sección de estilos de este mismo documento. (Ver Figura 6)
2.3.4 Contenidos
Contenidos propiamente dichos del documento en cuestión: Usan una estructura de
información jerarquizada. Esta estructura está formada por cinco niveles de profundidad
usando los estilos de título. En cada uno de estos niveles jerárquicos, se muestra la
información respectiva. Todo el contenido usa alguno de los estilos descritos en la sección de
estilos de este mismo documento. Así, nos podemos encontrar con párrafos, viñetas,
imágenes, pies de foto, viñetas numeradas, etc.
Es importante hacer ver que en ningún momento se mezcla semántica con presentación. Es
decir. Nunca se ponen tabulados a mano, sangrías, saltos de página ó retornos de carro. Eso
sería introducir semántica extra en el contenido de la página. Absolutamente todos estos
detalles de presentación han sido incluidos en los estilos, definidos en la sección de estilos de
este documento.
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 8 de 15
2.4 Fuentes y estilos
A continuación se definen los tipos de fuente utilizados para los diferentes formatos de texto del
documento:
Título 1: Arial 16, Negrita.
Título 2: Arial 14, Negrita, Cursiva.
Titulo 3: Arial 13, Negrita.
Título 4: Trebuchet MS 10, Negrita.
Texto normal: Trebuchet MS 10.
Texto en píe de imágenes: Lista numerada, de fuente Arial 10, Cursiva, centrado.
Texto de Código fuente o acciones de línea de comandos: Courier New 10.
2.5 Interlineado y formato de párrafos
El interlineado utilizado en la documentación será sencillo. El texto se justificará por ambos
márgenes.
Se empezará página nueva entre apartados de primer nivel (Título 1)
Se evitará dejar títulos de segundo y tercer nivel como última línea de una página, siendo
ubicados en la página siguiente.
Todos los títulos tendrán al menos 20 puntos de separación con el texto anterior.
Las relaciones de elementos se separarán mediante un salto de línea y se indicarán con un
punto al principio de la línea, sin tabulado. En el caso de subrelaciones se indentarán mediante
tabulados sin guión de la siguiente manera:
Elemento 1
o Elemento de Nivel 2
Elemento de Nivel 3
Elemento de Nivel 3
Elemento de Nivel 3
o Elemento de Nivel 2
o Elemento de Nivel 2
o Elemento de Nivel 2
o Elemento de Nivel 2
o Elemento 2
Elemento 3
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 9 de 15
2.6 Imágenes y diagramas
Las imágenes y diagramas se colocarán centrados y ajustando en lo posible su tamaño a los
márgenes habituales de la página, excepto en el caso de que su tamaño sea excesivo para
visualizarlos de manera óptima dentro de esos márgenes, en cuyo caso se colocaran en
posición apaisada en una página nueva. Todas las imágenes estarán numeradas y se les
referenciará en el texto al que acompañan y mediante una definición centrada debajo de las
mismas que siempre se colocará orientada verticalmente incluso en imágenes que se hayan
ubicado en el documento apaisadas de la siguiente manera (Ver Figura 3).
Figura 3. Ejemplo de formato de imagen
2.7 Guía de estilos
Deberá utilizarse un estilo de redacción claro y conciso, y mostrando ejemplos si eso ayuda en
la compresión. Así mismo, la información podrá estar recogida en resúmenes, históricos,
gráficos u otros esquemas aclarativos, que aunque repliquen la información existente, ayuden a
la comprensión de los contenidos de un documento. Siguiendo esta misma línea, se podrán
incluir apéndices en los documentos con los mismos fines.
La redacción de contenidos deberá hacerse de forma sencilla, clara y concisa, sin caer en un
lenguaje lleno de tecnicismos. Para ello se permitirá el uso de expresiones coloquiales
utilizando comillas.
Así mismo se permite el uso de la negrita cuando se considere necesario resaltar o dar
importancia a algún texto, quedando la cursiva reservada para el marcado de ciertos elementos
dentro de la maquetación como el nombrado de imágenes o referencias a documentos.
Es importante reducir el uso de tablas y/o gráficos que introduzcan nuevos estilos que no
aparezcan en este documento. De esta forma, se evita caer en el uso de un número grande de
estilos, con la consiguiente sensación de caos que esto produce.
Las normas y guías de estilo sobre la colocación de ciertos elementos o colores se realizan con
la función de facilitar al lector la búsqueda de los elementos que precise de la mejor manera
posible.
A continuación se describe para que deben de utilizarse los principales estilos y aquellas
apreciaciones que puedan resultar de interés al usarlos:
Títulos: su funcionalidad es mantener bien acotados los contenidos de la sección y
facilitar su localización. Es importante observar que los títulos sirven para dar jerarquía
al contenido de los documentos, por lo que es interesante tener la estructura del mismo
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 10 de 15
clara antes de utilizarlos.
Enumeraciones (Viñetas): se utilizan para listar elementos, pueden ser con viñetas o
numeradas. Normalmente se utilizarán las que utilizan viñetas y solo en caso de
necesidad de establecer un orden entre los puntos se recurrirá a las numeradas.
Marcado: se utiliza el estilo cursiva para referirnos a cualquier documento o sección del
mismo. Siempre que se haga una referencia a una sección de un documento ajeno al
actual deberá citarse también el documento al que se hace referencia.
Espacios: El espaciado está introducido en los propios estilos. Con esto lo que se
quiere decir es que no se deben introducir espacios manualmente, ya sean
tabulaciones, saltos de línea, saltos de página, retornos de carro, etc. Por poner un
ejemplo, el estilo Título 1 ya incorpora un salto de página para que cada vez que se
usa, se haga en una página nueva.
Imágenes: Las imágenes deberán llevar el estilo Imagen centrada, y llevarán pies
explicativos. En tal caso, estas explicaciones deben llevar el estilo Pie de foto.
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 11 de 15
3. PLANTILLAS DE DOCUMENTACIÓN
Las plantillas explicadas en este apartado se encuentran guardadas en formato electrónica y
por razones de espacio no se pueden mostrar aquí a tamaño real. El objetivo de este apartado
es especificar el formato de los documentos para cualquiera que desarrolle algún texto para el
proyecto. Por ello se muestra una captura a tamaño reducido y una explicación de las partes
que las componen y la manera de utilizarlas. Como muestra del aspecto final sirve el presente
documento.
3.1 Plantilla de documento
3.1.1 Hoja 1. Portada
El formato de la portada de todos los documentos es el siguiente (Ver Figura 4).
Figura 4. Hoja 1 - Portada
En él se indica el titulo del documento con fuente Arial 34 negrita y se incluye información de
copyright y de control de distribución y autorización. Se incluye una cabecera común a todas
las hojas del documento en el que aparecen el logotipo de Endalia, el título del documento, el
nombre del archivo, la versión del documento, la fecha y la información de número de página.
El píe de página es también común a todas las hojas del documento e incluye la leyenda ‘
2007 Endalia’.
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 12 de 15
3.1.2 Hoja 2. Información de documento
El formato de la segunda hoja de todos los documentos es el siguiente (Ver Figura 5).
Figura 5. Hoja 2 –Información de documento
En esta hoja aparte de los elementos comunes de cabecera y pie de página aparece la
información de identificación del documento (Proyecto, Título del documento, Autor y
Descripción) y la historia del documento (Nombre del fichero, versión, fecha de creación, fecha
de última modificación y fecha de impresión) y un cuadro con información de revisiones.
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 13 de 15
3.1.3 Hoja 3 y siguientes. Índice
El formato del índice se indica en la siguiente imagen (Ver Figura 6) Se genera
automáticamente con Word estableciendo el tipo de letra de los apartados de nivel 1 a
Trebuchet 12 Negrita.
Figura 6. Índice
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 14 de 15
3.2 Plantilla de acta de reunión
El formato de plantilla de acta de reunión es el siguiente (Ver Figura 7). Incluye el nombre del
proyecto, la fecha lugar y hora de la reunión, los asistentes, el orden del día y las incidencias y
decisiones adoptadas.
Figura 7. Acta de Reunión
Endalia Versión: 2.01
Estándar de documentación Fecha:
28/07/200711
ESTÁNDAR DE DOCUMENTACIÓN
CONFIDENCIAL 2007 Endalia Página 15 de 15
4. BIBLIOGRAFÍA
4.1 Referencias
[HUT] Edward J Huth Scientific Style and Format: The CBE Manual for Authors, Editors, and
Publishers Cambridge University Press 1994
Estándar de documentación de Formación y Perfeccionamiento S.L.
4.2 Referencias Web
[Ref. Web 1] http://www.wikipedia.org
[Ref. Web 2] http://www.monografias.com/trabajos6/dosi/dosi.shtml
[Ref. Web 3] http://www.buenosaires.gov.ar/dgsinf/estandares/estandar_docu.php
[Ref. Web 4] http://www.apa.org/journals/webref.html
[Ref. Web 5] http://www.ucm.es/BUCM/psi/guia_red.htm
Endalia
Gestión de configuraciones
Versión 1.0 – Fecha: 22/12/2011
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 2 de 18
REVISIONES
Fecha Versión Descripción Autor
22/12/2011 1.0 Documento de gestión de configuraciones Miguel Ángel Catalán
Va
Copyright © 2007, ENDALIA, S.L. Todos los derechos reservados.
Este documento contiene información propietaria de ENDALIA, S.L. Se emite con el único propósito de informar proyectos Integra, por lo que no se ofrece ninguna garantía explícita o implícita. Ninguna parte de esta publicación puede ser utilizada para cualquier otro propósito, y no debe ser reproducida, copiada, adaptada, divulgada, distribuida, transmitida, almacenada en un sistema de recuperación o traducida a cualquier lenguaje del ser humano o de programación, en cualquier forma, por cualesquiera medios, por entero o en parte, sin el consentimiento previo por escrito de FP.
Algunos productos o compañías que se mencionan son marcas de sus respectivos propietarios.
ENDALIA, S.L. • Plaza Roma F-1 7ºE 50010, Zaragoza • España
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 3 de 18
TABLA DE CONTENIDOS
1. INTRODUCCIÓN 4
1.1 PROPÓSITO DEL DOCUMENTO 4 1.2 ALCANCE DEL DOCUMENTO 4 1.3 ACRÓNIMOS 4 1.4 DEFINICIONES 4 1.5 REFERENCIAS 5 1.6 RESUMEN 5
2. ESPECIFICACIONES DE GESTIÓN 6
3. ACTIVIDADES DE GESTIÓN DE CONFIGURACIONES 7
3.1 IDENTIFICACIÓN DE LA CONFIGURACIÓN 7 3.2 GESTIÓN DE LA CONFIGURACIÓN 7 3.3 CONTROL DE CAMBIOS DE LA CONFIGURACIÓN 8
4. HERRAMIENTAS UTILIZADAS 9
4.1 TEAM FOUNDATION SERVER 9 4.2 HABITUAL TASK 17
5. BIBLIOGRAFÍA 18
5.1 REFERENCIAS 18 5.2 REFERENCIAS WEB 18
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 4 de 18
1. INTRODUCCIÓN
1.1 Propósito del documento
En este documento, se describe cómo se gestionan las configuraciones de software, para
mantener la integridad de los productos desarrollados durante el desarrollo del proyecto,
garantizando que no se realizan cambios incontrolados y que todos los participantes en el
desarrollo del sistema disponen de la versión adecuada de los productos que manejan.
1.2 Alcance del documento
Las actividades de GCS se prolongan a lo largo del ciclo de vida del producto software.
1.3 Acrónimos GCS: Gestión de Configuraciones Software. ECS: Elemento de Configuración de Software. GC: Gestor de Configuraciones. RUP: Rational Unified Process. CCC: Comité de Control de Cambios.
IEEE: Institute of Electrical and Electronic Engineers (Instituto de Ingenieros Eléctricos
y Electrónicos).
PGCS: Plan de Gestión de Configuraciones de Software.
TFS: Team Foundation Server
1.4 Definiciones
Artefacto: Cualquier tipo de información creada, producida, cambiada o utilizada por el
equipo de desarrollo del proyecto.
Camel-Casing: Notación similar a Pascal-Casing con la excepción de que la letra inicial
del identificador debe ser minúscula.
Elemento de Configuración de Software: cualquier artefacto sujeto a todas las
especificaciones estipuladas en el plan de gestión de configuraciones de software.
Línea base: Punto de referencia en el proceso de desarrollo que queda marcado por la
aprobación de uno o varios elementos de Configuración de Software, mediante una
revisión técnica formal.
Pascal-Casing: Notación en la que un identificador está compuesto por múltiples
palabras juntas comenzando cada una de ellas por una letra mayúscula.
Revisión: Instancia de un ECS, en un momento dado del proceso de desarrollo, que es
almacenada en un repositorio, y que puede ser recuperada en cualquier momento para
su uso o modificación.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 5 de 18
1.5 Referencias
En este documento no se realizan referencias a otros documentos del proyecto.
1.6 Resumen
Este documento describe el plan de gestión de configuraciones del SWGECL. Se compone de
cinco apartados:
Apartado 1: Introducción del documento, definición del propósito y alcance del mismo.
Apartado 2: Descripción de la organización de la gestión de configuraciones.
Apartado 3: Especificación de las tareas a realizar para llevar a cabo la gestión de
configuraciones.
Apartado 4: Descripción de las herramientas utilizadas para la gestión de
configuraciones.
Apartado 5: Bibliografía y referencias Web utilizadas para la realización de este
documento.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 6 de 18
2. ESPECIFICACIONES DE GESTIÓN
La gestión de configuraciones de software es el proceso de identificar y definir los elementos en
el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando
e informando del estado de los elementos y las solicitudes de cambio, y verificando que los
elementos estén completos y que sean los correctos.
Dado que el proyecto ha sido realizado dentro de un entorno de trabajo real, y está integrado
con otro proyecto compartiendo BD, toda la gestión de configuraciones será tomada de ese
proyecto, para unificar el proceso al máximo.
Debido al tamaño que puede adquirir este proyecto, y al tratarse de un proyecto académico, en
el momento en que el proyecto cumpla los requisitos especificados será aislado del proyecto
principal, y en ese momento, el proyectando será el encargado de mantener las
configuraciones, control de cambios y versiones.
Asimismo, el Comité de Control de Cambios, que es el responsable de tomar las decisiones
finales sobre el estado y prioridad de las peticiones de cambios realizadas sobre los artefactos
almacenados en la biblioteca gestionada por el GC, queda constituido por Fernando Cortés
Franco y Ana María Sosa Berlanga, director y proyectando respectivamente de este proyecto.
El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad
de los productos de software durante su ciclo de vida. Para conseguirlo, se sigue el estándar
del IEEE Std 828-1990, y se realizan las siguientes actividades:
Identificación de la Configuración: Identificación de la estructura del producto, sus componentes y la naturaleza de los mismos. Haciéndolos únicos y accesibles de alguna forma.
Control de Cambios en la Configuración: Controlar las versiones y entregas de un producto y el control de cambios que se producen en él a lo largo de su ciclo de vida.
Generación de Informes de Estado: Informar acerca del estado de los componentes de un producto y de las solicitudes de cambio, recogiendo estadísticas acerca de la evolución del producto.
Auditoria de la Configuración: Validar la completitud de un producto y la consistencia entre sus componentes, asegurando que el producto es lo que el usuario quiere.
Debido al carácter académico del proyecto, se aplicarán únicamente los dos primeros puntos,
por considerar que el procedimiento de implantación de los dos últimos será más costoso que
los beneficios que aporta, y los dos primeros ya aportan una buena calidad en la gestión de
configuraciones.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 7 de 18
3. ACTIVIDADES DE GESTIÓN DE CONFIGURACIONES
En esta sección se van a describir los artefactos considerados para almacenar en las
bibliotecas junto con sus convenciones de nombrado, así como el modo de gestionar el control
de cambios de dichas configuraciones.
3.1 Identificación de la configuración
Para la correcta clasificación de los artefactos, se van a agrupar en distintas líneas base,
asignando identificadores apropiados a cada uno de ellos. La definición de las líneas base se
va a basar en los flujos de trabajo definidos en la metodología RUP utilizada, lo que lleva a la
siguiente taxonomía:
Planificación del proyecto.
Gestión de configuraciones.
Requisitos.
Análisis.
Diseño.
Implementación.
Pruebas.
Entrega del producto.
Para nombrar cada uno de los ECS que forman los diferentes artefactos definidos en este
documento, se seguirán las siguientes convenciones:
El nombre debe estar escrito en mayúsculas, y resumirá e indicará de modo intuitivo el
contenido del artefacto, seguido por una breve descripción del tipo de elemento por el que está
formado. Excepto en el caso de artefactos correspondientes a código fuente, se nombrarán
según la notación “Pascal-Casing”. En caso de tratarse de archivos binarios y scrips, serán
nombrados según la notación “Camel-Casing”. El nombre del artefacto, siempre terminará con
un punto, y la extensión del contenido del mismo, siguiendo lo estándares de nombrado de
archivos.
3.2 Gestión de la configuración
Para la gestión de configuraciones del presente proyecto, se definen las siguientes bibliotecas:
Biblioteca de trabajo. Se establece al inicio del proyecto y gestiona el área de trabajo de los ECS que se encuentran activos, esto es sobre los que se están realizando modificaciones.
Biblioteca maestra. Contiene elementos de configuración finalizados respecto a una iteración concreta del proceso de desarrollo. Sus elementos solamente pueden ser accedidos en modo de lectura una vez han sido establecidos.
Biblioteca de copias de seguridad. Contiene copias incrementales de las bibliotecas de trabajo y maestra generadas periódicamente.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 8 de 18
Para la gestión de las bibliotecas se emplea la herramienta Microsoft Team Foundation Server
la cual será explicada en detalle en el apartado 4 de este documento. (Herramientas utilizadas)
3.3 Control de cambios de la configuración
Para la gestión de cambios de la configuración, se van a tener en cuenta dos tipos de
modificaciones:
Control de cambios informal. Cambios realizados en ECS fuera de la política de control
de cambios, siendo éstos responsabilidad del desarrollador. Esta ausencia de control
está motivada por la necesidad de realizar modificaciones de un modo más dinámico al
comienzo del desarrollo de un ECS cuando los cambios son continuos y las
notificaciones y controles de corrección podrían saturar el proceso.
Control de cambios formal. Cambios realizados cuando un ECS es transferido a la
biblioteca de trabajo o a la biblioteca maestra, para ello, el responsable de la
modificación debe realizar una solicitud de cambio indicando si éste está motivado por
la detección y resolución de un defecto, por una variación en los requisitos o por la
realización de una mejora, la prioridad de la modificación según la relevancia de esta y
la línea base a la que afecta. Una vez realizada la petición, el CCC debe revisar el ECS
y aprobarlo si estima que es correcto o rechazarlo en caso contrario devolviéndolo a la
versión anterior.
En ambos casos se utilizará una nomenclatura especificada por el departamento de soporte y
gestión de cambios, incluyendo una cabecera generada por la herramienta Habitual Task
propia de Endalia. Esta herramienta genera la cabecera del registro del cambio en función del
proyecto y funcionalidad afectado.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 9 de 18
4. HERRAMIENTAS UTILIZADAS
4.1 Team Foundation Server
Como se ha comentado anteriormente, la herramienta utilizada para la gestión de cambios de
las configuraciones de software es Microsoft Team Foundation Server (TFS) que es una
aplicación que se integra con el entorno de desarrollo Visual Studio también de Microsoft,
permitiendo realizar gestión de código, recopilación de datos, generación de informes y trazado
de proyectos en un entorno colaborativo de desarrollo de software.
El TFS proporciona una interfaz completamente integrada con el entorno de desarrollo utilizado
para el desarrollo del presente proyecto, lo que facilita las labores de petición, comprobación y
gestión de modificaciones de ECS. Asimismo, proporciona herramientas para gestionar
posibles conflictos en ECS modificados por distintos desarrolladores y el acceso que estos
deben tener a cada uno de los recursos.
También permite la gestión de diferentes bibliotecas, aunque, por motivos de seguridad, la
biblioteca de copias de seguridad debe ser gestionada de un modo alternativo, mediante copias
incrementales de ficheros.
A continuación, se describen las principales funcionalidades del TFS empleadas para la gestión
de configuraciones:
Bloquear para modificación. Esta funcionalidad permite el bloqueo tanto exclusivo
como no exclusivo de un ECS, indicando la intención por parte del desarrollador de
modificarlo. Si lo bloquea en modo exclusivo no permite que otros desarrolladores
puedan tener acceso al mismo excepto que sea en modo de sólo lectura.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 10 de 18
Figura 1. Bloquear modificación
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 11 de 18
Descargar versión de la biblioteca. Esta funcionalidad permite la actualización de ECS
en la biblioteca local de cada desarrollador modificados por el resto del equipo.
Figura 2. Descargar última versión
Modificación de ECS. Esta funcionalidad permite la actualización de uno o varios ECS
por parte de un desarrollador que los tenía previamente bloqueados, debiendo éste
indicar la petición en el formato previamente establecido.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 12 de 18
o Indicando en modo texto el motivo del cambio en el campo de comentarios,
manteniendo un encabezado con un formato especifico de cabecera
determinado por el departamento de soporte. (Ver apartado 0 Para la gestión
de configuraciones del presente proyecto, se definen las siguientes bibliotecas:
Biblioteca de trabajo. Se establece al inicio del proyecto y gestiona el área de trabajo de los ECS que se encuentran activos, esto es sobre los que se están realizando modificaciones.
Biblioteca maestra. Contiene elementos de configuración finalizados respecto a una iteración concreta del proceso de desarrollo. Sus elementos solamente pueden ser accedidos en modo de lectura una vez han sido establecidos.
Biblioteca de copias de seguridad. Contiene copias incrementales de las bibliotecas de trabajo y maestra generadas periódicamente.
Para la gestión de las bibliotecas se emplea la herramienta Microsoft Team Foundation Server
la cual será explicada en detalle en el apartado 4 de este documento. (Herramientas utilizadas)
o Control de cambios de la configuración).
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 13 de 18
Figura 3. Subir a la biblioteca las modificaciones
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 14 de 18
o Antes de realizar la modificación puedes consultar los cambios que has
realizado, respecto a la versión del ECS que se encuentre en el servidor.
Figura 4. Comparar versión local y versión de la biblioteca antes de subir modificaciones
Figura 5. Comparar versión local y versión de la biblioteca antes de subir modificaciones
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 15 de 18
o Otra funcionalidad adicional que proporciona TFS, es la asignación de tareas y
errores. En caso de estar relacionados con alguno de los dos, o con varios,
pueden seleccionarse antes de subir los cambios de modo que a la hora de
testear la aplicación en caso de error se encuentren los archivos relacionados
rápidamente.
Figura 6. Asignar y crear de tareas y errores
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 16 de 18
Figura 7. Visualizar tareas y errores
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 17 de 18
Resolución de conflicto en ECS modificado por diferentes desarrolladores. Esta
funcionalidad permite mezclar el contenido de un ECS modificado simultáneamente por
diferentes desarrolladores. Para que surja la necesidad de emplear esta funcionalidad
es necesario que los desarrolladores bloqueen dicho artefacto en modo no exclusivo.
Figura 8. Asignar y crear de tareas y errores
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 18 de 18
Figura 9. Resolución de conflicto mediante mezcla de versiones
4.2 Habitual Task
Se trata de una herramienta generada por los desarrolladores de Endalia, en la que se van
incorporando funcionalidades que sean repetitivas. Está incorporado en el escritorio tal y como
se muestra en la imagen a continuación.
Figura 10. Habitual Task
Para generar la cabecera de control de cambios solo hay que seleccionar las opciones
deseadas, y se copia en el portapapeles la cabecera a insertar en el comentario del cambio a
realizar.
Por ejemplo:
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 19 de 19
MO_L_S_ERP_CONSIST_: listado de contactos. Prioridad alta, dentro del módulo de clientes.
Endalia Versión: 1.0
Gestión de configuraciones Fecha:
20/08/200711
GESTION DE CONFIGURACIONES
CONFIDENCIAL 2007 Endalia Página 20 de 20
5. BIBLIOGRAFÍA
5.1 Referencias
[IGJ, 2000] - I. Jacobson, G. Booch, J. Rumbaugh. 2000. El Proceso Unificado de Desarrollo de
Software. Pearson Education
5.2 Referencias Web
[Ref. Web 1] http://www.wikipedia.org
[Ref. Web 2] http://www.ieee.org
[Ref. Web 3] http://www.histaintl.com/soluciones/configuracion/configuracion.php
Recommended