Entregable: Requerimientos

Definiciones
BCCR: Banco Central de Costa Rica.
SINPE: El Sistema Nacional de Pagos Electrónicos (SINPE), es una plataforma
tecnológica desarrollada y operada por el BCCR, que conecta a las distintas entidades del
Sistema Financiero Nacional a través de una red privada de telecomunicaciones y ofrece
numerosos servicios financieros y de valores. Para mayor información, visite
http://www.bccr.fi.cr/SINPE/info.html.
Servicio SINPE: Un sistema financiero, de valores o de otro tipo que aprovecha la
infraestructura base del SINPE para brindar su funcionalidad.

Introducción
El establecimiento de una estrategia de integración continua para servicios de la nueva
plataforma web del SINPE se va a fundamentar en el análisis de requerimientos realizado
en este entregable.

Visión general
Este documento presenta una visión de la arquitectura y un inventario de los artefactos
que conforman un servicio. Luego, se indica los requerimientos de integración desde
diversos puntos de vista.

Visión de la arquitectura
Los servicios SINPE son expuestos a través de un front-end web de manera que pueda ser
accedido por el usuario final sin la necesidad de instalar una aplicación en su computador
de escritorio. Algunos servicios serán expuestos por Internet y otros por la extranet del
Banco Central de Costa Rica. De esta manera, se puede direccionar servicios a diferentes
usuarios meta, manteniendo una diferenciación entre servicios para entidades asociadas al
SINPE y servicios para ciudadanos.

Tecnología de la arquitectura
La tecnología del SINPE en infraestructura y software está mayormente sobre tecnologías
Microsoft. El sistema operativo en los clientes de desarrollo es Windows XP Service
Pack 3. Los servidores funcionan sobre Windows Server 2008. En materia del software
de aplicación desarrollado, este se implementa sobre el Microsoft Framework .NET 3.5,
procurando dar un buen uso de las últimas tecnologías disponibles. El ambiente de
desarrollo es Visual Studio 2008. En una sección posterior, se explicará cada tecnología
utilizada.
En general, se referirá por “componente” a cada archivo DLL de la plataforma .NET
utilizado. Cada componente contiene estructuras tales como clases e interfaces, siempre
dentro del paradigma orientado a objetos.
Aplicación web compuesta
Esta plataforma web tiene la necesidad de poder soportar múltiples servicios, pero
presentando siempre una solución de cliente web coherente. Su arquitectura debe ser
escalable debido a que siempre hay nuevos servicios en desarrollo, y debe permitir el
desarrollo e instalación de servicios SINPE de manera independiente.
Debido a estos requerimientos, se optó por utilizar el patrón llamado Aplicación web
compuesta. Este patrón permite tener una aplicación compuesta por una serie de piezas
independientes, pero integradas dentro de un solo entorno de servidor web.
Algunos de sus beneficios incluyen:
• Permite un alto grado de separación entre la infraestructura de la aplicación y la
lógica del negocio.
• El permite el desarrollo independiente de los componentes de lógica del negocio.
• Promueve la reutilización.
• Provee de una excelente arquitectura para ofrecer servicios de negocio integrados
para dar una experiencia unificada al usuario.

La figura anterior ilustra el entorno web en el que un servidor web presenta al usuario una
plataforma unificada y le ofrece servicios que internamente provienen de diversas
fuentes. Obtenga más información relacionada en el siguiente enlace:
http://websf.codeplex.com/Wiki/View.aspx?title=Composite%20Web%20Clients.
Debido a esta elección de arquitectura, se seleccionó el Web Client Software Factory
(WCSF) del equipo de Pattern and Practices de Microsoft para apoyar en su
implementación. El WCSF provee de herramientas automatizadas y guías para desarrollar
aplicaciones web empresariales, y facilita el crear aplicaciones compuestas de módulos
desarrolladores e instalados de manera independiente.
Los módulos son integrados en tiempo de ejecución por un marco común. Cada servicio
SINPE se implementa como un módulo de negocio (Business Module). El marco común
(o shell) es conformado por un Website principal y por un componente que coordina la
lógica de presentación común. Cada servicio SINPE implementa su capa de interfaz
como un subwebsite para el principal.

