LINEAMIENTO: CRITERIOS DE ACEPTACIÓN PARA

LINEAMIENTO: CRITERIOS DE ACEPTACIÓN PARA ENTREGABLES DISCIPLINAS DE ARQUITECTURA
Oficina de Informática
Departamento Nacional de Planeación
Bogotá, 2013
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA
CÓDIGO:PI-L01
PÁGINA: 2 de 9 VERSIÓN: 0
TABLA DE CONTENIDO
INTRODUCCIÓN ................................................................................................................................ 3
1
OBJETIVO.................................................................................................................................. 4
2
ALCANCE .................................................................................................................................. 4
3
REFERENCIAS NORMATIVAS .................................................................................................... 4
4
DEFINICIONES........................................................................................................................... 5
4.1
VISTA DE NEGOCIOS. ......................................................................................................... 5
4.2
ORGANIZACIÓN Y GOBIERNO. ........................................................................................... 5
4.3
MÉTODOS........................................................................................................................... 5
4.4
APLICACIONES ................................................................................................................... 5
4.5
ARQUITECTURA ................................................................................................................. 5
4.6
INFORMACIÓN .................................................................................................................... 6
4.7
INFRAESTRUCTURA ........................................................................................................... 6
5
CRITERIOS DE ACEPTACIÓN. ................................................................................................... 6
5.1
DIMENSIÓN DE NEGOCIO. .................................................................................................. 6
5.2
ORGANIZACIÓN Y GOBIERNO ............................................................................................ 6
5.3
MÉTODOS........................................................................................................................... 6
5.4
APLICACIONES ................................................................................................................... 7
5.4.1
ARQUITECTURA. ......................................................................................................... 7
5.4.2
INFORMACIÓN............................................................................................................. 8
5.4.3
INFRAESTRUCTURA .................................................................................................... 9
2
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA
CÓDIGO:PI-L01
PÁGINA: 3 de 9 VERSIÓN: 0
INTRODUCCIÓN
Dentro de las responsabilidades y funciones que atañen a la Oficina de Informática para la Gestión de
Tecnologías de la Información y Comunicaciones en el Departamento Nacional de Planeación, se incluye el
desarrollo de la arquitectura de aplicaciones informáticas que apoyan los sistemas de gestión, dentro de estas
responsabilidades se establecieron políticas y lineamientos; se definió el uso de arquitecturas orientadas a
servicios (SOA) con base en un marco de desarrollo iterativo fundamentado en el desarrollo de capacidades
tecnológicas y a la búsqueda de la evolución de la misma basado en el estándar OSIMM (Oriented Services
Integration Madurity Model) del Open Group el cual determina la alineación de las arquitecturas con una
estrategia SOA.
Para medir el nivel de consistencia de las arquitecturas de los sistemas de información con la política general de
adopción de Arquitecturas orientadas a servicios se establece el uso del estándar OSIMM (Oriented Services
Madurity Model) propuesto por el open group, se cuenta con siete dimensiones a través de siete niveles de
madurez.
Cada nivel de madurez representa un aumento significativo en el nivel de madurez necesario para realizar la
orientación de servicio.
OSIMM define un conjunto de dimensiones, que representan diferentes puntos de vista (por ejemplo,
Arquitectura de negocios de la siguiente manera:







Negocios
Organización y Gobierno
Métodos
Aplicaciónes
Arquitectura
Información
Infraestructura y Gestión
Los siete niveles de madurez SOA son:







Silo
Integrada
Componentizada
Servicios
Composición de Servicios.
Virtualización de Services
Servicios Dinámicos y reconfigurables.
3
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA
CÓDIGO:PI-L01
PÁGINA: 4 de 9 VERSIÓN: 0
Figura 1. *Modelo Base OSIMM
1
OBJETIVO
En esta guía se presenta el modelo de madurez de la arquitectura Orientada a servicios, con el propósito de alinear
los desarrollos de los sistemas de información con las políticas generales de la oficina de informática y así garantizar
la sostenibilidad a largo plazo.
2
ALCANCE
Dentro de los roles de la Oficina de Informática del DNP como integrador de soluciones existe la necesidad de dirigir
los proyectos hacia la adopción de Arquitecturas enfocadas a la integración, Calidad, Agilidad y flexibilidad por lo
cual se establece la necesidad de incluir en los proyectos el aprovechamiento y desarrollo de nuevas capacidades
Tecnológicas en el marco del uso de Arquitecturas Orientadas a servicios.
Estos lineamientos aplican de igual manera para la contratación con terceros como para el desarrollo con recursos
propios o subcontratados de aplicativos informáticos para los sistemas de gestión del Departamento.
3
REFERENCIAS NORMATIVAS
Este documento esta basado en el estándar técnico internacional dado por “ The Open Group Service Integration
Maturity Model (OSIMM), versión 2” el cual ha sido desarrollado y aprobado por el open group.
4
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA
4
CÓDIGO:PI-L01
PÁGINA: 5 de 9 VERSIÓN: 0
DEFINICIONES
A continuación se describen cada una de las dimensiones o puntos de vista desde los cuales se desarrolla un
sistema de información Orientado a servicios.
4.1
VISTA DE NEGOCIOS.
La dimensión empresarial se centra en la arquitectura del negocio, es decir, las prácticas actuales de la
organización de negocios y políticas, cómo los procesos de negocio se han diseñado y estructurado,
implementado y ejecutado. La dimensión de negocios también se ocupa de cómo el costo de las capacidades de
TI se asigna a través de la empresa, y qué tan bien las capacidades de TI apoyar a la flexibilidad de la empresa,
la agilidad y los SLAs. La dimensión de negocios incluye la estrategia de TI.
4.2
ORGANIZACIÓN Y GOBIERNO.
La dimensión de Organización y Gobierno se centra en la estructura y el diseño de la propia organización y las
medidas necesarias de eficacia de la organización en el contexto de una arquitectura SOA y la gobernabilidad de
SOA. El aspecto de la Organización se centra en la estructura organizacional, las relaciones, los roles, y la necesaria
autonomía para adoptar una estrategia orientada a servicios. Esto incluye los tipos y el alcance de las habilidades, la
capacitación y la educación que están disponibles dentro de la organización. Gobierno se asocia con procesos
formales de gestión para mantener las actividades de TI, las capacidades de servicios y soluciones SOA alineadas
con las necesidades de la empresa.
4.3
MÉTODOS
La dimensión de métodos se centra en los métodos y procesos empleados por la organización para su
información y la transformación del negocio y la madurez de la organización durante todo el ciclo de vida de
desarrollo de software, tales como el uso de la gestión de requisitos, las técnicas de estimación, gestión de
proyectos, los procesos de garantía de calidad, metodologías de diseño y las técnicas y herramientas para
el diseño de soluciones.
4.4
APLICACIONES
La dimensión de aplicación se centra en el estilo de la aplicación, la estructuración de la solicitud y la
descomposición funcional, re-usabilidad, flexibilidad, fiabilidad y extensibilidad de las aplicaciones, la
comprensión y el uso uniforme de las mejores prácticas y patrones, Aun cuando sean múltiples aplicaciones
han sido creadas para servir a diferentes líneas de negocio con esencialmente la misma funcionalidad, y la
disponibilidad de esquemas empresariales.
4.5
ARQUITECTURA
La dimensión de la arquitectura se centra en la estructura de la arquitectura que incluye la topología, las
técnicas
de integración, las decisiones de arquitectura empresarial, las normas y políticas, la
5
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA
CÓDIGO:PI-L01
PÁGINA: 6 de 9 VERSIÓN: 0
adopción de servicios web de nivel, experiencia en la implementación de SOA, los criterios de cumplimiento,
y los artefactos típicos producidos.
4.6
INFORMACIÓN
La dimensión de la Información se centra en cómo se estructura la información, cómo la información es el
modelo, el método de acceso a los datos de la empresa, la abstracción del acceso a los datos de los
aspectos funcionales, las características de los datos, capacidades de transformación de datos, servicios y
definiciones de procesos, el manejo de los identificadores, las credenciales de seguridad, gestión del
conocimiento, el modelo de información empresarial y de gestión de contenidos.
4.7
INFRAESTRUCTURA
La dimensión de la Infraestructura y Gestión se centra en la capacidad de la infraestructura de la
organización, la gestión del servicio, las operaciones de TI, la gestión de TI y de administración de TI,
¿cómo se cumplen los SLA, cómo la supervisión se lleva a cabo, y qué tipos de plataformas de integración
se proporcionan.
5
CRITERIOS DE ACEPTACIÓN.
A continuación se describen los modelos que deben ser entregados en cada una de las dimensiones los cuales se
constituyen en los criterios de aceptación.
5.1
DIMENSIÓN DE NEGOCIO.
•
•
•
5.2
Modelado de Procesos de negocio usando BPMN.
Aceptación y conocimiento de las políticas y lineamientos usados por el Proyecto.
Establecimiento de niveles de servicio con la Oficina de Informática.
ORGANIZACIÓN Y GOBIERNO
Dentro de la perspectiva de Organización y gobierno se definen los siguientes criterios de aceptación.
• Descripción de los Roles de la solución y su par en la Oficina de informática describiendo las
diferentes interacciones entre las partes.
• Plan y desarrollo de Capacitación sobre la solución implementada a los diferentes miembros del
DNP (usuarios, Oficina de Informática).
• Plan de Transferencia Tecnológica Iterativa.
5.3
MÉTODOS
Dentro de los Criterios de aceptación se busca garantizar que los métodos usados por el proyecto estén
acordes con el nivel de madurez 4 o superior más no de la verificación de los resultados de cada uno de los
elementos medibles.
6
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA






5.4
CÓDIGO:PI-L01
PÁGINA: 7 de 9 VERSIÓN: 0
Gestión de requisitos (Uso de UML Casos de Uso)
Técnicas de Estimación.
Gestión de Proyectos (Uso de PMI y utilización de VSTS para la gestión del proyecto)
Procesos de Garantía de Calidad
Metodología de Diseño Orientadas a Servicio (Metodologías Agiles – RUP Agile)
Herramientas de Productividad alineadas a la metodología (VSTS – Selección de plantilla MSF
Agile, Uso de Pruebas automáticas)
APLICACIONES
Dentro de los Criterios de aceptación se busca garantizar que las aplicaciones desarrolladas en los
proyectos estén acordes con el nivel de madurez 4 o superior, es decir, que estén desarrolladas con
servicios, por lo cual se verificará lo siguiente.




5.4.1
Uso de Servicios Existentes (Configuración, Archivos, auditoria, seguridad)
Construcción de servicios de acceso a datos bajo los lineamientos y la guía de construcción de
servicios WCF.
Uso de mejores practicas (Utilización de los Microsoft applications Blocks, para acceso a datos,
registro de logs, manejo de cache, uso de membership para manejo de usuarios)
Exposición de Nuevos servicios documentados usando el Estandar SoaML
ARQUITECTURA.
Para este dominio se definen los criterios de aceptación, de acuerdo con la guía de elaboración de
arquitectura en la cual se hace referencia a las diferentes vistas de Arquitectura así:
5.4.1.1
Vista Conceptual



5.4.1.2
Diagrama de Contexto.
Diagrama General de Procesos Modelados en BMPN.
Diagramas de Casos de Uso de Negocio.
Vista Lógica
 Patrones de Diseño de Capas acorde con la guía para la construcción de Servicios WCF.
 Modelamiento Lógico de Servicios Usando SoaML.
 Empaquetado de los servicios empleados por la Solución.
5.4.1.3
Vista Física
 Diagrama de modelo Físico (ilustra la distribución del procesamiento entre los distintos equipos que
conforman la solución, incluyendo los servicios y procesos de base)

Los Servicios deben ser reusables: Todo servicio debe ser diseñado y construido pensando en
su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o
incluso dentro del dominio público para su uso masivo.
7
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA
CÓDIGO:PI-L01
PÁGINA: 8 de 9 VERSIÓN: 0

Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe
proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las
funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de
salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato,
logrando así la independencia entre el consumidor y la implementación del propio servicio.

Los Servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen que ser
independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que
cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la
independencia entre el servicio que se va a ejecutar y el que lo llama. De esta manera serán
totalmente reutilizables.

Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera
que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará
compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará
mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).

