Informática y Telecomunicaciones

Página de inicio de los Estándares Tecnológicos del Gobierno Vasco

Departamento de Gobernanza, Administración Digital y Autogobierno

Directrices de Desarrollo

Detalles

Descripción

El contenido de este estándar se estructura según el siguiente Índice cuyos apartados se describen posteriormente:

Estándares de desarrollo        

  • Alcance        
  • Estructura        
    • Procesos organizativos        
    • Procesos operativos        
  • Flujo de Procesos        
  • Arquitectura        
    • Contextos de albergue        
    • Normativas y documentación        
    • Herramientas de desarrollo        
    • Sistemas horizontales    
    • Requerimientos de referencia        

Estándares de calidad de sistemas software        

  • Objetivo        
  • Estándares aplicados        
  • Oficina Técnica de Calidad de producto y pruebas        
  • Modelo de Aseguramiento de la Calidad        

Metodología de desarrollo ARINbide        

  • ARINbide-Predictivo        
    • Ingeniería del software (ISW)        
    • Gestión de Proyectos (GPR)        
    • Gestión de Riesgos de Proyectos (GRP)        
    • Gestión de la Configuración (GCO)        
    • Mantenimiento de Sistemas de Información (MSI)        
    • ARINbide-Adaptativo        
      • Gestión de Proyectos e Ingeniería del Software        

      Metodología de pruebas Probamet        

      Utilidades de Desarrollo de Aplicaciones (UDA)        

      • Introducción        
      • Arquitectura Tecnológica        
      • Patrones de interacción        
      • Kit de desarrollo

       

      Estándares de desarrollo

      Alcance

      Desde una perspectiva tecnológica, es conveniente que todas las actividades y tareas necesarias en el proceso de desarrollo del software sean estandarizadas e interconectadas entre sí, facilitando y acelerando de este modo, ya no sólo dicho proceso, sino también la propia operativa de creación de los sistemas. La documentación de Estándares de desarrollo se puede consultar en el siguiente enlace Anexos Pliegos de condiciones técnicas donde aparece como el Anexo de Estándares de desarrollo de sistemas software.

      Es objeto de la presente área de estandarización:

      • Establecer el conjunto mínimo de requerimientos y recomendaciones técnicas que estandaricen el proceso de desarrollo de software en las fases definidas por la metodología de aplicación
      • Definir una serie de instrucciones de trabajo estandarizadas y coherentes en dicho proceso.
      • Proporcionar un marco de referencia de terminología y vocabulario común para el desarrollo del software
      • Identificar las principales expectativas a gestionar en las distintas modalidades de contratación del desarrollo. Con recursos humanos y/o materiales propios y/o ajenos, como adquisición de «producto», etc. Se fijará especialmente en los entregables (código, ejecutables, documentación, etc.) a exigir y auditar
      • Estandarizar las herramientas de gestión asociadas a las fases del ciclo de vida del proceso de desarrollo del software
      • Enfatizar las necesidades de gestión de la calidad de los productos a implantar orientadas a minimizar al máximo los fallos del servicio en el entorno de producción
      • Limitar las posibles arquitecturas software y hardware, ajustándolas al modelo de albergue de GV-EJIE

      El estándar contiene un conjunto de procesos, actividades y tareas diseñadas para ser utilizadas en los proyectos de desarrollo software, alineadas en todos los casos con la metodología normalizada, así como el conjunto de roles identificados y los que intervendrán en cada uno de dichos procesos, actividades y tareas.

      Para cada proceso, actividad y tarea en que se descompone el estándar se indica el grado de exigencia para su conformidad:

      Indicador Descripción
      Deberá Indica un requisito obligatorio para su conformidad
      Debería Indica una fuerte recomendación que no es obligatoria para su conformidad
      Puede Indica una forma autorizada de cumplir un requisito o de evitar la necesidad de satisfacer la conformidad
      Si…entonces
      [/deberá / /debería / /puede]       		Indica que el grado de conformidad indicado está sujeto al cumplimiento de ciertas condiciones

        Del mismo modo, se remarcan aquellos aspectos que deben ser tratados y cumplidos de manera rigurosa

      Estructura

      La Guía de estándares de desarrollo de sistemas software se descompone en:

      Procesos organizativos

      Engloba los procesos más relacionados con la gestión y preparación, necesarios para el desarrollo del sistema software.

      Proceso Descripción
      Preparación y provisión Definir el alcance del desarrollo a realizar, las infraestructuras técnicas necesarias para su ejecución y los acuerdos de gestión del proceso, comprendiendo las actividades de: Adquisición, Equipamiento e Infraestructura técnica
      Administración del proyecto Comprende las actividades y tareas necesarias para la correcta administración del proyecto, en lo referente a Gestión del Proyecto y Gestión del Cambio

      Procesos operativos

      Define los procesos a realizar desde el punto de vista de la construcción del sistema software.

      Se deberá inicialmente seleccionar la metodología de desarrollo

      Proceso Descripción
      Selección de metodología de desarrollo Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide en su fase inicial, distinguiendo qué metodología seguir.

      Si se ha seleccionado ARINbide-predictivo se deberá seguir estos procesos:

      Proceso Descripción
      Análisis Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide-predictivo en la fase de análisis del sistema de información (ASI), las definidas por Probamet en la fase de planificación de pruebas (PPB1) y parcialmente, en la fase de análisis y diseño de las pruebas (APB).
      Diseño Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide en la fase de diseño del sistema de información (DSI), y parcialmente, las definidas por Probamet en la fase de análisis y diseño de las pruebas (APB)
      Implementación Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide-predictivo en la fase de construcción del sistema de información (CSI), y parcialmente, las definidas por Probamet en la fase de ejecución de pruebas (EPB). Se indican también las mejores prácticas de aplicación en dicha fase, orientadas a mejorar tanto la ejecución del propio proceso, como a optimizar la tarea de entrega del sistema software
      Implantación y aceptación del sistema Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide-predictivo en la fase de implantación y aceptación del sistema (IAS), y parcialmente, las definidas por Probamet en la fase de ejecución de pruebas (EPB)
      Aseguramiento de la calidad Asegurará que los productos obtenidos y los procesos del ciclo de vida del proyecto cumplen con los requerimientos y los planes establecidos, mediante la aplicación Modelo SQA

      Para cada una de ellos se indican además las herramientas de uso en cada actividad y tarea en las que se descomponen.

      Si se ha seleccionado ARINbide-adaptativo se deberán seguir estos procesos:

      Proceso Descripción
      Preparación o Sprint 0

      Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide-adaptativo en fase Preparacióno, como son:

      Definir la Visión del producto

      Establecer el entorno tecnológico y los estándares

      Identificar participantes

      Definir procedimientos de trabajo

      Preparar la logística

      Generar la Pila de Producto (Product Backlog)

      Elaborar el Plan de Entregas (Release Plan)
      Sprint

      Comprende las actividades y tareas dictadas por la metodología de aplicación ARINbide-adaptativo en fase Sprint (Iteración), como son:

      Refinamiento (Refinement)

      Reunión de planificación del Sprint (Sprint Planning)

      Reunión de planificación detallada del Sprint

      Desarrollo

      Reunión diaria (Daily Scrum)

      Reunión de revisión del Sprint (Sprint Review Meeting)

      Reunión de retrospectiva del Sprint (Sprint Retrospective Meeting)

      Flujo de Procesos

      La Guía de estándares de desarrollo de sistemas software establece también el flujo de ejecución de procesos que deberá seguir el proceso de desarrollo de un sistema software, detallando el conjunto de actividades y tareas necesarias, así como los roles involucrados.

      El flujo de ejecución de procesos deberá seguir la metodología de desarrollo ARINbide-predictiva o ARINbide-adaptativa, más adelante descrita.

       ARINbide-predictiva:

       

      ARINbide-adaptativa:

      Y para el proceso de implementación:

      Requerimientos de referencia

      Con objeto de contextualizar la Guía de estándares de desarrollo de sistemas software dentro del entorno de albergue de los sistemas software a construir, se facilitan un conjunto de requerimientos básicos de referencia que deberán tenerse en consideración:

      Arquitectura

      La arquitectura física de los sistemas software se ve afectada por el modelo de seguridad corporativo definido. Y, por ende, su arquitectura lógica se ve segmentada también en tres —o más— niveles con cometidos distintos: uno para los servicios de usuario —presentación—, otro para los servicios de la lógica de negocio —la lógica principal de la aplicación—, y otro nivel para los servicios de datos.

      Existe además una capa de integración, que provee el modelo de compartición de funciones y datos y orquestación de servicios entre distintos sistemas, departamentales y horizontales.

      Se identifican, además, distintos entornos operativos:

      Entorno Descripción
      Desarrollo Sobre el que se realizará la primera integración y prueba de lo desarrollado y testeado en PC local, simulando la arquitectura y el entorno tecnológico final que sustentará el aplicativo
      Pruebas Sobre el que se llevarán a cabo las principales tareas de aseguramiento de la calidad, se realizarán los ensayos de instalación del aplicativo y las pruebas de de aceptación del usuario
      Producción Entorno productivo final en el que se ejecutará la aplicación con los usuarios finales y los datos reales

      El traspaso entre los diferentes entornos sucesivos se realizará mediante la sistemática de traspasos ya normalizada.

      Contextos de albergue

      Cada sistema software se deberá ejecutar en alguno de los diferentes contextos de albergue existentes según sus características de negocio y por tanto de las tipologías de usuarios a los que da soporte:

      Contexto Descripción
      Internet Para aplicaciones que requieren accesos desde Internet. Este contexto tiene connotaciones especiales en lo referente a la publicación de los contenidos estáticos y estilos
      Intranet Para aplicaciones que requieren únicamente accesos de usuarios corporativos del Gobierno Vasco
      Extranet Aplicaciones que requieren exponer todo o parte de su negocio a un grupo acotado de usuarios —generalmente, adscritos a otras administraciones u organizaciones afines— apoyándose en otras redes que no se corresponden con la intranet de GV. Actualmente, existen dos tipos de extranet: la de «jakinaplus» y la de «JASO»

      Normativas y documentación

      Para asegurar la gobernabilidad de los sistemas software y, por tanto, de sus procesos de instalación y albergue en los servidores corporativos, se dispone de un conjunto de normativas y documentación adicional. Éstos se asocian tanto a tecnologías como a productos, como a los distintos sistemas básicos de infraestructura:

      • JAVA: Normas de albergue de aplicaciones «Weblogic», guías de desarrollo, estándares, librerías y productos
      • .NET: Normas de albergue .NET, desarrollo e implantación
      • ORACLE: Estándares y normas de uso de Oracle
      • PLATEA—Presencia en Internet: Normativas, guías de desarrollo y documentación técnica para el uso de la infraestructura de Presencia en Internet
      • PLATEA—Tramitación: Guías de uso de la infraestructura de tramitación
      • Otros sistemas corporativos: Normativas de desarrollo y guías de procedimiento de aplicaciones horizontales y sistemas de uso común: Dokusi, Pasarela de Pagos, K31/O75, XLNets, SMS Corporativo, GIS, Nora

      Herramientas de desarrollo

      Se enumeran el conjunto de herramientas homologadas para dar soporte al ciclo completo de vida de desarrollo de los sistemas software. Éstas, además, se ven referenciadas y marcadas de uso obligatorio en la misma Guía de estándares de desarrollo de sistemas software.

      Sistemas horizontales

      Se enumeran los sistemas básicos de infraestructura sobre los cuales deben generarse los nuevos aplicativos software a construir: XLNetS, PLATEA, Utilidades de Desarrollo de Aplicaciones (UDA), Control M, K31/O75, Pasarela de pagos, Nora, SGA (Sistema de Gestión de Archivos), Dokusi.

      Estándares de calidad de sistemas software

      Objetivo

      El propósito de la presente área de estandarización se centra en el aseguramiento de la calidad del producto. Para ello se establece el modelo básico de aseguramiento de la calidad de los productos software que se deban implantar en el entorno de GV-EJIE.

      El Modelo de Aseguramiento de Calidad de Sistemas Software o Modelo SQA, es el marco de referencia que engloba todas las actividades relacionadas con el aseguramiento de calidad durante todo el ciclo de vida de desarrollo y pruebas.

      Estándares aplicados

      El Modelo SQA definido, se apoya y toma como referencia una serie de estándares comúnmente reconocidos (ISO e IEEE):

      • Se adapta a la Norma UNE-EN ISO 9001:2000 Sistema de Gestión de Calidad, en lo referente al enfoque que propone de gestión de calidad basado en procesos interrelacionados y los requisitos de cliente con el fin de lograr la satisfacción del cliente mediante la aplicación efectiva del sistema.
      • Toma como referencia el estándar ISO/IEC 9126:1991 Ingeniería del Software – Calidad de Producto, la cual contiene un modelo de calidad y medición que permite la evaluación de la calidad de un producto software, y las series SQuaRE ISO/IEC 25000. El modelo SQuaRE (Software Product Quality Requirements and Evaluation) es una revisión de la norma ISO/IEC 9126-1:2001.
      • IEEE Std.730 – 2002: IEEE Standard for Software Quality Assurance Plans. Define la información que debe contener un plan de aseguramiento de la calidad software, y su relación con otros procesos implicados (gestión de incidencias, gestión de la configuración).
      • IEEE Std.829 – 1998: IEEE Standard for Software Test Documentation. Define la documentación generada en cada una de las fases del proyecto de pruebas.
      • IEEE Std.830 – 1998: IEEE Recommended Practice for Software Requirements Specifications. Proporciona una guía de buenas prácticas para la elaboración de una especificación de requisitos.
      • IEEE Std.1012 – 2004: IEEE Standard for Software Verification and Validation. Detalla los procesos de verificación y validación (V&V) del software, y su organización.
      • IEEE Std.1061 – 1998: IEEE Standard for a Software Quality Metrics Methodology. Define el establecimiento, la implementación, el análisis y la validación de métricas de calidad de software.

      El Modelo SQA se basa también en las buenas prácticas del Modelo CMMI «Capability Maturity Model Integration». Una de las variantes del modelo, es el CMMI-ACQ «CMMI for Adquisition» que está orientado a la gestión de adquisiciones para organizaciones con un porcentaje elevado de subcontratación de desarrollos de software. El Modelo CMMI-ACQ se estructura en diferentes Áreas de Proceso relativas a la Gestión de Proyectos, la Gestión de Procesos, la Gestión de la Adquisición y otros procesos de Soporte. Es un Modelo estructurado en 5 niveles de madurez, cada uno de los cuales contiene un conjunto de buenas prácticas agrupadas en áreas de proceso.

      Para la definición del Modelo SQA y la metodología de pruebas PROBAMET se han tenido en cuenta ciertas pautas del Modelo CMMI-ACQ, principalmente las Áreas de Proceso de los niveles de madurez 2 y 3, como son:

      1. Enfoque en el proceso organizativo OPF (nivel 3)
      2. Definición de proceso organizativo OPD (nivel 3)
      3. Gestión Técnica de la Adquisición ATM (nivel 3)
      4. Validación de la Adquisición AVAL (nivel 3)
      5. Verificación de la Adquisición AVER (nivel 3)
      6. Medición y Análisis MA (nivel 2)
      7. Aseguramiento de la Calidad PPQA (nivel 2)
      8. Gestión de la Configuración CM (nivel 2)

      Oficina Técnica de Calidad de producto y pruebas

      Según el estándar IEEE 1012, se recomienda que el control de calidad de software sea realizado por un equipo experto e independiente al grupo de desarrollo, trabajando paralelamente junto con éste durante el ciclo de vida de desarrollo pero gestionado de forma autónoma, garantizando así su independencia.

      En función del volumen de la contratación, de la criticidad del servicio que se desea resolver, del posible coste adicional al propio proyecto de desarrollo, o de cualquier otro criterio que se considere relevante, el contratista debería estimar conveniente la contratación de una Oficina Técnica de Calidad (OTC) de producto y de pruebas que permita asegurar el nivel de calidad de producto adecuado a las expectativas establecidas para el servicio, en cuyo caso se deberá seguir la metodología de calidad definida para tal efecto. No obstante, y con independencia de la contratación o no de dicha oficina, se deberá asegurar que el producto software obtenido cumple el estándar de calidad detallado en el presente documento.

      Modelo de Aseguramiento de la Calidad

      A grandes rasgos, el modelo de aseguramiento de la calidad del producto software «Modelo SQA» - consta de:

      • Asignación del valor NAC (nivel de aseguramiento de la calidad) asociado al proyecto
      • Elaboración del Plan SQA del proyecto, definiendo las actividades de aseguramiento de calidad a realizar durante el ciclo de vida dependiendo del NAC asociado al proyecto
      • El proceso para la realización de las actividades de aseguramiento de calidad definidas, alineadas con la metodología de desarrollo ARINBIDE-predictivo y cumpliendo implícitamente la metodología de pruebas PROBAMET. Caso de usar metodología ARINbide-adaptativo se definirá un plan de actividades de calidad de acorde a los entregables que identifica la metmetodologíaINbide-predictivo.
      • Los indicadores de calidad estándar y sus umbrales permitidos.
      • El conjunto de herramientas que facilitan la aplicación del modelo y las metodologías

      El contratista deberá incluir en el Pliego de Bases Técnicas los detalles suficientes relativos a la aplicación del modelo de aseguramiento de la calidad para que el licitador pueda ofertar adecuadamente el esfuerzo a ejecutar.

      El Modelo SQA orquesta y alinea las actividades definidas en las metodologías ARINbide y Probamet, estableciendo a su vez las actividades de aseguramiento de la calidad:

       

      Documento principal del Modelo SQA en formato ZIP

      Documentos de indicadores de calidad en formato ZIP

      Metodología de desarrollo ARINbide

      ARINbide es una metodología práctica de desarrollo para el ciclo de vida completo de los sistemas de información. Sistematiza las actividades a realizar en los proyectos de desarrollo de aplicaciones, estandariza los entregables a obtener, y sugiere las técnicas apropiadas para su realización.

      Hasta la versión 3.0 ARINbide sólo contemplaba un ciclo de vida de proyectos con enfoque tradicional o predictivo, tomando como referencia la metodología MÉTRICA versión 3. La versión actual de ARINbide añade a sus posibles modelos de uso un enfoque adaptativo o ágil, basado esta vez en la aplicación combinada de Scrum y de Extreme Programming (XP).

      Antes de iniciar cualquier proyecto software será imprescindible valorar las necesidades y objetivos establecidos para este y determinar cuál es el enfoque más apropiado: ARINbide-Predictivo o ARINbide-adaptativo.

      Documento de ARINbide en formato ZIP, con consideraciones básicas para seleccionar el enfoque más adecuado.

      ARINbide-Predictivo

      Ingeniería del software (ISW)

      En su proceso principal de ingeniería del software (ISW) describe y normaliza la secuencia de fases y actividades a realizar en el proyecto de elaboración de un sistema de información, así como los entregables a obtener en cada una de ellas. En este ámbito, ARINBide contempla el desarrollo de las siguientes fases:

      • Catálogo de Requisitos de Usuario (CRU) (proceso diferenciado del Análisis del Sistema de Información, ASI)
      • Análisis del sistema (ASI)
      • Diseño del sistema (DSI)
      • Construcción del sistema (CSI)
      • Implantación y aceptación del sistema (IAS)

      El ciclo de vida descrito en la metodología de desarrollo ArinBide se alinea y complementa a lo largo del tiempo con la metodología de pruebas corporativa Probamet, centrándose ésta última en la especificación de todas las actividades relacionadas con la planificación, definición y ejecución de los diferentes tipos de pruebas.

      Documento de Ingeniería del Software en formato ZIP

      ARINbide contempla además el establecimiento de otros procesos necesarios y que conviven en el tiempo con el proceso principal de ingeniería del software, que son los siguientes.

      Gestión de Proyectos (GPR)

      Facilita la planificación, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información.

      Documento de Gestión de Proyectos en formato ZIP

      Gestión de Riesgos de Proyectos (GRP)

      Facilita la prevención y la minimización de riesgos para el proyecto, mediante la identificación y análisis de riesgos, la planificación de acciones, su registro y control.

      Documento de Gestión de riesgos en formato ZIP

      Gestión de la Configuración (GCO)

      Permite establecer el modo como se va a mantener la integridad y trazabilidad de la calidad de los productos software y documentales durante todo el ciclo de vida.

      Documento de Gestión de la Configuración en formato ZIP

      Mantenimiento de Sistemas de Información (MSI)

      Proporciona el modelo de gestión de los servicios de mantenimiento de aplicativos una vez que están implantados, en base a un Acuerdo de Nivel de Servicio.

      Documento de Mantenimiento de Sistemas de Información en formato ZIP

      Además, ARINbide proporciona plantillas para facilitar la elaboración de los documentos entregables de todos los procesos metodológicos y un anexo con conceptos básicos y técnicas a utilizar.

      Plantillas de documentos en formato ZIP

      Anexo de conceptos básicos y técnicas en formato ZIP

      ARINbide-Adaptativo

      Gestión de Proyectos e Ingeniería del Software

      En este caso la gestión de proyectos de ARINbide adopta el marco metodológico propuesto por Scrum al que se le añaden, para las tareas de ingeniería del software, las sugerencias de Extreme Programming (XP):

      • Se identifican los roles participantes en el proyecto
      • Las fases etapas, actividades y tareas:
      • Preparación o Sprint 0
      • Iteraciones o Sprints sucesivos
      • Se describen los artefactos a gestionar
      • Y los entregables documentales a generar

      Junto a la descripción de la metodología se acompaña un documento con conceptos básicos sobre «agilismo», Scrum y XP.

      Documento de metodología y anexo con conceptos básicos en formato ZIP.

      Se facilitan también un conjunto de plantillas de referencia para la creación de los entregables documentales.

      Plantillas de documentos en formato ZIP

      Metodología de pruebas Probamet

      Documentación de la metodología de pruebas PROBAMET, que establece el modelo a seguir referente al proceso de pruebas de un producto software, analizando en detalle cada una de las fases que forman el ciclo de vida de las aplicaciones, y describiendo, para cada una de ellas en materia de pruebas, las actividades a realizar y la documentación de entrada y salida que las conforman. Esta metodología corporativa está completamente alineada con la metodología de desarrollo ARINBIDE.

      PROBAMET describe todas las actividades de pruebas del producto software y se divide en las siguientes fases:

      • Planificación y Seguimiento de las Pruebas (PPB)
      • Planificación de las Pruebas (PPB1)
      • Seguimiento de las Pruebas (PPB2)
      • Análisis y Diseño de las Pruebas (APB)
      • Ejecución de las Pruebas (EPB)

      Documento principal de PROBAMET en formato ZIP

      Utilidades de Desarrollo de Aplicaciones (UDA)

      Introducción

      UDA es un conjunto de herramientas, tecnologías, componentes y normativas funcionales y técnicas que permiten acelerar y normalizan el proceso de construcción de aplicaciones JEE en el ámbito de Gobierno Vasco – EJIE

      • Determina la arquitectura conceptual básica de los nuevos sistemas JEE, así como la selección y configuración de tecnologías que implementan sus componentes
      • Potencia la ayuda al desarrollo, posibilitando mediante herramientas la generación de forma automatizada y asistida del código de las nuevas aplicaciones a construir, en coherencia con la arquitectura definida
      • Proporciona componentes reutilizables y adaptables que implementan patrones de interacción para la construcción de aplicaciones de Internet enriquecidas (RIA)

      Arquitectura Tecnológica

      Uno de los principios básicos en la definición de arquitectura para cumplir con los requisitos establecidos (extensibilidad, mantenibilidad, facilidad de manejo) es la división de responsabilidades o la creación de módulos con una finalidad en concreto. A su vez, para el desarrollo de la arquitectura conceptual se han seleccionado distintas tecnologías basadas en estándares

      Ámbito Tecnología
      Presentación

      Componentes RIA:

      • Cliente: JavaScript, CSS y AJAX

      Vista: Bootstrap + jQuery + jQuery UI

      • Servidor: JSP

      Controlador: Spring MVC
      Modelo POJOS que definen entidades (Spring Beans)
      Comunicación remota
      • EJB 3.0 para la comunicación remota
      • Implementación mediante interfaces remotas
      • Wrappers para el despliegue
      Servicios de negocio

      POJOS para la implementación

      Fachada para las peticiones

      • Locales
      • Remotas
      Acceso a datos

      POJOS para la implementación

      APIs de persistencia

      • JDBC -> SpringJDBC
      • JPA 2.0 -> Eclipselink
      Librería de utilidades comunes (x38)

      Se integra en las aplicaciones a nivel de EAR

      Solventa requerimientos estructurales de EJIE

      Podrá evolucionar según se detecten nuevos requerimientos

      Bajo acoplamiento con las aplicaciones desarrolladas con UDA (AOP)

      Funcionalidades incluidas:

      • Seguridad (incluye adaptador XLNetS)
      • Validación (facilita validación de campos en servidor)
      • Trazas (aplica formato estándar)
      • Utilidades y complementos
      Resolución de dependencias / librerías

      Apache Maven

      • Librerías a nivel de EAR [pom.xml]

      Patrones de interacción

      UDA ofrece una serie de componentes (RUP) que implementan un grupo de patrones de interacción de usuario identificados:

      • Tooltip: Sistema de ayuda contextual que facilita el aprendizaje progresivo de la aplicación. Debe, por un lado, ayudar al usuario impaciente y/u ocasional tan extensamente como sea posible y, por otro, a los usuarios expertos.
      • Feedback: Canal informativo por el que se comunica al usuario los posibles errores o problemas acaecidos, los resultados de su interacción con los elementos de la aplicación y las posibles medidas a tomar para solucionar ciertas inconsistencias.
      • Mensaje: Tiene como objetivo mostrar al usuario de forma homogénea, clara y llamativa, los posibles mensajes que pueden desencadenar las acciones en la aplicación. Estos mensajes predefinidos pueden ser de diferente tipología: error, confirmación, aviso o alerta.
      • Diálogo: Permite lanzar un subproceso o un mensaje de confirmación dentro de un proceso principal sin salirse de este. Es una evolución del patrón mensaje.
      • Idioma: El componente de idioma está diseñado para permitir al usuario elegir de forma intuitiva el idioma en el que se le presenta la aplicación.
      • Menú: Menú de la aplicación mantenido a lo largo de todas las páginas de forma consistente que muestra entradas directas a secciones clave de la aplicación.
      • Menú contextual: Menú auxiliar de opciones inicialmente no visible referido a un elemento que se muestra junto a éste para agilizar la interacción y la realización de las tareas.
      • Migas de pan: Muestra a los usuarios los pasos de navegación seguidos durante su interacción con la aplicación y facilita enlaces para volver a páginas precedentes o la página de inicio.
      • Combo: Permite guiar al usuario en la introducción de datos posibilitando seleccionar un elemento de una gran lista de elementos o de varias listas dependientes de forma sencilla y ocupando poco espacio en la interfaz.
      • Autocompletar: En cuanto el usuario comienza a escribir una búsqueda se le sugieren búsquedas relacionadas con lo que ha escrito que pueden ser de su interés.
      • Fecha: Permite al usuario introducir y seleccionar una fecha, tanto de forma manual como visual, moviéndose fácilmente por días, meses y años. Además, para minimizar las posibilidades de introducir una fecha incorrecta, ofrece al usuario ayudas y sugerencias de formato.
      • Hora: El usuario puede introducir y seleccionar una hora tanto de forma manual como visual, moviéndose fácilmente por las horas y los minutos, recibiendo ayudas y sugerencias para minimizar las posibilidades de introducir una hora incorrecta.
      • Adjuntar ficheros: Hace posible añadir uno o varios ficheros dentro de la actividades de una aplicación proporcionando información básica sobre los mismos y la posibilidad de cancelar el proceso una vez se ha iniciado la carga o al término de la misma.
      • Botonera: Se presenta a los usuarios una barra de botones con diversas funcionalidades relacionadas con elementos de la página. Gracias a este componente se presentan, ordenan y agrupan las distintas funcionalidades gestionadas por las aplicaciones.
      • Tabla: Presenta los datos de forma tabular para que la información se visualice de manera ágil y rápida, facilitando así su comprensión y manejo.
      • Mantenimiento: Implementa un patrón definido para facilitar la lógica necesaria en las acciones básicas, denominadas CRUD (create, read, update y delete), sobre una tabla.
      • Pestañas: Permiten dar acceso de forma compacta a grupos de contenidos mutuamente excluyentes pudiendo ser integradas en zonas muy reducidas de la interfaz.
      • Árbol: Presenta al usuario información jerarquizada, pudiendo identificar claramente el nivel de profundidad en que se sitúa cada dato.

      Kit de desarrollo

      UDA se presenta como un kit de desarrollo, que contiene:

      • Eclipse Neon OEPE, como IDE para desarrollar
      • Apache Maven, para la resolución de dependencias de terceros
      • Plugin UDA, asistente de eclipse basado en plantillas para la generación de la estructura de proyecto, código de negocio (en base al modelo relacional), código de presentación para las interfaces de usuario .
      • Conjunto de reglas para la revisión de calidad de código.
      • Librería de utilidades comunes

      Para todo esto se requiere como software de base:

      • Servidor de aplicaciones Weblogic
      • Java 6
      • Acceso a Base de Datos Oracle
      • Repositorio SVN

      Se puede ampliar información sobre UDA en http://uda-ejie.github.io/

      Documentación asociada y otros enlaces

      Anexos Pliegos de condiciones técnicas - (http://www.ejie.eus/contratacion/-/contratacion-informacion-tecnica/)

      Documento de ARINbide en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide.v4.0.zip)

      Documento de Ingeniería del Software en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-ISW(1.3).pdf.zip)

      Documento de Gestión de Proyectos en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-GPR(1.3).pdf.zip)

      Documento de Gestión de riesgos en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-GRP(1.3).pdf.zip)

      Documento de Gestión de la Configuración en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-GCO(1.3).pdf.zip)

      Documento de Mantenimiento de Sistemas de Información en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-MSI(2.1).pdf.zip)

      Plantillas de documentos en formato ZIP - MSI - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/Plantillas_ARINbide-predictivo.zip)

      Anexo de conceptos básicos y técnicas en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-Anexo_Conceptos_Basicos_y_Tecnicas.zip)

      Documento de metodología y anexo con conceptos básicos en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-Adaptativo.v1.0.zip)

      Plantillas de documentos en formato ZIP - de ARINbide-Adaptativo - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/ARINbide-Adaptativo.v1.0.Plantillas.zip)

      Documento principal de PROBAMET en formato ZIP - (http://www.ejie.eus/contenidos/informacion/ejie2016_contratacion_tecnica/es_def/adjuntos/OTC_PROBAMET_%20v2.0%20Metodologia%20de%20pruebas%20PROBAMET.pdf.zip)

      Información sobre UDA - (http://uda-ejie.github.io/)

      Estándares nacionales e internacionales

      UNE-EN ISO 9001:2000 - Sistema de Gestión de Calidad - (https://www.iso.org/standard/21823.html)

      ISO/IEC 9126:1991 - Ingeniería del Software - Calidad de Producto - (https://www.iso.org/standard/16722.html)

      ISO/IEC 9126-1:2001 - (https://www.iso.org/standard/22749.html)

      IEEE Std.730 - 2002 - IEEE Standard for Software Quality Assurance Plans

      IEEE Std.829 - 1998 - IEEE Standard for Software Test Documentation

      IEEE Std.830 - 1998 - IEEE Recommended Practice for Software Requirements Specifications

      IEEE Std.1012 - 2004 - IEEE Standard for Software Verification and Validation

      IEEE Std.1061 - 1998 - IEEE Standard for a Software Quality Metrics Methodology

      Versiones de producto

      No aplica

      Otros estándares del catálogo relacionados
      Historial de revisiones
      • Versión 1: 03-07-2017
      • Versión 2: 28-09-2020 (última versión)