Responsabilidades por capa de aplicación

La arquitectura del SINPE es "n" capas, cada una con una responsabilidad definida. A
continuación se da un resumen de cada capa del sistema, dejando la explicación de
tecnológicas para la siguiente sección.
::Imagen de las capas y su distribución en servidores::
Interfaz de usuario (User Interface, UI): Esta capa es la que utiliza el usuario final y es
dependiente de la tecnología de presentación utilizada, sea esta un cliente windows, una
aplicación web, u otras. Por ser una capa acoplada con la tecnología de presentación, se
debe minimizar lo más que sea posible la codificación de lógica de la aplicación, y esto
se realiza al implementar el patrón de Model View Presenter. Su responsabilidad es de
recibir eventos del usuario y presentar información.
Servicios de usuario (User services, US): Esta capa es la encargada de recibir los
eventos del usuario a través de la capa de interfaz de usuario y coordinar el flujo del
proceso en general, invocando a la capa de servicios para que realicen la lógica de la
aplicación. La capa US es independiente de la tecnología de presentación.

Una responsabilidad de las clases contenidas en la capa es el rol de «Presenter» dentro

del patrón Model View Presenter, siendo estas las que coordinan el flujo del proceso en
general y mantienen la separación entre presentación gráfica (UI) y lógica del negocio.

Un componente US puede contener clases que realicen transformaciones de manera que

los datos obtenidos de la capa de lógica del negocio queden listos para ser enviados a la
capa de interfaz grafica (por ejemplo, al transformar un objeto en un formato Xml).

Las dos capas anteriores residen en el servidor que publica el contenido del sitio web, que
llamaremos servidor web.
Interfaz de servicios (Service Interface, SI): La capa de servicios de usuario se
comunica con la capa de interfaz de servicios par acceder a la lógica del negocio. Esta
capa se compone de una serie de servicios web («webservices») publicados en el servidor
de lógica del negocio. Los componentes que implementan esta capa no poseen lógica de
negocio, aunque sí contienen información acerca de la configuración del manejo de
errores y de transaccionalidad.
Servicios del negocio (Business Services, BS): Esta capa corresponde a los componentes
que coordinan e implementan los procesos del negocio. Para realizar un proceso del
negocio, esta capa puede requerir la comunicación con la cada de datos para acceder a
bases de datos, o puede invocar componentes de Interfaz de Servicios de otros servicios
SINPE.
Servicios de datos (Data Services, DS): Esta capa ofrece el acceso a la base de datos y el
mapeo Objeto-Relacional.
Contratos de datos (SI.Datos): La transferencia de datos entre todas las capas se realiza
a través de objetos tipo «entidad» que no contienen funcionalidad, sino que son
contenedores de información.
Base de datos: La persistencia de datos se realiza en una base de datos relacional. Por
directrices del área de base de datos, toda consulta u operación a la base de datos se
realiza a través de procedimientos almacenados.

Inventario de artefactos por capa

En esta sección se brinda una explicación de los artefactos que conforman a un servicio
SINPE.

Capa de Interfaz de usuario (UI)

Esta capa de interfaz de usuario se implementa en la tecnología ASP.NET 3.5,s iendo la
misma un sitio web. Este ejecuta en el contexto del sitio web principal creado por el Web
Client Software Factory. Al crear un módulo nuevo en el Factory, se agrega la capa de
Interfaz de Usuario (UI) y la siguiente capa de Servicios de Usuario (US) como dos
elementos individuales pero integrados.

A continuación, se enumera los tipos de artefactos que componen la interfaz de usuario

de un servicio SINPE:

