Embed Size (px)
Citation preview
ESTÁNDARES DESARROLLO DEAPLICACIONES
Mayo 2018
CONTROL DE VERSIONES Y DISTRIBUCIÓNArquitecturas Tecnológicas
NOMBRE DEL DOCUMENTO: Estándares Desarrollo de Aplicaciones VERSIÓN: 03.00
CODIFICACIÓN DEL DOCUMENTO:ARQAP-DT-v.03.01-Estandares_Desarrollo_Aplicaciones.odt
ELABORADO POR: Arquitecturas Tecnológicas FECHA: 30/11/17
VALIDADO POR: FECHA:
APROBADO POR: Comité de Dirección FECHA: 27/12/17
REGISTRO DE CAMBIOS
Versión Causa de la nueva versión Fecha deaprobación
03.00 Revisión general del documento. 27/12/17
03.01
Se elimina referencia obsoleta a la guía de estilos de Intranet. Se actualizan las referencias a la guía de estilo de las interfaces gráficas para aplicaciones Intranet. Se incluye referencia al documento de gestión de contenido estático en las aplicaciones.
16/05/18
LISTA DE DISTRIBUCIÓN (opcional)
Nombre Número decopia
Área/Centro/Ubicación
CLÁUSULA DE CONFIDENCIALIDADCLÁUSULA DE CONFIDENCIALIDAD
Este documento es propiedad de la Consellería de Sanidade.
Se deberá utilizar dicho material exclusivamente para los servicios que han sido acordados con laConsellería de Sanidade y que requieren necesariamente su empleo.
Dicho compromiso incluye la prohibición de la reproducción total o parcial del materialmencionado, por cualquier medio o método.
ÍNDICEÍNDICE
1. INTRODUCCIÓN...................................................................................................6
2. PLATAFORMA BASE CORPORATIVA DE LA CONSELLERÍA DE SANIDADE 7
2.1. ENTORNOS DE DESARROLLO................................................................................7
2.2. SISTEMAS OPERATIVOS..........................................................................................7
2.3. GESTORES DE BASES DE DATOS..........................................................................8
2.4. SERVIDORES DE APLICACIONES...........................................................................8
2.5. SERVIDORES WEB....................................................................................................9
2.6. SERVIDORES DE INFORMES Y DE INTELIGENCIA DE NEGOCIO.......................9
2.7. ENTORNOS EMPRESARIALES DE GESTIÓN DOCUMENTAL Y DECONTENIDOS....................................................................................................................9
2.8. VIRTUALIZACIÓN.......................................................................................................9
2.9. SISTEMAS DE INFORMACIÓN GEOGRÁFICOS...................................................10
2.10. ENTORNOS DE INTEGRACIÓN............................................................................10
2.11. GESTORES DE IDENTIDADES.............................................................................10
2.12. GESTORES DE CORREO......................................................................................10
2.13. DIRECTORIO ACTIVO............................................................................................10
2.14. OTRAS HERRAMIENTAS.......................................................................................10
3. PROCEDIMIENTOS Y ESTÁNDARES GENÉRICOS DE DESARROLLO........12
3.1. ARQUITECTURA CORPORATIVA PARA EL DESARROLLO DE APLICACIONES 12
3.1.1. NORMATIVA GENERAL...............................................................................................12
3.1.2. PRINCIPIOS DE ARQUITECTURA..............................................................................12
3.2. CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE.........................................12
3.3. PROCEDIMIENTOS DE DESARROLLO..................................................................13
3.3.1. DOCUMENTACIÓN COMPLEMENTARIA ASOCIADA A UN PROYECTO...................16
3.4. CICLO DE VIDA DE PUBLICACIÓN DE APLICACIONES.......................................17
3.5. DOCUMENTO DE SEGURIDAD..............................................................................17
3.6. ASPECTOS FUNCIONALES....................................................................................18
3.6.1. GESTIÓN DE PERFILES.............................................................................................18
3.6.2. GESTIÓN DEL CICLO DE VIDA DE LA INFORMACIÓN EN LAS APLICACIONES.....18
3.6.3. NORMATIVA ACCESIBILIDAD.....................................................................................18
3.7. GUÍAS DE ESTILO...................................................................................................18
3.7.1. GUÍA DE ESTILO DE BASES DE DATOS....................................................................18
3.7.2. GUÍA DE ESTILO DE PROGRAMACIÓN.....................................................................19
3.7.3. GUÍA DE ESTILO DE INTERFAZ GRÁFICA.................................................................19
4. PROCEDIMIENTOS Y ESTÁNDARES ESPECÍFICOS DE DESARROLLO......20
4.1. SEGURIDAD EN EL DESARROLLO........................................................................20
4.2. NORMA TÉCNICA DE FIRMA ELECTRÓNICA........................................................20
4.3. USO DE CERTIFICADOS.........................................................................................20
4.4. PLATAFORMA DE FIRMA........................................................................................20
4.5. PROYECTOS JEE....................................................................................................21
4.6. INTEGRACIÓN ENTRE APLICACIONES WEB.......................................................22
4.7. SERVICIOS WEB......................................................................................................22
4.8. SERVICIOS WEB DE TARJETA SANITARIA...........................................................22
4.9. DISPOSITIVOS MÓVILES........................................................................................22
4.10. REPOSITORIO DE COMPONENTES REUTILIZABLES.......................................23
4.11. DESARROLLO DE INTEGRACIONES MIRTH.......................................................23
4.12. CATÁLOGO DE LÍNEAS BASE EXTENSIONES SOFTWARE PUESTO CLIENTE..........................................................................................................................................23
4.13. ACCESO A DATOS EN APLICACIONES................................................................24
4.14. GESTIÓN DOCUMENTAL EN APLICACIONES.....................................................24
4.15. ACCESO AL DIRECTORIO ACTIVO......................................................................24
4.16. GESTIÓN DE ERRORES Y LOGS EN LAS APLICACIONES...............................24
4.17. GENERACIÓN DE INFORMES Y DOCUMENTOS................................................25
4.18. OPTIMIZACIÓN DE APLICACIONES WEB...........................................................25
4.19. GESTIÓN DE CONTENIDO ESTÁTICO EN LAS APLICACIONES.......................25
4.20. RICH INTERNET APPLICATIONS..........................................................................25
4.21. RECOMENDACIONES PLATAFORMA DE APLICACIONES WINTEL..................26
4.22. ARQUITECTURA DE DESARROLLO SOBRE MOSS...........................................26
4.23. ARQUITECTURA DESARROLLO PLATAFORMA GIS..........................................26
4.24. ESTÁNDARES DESARROLLO PROCESOS BPM................................................26
4.25. DESARROLLO DE PROYECTOS BIZTALK...........................................................26
4.26. SISTEMAS DE INFORMACIÓN ANALÍTICA..........................................................27
4.27. ANTIPATRONES.....................................................................................................27
4.28. GESTIÓN DE PRUEBAS........................................................................................27
4.29. OTROS PROCEDIMIENTOS..................................................................................27
5. ARQUITECTURA SISTEMAS DE ANÁLISIS DE LA INFORMACIÓN...............28
5.1. ARQUITECTURA EN BUS DE LOS SIACS DE LA CONSELLERÍA DE SANIDADE...........................................................................................................................................29
5.2. MODELADO DE DATOS EN LOS SIACS DE LA CONSELLERÍA DE SANIDADE. 29
5.3. ARQUITECTURA DE PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN YCARGA.............................................................................................................................29
5.4. GUÍA DE ESTILO DE BUSINESS OBJECTS DESIGNER.......................................29
5.5. ESTRUCTURA DEL SUPERVISOR DE BUSINESS OBJECTS DE LACONSELLERÍA DE SANIDADE.......................................................................................30
6. HERRAMIENTAS DE DESARROLLO................................................................31
6.1. GESTIÓN DE PROYECTOS.....................................................................................31
6.2. MODELADO DE DATOS...........................................................................................31
6.3. DESARROLLO DE DIAGRAMAS PARA EL DESARROLLO...................................31
6.4. EMPAQUETADO DE SOFTWARE...........................................................................31
6.5. CONSTRUCCIÓN DE AYUDAS DE PROGRAMAS.................................................31
6.6. ENTORNOS INTEGRADOS DE DESARROLLO.....................................................31
1.1. INTRODUCCIÓNINTRODUCCIÓN
Este documento pretende servir como índice de todos los procedimientos y estándaresdefinidos por la Subdirección Xeral de Sistemas e Tecnoloxías da Información (enadelante SXSTI), que serán aplicables en el desarrollo, mantenimiento y adquisición deaplicaciones software en el ámbito de los proyectos de la Consellería de Sanidade y elServizo Galego de Saúde.
Se indica en primer lugar la plataforma base corporativa de la Consellería de Sanidade, ala que se deberán adaptar los nuevos desarrollos y aplicaciones informáticas asociados aestos proyectos para facilitar su despliegue, mantenimiento y operación.
Posteriormente se enumeran los diferentes estándares técnicos, metodologías, guías deestilo, herramientas de desarrollo, etc, existentes en la organización, que serán deaplicación en los proyectos de desarrollo y adquisición de aplicaciones.
La Consellería de Sanidade /Servizo Galego de Saúde dispone de documentosespecíficos para cada estándar y procedimiento recogido en este documento que seránfacilitados a los equipos implicados en las tareas de desarrollo y despliegue deaplicaciones.
Página 6 de 31
2.2. PLATAFORMA BASE CORPORATIVA DE LA CONSELLERÍA DEPLATAFORMA BASE CORPORATIVA DE LA CONSELLERÍA DESANIDADESANIDADE
2.1. ENTORNOS DE DESARROLLO
Los entornos de desarrollo existentes en la Consellería de Sanidade, dependiendo de laplataforma, son los siguientes:
• JEE:
◦ Especificaciones J2SE y JEE.
• .NET:
◦ Lenguajes .NET: C#, Visual Basic.NET.
Existen también otros entornos de desarrollo en uso, pero que no se podrán usar paranuevos desarrollos:
• Visual Basic.
• 4GL de Informix.
• 4GL de MultiBase.
2.2. SISTEMAS OPERATIVOS
Los sistemas operativos existentes en la Consellería de Sanidade son los siguientes:
• HP-UX.
• AIX.
• Windows Server.
• Windows.
• Linux RedHat.
Los sistemas operativos corporativos de la Consellería de Sanidade serán:
• Entorno Servidor:
◦ HPUX.
◦ Linux RedHat.
◦ Windows Server.
• Entorno Cliente:
◦ Windows.
Página 7 de 31
2.3. GESTORES DE BASES DE DATOS
Los gestores de bases de datos existentes en la Consellería de Sanidade son lossiguientes:
• Informix.
• SQL Server.
• Oracle.
• MultiBase.
• Tamino XML Server.
• MySQL.
• MariaDB.
• Cassandra.
• MongoDB.
Los SGBDs corporativos para el desarrollo de aplicaciones de la Consellería de Sanidadea utilizar en sistemas operacionales serán:
• Informix.
• Oracle.
El SGBD corporativo para almacenar datos XML en formato nativo es Tamino.
La SXSTI podrá elegir otro gestor o gestores en proyectos concretos si lo consideraadecuado.
2.4. SERVIDORES DE APLICACIONES
Los servidores de aplicaciones existentes en la Consellería de Sanidade, dependiendo dela plataforma, son los siguientes:
• Plataforma JEE:
◦ WebSphere Application Server.
◦ Tomcat.
• Plataforma .NET:
◦ IIS.
En la plataforma JEE el servidor de aplicaciones corporativo es WebSphere ApplicationNetwork Deployment, configurado en clúster, sobre plataforma Linux RedHat.
Para plataforma JEE, en casos debidamente justificados, y contando con la autorizaciónde la SXSTI, se podrá utilizar Tomcat como servidor de aplicaciones.
Página 8 de 31
En la plataforma .NET el servidor de aplicaciones para nuevas aplicaciones es InternetInformation Server sobre Windows Server Se dispondrá de un clúster NLB parabalanceo y alta disponibilidad.
2.5. SERVIDORES WEB
Los servidores web existentes en la Consellería de Sanidade, dependiendo de laplataforma, son los siguientes:
• Plataforma JEE:
◦ IBM HTTP Server.
◦ Apache.
• Plataforma .NET:
◦ IIS.
2.6. SERVIDORES DE INFORMES Y DE INTELIGENCIA DE NEGOCIO
Los servidores de informes y de inteligencia de negocio existentes en la Consellería deSanidade, son los siguientes:
• Business Objects Enterprise.
• IBM DataStage.
• Pentaho.
• Birt.
• Talend.
2.7. ENTORNOS EMPRESARIALES DE GESTIÓN DOCUMENTAL Y DECONTENIDOS
Los entornos empresariales de gestión documental y de contenidos existentes en laConsellería de Sanidade, son los siguientes:
• Alfresco (gestor documental).
• Microsoft SharePoint Enterprise (gestor de contenidos).
2.8. VIRTUALIZACIÓN
La plataforma de virtualización existente en la Consellería de Sanidade, es la siguiente:
• VMWARE ESX.
• Citrix XenApp sobre Windows Server.
Página 9 de 31
2.9. SISTEMAS DE INFORMACIÓN GEOGRÁFICOS
El sistema de información geográfico existente en la Consellería de Sanidade, es elsiguiente:
• ESRI: ArcGis Server.
2.10. ENTORNOS DE INTEGRACIÓN
Los entornos de integración existentes en la Consellería de Sanidade, son los siguientes:
• BizTalk sobre Windows.
• Mirth sobre Linux.
2.11. GESTORES DE IDENTIDADES
El gestor de identidades existente en la Consellería de Sanidade, es el siguiente:
• Oracle Identity Manager.
2.12. GESTORES DE CORREO
El gestor de correo existente en la Consellería de Sanidade, es el siguiente:
• Microsoft Exchange Server.
2.13. DIRECTORIO ACTIVO
El gestor de directorio activo existente en la Consellería de Sanidade, es el siguiente:
• Active Directory de Microsoft basado en Windows.
2.14. OTRAS HERRAMIENTAS
Otras herramientas existentes en la Consellería de Sanidade son:
• Control de versiones:
◦ CVS, Subversion.
◦ La versión corporativa de la Consellería de Sanidade es Subversion.
• Entornos de construcción automática e integración continua:
◦ Maven.
◦ Jenkins.
• Herramientas de automatización de control de la calidad del software:
◦ Sonar.
Página 10 de 31
• Herramientas para la gestión de proyectos:
◦ Redmine.
• Herramientas para la gestión de pruebas:
◦ TestLink.
• Herramientas de automatización de pruebas (unitarias, funcionales –de interfaz deusuario-, pruebas de carga):
◦ Junit.
◦ jMeter.
◦ Selenium.
• Herramientas de Comunicaciones:
◦ Microsoft Lync .
• Herramientas de Contact Center:
◦ Cisco PCCE.
• Plataforma eLearning:
◦ Moodle.
Página 11 de 31
3.3. PROCEDIMIENTOS Y ESTÁNDARES GENÉRICOS DE DESARROLLOPROCEDIMIENTOS Y ESTÁNDARES GENÉRICOS DE DESARROLLO
3.1. ARQUITECTURA CORPORATIVA PARA EL DESARROLLO DE APLICACIONES
3.1.1. NORMATIVA GENERAL
El desarrollo de aplicaciones para la Consellería de Sanidade debe realizarse en base alas especificaciones de plataforma, patrones arquitectónicos y de diseño, definidos en eldocumento de arquitectura de aplicaciones. En el planteamiento arquitectónico de lasaplicaciones, dudas y excepciones relativas al documento de referencia, se consultaráncon el responsable de arquitectura del área correspondiente.
• “ARQAP-AT-v.xx.yy-Arquitectura_Desarrollo_Aplicaciones”.
3.1.2. PRINCIPIOS DE ARQUITECTURA
Este documento sirve para definir los principios de arquitectura generales para losentornos de la Consellería de Sanidade / Servizo Galego de Saúde, y por tanto a tener encuenta para el desarrollo de todos los proyectos.
• “ARQAP-DT-v.xx.yy-Principios_Arquitectura_Sergas”.
3.2. CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE
La organización está comenzando a implantar el modelo de integración continua medianteel uso de diversas herramientas para poder mejorar la gestión del ciclo de vida.
Entre los objetivos de mejora deseados se encuentran:
• Detección y solución de problemas de forma anticipada
• Disponibilidad constante de una build para pruebas o demos
• Inmediatez y mejor registro de las pruebas unitarias
• Monitorización continua de las métricas de calidad del proyecto.
• Facilitar la gestión de la información generada a través de la herramienta degestión de incidencias
Las herramientas corporativas utilizadas son las siguientes:
• Jenkins: para proporcionar la herramienta central de integración continua
• Maven: para la gestión y construcción del proyecto:
◦ “ARQAP-DT-v.xx.yy-H2050IS-Uso_Maven_en_Proyectos”.
• SVN: para el control de versiones del código fuente:
◦ “ARQAP-GT-v.xx.yy-Control_versiones_codigo_fuentes_SVN”.
• Nexus: para el repositorio de artefactos:
Página 12 de 31
◦ “ARQAP-DT-v.xx.yy-Uso_Nexus_en_Proyectos”.
• Sonar: para la revisión de la calidad del código fuente.
• TestLink: para la gestión de pruebas:
◦ “ARQAP-GT-v.xx.yy-Gestion_pruebas_TestLink”.
• Redmine: para la gestión de proyectos:
◦ “ARQAP-GT-v.xx.yy-Gestion_proyectos_Redmine”.
• Selenium: para la realización de pruebas automatizadas:
◦ “ARQAP-DT-v.xx.yy-H2050IS-Uso_Selenium_en_Proyectos”.
Por otro lado, también está disponible en la SXSTI un Repositorio de Software – DML(Definitive Media Library), cuya función principal es tener disponible y controlado todo elsoftware que se precisa en la organización:
• “HADES-GT-v.xx.yy-Definitive_Media_Library_DML”.
3.3. PROCEDIMIENTOS DE DESARROLLO
Existe un procedimiento de Desarrollo / Mantenimiento / Adquisición de Aplicaciones quetiene por objetivo establecer el marco de actuación básico para garantizar el cumplimientode la metodología de desarrollo y su ciclo de vida, así como los estándares corporativosestablecidos por la SXSTI. Es de carácter OBLIGATORIO para todos los nuevosdesarrollos realizados por los Servicios de Informática de la Consellería de Sanidade,tanto si provienen de desarrollo interno o externo a medida, como si se trata de paquetescerrados.
• Procedimiento de desarrollo, mantenimiento y adquisición de aplicaciones:
◦ “GESTI-PC-v.xx.yy-SXSTI-Desarrollo_Mantenimiento_Adquisicion_Aplicaciones”.
◦ Documentación asociada (fases del procedimiento):
▪ Ficha inicial.
▪ Estudio viabilidad del sistema (opcional).
▪ Análisis funcional.
▪ Arquitectura técnica.
▪ Diseño técnico.
▪ Plan de pruebas.
▪ Código Fuente.
▪ Guía de instalación y administración.
▪ Manual de usuario (opcional).
▪ Implantación de la aplicación en Preproducción.
▪ Resultado del plan de pruebas.
Página 13 de 31
▪ Resultado del plan de pruebas con ancho de banda limitado (opcional),
▪ Plan de implantación (opcional).
▪ Guía de implantación (opcional).
▪ Implantación de la aplicación en Producción.
Además, existen particularizaciones de dicho procedimiento para procesos o desarrollosno convencionales, que se enumeran a continuación:
• Procedimiento reducido de desarrollo de aplicaciones: se utiliza paraaplicaciones de pequeña envergadura (pocos módulos funcionales), con unnúmero muy restringido de usuarios, de baja criticidad, y que suelen venircondicionados por el cumplimiento de unos plazos muy reducidos. También seincluyen en esta categoría las evoluciones de aplicaciones existentes queimpliquen desarrollos rápidos y requisitos de baja complejidad.
◦ “GESTI-PC-v.xx.yy-SXSTI-Desarrollo_Aplicaciones_Reducido”.
◦ Documentación asociada (fases del procedimiento):
▪ Ficha inicial.
▪ Estudio viabilidad del sistema (opcional).
▪ Análisis funcional técnico.
▪ Plan de pruebas.
▪ Código fuente.
▪ Guía de instalación y administración.
▪ Manual de usuario (opcional).
▪ Implantación de la aplicación en Preproducción.
▪ Resultado del plan de pruebas.
▪ Resultado del plan de pruebas con ancho de banda limitado (opcional),
▪ Plan de implantación (opcional).
▪ Guía de implantación (opcional).
▪ Implantación de la aplicación en Producción.
• Procedimiento ágil de desarrollo de aplicaciones: se utiliza para aplicacionesorientadas al desarrollo específico de casos de uso de negocio (enfoque claro alnegocio), con la participación frecuente y continua del usuario final (requisitosdesconocidos con una aproximación basada en prototipos, por ejemplo), sin casosde uso complejos, con una arquitectura conocida y sencilla, un nivel derequerimientos de integración, seguridad y concurrencia bajos, con un nivel decriticidad bajo en la organización y/o con riesgos controlados.
◦ “GESTI-PC-v.xx.yy-SXSTI-Desarrollo_Aplicaciones_Agil”.
◦ Documentación asociada (fases del procedimiento):
Página 14 de 31
▪ Ficha inicial.
▪ Análisis funcional técnico.
▪ Validación de prerrequisitos para implantación en Preproducción:
• Código fuente.
• Guía de instalación.
• Plan de pruebas (opcional).
• Manual de usuario (opcional).
▪ Validación de prerrequisitos para implantación en Producción:
• Resultado de plan de pruebas (opcional).
• Procedimiento de desarrollo Sistemas Análisis: aplica en el desarrollo denuevos Sistemas de Análisis y en la evolución de los existentes.
◦ “GESTI-PC-v.xx.yy-Desarrollo_Sistemas_Analisis”.
◦ Documentación asociada (fases del procedimiento):
▪ Ficha inicial.
▪ Estudio de viabilidad del sistema (opcional).
▪ Análisis de requisitos.
▪ Modelo de datos / Modelo predictivo.
▪ Procesos ETL:
• Diseño de procesos de carga / Diseño sistema análisis predictivo.
• Cuaderno de carga.
▪ Plan de pruebas.
▪ Manual de usuario.
▪ Guía de instalación, administración y operación.
▪ Implantación en Preproducción.
▪ Resultado de plan de pruebas.
▪ Plan de implantación (opcional).
▪ Guía de implantación (opcional).
▪ Implantación en Producción.
Estos procedimientos establecen las fases por las que debe pasar un proyecto, y ladocumentación que debe ser entregada, para ser implantado en la Consellería deSanidade.
Como regla general toda la documentación generada en un proyecto que tenga comodestinatario al usuario (por ejemplo, el manual de usuario) tendrá obligatoriamente unaversión en gallego, pudiendo existir versiones adicionales en otros idiomas.
Página 15 de 31
3.3.1. DOCUMENTACIÓN COMPLEMENTARIA ASOCIADA A UN PROYECTO
3.3.1.1. Gestión de Proyectos
A lo largo del desarrollo de un proyecto existen una serie de actividades que se realizanen paralelo a las actividades principales del ciclo de vida y que están orientadas aaspectos como la planificación del proyecto, asignación de responsabilidades, medidas decontrol de calidad, gestión de riesgos, control y seguimiento del proyecto, evaluación deresultados, etc. Estas actividades están englobadas dentro de lo que conocemos comogestión de proyectos.
En la SXSTI se han definido una serie de plantillas de documentos para llevar a cabotodas estas tareas: Presentaciones, Actas, Seguimiento del proyecto, etc.
El uso de estas plantillas será de carácter obligatorio para todos los proyectos realizadospara la Consellería de Sanidade siguiendo la metodología establecida.
Asimismo existe una estructura de directorios definida para almacenar la documentaciónde un proyecto.
El empleo de dicha estructura de directorios será de carácter obligatorio para todos losproyectos realizados para la Consellería de Sanidade siguiendo la metodologíaestablecida.
3.3.1.2. Gestión de la configuración
En los proyectos existen multitud de elementos que hay que gestionar, identificar ycontrolar y que hay que seguir su evolución en el proyecto: software, hardware,documentos, etc.
El objetivo de este documento es ayudar al control de elementos configurables en elmarco de los proyectos.
La Gestión de Configuración (GC) es un conjunto de técnicas, que permiten manejaradecuadamente la configuración de un producto, con objeto de controlar totalmente sudesarrollo y evolución, entendiendo por “producto”, cualquier elemento software o materialcreado durante un desarrollo y/o su mantenimiento y utilizado durante el mismo(incluyendo la documentación asociada).
En la organización se está implantando el uso de la Remedy ITSM Suite. Dentro de ella elBMC Remedy Asset Configuration Management permite gestionar de forma global elseguimiento de activos, la automatización de la conformidad del software, las aplicacionesde negocio y las posibles amenazas de seguridad.
Toda la información se almacena en la CMDB compartida por todos los procesos,asegurando por tanto que la gestión de activos e ITIL están completamente alineados.
Por tanto, se recomienda que los nuevos proyectos tengan sus elementos configurablesintegrados en la herramienta.
Página 16 de 31
3.4. CICLO DE VIDA DE PUBLICACIÓN DE APLICACIONES
Ligado a los procedimientos de desarrollo, mantenimiento y adquisición de aplicacionesse encuentra el procedimiento de Ciclo de Vida de Publicación de Aplicaciones. Esteprocedimiento establece los procesos a seguir para la instalación de una aplicación en losentornos de preproducción y producción. Además, define cómo se deben versionar tantolas aplicaciones como los entregables.
• “GESTI-PC-v.xx.yy-SXSTI-Ciclo_Vida_Publicacion_Aplicaciones”.
Existe una particularización de este procedimiento para el caso específico de publicaciónde integraciones Mirth:
• “ARQAP-PC-v.xx.yy-SXSTI-Ciclo_Vida_Publicación_Integraciones_MIRTH”.
3.5. DOCUMENTO DE SEGURIDAD
Este documento responde a la obligación establecida en el artículo 88 del Real Decreto1720/2007 de 21 de diciembre en el que se regulan las medidas de seguridad de losficheros automatizados que contengan datos de carácter personal.
El documento hace especial hincapié en la política de seguridad definida por laorganización para los ficheros que contienen datos de carácter personal, aunque lapolítica de seguridad se aplica a todos aquellos ficheros y recursos, afectados por la Ley,que contengan o traten datos automatizados.
Todo proyecto realizado para la Consellería de Sanidade deberá respetar lo establecidopor dicho documento de seguridad.
Son especialmente relevantes los siguientes documentos:
• Registro de Acceso a Datos de Nivel Alto: establece las distintas opciones y lainformación y formato que debe tener el registro de accesos a datos de nivel alto.
◦ “LOPDS-PC-v.xx.yy-Formato_acceso_nivel_alto”.
• Gestión de Contraseñas en las Aplicaciones: establece las normas generales degestión de las contraseñas asociadas a usuarios de los sistemas de información dela Consellería de Sanidade y cómo se deben gestionar los usuarios de acceso a lasBBDD.
◦ “LOPDS-PC-v.xx.yy-Gestion_de_contraseñas_aplicaciones”.
• Gestión de Acceso a Fuentes de Datos: establece el procedimiento a seguir parasolicitar el acceso a una fuente de datos de la Consellería de Sanidade.
◦ “GESTI-GT-v.xx.yy-Gestion_Accesos_Fuentes_de_Datos”.
Página 17 de 31
3.6. ASPECTOS FUNCIONALES
3.6.1. GESTIÓN DE PERFILES
Se ha estandarizado el diseño técnico de la base de datos para gestionar los perfiles, asícomo el interfaz gráfico sobre el que se sustenta:
• “ARQAP-DT-v.xx.yy-Gestion_perfiles”.
En la Consellería de Sanidade existe una plataforma centralizada de aprovisionamientode identidades y gestión de perfiles. Los proyectos deberán evaluar la conveniencia deintegración con este sistema.
3.6.2. GESTIÓN DEL CICLO DE VIDA DE LA INFORMACIÓN EN LAS APLICACIONES
Las aplicaciones deben realizar, durante la fase funcional, un análisis de los datos que sevan a gestionar desde dichas aplicaciones.
El documento que define el estándar a seguir en este análisis de datos:
• “ARQAP-DT-v.xx.yy-Gestión_del_ciclo_de_vida_de_la_información_en_aplicaciones”.
3.6.3. NORMATIVA ACCESIBILIDAD
El documento recoge la Normativa y Recomendaciones que en materia de Accesibilidadha de observarse en la construcción y diseño de los Sistemas de Información corporativosde la Consellería de Sanidade.
• “ARQAP-DT-v.xx.yy-Legislación_Accesibilidad”.
3.7. GUÍAS DE ESTILO
Son documentos en los que se normalizan diversos aspectos dentro del proceso dedesarrollo de aplicaciones informáticas.
3.7.1. GUÍA DE ESTILO DE BASES DE DATOS
Describe las convenciones adoptadas por la SXSTI para nombrar los elementos de lasbases de datos. Se describe la nomenclatura a emplear tanto en el modelo lógico comoen el físico.
En la elaboración de los nuevos proyectos, las bases de datos tendrán que seguir lasdirectrices apuntadas en esta guía.
• “INCST-DT-v.xx.yy-Guia_de_estilo_Base_de_Datos”.
Página 18 de 31
3.7.2. GUÍA DE ESTILO DE PROGRAMACIÓN
La razón principal de usar un conjunto coherente de convenciones de código esestandarizar la estructura y el estilo de codificación de una aplicación de forma que elautor y otras personas puedan leer y entender el código fácilmente.
Las convenciones de codificación correctas dan como resultado un código fuente preciso,legible y sin ambigüedad, que es coherente con otras convenciones del lenguaje y lo másintuitivo posible.
Un conjunto de convenciones de codificación de propósito general define los requisitosmínimos necesarios para conseguir los objetivos explicados anteriormente, dejandolibertad al programador para crear la lógica y el flujo funcional del programa.
El objetivo es hacer que el programa sea fácil de leer y de entender sin obstruir lacreatividad natural del programador con imposiciones excesivas y restricciones arbitrarias.
Las convenciones serán las indicadas por Oracle para los desarrollos llevados a cabo enplataforma J2EE y las indicadas por Microsoft para la plataforma .NET.
3.7.3. GUÍA DE ESTILO DE INTERFAZ GRÁFICA
Pretende definir un estándar que regule el formato gráfico que deben cumplir todas lasaplicaciones de la Consellería de Sanidade.
La guía de estilo de interfaz gráfica será de carácter obligatorio para todos los proyectosrealizados para la Consellería de Sanidade siguiendo la metodología establecida.
El documento con la guía de estilo de interfaz gráfica específica para aplicacionesIntranet :
• “GESTI-DT-v.xx.yy-Guia_estilo_aplicaciones_intranet”.
• “GESTI-DT-v.xx.yy-Guia_estilo_aplicaciones_intranet_ANEXOS”.
• “GESTI-DT-v.xx.yy-Guia_estilo_aplicaciones_intranet_FUENTES”.
Página 19 de 31
4.4. PROCEDIMIENTOS Y ESTÁNDARES ESPECÍFICOS DEPROCEDIMIENTOS Y ESTÁNDARES ESPECÍFICOS DEDESARROLLODESARROLLO
4.1. SEGURIDAD EN EL DESARROLLO
Trata de establecer una serie de consejos y recomendaciones de seguridad a tener encuenta para desarrollar aplicaciones para la Consellería de Sanidade.
• “ARQAP-DT-v.xx.yy-Seguridad_Desarrollo”.
4.2. NORMA TÉCNICA DE FIRMA ELECTRÓNICA
Este documento define las directrices en cuanto a firma electrónica en SERGAS.
• “ARQAP-DT-v.xx.y-Norma_Tecnica_Firma_Electronica_SERGAS”.
4.3. USO DE CERTIFICADOS
En relación al uso de certificados en las aplicación de la Consellería de Sanidade /Servizo Galego de Saúde están disponibles varios documentos.
• Estándar de certificados digitales: identifica y detalla los escenarios existentesen Sergas de uso de certificados en las aplicaciones.
◦ “ARQAP-DT-v.xx.yy-Certificados_Digitales”.
• Procedimiento de Gestión de certificados digitales: define una política degestión que permite llevar a cabo la solicitud, seguimiento y buen uso de loscertificados.
◦ “ARQAP-PC-v.xx.yy-Gestión_Certificados_Digitales”.
• Solicitud de firma de código: define el modo define el modo de realizar lassolicitudes de firma de código de los componentes software que se ejecutan encliente.
◦ “ARQAP-PC-v.xx.yy-Solicitud_firma_código”.
4.4. PLATAFORMA DE FIRMA
En relación a la integración con la plataforma de FIRMA por parte de las aplicaciones dela Consellería de Sanidade / Servizo Galego de Saúde están disponibles variosdocumentos.
• Procedimiento de acceso a FIRMA: define el procedimiento de solicitud deintegración con la plataforma de FIRMA en los diferentes entornos disponibles.
◦ “ARQAP-GT-v.xx.yy-Acceso_FIRMA”.
Página 20 de 31
• Kit de integración con la plataforma de FIRMA: define las directrices a aplicar enel desarrollo de una aplicación que integrará con la plataforma, dependiendo dellenguaje de desarrollo (JAVA, .NET, PHP).
• Kit de integración con el Portafirmas: define las directrices a aplicar en eldesarrollo de una aplicación que integrará con el Portafirmas, dependiendo dellenguaje de desarrollo (Java, .NET)
4.5. PROYECTOS JEE
• Desarrollo y despliegue aplicaciones J2EE: este documento recoge una serie derecomendaciones que se deben tener en cuenta en los desarrollos J2EE que serealicen para la Consellería de Sanidade / Servizo Galego de Saúde.
◦ “ARQAP-DT-v.xx.yy-Desarrollo_y_despliegue_J2EE”.
• Desarrollo y despliegue de EJB Timers: este documento recoge lasparticularidades técnicas del uso de EJB Timers en los servidores JEE de laConsellería de Sanidade / Servizo Galego de Saúde.
◦ “ARQAP-DT-v.xx.yy-Desarrollo_Despliegue_EJBTimers”.
• Aplicaciones JAVA en entorno Extranet: describe la arquitectura que se haelegido para permitir el acceso seguro desde el exterior a los servidoresWebSphere situados en la Intranet y define qué es lo que deberán tener en cuentalas aplicaciones que se desplieguen de este modo.
◦ “ARQAP-DT-v.xx.yy-Aplicaciones_Java_Extranet”.
• Desarrollo clientes ricos en Java: este documento pretende ser una guía derecomendaciones para el desarrollo de aplicaciones cliente codificadas en lenguajeJava.
◦ “ARQAP-DT-v.xx.yy-Recomendaciones_Cliente_Rico_Java”.
• Persistencia de datos en aplicaciones JEE: el documento evalúa la utilización deuna solución de persistencia en las aplicaciones Java EE como parte de laarquitectura. Se definen las ventajas e inconvenientes asociados y se detallandiferentes alternativas de mercado, todas ellas con licencia LGPL (Lesser GeneralPublic License). De igual modo, se indican las recomendaciones y estándaresdefinidos por el Servizo Galego de Saúde para la implementación de una soluciónde persistencia en los proyectos JEE.
◦ “ARQAP-DT-v.xx.yy-Persistencia_de_datos_en_aplicaciones_JavaEE”.
Página 21 de 31
• Inversión de control e inyección de dependencias en aplicaciones JEE: eldocumento detalla las características más importantes asociadas a las solucionesde inyección de dependencias en las arquitecturas de aplicaciones JEE (JavaEnterprise Edition). De igual modo, define las buenas prácticas asociadas a estetipo de frameworks y describe las recomendaciones a tener en cuenta en losproyectos desarrollados dentro de la Consellería de Sanidade / Servizo Galego deSaúde y organismos dependientes.
◦ “ARQAP-DT-v.xx.yy-Inversion_Control_Inyeccion_Dependencias_JEE”.
• Desarrollo bajo el framework de presentación Java Server Faces: estedocumento trata de realizar una descripción de la tecnología JavaServer Faces,indicando sus ventajas e inconvenientes respecto a tecnologías precedentes,especialmente Struts.
◦ “ARQAP-AT-v.xx.yy-Java_Server_Faces”.
4.6. INTEGRACIÓN ENTRE APLICACIONES WEB
Cuando se pretenda llevar a cabo la integración de aplicaciones web basada enredireccionar desde una aplicación a otra y sea necesario un proceso de autenticación enel sistema destino, deberá seguirse la siguiente recomendación:
• “ARQAP-DT-v.xx.yy-Integracion_Aplicaciones_Web_(Redirecciones-SSO)”.
4.7. SERVICIOS WEB
El documento recoge las particularidades técnicas del desarrollo y despliegue deServicios Web en la Consellería de Sanidade/Servizo Galego de Saúde, para plataformaJEE y .NET.
• “ARQAP-DT-v.xx.yy-Desarrollo_Despliegue_Servicios_Web”.
4.8. SERVICIOS WEB DE TARJETA SANITARIA
Para acceder a la información gestionada por el sistema de información de TarjetaSanitaria existe un conjunto de servicios web interoperables. Las característicasfuncionales y técnicas de estos servicios web pueden ser consultadas en ladocumentación disponible en ComunidadeTic.
4.9. DISPOSITIVOS MÓVILES
En este documento se describe de forma genérica las arquitecturas típicas de solucionesde movilidad, las tecnologías asociadas y las recomendaciones del Servizo Galego deSaúde (SERGAS) a tener en cuenta durante el desarrollo de un aplicación móvil. Estedocumento será de aplicación tanto para el desarrollo de aplicaciones móviles orientadas
Página 22 de 31
al ciudadano como para las orientadas a profesionales del Servizo Galego de Saúde(SERGAS).
• “ARQAP-DT-v.xx.yy-Desarrollo_Dispositivos_móviles”.
4.10. REPOSITORIO DE COMPONENTES REUTILIZABLES
La Consellería de Sanidade dispone de un almacén de componentes, funciones, librerías,utilidades, etc. que pueden ser reutilizados en diversos proyectos de la organización.
Su funcionamiento se rige por el siguiente procedimiento:
• “ARQAP-PC-v.xx.yy-Repositorio_Componentes”.
4.11. DESARROLLO DE INTEGRACIONES MIRTH
• Estándar de desarrollo de integraciones Mirth: este documento establece unestándar de desarrollo que permite optimizar el comportamiento de los proyectosde integración sobre plataforma MIRTH.
◦ “ARQAP-DT-v.xx.yy-SXSTI-Estándar_Desarrollo_Integraciones_MIRTH”.
• Empleo de pool de conexión de bases de datos en Integraciones Mirth: Estedocumento tiene como objetivo describir la solución empleada en MIRTH paraemplear un pool de conexiones de base de datos en los diferentes tipos de scriptsde los canales desarrollados.
◦ “INAPL-DT-v.xx.yy-SXSTI-Pool_de_conexiones_Base_de_datos”.
4.12. CATÁLOGO DE LÍNEAS BASE EXTENSIONES SOFTWARE PUESTO CLIENTE
Este documento detalla la configuración software estándar que debe tener un puestocliente en la Consellería de Sanidade / Servizo Galego de Saúde y organismosdependientes.
• “GESTI-RG-v.xx.yy-Catalogo_Lineas_Base_Extensiones_Software_Puesto_Cliente”.
Como complemento del anterior documento, se encuentra el de Configuración de InternetExplorer en los puestos cliente.
• “GESTI-DT-v.xx.yy-Configuración_IE_LB04”.
Página 23 de 31
4.13. ACCESO A DATOS EN APLICACIONES
Define la normativa y recomendaciones a seguir en cuanto al acceso a datos en lasaplicaciones desarrolladas para la Consellería de Sanidade.
Se recoge también un listado de los drivers de acceso a datos que se están usando en lasdiferentes aplicaciones en producción.
Este documento es de obligado cumplimiento para todos los desarrollos realizados para laConsellería de Sanidade y organismos dependientes. La utilización en las aplicaciones deestrategias contrarias a lo especificado en el documento deberá ser autorizada por laSXSTI.
• “ARQAP-DT-v.xx.yy-Acceso_a_datos_en_aplicaciones”.
En el caso de utilizar Oracle como gestor de Bases de Datos, existe un documento conlas recomendaciones a tener en cuenta.
• “GENSI-DT-v.xx.yy-Recomendaciones_Oracle_aplicaciones”.
En el caso de utilizar Informix como gestor de Bases de Datos, existe un documento conlas recomendaciones a tener en cuenta.
• “ARQAP-DT-v.xx.yy-Recomendaciones_sobre_SQL-Informix”.
4.14. GESTIÓN DOCUMENTAL EN APLICACIONES
Este documento define la normativa y recomendaciones a seguir en cuanto a la gestión ymantenimiento de los documentos generados y almacenados en las aplicacionesdesarrolladas para la Consellería de Sanidade.
• ARQAP-DT-v.xx.yy-Gestion_documental_en_aplicaciones”.
4.15. ACCESO AL DIRECTORIO ACTIVO
Este documento contiene una serie de indicaciones sobre cómo se deben realizar losaccesos al Directorio Activo del dominio SERGAS de la Consellería de Sanidade.
• “ARQAP-DT-v.xx.yy-Acceso_DA”.
4.16. GESTIÓN DE ERRORES Y LOGS EN LAS APLICACIONES
Trata de establecer la forma en que las aplicaciones de la Consellería de Sanidade van agestionar los registros de actividad e incidencia (avisos, errores, trazas, logs, etc.), esdecir, todas las salidas que no sean al usuario o que no sean productos de la aplicación.
• “ARQAP-DT-v.xx.yy-Gestion_de_errores_y_logs_en_las_aplicaciones”.
Página 24 de 31
4.17. GENERACIÓN DE INFORMES Y DOCUMENTOS
La Consellería de Sanidade dispone de un servidor de generación de informes BOE 4 enclúster que asegura alta disponibilidad para los servicios de impresión.
No se excluyen otras posibilidades para la generación de informes de forma centralizada,pero deberán ser aprobadas por la SXSTI.
• Generación de Informes con BOE: explica la arquitectura del producto y las APIsde programación disponibles. Define la normativa en cuanto a la programación deaplicaciones que utilicen BOE para la generación de informes.
◦ “ARQAP-DT-v.xx.yy-Generacion_informes_BOE”.
• Generación de Informes y Documentos: recomienda los métodos que podránincorporar las aplicaciones con el fin de poder generar informes y documentosdentro de las aplicaciones. Los métodos definidos en este documento aplican enaquellos casos de baja concurrencia que no precisen de la utilización de BusinessObjects Enterprise o en el caso de aplicaciones descentralizadas donde no esposible la utilización del mismo.
◦ “ARQAP-DT-v.xx.yy-Generacion_informes_documentos”.
4.18. OPTIMIZACIÓN DE APLICACIONES WEB
En este documento se recogen una serie de normativas y recomendaciones que sedeberán seguir en los desarrollos web realizados para la Consellería de Sanidade, encuanto a la optimización de los tiempos de respuesta en aplicaciones web, obtenidos en ladescarga del contenido desde el servidor a los clientes.
• “ARQAP-DT-v.xx.yy-Optimizacion_aplicaciones_web”.
4.19. GESTIÓN DE CONTENIDO ESTÁTICO EN LAS APLICACIONES
El propósito de este documento es establecer una recomendación mínima de gestión dela caché de contenido estático por parte de las aplicaciones.
• “ARQAP-DT-v.xx.yy-Cache_contenido_estatico”.
4.20. RICH INTERNET APPLICATIONS
Las Rich Internet Applications (en adelante RIAs) son un nuevo tipo de aplicaciones web.Este documento detalla las características de esta tecnología y establece la normativa encuanto a la programación de aplicaciones que la empleen dentro de la Consellería deSanidade y el Servizo Galego de Saúde. Esta normativa es de obligado cumplimiento.
• “ARQAP-DT-v.xx.yy-Rich_Internet_Applications”.
Página 25 de 31
4.21. RECOMENDACIONES PLATAFORMA DE APLICACIONES WINTEL
El documento pretende ser una referencia para que los grupos de desarrollo conozcan laplataforma en la que posteriormente se ejecutarán las aplicaciones que estándesarrollando y que los grupos de sistemas conozcan las funcionalidades del desarrolloque correrán sobre las plataformas que gestionan.
• “WINNT-DT-v.xx.yy-Recomendaciones_plataforma_aplicaciones_wintel”.
4.22. ARQUITECTURA DE DESARROLLO SOBRE MOSS
El documento recoge una serie de recomendaciones que se deben tener en cuenta en losdesarrollos que se realicen para la Consellería de Sanidade y organismos dependientesde ésta, sobre MOSS (Microsoft Office SharePoint Server) y aplicaciones JEE o .NET quetengan algún tipo de integración con éste. Se tratan aspectos de arquitectura dedesarrollo, mejores prácticas de desarrollo, así como los procesos para el despliegue delas aplicaciones. Se hace también una descripción del entorno disponible en laConsellería de Sanidade.
• “ARQAP-DT-v.xx.yy-Arquitectura_de_desarrollo_sobre_Sharepoint”.
4.23. ARQUITECTURA DESARROLLO PLATAFORMA GIS
El objetivo de este documento es definir una serie de recomendaciones a seguir duranteel desarrollo y la implantación de aplicaciones basadas en la plataforma GIS corporativadel Servizo Galego de Saúde.
• “ARQAP-DT-v.xx.yy-Arquitectura_desarrollo_plataforma_GIS”.
4.24. ESTÁNDARES DESARROLLO PROCESOS BPM
Este documento pretende servir como índice de buenas prácticas para el desarrollo,mantenimiento y adquisición de procesos BPM en el ámbito de la Consellería deSanidade.
• “ARQAP-DT-v.xx.yy-Estandares_Desarrollo_Procesos_BPM”.
4.25. DESARROLLO DE PROYECTOS BIZTALK
Este documento establece una serie de recomendaciones en relación al desarrollo desoluciones de integración basadas en BizTalk Server.
• ARQAP-DT-v.xx.yy-Desarrollo_de_proyectos_BizTalk_Server”.
Página 26 de 31
4.26. SISTEMAS DE INFORMACIÓN ANALÍTICA
• Difusión información analítica plataforma PADIA: en este documento sedescribe las particularidades del entorno abierto corporativo de difusión de lainformación analítica del Servizo Galego de Saúde, denominada PADIA (PlataformaAbierta de Difusión de Información Analítica).
◦ “ARQAP-DT-v.xx.yy-Difusión_información_analítica_plataforma_PADIA”.
• Talend: este documento describe las convenciones y conjunto de reglas acordadoscomo guía de buenas prácticas para el diseño e implementación de procesos deextracción, transformación y carga – ETL en inglés- en el entorno TOSDI (TalendOpen Studio for Data Integration).
◦ “ARQAP-DT-v.xx.yy-Talend_Guía_de_estilo”.
4.27. ANTIPATRONES
Este documento pretende ser una breve introducción a los antipatrones de desarrollo,arquitectura y gestión que nos podemos encontrar en el desarrollo de software.
• “ARQAP-DT-v.xx.yy-Antipatrones”.
4.28. GESTIÓN DE PRUEBAS
Contiene una serie de indicaciones sobre cómo se deben realizar las pruebas de lasaplicaciones de la Consellería de Sanidade.
• “INCST-PC-v.xx.yy-Gestion_Pruebas”.
4.29. OTROS PROCEDIMIENTOS
Para los equipos de desarrollo, es también importante conocer y cumplir los siguientesprocedimientos:
• Procedimiento de Publicación de aplicaciones en entorno WebSphere
◦ “GENSI-PC-v.xx.yy-Particularidades_tecnicas_publicacion_aplicaciones_Websphere”.
• Procedimiento de desarrollo de portales y sitios web del SERGAS
◦ “GEWEB-PC-v.xx.yy-aprobacion_sitios_web_y_portales_corporativos”.
• Procedimiento actualización de líneas base de software en PCs del SERGAS
◦ “GESTI-PC-v.xx.yy-Actualizacion_Lineas_Base_Software_Equipos”.
Página 27 de 31
5.5. ARQUITECTURA SISTEMAS DE ANÁLISIS DE LA INFORMACIÓNARQUITECTURA SISTEMAS DE ANÁLISIS DE LA INFORMACIÓN
Para extraer los datos de los sistemas operacionales, transformarlos y cargarlos en lossistemas de análisis, la Consellería de Sanidade utiliza como herramienta corporativaDataStage, por lo que todo Data Mart de la Consellería de Sanidade es alimentadoutilizando dicha herramienta.
DataStage es un completo conjunto de componentes diseñado para gestionar losprocesos de recopilación, integración, validación, organización y administración degrandes volúmenes de datos. Asimismo realiza las funciones necesarias para extraer,transformar y cargar datos de una amplia variedad de fuentes e integrarlos en datawarehouses, data marts y aplicaciones analíticas. También incluye funciones de gestiónde metadatos y de control de calidad de datos.
El gestor de base de datos utilizado para almacenar los datos del Data Mart también escorporativo y se ha seleccionado tras un estudio de rendimiento en el que se valoraronvarios productos comerciales.
En cuanto a la explotación de la información se ha hecho una evaluación de laherramienta más adecuada en función de las necesidades de la Consellería de Sanidade,y se ha optado por la línea de productos de Business Objects. Una vez seleccionadadicha línea de productos, se ha implantado como herramienta corporativa. Con ello se haconseguido que todo el personal de la organización acceda a la información a través deuna interfaz común, de forma que un usuario que conozca dicha herramienta es capaz deacceder a cualquier Data Mart definido en la Consellería de Sanidade (siempre y cuandotenga los permisos correspondientes).
Business Objects se orienta hacia el usuario final, es decir, es de fácil aprendizaje ymanejo, no exigiendo conocimientos informáticos.
La Consellería de Sanidade dispone tanto de la herramienta WebIntelligence, que permiterealizar consultas, informes y análisis a través de la Web, como la herramientacliente/servidor, que además permite al usuario construir sus propios informes de unaforma simple e intuitiva. A través de Infoview se dispone de un punto de entrada común alos Data Marts y que va a permitir a nuestros usuarios tanto visualizar, como refrescar,enviar, publicar y planificar documentos en ambos entornos.
Existe documentación con los estándares definidos en la Consellería de Sanidade para eldesarrollo de SIACs.
A continuación se comentan algunos de los estándares que se han definido en laConsellería de Sanidade con respecto a los Sistemas de Información de AnálisisComplejos (SIACs).
Página 28 de 31
5.1. ARQUITECTURA EN BUS DE LOS SIACS DE LA CONSELLERÍA DE SANIDADE.
El objetivo de este documento es definir el conjunto de guías y estándares que permitiránconstruir el Data Warehouse de la Consellería de Sanidade como conjunto de SIACS,dotándolos de una arquitectura común, reflejando características y normativas que sedeben emplear en los desarrollos e implantaciones de esos proyectos, con el fin de evitar“islas de información”, encajando todos los Data Marts de forma que se permita una visiónglobal de cada área de negocio, a través de las dimensiones y los hechos conformados.
5.2. MODELADO DE DATOS EN LOS SIACS DE LA CONSELLERÍA DE SANIDADE
Describe una serie de normas y estándares que debe cumplir el modelado de datos de losdiferentes sistemas que conforman la arquitectura en bus de Data Mart de la Conselleríade Sanidade.
Pretende ser una guía que permita unificar el diseño de todos los Data Marts y quedescriba las soluciones a distintas problemáticas que surgen en la construcción de estossistemas.
El objetivo es definir un estándar en la elaboración de modelos para proyectos DataWarehouse para dotarlos a todos de una estructura común, reflejando características ynormativas que se deben emplear en los desarrollos e implantaciones de esos proyectos,con el fin de evitar “islas de información”, encajando todos los Data Marts a través de laconformación de dimensiones y hechos comunes.
5.3. ARQUITECTURA DE PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN YCARGA
Define un estándar de nomenclatura y documentación para proyectos realizados con laherramienta DataStage, para dotar a todos los proyectos de una apariencia común yfacilitar su desarrollo y mantenimiento. Se describen las convenciones adoptadas por laSXSTI para nombrar y documentar los elementos que componen cada uno de los trabajosde DataStage (herramienta de Extracción Transformación y Carga de datos empleada pordicho servicio en los proyectos de inteligencia de negocio o SIACs).
5.4. GUÍA DE ESTILO DE BUSINESS OBJECTS DESIGNER
Describe las convenciones para nombrar los elementos que componen cada uno de lostrabajos de Designer, la herramienta de diseño de universos de Business Objectsempleada por la Consellería de Sanidade en los proyectos de inteligencia de negocio oSIACs. Esta guía recoge las características mínimas que debe cumplir un universo paralograr rapidez y simplicidad de uso por el usuario de dicho universo.
Página 29 de 31
5.5. ESTRUCTURA DEL SUPERVISOR DE BUSINESS OBJECTS DE LACONSELLERÍA DE SANIDADE
Describe las convenciones adoptadas para organizar a los usuarios que acceden a lainformación de los SIACs mediante la herramienta Business Objects. La estructura degrupos de usuarios y la política de asignación de permisos a funcionalidades einformación se definen mediante la herramienta Supervisor de Business Objects.
El objetivo de este documento es definir un estándar de organización para proyectosrealizados con la herramienta Business Objects, para dotar a todos los proyectos de unaestructura común y facilitar el mantenimiento de los permisos de acceso a usuarios.
Se describen un conjunto de indicaciones acerca de cómo se deben organizar losusuarios en grupos, cuál es la política adecuada de asignación de permisos y cómo debenpublicarse los recursos de Business Objects. Son normas de obligado cumplimiento paralos desarrollos que empleen Business Objects.
Página 30 de 31
6.6. HERRAMIENTAS DE DESARROLLOHERRAMIENTAS DE DESARROLLO
Las herramientas de desarrollo que se indican a continuación, serán de uso obligatoriopara los proyectos desarrollados por la SXSTI.
6.1. GESTIÓN DE PROYECTOS
La herramienta que deberá utilizarse para la gestión de proyectos es ProjectLibre.
Ayuda a crear y realizar el seguimiento de planes de proyectos, administrarprogramaciones y recursos, y analizar la información del proyecto.
6.2. MODELADO DE DATOS
En los desarrollos los modelos de datos deberán entregarse en formatos legibles en losque se visualicen las tablas, relaciones y tipos de atributos.
6.3. DESARROLLO DE DIAGRAMAS PARA EL DESARROLLO
Para el diseño de diagramas UML la única exigencia en cuanto a la herramienta aemplear es que ésta permita exportar los trabajos al formato estándar XMI.
6.4. EMPAQUETADO DE SOFTWARE
Para la generación del paquete de instalación en las aplicaciones cliente/servidor seutilizará la herramienta InstallShield Developer.
6.5. CONSTRUCCIÓN DE AYUDAS DE PROGRAMAS
Para la construcción de ayudas de programas, tanto en entornos cliente/servidor como enentornos Web, se podrá utilizar cualquier software gratuito que permita la exportación aHTML, previa evaluación y aprobación por parte de la SXSTI.
6.6. ENTORNOS INTEGRADOS DE DESARROLLO
Para los proyectos que se hagan dentro de la SXSTI, la herramienta corporativa para eldesarrollo en plataforma .NET será Microsoft Visual Studio y para plataforma J2EE seráRational Application Developer
Página 31 de 31