Los Servicios deben de ser autónomos: Todo Servicio debe tener su propio entorno de
ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que
así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.

Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información.
Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si
un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia
de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté
almacenada en algún sistema de información sea del tipo que sea.

Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de
alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de
servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el
descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.

5.4.1.4
Vista de Implementación
 Diagrama de implementación (describe cómo se implementan los componentes físicos mostrados
en vista de distribución agrupándolos en subsistemas)
5.4.1.5
Seguridad
 Autenticación
 Autorización
 Comunicación Segura
 Auditoría
 Administración de perfiles
5.4.2
INFORMACIÓN
Dentro de los criterios a evaluar en las soluciones se establecen.
 Uso de Servicios existentes.
 Modelado de Servicios incluyendo (Modelado de Contratos y Mensajes)
8
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP
LINEAMIENTO: CRITERIOS DE ACEPTACIÓN
PARA ENTREGABLES
DISCIPLINAS DE ARQUITECTURA



5.4.3
CÓDIGO:PI-L01
PÁGINA: 9 de 9 VERSIÓN: 0
Exposición de nuevos servicios.
Verificación del acceso a los datos vía servicios consumibles.
Identificación de las fuentes de datos (Servicios BD).
INFRAESTRUCTURA
Dentro de este dominio se establecen los siguientes criterios.



Listado de las necesidades de infraestructura.
Planes de adopción de nuevas tecnologías.
Modelo de las características de la infraestructura utilizada (Redes, Comunicaciones, Plataformas
Tecnológicas.)
Fecha aprobación: 15/06/2013
Revisó:
__________________________
Juan Manuel Moreno Abello
Contratista: Arquitecto software Oficina de Informática
Aprobó:
____________________________
Carlos Alberto Ferrer Infante
Coordinador Grupo Gestión de Proyectos Informáticos - OI
9
ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIÓN DEL DNP