• Archivo DLL: Una vez compilado el proyecto, se produce un archivo DLL que es
el binario que se instalará para el funcionamiento del sitio web.
• Páginas Aspx: Son páginas web dinámicas que responden a eventos del usuario.
• Web.config: Este archivo contiene la configuración del sitio web. Este archivo
normalmente es diferente dependiendo del ambiente en que se ejecute, es decir, el
archivo que se utiliza en Producción es diferente al usado en un ambiente de
Pruebas.

Además, el sitio web puede contener elementos propios de la tecnología web, tales como
páginas HTML, imágenes, archivos CSS o JavaScript, entre otros. Esta capa tiene
dependencia con los componentes (DLL) del Web Client Software Factory. La siguiente
imagen muestra un ejemplo de esta capa:

:: colocar imagen de un sitio web ejemplo ::

Capa de Servicios de usuario (US)

Como se mencionó anteriormente, la capa US es creado automáticamente por el WCSF

junto con el sitio web del servicio SINPE. Dentro del ambiente de desarrollo, el US es un
proyecto tipo “Class library” que al compilar produce un archivo DLL como su único
artefacto.
PREGUNTA: Cuando agrego un WCF endpoint en el US, se agrega también en el
Website?

Capa de interfaz de servicios (SI)

Todo servicio SINPE expone sus servicios por medio de la capa SI. Esta capa es
implementada en la tecnología Windows Communication Foundation (WCF), la cual es
un modelo unificado de programación para el desarrollo de servicios web. Dentro del
ambiente de desarrollo, la capa SI es un proyecto tipo “WCF Website?”.
Sus artefactos son:

• Archivo DLL: Contiene la lógica del componente.

• Archivos Svc: Cada archivo con extensión .svc representa a un servicio
publicado.
• Archivo web.config: Este es el archivo que indica la configuración del servicio
WCF, y expone los “endpoints” que son los contratos de servicio.

Capa de servicios del negocio (BS)

Dentro del ambiente de desarrollo, el US es un proyecto tipo “Class library” que al
compilar produce un archivo DLL como su único artefacto.

Capa de servicios de datos (DS)

Dentro del ambiente de desarrollo, el US es un proyecto tipo “Class library” que al
compilar produce un archivo DLL como su único artefacto. La configuración de la
conexión a la base de datos se realiza por medio de archivos de configuración del
Microsoft Enterprise Library 4.0 que son globales al sistema operativo para lograr una
configuración compartida entre todos los servicios SINPE.

Base de datos
La base de datos está alojada en el Microsoft SQL Sever 2008. Se cuenta con una base de
datos principal que es en donde se persiste los datos de los servicios SINPE en general,
aunque hay otras que existen para propósitos específicos, tales como servidos de reporte
o de inteligencia de negocios.

Como es sabido, la base de datos contiene objetos tales como tablas, llaves primarias,
llaves foráneas, índices, vistas, procedimientos almacenados y funciones. Además, los
datosque almacenan pueden verse como parte de los objetos que la componen.

En materia del desarrollo de la base de datos, se puede decir que los artefactos que se
administran para crear y mantener la base de datos son de dos tipos:
 • Scripts SQL de definición de datos (DDL), los cuales crean las estructuras de la
base de datos.

• Scripts SQL de manipulación de datos (DML): los cuales realizan operaciones de

consulta y modificación de los datos.

Dependencias entre capas

Gráfico de dependencias

Dependencias con componentes del Framework y entlib

Mostrar todos los componentes en los que depende un servicio SINPE (gráfico?).

Deploy de artefactos por capa

Se puede explicar en cada servidor (Web, logica) y los lugares en los que se debe colocar
cada artefacto mencionado anteriormente.

Requerimientos de integración
Como se procesa cada capa para producir los binarios?
Dependencias
Integracion con la base de datos

Deployment
explicar deployment de cada capa

Requerimientos
Administración de múltiples archivos de configuración

Multiples archivos de configuracion (web.config): 1 archivo por servicio, 1 archivo

"padre" compartido por todos los servicios. Estos dos archivos son unidos por el
Framework del WCSF pasra obtener la configuracion del servicio, por ende estableciendo
una relacion de herencia entre dichos archivos web.config

- Requerimiento: Se debe tener un modelo del webconfig que debe usar un servicio
SINPE para incluir la configuracion de su
Para minimizar riesgos en las liberaciones, se debe reducir los cambios que haya que
hacer en estos archivos ya que actualmente los cambios se realizan manualmente.

El control de versiones debe ser autoritario

El repositorio de control de versiones no tiene una version que cualquier developer pueda
bajar a su PC

- Requerimiento: El control de versiones debe ser autoritario, es decir, siempre debe tener
la ultima palabra en materia de como se puede obtener la ultima version estable de la
aplicacion. Si hay un error y se corrige en el sandbox, se debe incluir en el repositorio, y
comunicar al equipo del proyecto. Estos archivos no deben ser especificos para una sola
maquina de desarrollador, sino genericos para funcionen con todos.

Modificacion manual de archivos de configuración

La existencia de multiples archivos de configuracion se complica al considerar que estos

deben modificarse manualmente para pasar a los diferentes ambientes (Integracion,
Pruebas, Preproduccion, Produccion). Esto se realiza manualmente y se depende de que
el desarrollador para que recuerde hacer la modificaciones sin afectar a lo existente. Esto
hace al proceso muy propenso a errores.

- Requerimiento: Se debe contar con una manera automatizada de revisar o generar los
archivos de configuracion de cada ambiente, asi minimizando tareas tediosas y la
probabilidad de errores humanos.

Cuando un archivo se elimina del código fuente, no estamos eliminando el mismo del
ambiente de pruebas o producción. Por ejemplo, un asmx.

Instalación de una máquina de desarrollo

Actualmente, se toma un tiempo aproximado de dos semanas para poder tener una
máquina de desarrollo de servicios SINPE.

Se debería analizar las tareas a realizar, tratar de simplificarlas, documentarlas mejor o

automatizarlas.
Configuración para desarrollar un servicio SINPE
Ya teniendo una máquina de desarrollo configurada, lo normal es que se tome varios días
logrando que un servicios SINPE esté funcional y se pueda programar en él.

Se debería analizar las tareas a realizar, tratar de simplificarlas, documentarlas mejor o

automatizarlas.

Test
explicar capas de pruebas y tipos.

sugerir mejoras de pruebas de aceptación y un diseño domain driven.

Errores de deployment

7 de agosto - caso con gran urgencia acerca de un error en produccion ya que se le debia
generar un certificado digital al Director del MICIT en lo relacionado con Firma Digital.
La causa del error fue un error en la instalacion de un componente en el servidor de
logica del negocio. El componente registrado en el GAC era diferente al requerido por la
aplicacion.

Requerimiento: Se debe automatizar la liberación a servidores staging

Diseño: http://stackoverflow.com/questions/711721/automating-net-deployment-using-
cruise-control-net Una alternativa es que el build server cree el paquete de deploy, y que
este contenga los tasks requeridos para realizar el deploy. De esta manera, se mantiene
versionado incluso el script de liberación. Si en algún momento se da algún problema,
entonces se puede verificar el script usado para mejorarlo. Entonces, la tarea del personal
de instalación es ser los encargados de loguearse en el servidor dado, obtener la versión a
instalar, y ejeutar un deploy.bat que ejecute nant.

otras alternativas: http://stackoverflow.com/questions/974799/what-method-do-you-use-

to-deploy-asp-net-applications-to-the-wild
Requerimiento: Se debe contar con un mecanismo para verificar luego de cada
instalacion.

Diseño: La aplicación misma debe contar con un mecanismo que indique su "salud". Por
ejemplo, si es un sitio web, podría contar con un aspx que acceda a todas las capas y
retorne un XML con los resultados, y que pueda ser verificado visualmente por un
humano.

Reversar liberación

Requerimiento: Se debe poder regresar a la versión anterior.

Diseño:

Requerimiento: Se debe poder saber la versión del servicio instalado en cada ambiente.

Tengo que leer: http://startuplessonslearned.blogspot.com/2009/06/why-continuous-

deployment.html
Metodologia
En un ambiente de Pruebas se halla que el software no ha sido terminado

Se halla que

- en el ambiente de pruebas llegan errores muy basicos de programacion y en general del

desarrollo del software. por ejemplo, la aplicacion no muestra asistentes que el caso de
uso solicita, o se halla componentes graficos (como botones) que no tienen una
implementacion.

esto muestra que el software nunca fue usado.

otros companeros han indicado que han tenido que arreglar defectos producto de software
que al ver el codigo, se nota a simple vista que este nunca fue ejercitado, ya que no pudo
haber funcionado en momento alguno.

Esto refleja el hecho de que el proceso de desarrollo no verifica en ningun momento el

software en un ambiente de Integracion en donde se pueda ver la funcionalidad
ejecutando.

Ademas, no hay revisiones de codigo que asegure el cumplimiento con buenas practicas
de diseno y de diseno de pruebas unitarias.

El requerimiento: modificar el proceso de desarrollo para que incluya acciones

especificas a realizar para asegurar la calidad del producto desarrollado (por ejemplo,
revisiones con obketivos bien definidos, demostraciones de desarrollo parcial o final de
un caso de uso).

El objetivo es que al terminar la programacion de un caso de uso, y antes de enviarlo a

pruebas, se tenga certeza de la estabilidad y funcionamiento correcto del software. La
integracion continua y deploy continuo, da la posibilidad de hacer una instalacion
automatizada en un ambiente de integracion de manera que sea sencillo realizar tales
demostraciones.

Verificación de instalaciones

Requerimiento: Una instalación de un sitio web, wcf y base de datos debe ofrecer un
medio para verificar lo exitoso de la instalación.

Build

Actualmente, se tarde muchos días configurando una máquina de desarrollo para poder
ejecutar exitosamente el sitio web del SINPE y ver un servicio. Hay muchos pasos
manuales, tediosos, y hay guías defectuosas.

Requerimiento

El sitio web principal del SINPE debe poder ser obtenido del repositorio de control de
versiones, ensamblado e instalado de manera ágil para que el desarrollador pueda
empezar a contruir software lo más pronto posible.

Diseno

Todo el sitio debe estar contenido en el repositorio.

Los archivos de configuracion deben ser genéricos para cualquier máquina de
desarrollador.

Debe haber un build privado

Debe compilar de manera que el desarrollador pueda ejecutarlo y ver su trabajo

ejecutando la aplicacion.

Implementacion

Website principal

1. Hostear version del website principal en IIS.

2. Configurar build para que al compilar envie los DLLs y contenido Web al IIS.

3. Ejecute el build

4. Attach del Visual Studio al proceso del aspnet_wp.exe

SubWebsite

1. Configurar build para que al compilar envie los DLLs y contenido Web al IIS.

2. Ejecute el build

3. Attach del Visual Studio al proceso del aspnet_wp.exe

Compruebelo:

1. Coloque un breackpoint en un codigo de un ASPX.VB y otro en una clase de un US

2. Ejecute el IE y navegue hacia el ASPX

Creo un sitio de ejemplo, e instrucciones automatizadas para verificar su funcionamiento,
demostrando lo anterior.

Referencias de tecnologías utilizadas

Web Client Software Factory

http://www.codeplex.com/websf

SQL Server 2008

http://www.microsoft.com/sql/default.mspx

Composite web clients

http://websf.codeplex.com/Wiki/View.aspx?title=Composite%20Web%20Clients

Introducing Windows Communication Foundation

http://msdn.microsoft.com/es-cr/library/dd943056(en-us).aspx