universidad para la cooperacion internacional … · erp: enterprise resource planning ......
TRANSCRIPT
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL(UCI)
METODOLOGÍA PARA LA CREACIÓN DE SERVICIOS SOA EN LA DIVISIÓN DE SERVICIOS TECNOLÓGICOS DEL BANCO CENTRAL DE COSTA RICA
LUIS CARLOS GARCÍA MORA
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITOPARCIAL PARA OPTAR POR EL TITULO DE MASTER EN
ADMINISTRACIÓN DE PROYECTOS
San José, Costa Rica
Julio, 2008
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL(UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad comoRequisito parcial para optar al grado de Máster en Administración de Proyectos
__________________________Ing. Alejandro Rubinstein B., M.B.A.
PROFESOR TUTOR
_________________________Lic. Yorlenny Hidalgo Romero, M.A.P.
LECTOR No.1
__________________________Víctor Noguera Durán
LECTOR No.2
________________________Ing. Luis Carlos García M., M.C.I.
SUSTENTANTE
ii
BANCO CENTRAL DE COSTA RICA(BCCR)
Este Proyecto Final de Graduación fue recibido por el Área de Implementación del Departamento de Ingeniería de Software Institucional de la División de
Servicios Tecnológicos del BCCR.
__________________________M.C.I.. Hazel Umaña Morales.
ELECUTIVA DE ÁREABCCR
________________________Ing. Luis Carlos García M., M.C.I.
SUSTENTANTE
iii
DEDICATORIA
A DIOS, POR TANTAS BENDICIONES RECIBIDAS,
A MIS PADRES, POR SER SIEMPRE CONSEJEROS Y GUÍA,
A MI HERMANA POR TANTO APOYO RECIBIDO,
A MI ESPOSA, POR SER LA PERSONA MÁS ESPECIAL DEL
MUNDO,
A LOS COMPAÑEROS DE TRABAJO QUE HICIERON VALIOSOS
APORTES PARA CREAR ESTA METODOLOGÍA
iv
INDICE DE CONTENIDO
1. INTRODUCCIÓN.....................................................................................................................................1
1.1. Antecedentes...........................................................................................................................................1
1.2. Organigrama...........................................................................................................................................2
1.3. Problemática...........................................................................................................................................2
1.4. Justificación 3
1.5. Objetivos 4
2. MARCO TEÓRICO..................................................................................................................................6
2.1. Marco Institucional.................................................................................................................................6
2.2. Teoría de TI y SOA................................................................................................................................8
2.3. Relación con la administración de proyectos.......................................................................................17
2.3.1. Modelos aplicados.............................................................................................................................17
2.3.2. Proyectos 19
2.3.3. PMI 20
2.3.4. Alcance 23
2.3.5. Tiempo 24
2.3.6. Calidad 25
2.3.7. Integración.........................................................................................................................................27
2.3.8. Programas 28
2.3.9. Estructuras organizativas para proyectos...........................................................................................29
2.4. Herramientas relacionadas....................................................................................................................32
3. MARCO METODOLÓGICO.................................................................................................................34
3.1. Investigaciones comunes......................................................................................................................34
3.2. Revisión de software.............................................................................................................................36
3.3. EDT y cronograma...............................................................................................................................36
3.4. Estándares 37
3.5. Control y seguimiento...........................................................................................................................38
3.6. Documentación.....................................................................................................................................39
3.7. Buenas prácticas para SOA..................................................................................................................40
3.8. Validación 41
4. PLANEACIÓN DEL PROYECTO.........................................................................................................44
4.1. Tareas para crear un servicio SOA.......................................................................................................44
4.2. Secuenciación de tareas........................................................................................................................47
4.3. Organización por paquetes de trabajo...................................................................................................48
4.4. Estructura de desglose de trabajo (EDT)..............................................................................................49
4.5. Cronograma 59
v
5. ESTÁNDAR DE INTERFAZ E IMPLEMENTACIÓN.........................................................................61
5.1. Componentes de software.....................................................................................................................61
5.2. Estándar de implementación.................................................................................................................62
5.3. Estándar de interfaz y organización de componentes...........................................................................74
5.4. Estándar de documentación interna......................................................................................................77
6. MECANISMOS DE CONTROL PARA EL PROYECTO.....................................................................81
6.1. Flujos de trabajo y roles........................................................................................................................81
6.2. Hitos de control.....................................................................................................................................85
6.3. Mecanismos de control.........................................................................................................................87
7. GUÍA DE BUENAS PRÁCTICAS.........................................................................................................90
8. VALIDACIÓN DE LA METODOLOGÍA.............................................................................................95
8.1. Revisión primaria..................................................................................................................................95
8.2. Aspectos a validar y resultados esperados............................................................................................98
8.3. Mecanismos de validación y retroalimentación.................................................................................102
9. CONCLUSIONES.................................................................................................................................105
10. RECOMENDACIONES......................................................................................................................108
11. BIBLIOGRAFÍA.................................................................................................................................110
12. ANEXOS.............................................................................................................................................112
12.1. Charter del proyecto.........................................................................................................................113
12.2. Declaración de alcance ....................................................................................................................116
12.3. EDT del Servicio SOA.....................................................................................................................118
12.4. Cronograma del Servicio SOA.........................................................................................................119
12.5. Plantilla de Caso de Uso...................................................................................................................120
12.6. Plantilla para Diseño.........................................................................................................................121
12.7. Plantilla de revisión de calidad para Diseño.....................................................................................122
12.8. Plantilla para Base de Datos............................................................................................................123
12.9. Plantilla de revisión para Base de Datos...........................................................................................124
12.10. Plantilla para Componentes de Software.......................................................................................125
12.11. Plantilla de revisión para componentes de Software......................................................................126
12.12. Plantilla para documentación externa e integración......................................................................127
12.13. Plantilla para documento de validación..........................................................................................128
12.14. Plantilla para seguimiento de reuniones.........................................................................................131
12.15. Plantilla para solicitudes de cambio a productos ...........................................................................132
12.16. Plan de Implementación.................................................................................................................133
12.17. Análisis Costo-Beneficio................................................................................................................137
12.18. Áreas de conocimiento relacionadas..............................................................................................140
vi
INDICE DE ILUSTRACIONES
Figura 1: Organigrama del BCCR.................................................................................................................2
Figura 2: Interacción entre servicios (Pijanowsky, 2007)...........................................................................10
Figura 3: Niveles de SOA (Arsanaji 2004)..................................................................................................12
Figura 4: Objetivo de madurez de organizaciones según OPM3 (Eiipe, 2007)..........................................18
Figura 5: Modelo de arquitectura de capas (Blázquez 2005)......................................................................44
Figura 6: Ejemplo de clases y capas............................................................................................................74
Figura 7: Flujo de trabajo para crear un servicio SOA................................................................................83
vii
INDICE DE CUADROSCuadro 1: Tareas por rol (Arsanaji 2004)....................................................................................................14
Cuadro 2: Grupo de procesos......................................................................................................................21
Cuadro 3. Áreas de conocimiento................................................................................................................21
Cuadro 4: Diferencias entre proyecto y programa (Thiry, 2002)................................................................29
Cuadro 5: Tipos y ambientes de bases de datos .........................................................................................63
Cuadro 6: Nomenclatura para los DLL.......................................................................................................76
Cuadro 7: Lista de hitos del proyecto..........................................................................................................86
Cuadro 8: Lista de funcionarios que validaron metodología.......................................................................96
viii
INDICE DE ABREVIACIONES
BCCR: Banco Central de Costa Rica.
BD: Base de datos
BE: Business Entity
(Entidad de negocio)
BS: Business Service
(Servicio de negocios)
CRM.: Custom Relationship Management
(Administradores de relaciones con los clientes).
DBA: DataBase Administrador
Administrador de Base de Datos
DLL: Dynamic Linking Library
Librería de Enlace Dinámico.
DS: Data Service
(Servicios de datos)
DST.: División de Servicios Tecnológicos
EDT: Estructura de desglose de trabajo
ER: Modelo Entidad-Relación
ERP: Enterprise Resource Planning
(Sistemas de planificación de recursos empresariales)
IS: Interface Service
(Interfaz de servicios)
LINQ: .Net Language Integrated Query
Lenguaje de Consultas integradas para .Net
OPM3 : Organizational Project Management Maturity Model
(Modelo de gestión de madurez organizacional de proyectos)
PMI: Proyect Management Institute
(Instituto de administración de proyectos)
PMMM: Program Management Maturity Model
ix
(Modelo de programa de gestión de evolución)
RUP: Rational Unified Process
(Proceso Unificado de Rational)
SOA: Service Oriented Architechture
(Arquitectura orientada a servicios).
TI.: Tecnología de Información
XML: Extended Markup Language
(Lenguaje extendido de etiquetas)
x
RESUMEN EJECUTIVO
El BCCR (Banco Central de Costa Rica) es una sólida institución pública, fundada hace alrededor de 60 años, al empezar Costa Rica a comercializar sus productos con otras naciones y recibir divisas. En aquel tiempo, era necesario regular el naciente Sistema Bancario Nacional, pues el gobierno no tenía un ente que fiscalizara el manejo de los dineros que entraban al país.
Con los años, el BCCR ha ido evolucionando y ampliando su horizonte de acción. Actualmente se encarga de regular las fluctuaciones del tipo de cambio del colón, la política monetaria para controlar la inflación y los precios, la administración de las reservas monetarias internacionales y la administración del sistema nacional de pagos.
La tecnología ha llegado a ser un punto de apoyo base para cualquier negocio. El BCCR no es la excepción. Gran parte de sus tareas y obligaciones se fundamentan en una sólida plataforma tecnológica que incluye desde aplicaciones de software hasta redes de fibra óptica. En el caso de esta metodología, se trata el tema del desarrollo de aplicaciones de software.
Esta organización tiene muchos tipos distintos de aplicaciones de software, algunos modernos pero otros viejos y obsoletos. Hay mucho trabajo para migrar esos sistemas viejos a nueva tecnología, a la vez que se deben complementar los sistemas nuevos con mayor funcionalidad. Debido a esto, es necesario contar con una metodología que se pueda utilizar para crear todo este nuevo software (en general) que se necesita.
El paradigma de programación SOA (“Service Oriented Architechture” ó Arquitectura orientada a servicios) ha sido impulsado por grandes empresas comercializadoras de software, a través de herramientas y estándares que permiten crear servicios funcionales, flexibles y de mantenimiento sencillo, para construir plataformas de software robustas. Debido a esto, el BCCR ha adquirido las herramientas para desarrollar estos servicios y encaminar sus aplicaciones hacia esta tendencia. Parte del conocimiento que hace falta madurar está en los resultados de esta investigación.
El objetivo principal de este proyecto es dotar al BCCR de una metodología efectiva para construir servicios SOA, y así poder montar su plataforma aplicativa de sistemas sobre estos servicios, mejorando la calidad del trabajo. Esto se logrará aplicando algunas herramientas de administración de proyectos. Entre los principales objetivos específicos se tienen la creación de estándares para el desarrollo de componentes e interfaces entre ellos, la descripción de estándares para documentación interna y externa, la definición de los mecanismos de control y la validación de la metodología por parte de los analistas y desarrolladores de software, todo esto amparado bajo la aplicación de algunas áreas de conocimiento de la teoría de administración de proyectos.
xi
Para desarrollar esta metodología, se da un gran impulso a la investigación web y bibliográfica. Se utilizan motores de búsqueda y manuales técnicos para buscar propuestas de estándares para desarrollos de servicios SOA, mejores prácticas, formas de documentación y herramientas tecnológicas que ayuden en alguno de los pasos de la construcción de un servicio. También se hicieron entrevistas a los expertos encargados del mantenimiento de los sistemas actuales, para conocer las carencias actuales en cuando a análisis, diseño y desarrollo de componentes.
Para el control y seguimiento de los procesos de la metodología, se crearon una serie de formularios de validación que se utilizan en ciertos hitos del proyecto, para verificar el avance y el apego a los estándares. En cuanto a validación, se utiliza un par de proyectos piloto y se documenta toda la retroalimentación obtenida para incorporar cambios y mejoras a la metodología.
Al final se logró crear una metodología que cubre todo el proceso de desarrollo de software: desde el análisis de los requerimientos de los usuarios hasta las pruebas de integración del servicio SOA con respecto a la plataforma tecnológica. Dicha metodología se apoya mucho en el trabajo de equipo de miembros de distintas áreas especializadas, la calidad y el control del proyecto.
Si bien es cierto no se trata de una metodología exhaustiva, pues se busca dar un razonable grado de flexibilidad para aprovechar la creatividad de los profesionales en sistemas de programación, sí se establecen los lineamientos claros y de mayor nivel que constituyen aportes a la consistencia de los componentes.
También, se establece la importancia de algunos procesos de investigación, seguimiento y mejora continua sobre la metodología aplicada, para obtener información de primera mano que pueda ser útil para mejorar el trabajo, que al final es lo más importante.
Completan la metodología los estándares de programación, documentación y las plantillas para el control de los hitos.
Como recomendaciones finales, complementarias a la guía de desarrollo y los procesos asociados, están el mantenimiento de una investigación constante sobre nuevas técnicas y herramientas tecnológicas que ayuden en el desarrollo de software, la creación de un estándar de interfaz de usuario final para ponerle “cara” a los servicios y las consideraciones respectivas de seguridad de información y auditoría.
xii
1
1. INTRODUCCIÓN
1.1.Antecedentes
El Banco Central de Costa Rica es una institución pública fundada en 1950,
con la idea de que fiscalizara y regulara el accionar de los bancos emisores de
la época (Banco Central de Costa Rica [BCCR], 2007). Con el tiempo, sus
funciones han evolucionado hacia el establecimiento y control de políticas
monetarias, el manejo de la fluctuación del tipo de cambio y la administración
de las reservas monetarias internacionales del país.
Como toda organización moderna, en la actualidad la mayor parte del apoyo
que se ofrece a los distintos procesos del negocio se refleja en herramientas
tecnológicas tales como redes de fibra óptica, telefonía IP y por supuesto,
sistemas de información que ayudan en el trabajo diario de las distintas
dependencias.
Es en este último campo en el cual se presentan distintas tendencias sobre
sistemas y aplicaciones, paradigmas y herramientas, que ofrecen una gran
gama de posibilidades para su aprovechamiento. Grandes empresas que
comercializan tecnología han marcado la pauta en los últimos años.
Una de las principales empresas de tecnología a nivel mundial es Microsoft.
También es la de mayor arraigo en el BCCR y Costa Rica en general.
Microsoft ha creado una serie de herramientas y metodologías de creación de
sistemas y se ha encargado de fomentar su uso. Uno de estos esfuerzos lo ha
constituido la arquitectura basada en servicios SOA.
2
1.2.Organigrama
El organigrama del BCCR se muestra en la Figura 1:
Figura 1: Organigrama del BCCR.
1.3.Problemática
En instituciones como el BCCR, con gran cantidad de empleados, sistemas,
datos y procesos de negocio, la creación y el mantenimiento de sistemas de
información es un proceso delicado e importante, pues estos componentes
llegan a ser las primeras herramientas de apoyo al trabajo. Sin embargo, no
todos los sistemas cumplen con los requerimientos mínimos que se esperaría
3
tuvieran: algunos están desarrollados en herramientas obsoletas, otros están
operando sobre equipos obsoletos o incluso algunos han sido excluidos de los
procesos de mantenimiento que deberían tener regularmente, principalmente
por falta de personal o de tiempo.
1.4.Justificación
Por esto, se ha buscado alguna de las tendencias tecnológicas actuales para
desarrollar los nuevos sistemas que se van a construir, o bien migrar los de
tecnología obsoleta, de manera que se facilite el desarrollo, mantenimiento, uso
de herramientas y aplicación de estándares que garanticen calidad.
La tecnología SOA de Microsoft ofrece esto, además de otras ventajas en lo
que se refiere a escalabilidad de aplicaciones y reutilización de funcionalidad,
según (Roch, 2006). Es todo un nuevo paradigma con el cual se puede crear
una gran plataforma que soporte la operación del BCCR, e incluso que permita
una evolución futura hacia nuevas herramientas que sea más transparente.
Este proyecto pretende crear una metodología para desarrollar servicios SOA y
de esta forma lograr que los sistemas de información del BCCR tengan
documentación, estilos de programación, interfaz con otros componentes y en
general un conjunto de buenas prácticas, todo bajo un marco de trabajo
conocido y aplicadas por todos los analistas y desarrolladores de sistemas.
La idea de utilizar una metodología es porque los profesionales en informática
están acostumbrados a trabajar con este esquema, ya que es una herramienta
flexible donde puede ser flexible y rígida donde debe ser rígida. Una
metodología permite una sencilla difusión y asimilación por parte de las
personas que la van a poner en práctica. Además, admite cambios que
introducen mejoras en todos los procesos, al momento que sean requeridos.
4
En algunos casos, sobre todo para los sistemas obsoletos que todavía se
tienen en funcionamiento, la migración hacia una arquitectura de servicios no
es un proceso trivial. Sin embargo, una metodología de este tipo puede ayudar
a cuantificar y calificar el trabajo por hacer y que al final de cuentas, el proceso
en general se simplifique por tener lineamientos a los cuales ajustarse.
En términos generales, todas estas metodologías que corresponden a nuevas
tendencias de desarrollo de sistemas vienen soportadas por herramientas que
hacen que el trabajo quede mejor. No siempre se puede decir que es más fácil
(o difícil), sino lo importante es que queda mejor. Esa es la llave para abrir las
puertas de las organizaciones a estas tecnologías.
El Anexo 12.17 presenta un análisis Costo-Beneficio de la aplicación de esta
metodología en el BCCR.
1.5.Objetivos
El objetivo general es el siguiente:
“Dotar a la División de Servicios Tecnológicos del Banco Central de Costa Rica
de una metodología que le permita crear de manera eficiente y estandarizada
los servicios SOA que serán la base para construir una plataforma de software
robusto y flexible.”
Los objetivos específicos son:
• Identificar las tareas básicas que se requieren en un proceso de creación de
un servicio SOA y la forma en la que cada tarea debe ser efectuada, para
delimitar el alcance de cada producto.
• Estandarizar las interfaces e implementaciones de los servicios para todas
las aplicaciones nuevas que se solicitan por parte del negocio, para
5
mantener uniformidad en los componentes que faciliten el entender el uso y
el trabajo de mantenimiento.
• Definir los mecanismos de control que van a permitir concluir exitosamente
cada uno de los servicios que se construyan bajo esta metodología.
• Definir la documentación interna y externa que va a cumplir cada uno de los
servicios para contribuir con la calidad del producto y facilitar la consulta y
reutilización de funcionalidad.
• Definir un conjunto de buenas prácticas que aplique para el proceso de
diseño y construcción de los servicios, a lo largo de todo el ciclo, para
facilitar el mantenimiento posterior.
• Validar parcialmente la metodología, haciendo como mínimo una revisión
del documento con los compañeros de las áreas involucradas en proyectos
de este tipo, para verificar la aplicabilidad de la guía.
6
2. MARCO TEÓRICO
2.1.Marco Institucional
El BCCR fue creado a principios de la década de los años 50, en un momento
en el cual el país veía como el comercio con otras naciones empezaba a
florecer y las divisas generadas empezaban a engrosar las arcas de las
instituciones financieras rudimentarias de la época.
El gobierno vio la necesidad de fundar alguna institución independiente y con
una nueva misión: fundar las bases para la creación de un nuevo sistema
bancario costarricense (BCCR, 2007). Entonces, se promulgó la Ley 1130 el 28
de Enero de 1950 (Asamblea Legislativa, 1950) con el cual nació el Banco
Central de Costa Rica.
Con el paso de los años, esta institución ha ido diversificando sus funciones, de
manera que siempre ha sido el eje del Sistema Financiero Nacional. Ha habido
cambios significativos, pero siempre se mantienen los principios básicos con
los cuales la institución fue fundada: regular las distintas entidades financieras,
mantener estable el tipo de cambio, administrar las reservas financieras de la
nación y ser la base del sistema financiero nacional.
La misión del BCCR es la siguiente (BCCR, 2007):
“Contribuir al desarrollo de la economía costarricense procurando la estabilidad de precios.”
Este principio es sencillo, pero si se estudia a fondo, engloba de manera
implícita una gran cantidad de funciones en distintos campos de la economía,
7
finanzas, administración, estadística y, como apoyo a todos estos campos de
negocio, la tecnología.
La visión de la organización se define de la siguiente manera (BCCR, 2007):
“Ser un banco central reconocido por la sociedad costarricense y la comunidad
internacional por su eficiencia, transparencia, credibilidad y capacidad para
mantener una inflación baja y estable.”
Gracias a que la sociedad costarricense siempre ha reconocido al BCCR como
una institución pública de renombre, seria y al servicio del país, se ha admitido
el nombre de la institución como uno más de una serie de organizaciones en la
región que son líderes en sus campos de negocio, toda vez que este buen
nombre a nivel internacional da prestigio al país. En comparación con otras
instituciones públicas del país, el BCCR ha tenido y mantiene uno de los
mejores conceptos en el público desde su creación.
Como objetivos de la institución, aparte de mantener la estabilidad interna y
externa de la moneda nacional, se detallan también los siguientes (BCCR,
2007):
• Promover el ordenado desarrollo de la economía costarricense.
• Velar por el buen uso de las reservas monetarias internacionales.
• Promover la eficiencia del sistema de pagos internos y externos.
• Promover un sistema de intermediación financiera estable, eficiente y
competitivo.
La estructura orgánica del BCCR está conformada por los siguientes niveles
jerárquicos (BCCR, 2007):
8
• Nivel superior: Es el nivel ejecutivo. Tiene un alto grado de autoridad para
tomar las acciones que ayuden a alcanzar los objetivos institucionales.
• Nivel divisional: Es el responsable de la ejecución de las funciones para
alcanzar los objetivos institucionales. Cada división tiene asignado un
director. Actualmente, existen 8 divisiones.
• Nivel departamental: Ejecuta labores de tipo sustantivo y también algunas
administrativas. Cada departamento tiene asignado un director. El número
de departamentos por división es variable.
• Nivel Seccional: Se limita a funciones de apoyo técnico. Cada sección está
a cargo de un ejecutivo de área.
El BCCR es, sin duda, una organización consolidada y de buena proyección
hacia el futuro No existe en la actualidad ninguna institución de esta
envergadura que no tenga que apoyarse en herramientas tecnológicas e
informáticas, para cumplir con su labor.
La inversión tecnológica siempre ha sido una constante en el BCCR Gracias a
eso se ha logrado consolidar una plataforma fuerte, tanto a nivel de
infraestructura como de software, lo que redunda en buenos resultados para el
negocio. Claro que hay puntos por mejorar, algunos más prioritarios que otros,
pero es algo inherente a la evolución que tienen día a día los avances
tecnológicos.
2.2.Teoría de TI y SOA
La Tecnología de Información (TI) viene a ser una tendencia que empezó a
gestarse un par de décadas atrás, a partir de las matemáticas aplicadas y la
ingeniería. Los avances tecnológicos y la madurez de las organizaciones para
buscar mejorar sus negocios, hicieron que el valor de la información llegara a
ser el principal activo en muchos de los casos.
9
Actualmente, TI está extendido a diversos campos, con resultados significativos
para las organizaciones. Se puede citar campos tan diversos como
matemáticas, estadística, física, química, ingenierías, arquitectura, y otras.
Simples puntos de venta como supermercados o comercios de bienes, tienen
como base medular sistemas de información que les facturan, controlan
planillas, pagan a proveedores, mantienen inventarios, etc.
Evidentemente, no todos los negocios son iguales. De hecho, son tan
heterogéneos entre si que un sistema de información hecho para un negocio no
funciona en otro, sin antes hacer una actualización (que podría ser grande y
costosa). Por este motivo, durante los últimos años se han creado
metodologías de construcción y puesta en marcha de sistemas de información
y herramientas que apoyan estos procesos, que tienen la particularidad de que
son flexibles y permiten una gran versatilidad. El que atañe en esta
investigación es SOA.
SOA viene a ser un estilo arquitectónico para que los distintos negocios puedan
contar con una plataforma tecnológica que se ajuste 100% a su negocio, en
cuanto a eficiencia, eficacia y oportunidades. La diferencia de SOA con
respecto a otras metodologías es que se gestan componentes de software a
partir de coyunturas del negocio reales, identificadas y especificadas por
expertos. Todo lo que se construya, mantenga o cambie, va dirigido por los
principales interesados: los expertos de negocio.
Anteriormente, los profesionales de informática acostumbraban obviar el criterio
del negocio a la hora de diseñar los sistemas de software. Por lo general,
asumían algunas cosas que no se sabían. Similarmente, los conocedores del
negocio (economistas, ingenieros, administradores, supervisores, etc) nunca
tenían tiempo ni disposición para formar parte de los equipos de diseño y
desarrollo de sus propias aplicaciones. El resultado de este divorcio eran
sistemas poco útiles, incompletos, inexactos y difíciles de mantener.
10
Con alternativas como SOA, la alineación entre las unidades de negocio y TI se
vuelve más definida. Además, la infraestructura es más oportuna y con
mayores posibilidades de crecimiento. En general, todos los procesos se
simplifican y el resultado final es más efectivo para el negocio (el principal
objetivo de TI).
Un estilo de arquitectura de software es al final de cuentas un conjunto de
componentes y sus relaciones entre sí; también las restricciones y la forma en
la que cada una pueda ser combinada para lograr componentes más complejos
(Shaw & Garland, 1996).
La figura 2 ilustra la relación que se da entre servicios:
Figura 2: Interacción entre servicios (Pijanowsky, 2007)
En el caso particular de SOA, la definición más comúnmente aceptada es la
siguiente: “un estilo de arquitectura que promueve el concepto de servicios
alineados al negocio como una unidad fundamental de diseño, construcción y
composición de soluciones de negocio; múltiples patrones de diseño,
implementación y puesta en marcha completan el estilo”. (Lublinsky, 2007).
11
Cuando no se tiene una participación clara del negocio en los procesos de
diseño y elaboración de sistemas, tal y como sucedía hasta hace algunos años,
se corre el riesgo de crear “islas de información” (Arsanjani, 2004). Una isla de
información constituye un sistema (con sus datos) que tiene un propósito
específico y que es independiente de todo el resto de la organización.
Por ejemplo, una organización podría tener varias islas de información:
facturación, pagos, planillas, ventas, compras. Cada uno es independiente de
los demás, lo cual hace que el mantenimiento sea sumamente complicado
porque todos tienen componentes repetidos y su concepción podría ser distinta
dependiendo del sistema.
Algunas veces, para hacer un cambio de mantenimiento que afecta un sistema,
hay que ir a otros componentes de otros sistemas a efectuar el mismo ajuste,
lo cual es problemático y siempre acarrea consecuencias negativas.
Suponiendo que los sistemas del ejemplo anterior manejan el concepto de “tipo
de cambio”, si se desea cambiar la fórmula para el cálculo, es necesario ir a
cada uno de los sistemas que lo utiliza, buscar la fórmula y actualizarla.
SOA ha sido pensado para combatir este tipo de problemas. Con este estilo de
diseño y construcción de sistemas, lo que se haría es construir un único
componente de software llamado “tipo de cambio”, con toda la funcionalidad
necesaria para operar en todos los servicios que sea requerido, y se haría que
cada uno de los sistemas utilizara este componente. Entonces, con el caso del
ejemplo anterior, no es necesario ir a cada sistema para actualizar una fórmula
de cálculo, sino que se hace solamente una vez en el componente respectivo, y
así todos los sistemas reciben la actualización de manera transparente. Este es
el principio fundamental de SOA.
El concepto SOA, en su perfil más puro, se puede definir gráficamente por
niveles, como se muestra en la figura 3:
12
Figura 3: Niveles de SOA (Arsanaji 2004)
Cada nivel tiene sus propias características (Roch, 2006):
1. Nivel de sistemas base: Contiene las aplicaciones ya en funcionamiento,
los sistemas legados, paquetes CRP ó ERP (“Enterprise Resource
Planning” ó Sistema de Planificación de Recursos Empresariales), los
cuales se incorporan en la metodología a través de técnicas de integración
orientadas a servicios.
2. Nivel de componentes: Contiene los componentes responsables por la
funcionalidad y el mantenimiento, que cuentan prácticamente como activos
administrados de la organización. Típicamente se utilizan tecnologías
basadas en contenedores, servidores de aplicaciones y administradores de
cargas de trabajo y disponibilidad.
3. Nivel de servicios: Contiene los servicios que fundamentan la lógica de
negocio. Se rige por interfaces entre componentes, cada una con una
descripción bien clara para facilitar el uso entre componentes. Los servicios
13
pueden trabajar aisladamente, pero su mayor valor se obtiene cuando se
combinan.
4. Nivel de coreografía de procesos de negocio u orquestación: Contiene
una serie de reglas para que los servicios del nivel 3 tengan una operación
consistente, oportuna y eficaz. Formalmente, se crean workflows para
facilitar la administración de los servicios, así se logra que actúen como si
fueran una sola aplicación. Los procesos de negocio se especifican a este
nivel.
5. Nivel de presentación o acceso: Contiene los puntos de acceso para el
resto de los niveles. Es importante por los estándares que se empiezan a
gestar a este nivel.
El modelado orientado a servicios tiene técnicas, herramientas y
procedimientos para trabajar en cada uno de los niveles, de esta forma se ligan
todos los componentes para poder crear una única solución para el negocio.
Por ser una metodología voluminosa y que abarca varias áreas del desarrollo,
SOA tiene varios roles. La mayoría son técnicos. Sin embargo, a nivel más
general, existe una clasificación de roles que suele ser la más utilizada cuando
se explica la metodología. Estos roles se llaman Proveedor y Consumidor.
Como lo muestra el cuadro 1, la mayoría de las tareas de SOA (al menos las
de mayor valor para el negocio) se pueden agrupar en alguno de estos dos
roles.
14
Cuadro 1: Tareas por rol (Arsanaji 2004)
Generalmente, las tareas del Proveedor suelen ser un subconjunto de las
tareas del Consumidor. Básicamente el Consumidor especifica los servicios,
mientras que el Proveedor identifica y especifica los componentes necesarios
para soportar la funcionalidad que los servicios requieren. Es una agrupación
lógica, pero funciona bien para entender el alcance de lo que se desea nombrar
(Trowbridge, 2003).
Las principales características que diferencian a SOA de otros paradigmas son
propiedades de la arquitectura de sistemas distribuidos. Las siguientes son
algunas de las principales (Lublinsky, 2007):
• Vista lógica: Un servicio SOA es una abstracción lógica de un sistema,
aplicación o base de datos que se tiene actualmente, pero desde el punto
de vista de la funcionalidad que tiene para el negocio.
• Orientación a mensajes: El servicio es definido formalmente por los
mensajes que se intercambian Proveedor y Consumidor, no por las
propiedades de cada uno. La estructura interna de los servicios es
15
completamente abstracta (invisible desde afuera del mismo servicio). Las
capas de interfaz y comunicación están separadas.
• Descripción de la orientación: Un servicio está descrito por una definición
de patrones (“metadata”) compilados (traducidos a código binario de
computadora).
• Granularidad: El servicio tiende a utilizar un pequeño número de
operaciones con mensajes relativamente largos y complejos.
• Orientación a redes de datos: El servicio tiende a ser diseñado y utilizado
sobre redes de datos, aunque no es un requerimiento indispensable.
• Plataforma neutral: Los mensajes son enviados en formatos estándar
independientes de la plataforma. XML (“Extended Markup Language” ó
Lenguaje extendido de etiquetas) es el utilizado por excelencia.
Es importante aclarar que en la literatura sobre servicios en el desarrollo de
componentes de software, pueden existir algunas definiciones sobre “servicios”
que pueden ser utilizadas indistintamente, aunque en el fondo se refieren a
cosas distintas. Por ejemplo (Trowbridge, 2003):
• Servicios de negocio: componentes que efectúan alguna tarea de valor
para el negocio.
• Servicios de integración: componentes que permiten el trabajo conjunto
de componentes de negocio.
• Servicios de infraestructura: componentes que ayudan para el soporte a
la infraestructura.
Para esta metodología, se toman en cuenta los dos primeros tipos de
“servicios”, que son los más relacionados con el desarrollo y puesta en marcha
de sistemas.
Dado que los procesos de creación de servicios se pueden definir como
secuencias de pasos específicos y claros, se ha desarrollado por parte de
16
algunas empresas una serie de lineamientos que asisten en algunas de las
etapas de construcción de tareas. Estos procedimientos se llaman patrones.
Los patrones son formas de describir las mejores prácticas, mejores diseños y
mejores experiencias pasadas de manera que se puedan reutilizar en procesos
futuros de creación de servicios. Al final, no son más que guías de consulta
rápida que asisten en contextos conocidos, para evitar “redescubrir el agua
tibia”.
Existen diversos patrones que pueden ayudar para crear servicios SOA
Algunos de los principales son, por ejemplo:
• Patrones de acceso a servicios e infraestructura.
• Patrones de composición de servicios.
• Patrones de definición de servicios e implementación.
• Patrones de administración de versiones.
• Patrones de seguridad.
• Patrones de acceso a datos.
Estos patrones no son verdades absolutas. Podrían utilizarse puros o con
algunas variaciones específicas en cada paso o incluso no utilizarse del todo.
Si la organización encuentra algún valor en la utilización de estas guías, puede
ser de valor, principalmente cuando se va a empezar a utilizar esta tecnología.
Generalmente, suelen usarse parcialmente en los procesos más estándar, por
ejemplo el acceso a datos.
Una vez explicado el concepto de servicios SOA, se procede a definir la teoría
de administración de proyectos que permite crear la metodología que el BCCR
necesita.
17
2.3.Relación con la administración de proyectos
2.3.1.Modelos aplicados
Existen actualmente muchas metodologías ó modelos de administración de
proyectos. Algunas tratan de establecer un estándar como para que se puedan
utilizar de manera similar en distintas organizaciones de diversos países. Otras
han sido hechas a la medida de la organización patrocinadora, con tantas
particularidades como sea requerido. En todos los casos, hay una gran mayoría
de casos de éxito.
Entre los modelos más conocidos a nivel mundial, están la guía del PMI
(“Proyect Management Institute” ó Instituto de Administración de Proyectos),
PMMM (“Program Management Maturity Model” ó Modelo de programa de
gestión de evolución), OPM3 (“Organizational Project Management Maturity
Model” ó Modelo de Madurez para la Administración de Proyectos
Organizacionales) y PM Solutions. Todas tienen similitudes en cuanto a sus
planteamientos base y búsqueda un alto nivel de madurez en la organización.
Por madurez, se entiende el nivel que tienen las organizaciones para
conceptualizar, definir y aplicar procesos que apoyan directamente su negocio
y que aportan beneficios cualitativos y cuantitativos. Estos procesos se aplican
en los distintos departamentos o unidades de negocio por parte de las
personas involucradas en procesos productivos, con la idea de aportar
estándares y buenas prácticas. Las organizaciones de mayor nivel de madurez
incluso tienen procesos por medio de los cuales transforman información
retroalimentada en acciones para el mejoramiento continuo, de una manera
formal.
Al final de cuentas, todos estos modelos buscan que la organización sea más
estructurada, más eficiente y productiva. La figura 4 muestra la ruta ideal que
18
sigue una organización en su camino a obtener madurez (Eiipe, 2007). Se
empieza por procesos en proyectos, luego se pasa a programas y portafolios
en lo que se refiere al dominio de acción. En cuanto a madurez, se empieza por
crear estándares y la idea es terminar con procedimientos de mejoramiento
continuo.
Figura 4: Objetivo de madurez de organizaciones según OPM3 (Eiipe, 2007)
Siendo pragmáticos, todas las personas han aplicado la teoría de proyectos
durante muchas actividades que se realizan día a día. Claro que si se tiene un
criterio amplio, se puede considerar que actividades como montar una obra
teatral, planear una boda o construir un centro comercial, corresponden a
proyectos (Gido & Clements, 2003).
Con un breve análisis de estas situaciones, se nota que todas estas tareas
tienen un objetivo principal claramente definido (por ejemplo, tener el centro
comercial). Similarmente, algunos otros objetivos secundarios que están
19
directamente relacionados con el principal (por ejemplo, conseguir los
vestuarios para los actores de la obra de teatro).
Igualmente, todas las actividades deben tener un proceso de planeación
anterior al inicio mismo de las actividades; por ejemplo, para el centro
comercial deben hacerse planes o para la boda deben definirse quienes serán
los invitados. Esta planeación determina principalmente cuales serán las
actividades y su secuencia necesaria para conseguir el objetivo, además de las
personas encargadas de cada actividad; por ejemplo, las hermanas de la novia
organizan el Té de despedida de soltera.
Similarmente, todas las actividades tienen un presupuesto y todas también
tienen un periodo de tiempo para conseguirse; por ejemplo, la recepción de la
boda debe seguir a la ceremonia religiosa.
Finalmente, estas tres actividades de ejemplo requieren un control durante su
periodo de ejecución, para garantizar que las actividades van conforme a lo
planeado; por ejemplo, un atraso en la estructura de techos del centro
comercial puede atrasar los acabados internos del edificio.
Desde este punto de vista, se nota que todas las actividades, que a primera
vista aparentan ser diversas, en realidad mantienen una serie de similitudes,
las cuales hacen que todas se puedan catalogar como proyectos.
2.3.2.Proyectos
Un proyecto se define como un conjunto de esfuerzos temporales, dirigidos a
generar un producto o servicio único (Chamoun, 2002). Los tres ejemplos
anteriores cumplen con esta definición. También lo cumplen el preparar una
cena para los amigos, atender a un herido de un accidente ó estudiar un
20
postgrado. En resumen, casi cualquier situación que se enfrenta todos los días
tiene algunas características de proyectos.
En proyectos, la planeación y la comunicación son básicas para poder lograr el
objetivo planteado. Ambos tópicos ayudan a reducir conflictos, a ser más
oportunos para actuar en el desarrollo y para hacer diagnósticos más acertados
durante la ejecución de las actividades.
Es fundamental definir claramente los objetivos y que estos sean concisos y
conocidos por todos los involucrados. Hay un presupuesto que limita y un
grupo de recursos, humanos y materiales, que se encarga de las actividades y
son responsables por ellas. También hay un periodo o fecha de finalización
para entregar resultados, por eso es tan importante la planeación de las
actividades, para no exceder el tiempo, presupuesto o recursos disponibles. La
filosofía convencional indica que estas actividades deben conducir a los
objetivos de manera gradual (Project Management Institute [PMI], 2004).
Igual de importante es el control que se ejerce sobre las actividades de un
proyecto. La idea es detectar desviaciones en el proceder normal de las tareas
del proyecto tan pronto como sea posible, para tomar las medidas correctivas
lo antes posible de manera que el impacto negativo que se pudiera tener, sea
menor.
2.3.3.PMI
El PMI, organismo reconocido a nivel internacional que por excelencia ha
impulsado la gestión por proyectos de las organizaciones, define en su última
actualización cinco grupos de procesos y nueve áreas de conocimiento para
agrupar todas las actividades que requiere un proyecto.
21
Los grupos de procesos son los que se muestran en el cuadro 2 (PMI, 2004):
Cuadro 2: Grupo de procesos
Grupo de procesos DescripciónIniciación Define y autoriza el proyecto o una fase del
mismo.Planificación Define los objetivos, planifica el curso de
acción requerido para lograrlos y limita el alcance del proyecto
Ejecución Integra los recursos (personales y materiales) para llevar a cabo el plan de gestión del proyecto.
Seguimiento y Control Mide y supervisa el avance, para tomar medidas correctivas oportunas.
Cierre Formaliza la aceptación del producto ó servicio y termina de manera ordenada el proyecto o la fase.
Las áreas de conocimiento son las del cuadro 3 (PMI, 2004):
Cuadro 3. Áreas de conocimiento
Área de conocimiento DescripciónGestión de la Integración Incluye procesos y actividades necesarias
para identificar, definir, combinar, unificar y coordina los distintos procesos y actividades.
Gestión de Alcance Incluye procesos para asegurarse que el proyecto incluya todo el trabajo requerido y nada más allá de eso.
Gestión de Tiempo Incluye los procesos para lograr la conclusión del proyecto a tiempo
Gestión de Costos Incluye los procesos de planificación, estimación, preparación de presupuesto y control de costos para lograr la conclusión del proyecto dentro del presupuesto
Gestión de Calidad Incluye todas las actividades de la organización ejecutante del proyecto que determinan las políticas, objetivos y responsabilidades relativos a la calidad, de modo que se satisfagan las necesidades con las que se emprendió.
Gestión de Recursos Humanos Incluye los procesos que organizan y dirigen el equipo de proyecto (personas con roles y responsabilidades).
Gestión de Comunicaciones Incluye los procesos necesarios para
22
asegurar la generación, recogida, distribución, almacenamiento, recuperación y destino final de la información del proyecto, en tiempo y forma
Gestión de Riesgos Incluye los procesos relacionados con la planificación de la gestión de riesgos, su identificación, análisis, respuesta, control y seguimiento.
Gestión de Adquisiciones Incluye los procesos para comprar o adquirir los productos o servicios necesarios (fuera del equipo de proyecto) para realizar el trabajo.
Cada área de conocimiento se compone de procesos. Estos se agrupan dentro
de los grupos y así es como se determinan las fases que componen al
proyecto.
Todos los proyectos requieren de los grupos de procesos. Sin embargo, no
todos requieren utilizar todas las áreas de conocimiento. Algunos pueden
omitir específicas áreas por su naturaleza. En el caso de la metodología para
crear los servicios SOA, se van a utilizar procesos principalmente de las
siguientes áreas de conocimiento:
• Alcance
• Tiempo
• Calidad
• Integración
Hay que considerar que también se consideran implícitamente otras áreas. El
Anexo 12.18 contiene un mapeo detallado entre las áreas de conocimiento y la
metodología. Acá se explica la relación que existe con las áreas más explicitas,
consideradas como parte del proceso.
23
2.3.4.Alcance
Los objetivos del área de conocimiento de alcance es asegurar que se incluya
todo el trabajo requerido y solo el trabajo requerido para terminar el proyecto
exitosamente (Chamoun, 2002).
Hay cinco procesos para la gestión de alcance de un proyecto (PMI, 2004).
Estos son:
• Planificación del alcance: Se crea un plan que indica cómo se define,
verifica y controla el alcance de un proyecto y la EDT (Estructura de
Desglose de Trabajo)
• Definición del alcance: Se desarrolla un enunciado de alcance detallado.
• Crear EDT: Se subdivide los principales entregables del proyecto en
componentes más pequeños y sencillos de manejar.
• Verificación de alcance: Se formaliza la aceptación de los productos
entregados.
• Control de alcance: Se controla los cambios al proyecto.
Hay principalmente dos productos de esta área de conocimiento que son los
más importantes para la metodología de creación de servicios SOA: el
enunciado de alcance y la EDT En el primer caso, el enunciado de la
metodología tiene el alcance del servicio, algo importante para definir el tamaño
del trabajo. En el caso de la EDT, la metodología tiene una definición de una
EDT con todo el listado de los componentes de software que componen el
servicio, agrupando lógicamente las tareas necesarias para obtenerlos.
Tradicionalmente, la EDT se ha considerado como la estructura medular del
proyecto, pues a partir de él se establece la estimación de costos, el
presupuesto, el cronograma, los roles y funciones, los riesgos, etc.
24
Una declaración de alcance que haya sido publicada no significa que no se
pueda cambiar. Como se sabe, en proyectos los cambios están a la orden del
día. Sin embargo, cuando se cambia el alcance de los entregables, hay que ser
claro en tener la autorización de todas las partes involucradas, pues es un
hecho que se afectará el tiempo y el costo que se tenían programados.
2.3.5.Tiempo
En cuanto al área de conocimiento de tiempo, es otra de las que se consideran
básicas y siempre está presente en un proyecto. De hecho, es tan básica que
siempre resulta ser el primer tema que recibe el impacto de cualquier evento
que suceda en un proyecto.
Su concepción a nivel de procesos es básica, pero no por eso menos
importante (PMI 2004):
• Definición de las actividades: Se identifican las actividades específicas
del cronograma que conducen a los productos entregables.
• Establecimiento de secuencia de actividades: Se identifican y
documentan las dependencias (precedencias) entre las actividades
identificadas.
• Estimación de recursos: Se estima el tipo y las cantidades de recursos
para cada actividad.
• Estimación de la duración de las actividades: Se estima la cantidad de
periodos laborales que se necesitan para cumplir con el 100% de cada
actividad.
• Desarrollo del cronograma: Se analiza la secuencia de las actividades, su
duración, los requisitos de recursos y las restricciones, para crear un mapa
en el tiempo de las actividades.
25
• Control del cronograma: Se controlan los cambios del cronograma del
proyecto.
En palabras sencillas, esto es definir las actividades, el orden que deben llevar,
los recursos que ocupa cada una y montar un cronograma con todo eso.
Para el caso de los servicios SOA, se requiere una especie de plantilla de
cronograma que pueda servir como punto de partida para ser utilizado en un
proyecto de elaboración de un servicio. Para esta plantilla, se utiliza la EDT,
que ya tiene las actividades con un orden preestablecido. Entonces, el
desarrollador debe preocuparse más por los recursos y duraciones y no tanto
por las tareas o su secuencia (claro, salvo casos particulares de cada servicio).
Esta plantilla de cronograma tendrá su propio Diagrama de Gantt, para que sea
más sencillo montar el cronograma del proyecto y darse una idea rápida de la
duración del mismo, para tomar decisiones sobre el tiempo lo antes posible.
Esto es posible porque como ya la base del proyecto viene preestablecida, la
ruta crítica se obtiene fácilmente.
Vale la pena recalcar que algunos servicios SOA son pequeños, en el sentido
que tienen pocas actividades y que no son complejas. Para estos casos,
algunos de los procesos se pueden tratar de manera combinada entre sí, pues
no se amerita una definición formal de las actividades.
2.3.6.Calidad
Un área de conocimiento que no siempre se tiene en cuenta, pero que acá en
la metodología es trascendental, es la de calidad. No es solamente un asunto
26
de metodología, sino que va más allá. Llega incluso a ser una filosofía
institucional del BCCR
Para una metodología, los aspectos de calidad deberían ser un punto
primordial, pues es una serie de pasos que se repetirán una y otra vez. Es
indispensable asegurar que se efectúen de la mejor manera posible.
El área de conocimiento de calidad tiene solamente tres procesos que la
componen (PMI 2004):
• Planificación de la calidad: Se identifican las normas de calidad que son
relevantes para el proyecto.
• Aseguramiento de la calidad: Se aplican las actividades planificadas y
sistemáticas relativas a la calidad, para asegurar que el proyecto utilice
todos los procesos necesarios para cumplir con los requisitos.
• Control de la calidad: Se supervisan los resultados específicos del
proyecto, para determinar si cumplen las normas relevantes y si se están
eliminando las causas de rendimiento insatisfactorio.
En el mundo del software, la calidad es un requisito básico. Hay un sinnúmero
de justificaciones para esto. Las más importantes son las facilidades de
mantenimiento y la homogeneidad en los estilos de diseño e implementación.
Muchas instituciones no acostumbran darle la importancia que se merece a la
calidad en los desarrollos que hacen, sino que solamente se interesan en el
tiempo y el costo.
La metodología de creación de servicios SOA tiene estándares y buenas
prácticas que deben ser seguidas cuando se trabaja en un servicio. Con esto,
se logra que los procesos se sincronicen lo más posible. Además, la
metodología tiene formularios para hacer auditorias de calidad para cada
entregable.
27
Como responsable final de la calidad del proyecto, se considera a los
encargados de verificación y pruebas. Ellos deben recabar los formularios de
documentación y pruebas para cada componente y procurar tener todo ese
material a mano.
2.3.7.Integración
Finalmente, está el área de conocimiento de integración. Estos procesos
procuran que todos los diferentes elementos del proyecto trabajen de manera
coordinada. Comprende principalmente tres áreas: el desarrollo del plan de
proyecto, el sistema de control de cambios y las lecciones aprendidas
(Chamoun, 2002).
Los procesos de esta área son los siguientes (PMI, 2004):
• Desarrollar el acta de constitución del proyecto: Se autoriza
formalmente un proyecto o una fase del mismo.
• Desarrollar el enunciado del alcance del proyecto: Se ofrece una
descripción del alcance a alto nivel.
• Desarrollar el plan de gestión de proyecto: Se documentan las acciones
necesarias para definir, preparar, integrar y coordinar todos los planes
subsidiarios en uno solo.
• Dirigir y gestionar la ejecución del proyecto: Se ejecuta el trabajo
definido en el plan de gestión de proyecto para lograr los requisitos.
• Supervisar y controlar el trabajo del proyecto: Se supervisan y controlan
los procesos requeridos para iniciar, planificar, ejecutar y cerrar un proyecto.
• Control integrado de cambios: Se revisan todas las solicitudes de cambio,
se aprueban y controlan los cambios a productos entregables y activos de
procesos.
28
• Cerrar proyecto: Se finalizan todas las actividades de manera formal, para
un proyecto o una fase.
La metodología de creación de servicios va a tener un plan de proyecto, a partir
de un machote. Ahí se detalla el problema a ser resuelto, el diseño propuesto y
una descripción de todos los componentes necesarios para cumplir con la
necesidad.
También una especificación de los pasos a seguir para construir el componente
y un resumen de los hitos principales del cronograma, para que el desarrollador
pueda guiarse en el horizonte de tiempo que tiene para cada actividad.
Otro aspecto importante que toma en cuenta la metodología es el proceso para
revisión de solicitudes de cambio a los productos, a través de un formulario
descrito en el Anexo 12.15. Este proceso de aplicar los cambios en sí ya es
mantenimiento de software y se sale del alcance de la metodología, pero lo que
si se incluye es el formulario para que se puedan solicitar y evaluar los
cambios.
También, al cierre del proyecto, la metodología contempla la documentación de
lecciones aprendidas, tanto buenas como malas, para crear conocimiento que
pueda ser útil en cada uno de los proyectos futuros que se vayan a iniciar.
2.3.8.Programas
Constantemente, se relacionan estrechamente los términos “proyecto” y
“programa”. A nivel teórico, existe una sutil diferencia entre ambos. Un
programa viene a ser una colección de proyectos relacionados hacia un
objetivo común (Thiry, 2002).
29
La administración de un programa es en realidad la administración de los
proyectos que lo componen. Evidentemente que la complejidad operacional
aumenta, pues hay que coordinar varios proyectos simultáneamente, pero los
principios se mantienen. La administración de programas suele ser llevada por
equipos multidisciplinarios de dirección.
El cuadro 4 define algunas de las diferencias principales entre un proyecto y
un programa:
Cuadro 4: Diferencias entre proyecto y programa (Thiry, 2002)
Proyecto ProgramaDuración fija Duración indeterminadaObjetivos predefinidos Objetivos negociadosEnfocado en tareas Enfocado en metasCiclo de vida de procesos Ciclo de vida de productos
2.3.9.Estructuras organizativas para proyectos
No todas las organizaciones tienen la misma predisposición para trabajar bajo
metodologías de proyectos. Factores como el tipo de negocio, la cultura de las
personas o la madurez de la empresa, afectan la buena gestión de los
procesos y las actividades.
El principal factor que tiene su efecto en el éxito o fracaso de los proyectos es
la estructura organizativa. Existen diversos tipos, algunos de los cuales se
prestan más para el desarrollo del trabajo por proyectos y otros en los que es
sumamente difícil lograrlo.
30
Los principales tipos de estructura organizativa que existen son los siguientes
(Vega, 2006):
• Organización tradicional: Las líneas de producción y organizaciones
burocráticas son de este tipo. Suelen tener gerencias, subgerencias,
departamentos y áreas. Desde el punto de vista de proyectos, tienden a ser
lentas y poco flexibles. No permiten el flujo horizontal de las actividades, tan
necesario en proyectos.
• Organización funcional: Es eficiente para diseñar y construir proyectos
que involucran una sola especialidad, pero cuando se mezclan ramas, se
puede volver difícil el manejo del proyecto. Por ejemplo, una compañía de
electricidad con una distribución jerárquica por Subestaciones,
Transmisiones, Distribución, Operaciones, etc.
• Organización por especialidad: Los especialistas comparten conocimiento
y experiencia técnica. Suele enfocarse hacia las operaciones internas de
cada departamento, no tanto a las relaciones externas y el trabajo en
proyectos. Los canales de comunicación tienen a ser verticales, lo cual
tampoco favorece el trabajo a nivel de proyectos. Es eficiente si tiene
proyectos cortos y pequeños.
• Organización matricial: Incrementan el valor de la coordinación. Los
especialistas se mantienen en sus departamentos acumulando experiencia
y conocimiento, mientras que al mismo tiempo se crea una estructura en
paralelo de proyectos responsable de la gestión. Nadie trabaja para nadie,
todos trabajan para el proyecto. El compromiso y respeto por parte de las
personas que componen la organización son básicos. Es el tipo de
organización preferido para gestión por proyectos.
La organización matricial no es algo nuevo. Organizaciones de este tipo existen
desde hace más de 30 años, en industrias tan variadas como la ingeniería
aeroespacial, investigación y desarrollo, mercadeo, finanzas, proveedores de
servicios de salud, etc.
31
Cuando vino la teoría de proyectos y su aplicación práctica, se notó que las
organizaciones de este tipo eran las que mejores resultados obtenían, en
buena medida superiores a instituciones burocráticas y rígidas. Investigaciones
posteriores revelaron las razones de estos resultados.
Básicamente, una organización matricial contiene la tradicional estructura
jerárquica vertical y además, una estructura horizontal paralela que sobrescribe
la vertical en los casos de los proyectos. Las islas funcionales (jerarquía
vertical) “prestan” a sus expertos a los proyectos (jerarquía horizontal) para que
estos últimos puedan formar equipos de trabajo comprometidos con un
proyecto (Ford & Randolph, 1992).
Bien llevada, esta sinergia de las organizaciones puede traer grandes
beneficios para la organización: reducción de costos, aumento de ventas,
aumento de clientes, mejora de procesos, etc. No siempre es un trabajo
sencillo, pero las organizaciones maduras saben que es un costo inicial que les
puede dar beneficios posteriores.
El desarrollo de este tipo de estructura organizacional persigue la fusión de las
principales ventajas de todos los otros modelos, toda vez que minimiza algunas
de las desventajas. Por un lado, en una estructura funcional pura, los expertos
se mantienen actualizados y con un nivel similar de conocimientos y uso de
herramientas. Sin embargo, se torna difícil la coordinación con otras áreas.
En una organización por especialidad (también conocida como “enfocada a
producto”), los expertos pueden perder rápidamente el hilo de sus áreas de
experticia, a la vez me mantienen altos niveles de comunicación y
coordinación.
32
Una organización matricial se puede considerar un punto intermedio entre
estos extremos. Busca lograr un balance que permita maximizar ventajas de
modelos y minimizar desventajas.
La madurez que tenga la organización es vital para la buena gestión de
proyectos.
2.4.Herramientas relacionadas
Por ser esta metodología un producto aplicado directamente al desarrollo de
software, es de esperar que exista una serie de herramientas preestablecidas
desarrolladas por terceros que se puedan aprovechar en alguna de las etapas
del desarrollo propuestas en este documento.
Por ejemplo, el VBCommenter es una herramienta de tipo utilitario desarrollada
por empresas asociadas a Microsoft, que permite estandarizar la
documentación interna del código fuente en aplicaciones de Visual Studio
.NET. Esta herramienta introduce etiquetas dentro del código y luego, por
medio de un proceso aparte, permite recolectar todo el texto de la
documentación para crear un solo archivo que se puede imprimir o publicar en
Internet. La gran ventaja de utilizar una aplicación que ayude en la
documentación interna de sistemas es que facilita mucho la estandarización de
los manuales técnicos que se construyan sobre el software.
Otra herramienta, también de Microsoft, que se puede utilizar para
complementar la metodología es el MS Sharepoint Portal Server. Esta
herramienta tiene la función de integrar información y contenido en un
repositorio único que se puede publicar para el libre acceso de un grupo de
trabajo. Esta herramienta es lo que se utilizaría para publicar esta metodología
y todos los productos que se deriven de ella, como por ejemplo las plantillas.
33
Finalmente, también se cuenta con herramientas que ayudan a obtener y
clasificar requerimientos. Por ejemplo, el Caso de uso. Un documento de
especificación de caso de uso no es más que un formulario por medio del cual
el analista programador y el usuario final de la aplicación logran llegar a un
acuerdo sobre cierta funcionalidad que debe ser desarrollada y como debe ser
desarrollada. Este documento puede ser entendido por ambas partes y
constituye un detalle del trabajo por desarrollar.
Los casos de uso son parte de una metodología de análisis y diseño de
componentes de software orientado a objetos llamado RUP (Rational Unified
Process), el cual es muy grande y complejo y se escapa del alcance de esta
metodología. Sin embargo, esta porción de la RUP se ajustaba a lo que se
requería en los servicios SOA, así que se adoptó.
34
3. MARCO METODOLÓGICO
3.1.Investigaciones comunes
A nivel general, muchas de las tareas necesarias para llevar a cabo este
proyecto, requieren en alguna medida de ejecutar acciones comunes, cada una
enfocada a su área de aplicación. El ejemplo más claro son las investigaciones
web, investigaciones bibliográficas y las revisiones de sistemas internas en la
organización. Si bien es cierto que se utilizan en varias tareas, todas guardan
similitudes desde el punto de vista del tratamiento metodológico que se les da.
En el caso de las investigaciones web, la idea es utilizar un navegador
consolidado como Internet Explorer y el motor de búsqueda Google, que es
uno de los más utilizados de los que existen actualmente. Además, ofrece
mucha información sobre todo lo que sea Microsoft. En cada uno de los temas,
se va a definir una lista de las palabras o frases clave que se van a utilizar
como tópicos de búsqueda. Se ingresan cada una de esas palabras o frases y
se revisan los primeros 10 ó 12 links que aparecen. Aquellos que contengan
información relevante para el tema estudiado, se imprimirán y se guardará el
link como “favorito”, para futuras referencias. Cada documento impreso se va a
revisar detalladamente, subrayando la información importante que puede ser
útil para la investigación.
Las investigaciones bibliográficas se harán sobre los libros y manuales técnicos
que posee el BCCR. La mayoría versa sobre herramientas y tecnología en
general de Microsoft. Suelen ser libros técnicos, pero sus contenidos se ajustan
a las distintas necesidades que tiene el proyecto: ejemplos de implementación,
estándares y buenas prácticas para guiar el proceso. Similar que con las
referencias web, se seleccionar los mejores capítulos o apartados y se
35
fotocopian para poder subrayar la información más relevante. Eventualmente,
podría ser necesario buscar bibliografía adicional o más especializada en los
temas de los casos de estudio, depende de la cantidad de datos obtenida.
Para las revisiones internas de la organización, se va a buscar a cada uno de
los 2 ingenieros informáticos encargados de los mantenimientos de sistemas,
para solicitarles información y documentación general sobre los mismos. Estos
sistemas no son creados bajo la concepción de SOA, sino que son más
rudimentarios, algunos incluso hechos con tecnología que ya está obsoleta. Se
va a estudiar la arquitectura, el diseño y el modo de operación. También, los
problemas que tenga actualmente a nivel de diseño y arquitectura. Con esta
información, se documenta una lista de oportunidades de mejora y se calza con
las características de SOA.
Paralelo a la tarea anterior, se efectúan al menos 2 entrevistas a los
encargados de los sistemas en lo que se refiere a mantenimiento de las
aplicaciones, para escuchar las sugerencias sobre mejoras a la metodología de
desarrollo que les permitiera hacer más eficiente y sencillo el mantenimiento,
dado que son ellos quienes mejor conocen las carencias técnicas de los
sistemas.
En los cuatro casos anteriores (investigación web, investigación bibliográfica,
revisión de sistemas y entrevistas a encargados de mantenimiento), toda la
información recabada se analiza desde el punto de vista del proyecto, creando
resúmenes de lo más importante y obteniendo los cuadros o gráficos que se
puedan utilizar como referencias en la metodología de SOA. Inicialmente, no se
busca información específica, sino más que todo de corte general, que ayude a
dimensionar el problema actual y la oportunidad de utilizar una metodología
como SOA.
36
Con esta información, se le dará contenido a las distintas tareas de la
metodología, creando conocimiento que permita desarrollar cada entregable
acorde con SOA y adaptado para el BCCR. La mayor parte de los estándares,
buenas prácticas o formularios de revisión de calidad van a ser elaborados con
información de estas fuentes primarias. Los métodos de investigación utilizados
hasta este punto serán, principalmente, el analítico-sintético y el de
observación por entrevista, aparte de la siempre presente investigación
documental.
3.2.Revisión de software
La revisión de sistemas construidos con SOA es distinta a las anteriores. La
idea es buscar en web no tanto documentación, sino fragmentos de código
fuente de componentes construidos con SOA, en distintos casos de aplicación.
Estos fragmentos se bajan y se utilizan como una especie de plantilla para
crear componentes base, que sirven como ejemplo a la hora de construir un
componente propio. En esta labor ayuda la información obtenida sobre mejores
prácticas y estándares de negocio, aparte de los mencionados ejemplos.
3.3.EDT y cronograma
Entre los objetivos específicos se tiene la identificación, secuenciación y
documentación de cada una de las distintas tareas que debe ser realizada para
la creación de un servicio SOA Evidentemente no todos los servicios son
iguales ni requieren lo mismo; pueden variar en complejidad, requerimientos o
funcionalidad. Sin embargo, la idea acá es montar una especie de EDT y
cronograma que sirva como base (plantilla) para hacer la planeación del
proceso de creación de uno de estos servicios. Claro que habrá cosas
específicas en cada caso, pero en general la mayoría de servicios comparten
las mismas tareas.
37
Entonces, se monta una lista de tareas genérica, con todo lo que es necesario
hacer para crear un servicio SOA. Estas tareas se ordenan cronológicamente
como deberían realizarse y se organizan en paquetes de trabajo afines. Esta
información se mantiene en un formato similar a una EDT, para que cada vez
que se va a iniciar un proyecto para crear un servicio SOA, la persona
encargada sepa que es lo mínimo que tiene que hacer.
Una vez que se tiene esta plantilla de EDT para el servicio SOA, se construye
también, a partir de esa información, otra plantilla para un cronograma de la
creación del servicio. En este cronograma se va a llevar el control del avance
del proyecto, los atrasos, desviaciones y problemas encontrados. Es
prácticamente la principal herramienta para la gestión del proyecto.
Con la EDT, ya se tienen las tareas organizadas por paquetes de trabajo,
entonces, en el cronograma el único trabajo pendiente es estimar los tiempos
que va a tomar cada actividad, verificar las precedencias y asignar los
recursos. Esto simplifica el trabajo, pues el esquema de cómo se organiza el
proyecto, ya viene dado.
3.4.Estándares
Otro objetivo consiste en investigar y proponer un estándar para el desarrollo
de los componentes y sus interfaces entre sí. Esta tarea es de suma
importancia porque si todos los desarrolladores utilizan un estilo de desarrollo
similar, se facilita el mantenimiento posterior de las aplicaciones, reduciendo
tiempo y costo empleado en estas labores. Las interfaces estándar son básicas
porque uno de los principios fundamentales de los servicios SOA es que se
puedan comunicar entre sí, para reutilizar funcionalidad.
38
Ambos estándares son tratados de manera igual metodológicamente hablando.
Con toda la información investigada, los sistemas revisados, las necesidades y
carencias identificadas y la teoría sobre servicios SOA, se procede a establecer
lineamientos generales para todas las actividades previamente identificadas. El
estándar cubre desde nomenclatura de componentes hasta especificaciones de
forma. Se utilizan ejemplos para ilustrar todos los lineamientos que se
especifican, pues así es más sencillo que se pueda entender efectivamente.
Estructuralmente, estos estándares se agrupan por paquetes de trabajo en el
proyecto. Por ejemplo, estándares para construcción de componentes de base
de datos, estándares para componentes de lógica, estándares para establecer
y aplicar pruebas, estándares para documentación, etc. Estos documentos
pueden ir evolucionando con el tiempo y también son la base para que se
puedan aplicar mecanismos de control de calidad que verifiquen que se están
cumpliendo.
A nivel de forma, estos estándares son solamente prosa. Sin embargo, la idea
es que haya herramientas para asegurar que se están aplicando
adecuadamente. También, dado el enfoque que se quiere dar al proceso de
creación de servicios SOA, es indispensable contar con mecanismos de control
a lo largo del proceso, para así asegurar que los pasos se han estado
efectuando de la forma en la que fueron planeados y que al final el producto
tendrá un mínimo aceptable de funcionalidad y calidad. Por esto, el objetivo de
definir los mecanismos de control es importante desde el punto de vista de
control y seguimiento del proyecto y la calidad esperada.
3.5.Control y seguimiento
En el caso del control del proyecto como tal, una vez definidas las fases (casi
una relación 1 a 1 con entregables en la EDT), se definen los flujos de trabajo
39
de las actividades y, a partir de esto, los hitos de control del proyecto.
Entonces, en cada uno de esos hitos se establece un procedimiento formal de
revisión con la idea de verificar que todo se haya efectuado como debería y
que todos los productos se tienen, con los estándares y calidad esperados. Al
final de cada fase, se procura que se tengan todos los insumos necesarios y
con el nivel esperado, para poder empezar la siguiente.
Para lograr este control, se utilizarán formularios tipo “check list” y con espacio
para comentarios por parte de la persona que realiza la revisión.
Con respecto a la calidad, en los hitos de control del proyecto, se va a utilizar
otro formulario que va a tener todos los aspectos referentes a los estándares
que deberían tener aplicados los componentes. Como parte de la misma
finalización de una fase, se verifica que el nivel de calidad esté en el mínimo
requerido.
En ambos casos, la información obtenida en estas revisiones, a través de los
formularios para cada caso, se documenta y se utiliza para llevar una bitácora
del proyecto. En dicha bitácora se registra lo bueno y también las
oportunidades de mejora, las fechas de las revisiones, hallazgos y
notificaciones. Son documentos de acceso público.
3.6.Documentación
También es un objetivo importante la documentación. Es común que la
documentación de sistemas de información en general sea escasa, incompleta
y no actualizada. Esto genera múltiples problemas como el no dar adecuado
mantenimiento, asignar trabajo a personas nuevas que no conocen las
aplicaciones o que los usuarios finales puedan disponer de ayuda para utilizar
las aplicaciones.
40
Al poner en los estándares el trabajo de documentación interna (dentro del
código de los componentes) y externa (manuales de usuario, guías de
instalación, diccionarios de datos), se obliga al hecho de documentar,
atenuando en gran parte los problemas acarreados por la casi perenne falta de
información en momentos que es tan necesaria. Nunca es recomendable una
documentación exhaustiva y menos que no la exista, pero sí es indispensable
lograr una identificación de los puntos clave que se necesitan documentar y
garantizar que se haga de la mejor manera.
La idea es investigar sobre herramientas tecnológicas como VbCommenter o
MS Sharepoint Portal Server que ayuden a documentar y publicar la
información. Antes de utilizar las herramientas, se debe revisar los estándares
actuales por medio de investigaciones Web. Alternativamente, se pueden
obtener en Internet algunos ejemplos que ilustren la forma en la que se debe
documentar. Estos documentos sirven como base para definir los
requerimientos necesarios de documentación interna y externa. Estos
requerimientos se detallan claramente y se relacionan con las posibilidades que
ofrecen las herramientas de apoyo. Con toda esta información, se puede
proceder a redactar el estándar para cada caso.
Es importante hacer notar que las revisiones de calidad van a tomar en cuenta
todos los aspectos de documentación que indique el estándar. En otras
palabras, se considerarán puntos a mejorar si la documentación no existe o si
está distinta a lo que diga el estándar.
3.7.Buenas prácticas para SOA
Este paradigma de SOA, por ser parte de adelantos tecnológicos en la industria
del software, no está “escrito en piedra”. Similarmente, las herramientas que se
41
utilizan para análisis, diseño, construcción, pruebas, documentación, control de
calidad, y otras, no se pueden considerar únicas ni las mejores. Siempre hay
posibilidad de mejorar todo aspecto, más con la competencia por adoptar
mercado de las grandes compañías comercializadoras de software.
Esto significa que se debe mantener un conjunto de buenas prácticas para
utilizar en las distintas etapas del proceso, sin que esto implique que no se
pueda cambiar esas prácticas cuando surjan mejores opciones. De la misma
manera es con las herramientas y estándares. Lo que se utilice hoy, no
necesariamente será lo mismo que se utilice mañana.
Este documento es como una especie de apéndice a la metodología. La
mayoría de las buenas prácticas han sido incorporadas como parte del
estándar, pero hay algunas otras que son más recomendaciones generales. El
estándar detalla más éstas últimas. La idea es realizar investigaciones web en
foros y en documentación recomendada por los impulsores de tecnología SOA.
3.8.Validación
Un paso indispensable para cualquier metodología es la validación de la
misma. Esto significa que parte del proceso de implantación requiere la
selección de proyectos piloto para utilizar esta metodología de la forma más
completa posible, y así obtener retroalimentación de casos reales de
aplicación, que permita ver si en realidad se está llenando la expectativa
esperada o si es necesario eliminar, agregar, actualizar o detallar más las
distintas etapas del proceso.
Una metodología no validada podría quedar solamente en el papel, sin llegar a
tener un verdadero impacto en la forma de hacer el trabajo en la organización.
Sin embargo, para esta metodología y por cuestiones de tiempo, es imposible
42
realizar la validación completa tal y como se describe en los párrafos
siguientes. Entonces, lo que se va a hacer es una validación parcial, acorde
con el tiempo disponible.
Una vez listo el documento de la metodología, se va a organizar una pequeña
reunión con los analistas/desarrolladores del departamento de implementación
(15 personas), para hacerles una presentación general sobre el objetivo y
características principales de la metodología. Posterior a esto se va a entregar
el documento a todos para que lo puedan leer detenidamente y se dará un par
de semanas para que puedan presentar las solicitudes de mejora o
aclaraciones. Se pretende aprovechar los juicios expertos de cada uno.
Todos estos comentarios se van a analizar y tener en cuenta para incorporar
mejoras que enriquecen al documento. Esta será la validación que se va a
efectuar. Los pasos de validación que por cuestiones de tiempo y oportunidad
se tendrán que dejar de lado son los explicados en los párrafos siguientes de
esta misma sección. Solamente se dejan planteados.
Una vez seleccionados los proyectos piloto que van a ser usados para probar
la metodología, se determina los hitos principales de esos servicios que
necesitan ser creados y se define un formulario para que se pueda hacer una
revisión, en cada etapa, de la forma en la que está siendo aplicada la
metodología. Dicho formulario se limita a aspectos meramente metodológicos,
o sea, no tiene que ver con la funcionalidad del servicio como tal sino con la
forma en que se está construyendo. Lo que se desea conocer es el nivel de
apego a la metodología y los aspectos que por una u otra razón no se están
utilizando o se utilizan distinto a como debería ser.
Como parte de esta validación, debe existir un conjunto de resultados mínimos
esperados para la aplicación de esta metodología en los proyectos piloto. De
no cumplirse con esos resultados, no se podría asegurar que la validación es
43
significativa. Estos resultados se indican en el mismo formulario de validación,
para identificar rápidamente las áreas más sensibles a problemas.
También es importante ir documentando, luego de cada revisión de validación,
los casos que puedan aportar conocimiento aprovechable en el futuro, tanto
para validaciones posteriores como para mejorar la metodología en sí. Cada
formulario de revisión tiene un espacio para comentarios generales sobre
retroalimentación que se puede aprovechar oportunamente.
44
4. PLANEACIÓN DEL PROYECTO
4.1.Tareas para crear un servicio SOA
Los servicios SOA son una evolución directa del esquema de capas de
aplicaciones, tradicional en los años 90. De hecho, los componentes de un
servicio SOA siguen siendo parte de alguna de las capas del modelo para
efectos de su diseño y construcción.
El modelo de capas (o N-Capas), presenta una arquitectura como en la figura
5:
Figura 5: Modelo de arquitectura de capas (Blázquez 2005)
45
Desde hace mucho tiempo, se viene escuchando de componentes de acceso a
datos, componentes de lógica de negocio o componentes de interfaz. SOA no
contradice estos principios, al contrario, aprovecha el conocimiento que ya
tienen diseñadores y programadores trabajando con esto, solamente que con
otra perspectiva del uso. La diferencia entre SOA y las aplicaciones por capas
radica en el uso que tienen los componentes, no en la naturaleza de los
mismos.
Entonces, para establecer un listado de las tareas necesarias para crear un
servicio SOA, se puede analizar en detalle la figura anterior y extraer de ahí los
componentes de software que son necesarios de desarrollar.
En primer lugar, los más importantes son los componentes de lógica de
negocio. Estos contienen el peso de todos los procesos, rutinas o
procedimientos que hacen las aplicaciones. Obtienen información, ya sea de un
repositorio de base de datos, de la interfaz de usuario o de otro componente y
procesan todo de acuerdo a reglas que establecen los expertos del negocio y
que los programadores llevan a líneas de código. Hace 10 ó 15 años, en
modelos de desarrollo obsoletos, estos componentes eran complejos y poco
entendibles. Con SOA, la idea es que sean más focalizados.
También están los componentes de acceso a datos. De lo que se tenía en
modelos hace unos 10 años a lo que se tiene ahora, se puede considerar que
estos son los que menos cambios han sufrido. Prácticamente se mantienen
igual a como fueron concebidos. Sus funciones principales son proveer a la
capa de lógica con datos para procesar y mantener actualizada la base de
datos. Algunos autores llaman también a estos componentes como
“componentes de recursos”, para hacer una definición más general de la fuente
de datos.
46
Un tipo de componentes que sí son más utilizados en SOA son las entidades
de negocio. Una entidad de negocio es una estructura de datos que mantiene
la información relevante para un objeto. Por ejemplo, una factura tiene un
número, un nombre, un monto, una razón social. Entonces, una entidad de
negocio “Factura” podría definirse con todas esas propiedades y otras tantas
como aplique en cada caso.
Otro tipo de componentes que se utiliza específicamente en SOA es el de la
interfaz de servicios. Estos deben proveer los medios para hacer que un
usuario u otro servicio puedan hacer uso de la funcionalidad especificada en la
lógica de negocio, sin dar detalles específicos de cómo esta ha sido
desarrollada. La función de esta capa es exponer la funcionalidad sin dar
detalles de la implementación.
Finalmente, los componentes de interfaz de usuario, que son los que permiten
a los usuarios interactuar con las aplicaciones. En SOA se mantienen en
algunos casos, pero por lo general se delega esta función a otras herramientas
informáticas. No es tan común que usuarios utilicen servicios, sino es más
común que otros servicios sean los “usuarios”. Este proceso se llama
orquestación de componentes.
Básicamente, estos son los principales tipos de componentes que se requieren
para crear un servicio SOA. Hay algunos otros que se utilizan en casos
específicos y otros que no aplican para el caso del BCCR.
Con todos estos tipos de componentes, se deduce que las tareas necesarias
para crear un servicio en realidad son tareas para crear esos componentes,
más otras adicionales que son parte de la metodología.
Esta metodología tomará en cuenta los componentes que se utilizan de manera
más generalizada en el desarrollo de sistemas del BCCR. Algunos
47
componentes no son parte de esto, por lo cual no se provee su uso a corto
plazo. Eventualmente, podría ampliarse la metodología para que fuera más
amplia y abarcara más áreas, pero de momento, para lo que es funcional, no
todo se está utilizando.
4.2.Secuenciación de tareas
Según la teoría de capas para desarrollo de software, existen dos formas de
llevar un proceso de creación de un servicio: top-down ó botton-up
(Oppenheimer, 2004). Esto aplica tanto para el diseño como para la
implementación de los componentes y ambos tipos tienen sus ventajas y
desventajas.
Para esta metodología, se va a utilizar una combinación de ambos en distintas
etapas del desarrollo. De esta forma, se aprovechan mejor las bondades de
cada uno.
Para el diseño del componente SOA, se va a utilizar la metodología top-down.
La idea es empezar a diseñar por lo más general, viendo componentes y
funcionalidad general, para que así se pueda delimitar bien el alcance que se
busca. Con esto, se logra que el servicio SOA cumpla más fácilmente con la
funcionalidad requerida y que pueda ser verificado en la etapa de diseño.
Posterior a esta etapa, se va a diseñando cada componente interno del servicio
más en detalle, así como las relaciones entre sí.
En lo que se refiere a construcción de los componentes, lo más recomendable
es empezar desde abajo, desde las capas inferiores, hacia las superiores
(bottom-up). Por ejemplo, empezar desarrollando los componentes de base de
datos (tablas, procedimientos almacenados, índices). Luego, se crean los
componentes de acceso a datos y estos se pueden probar porque los
componentes de las capas inferiores ya existen, y así sucesivamente. El criterio
que impera para el desarrollo es poder formular una prueba unitaria sobre los
48
componentes utilizando aquellos que se encuentran en capas inferiores. En la
medida en que se puedan entregar componentes de software ya probados, se
reduce el tiempo de mantenimiento y depuración posterior a su liberación.
Al igual que con la definición de tareas, su secuenciación en realidad consiste
en ordenar las tareas de acuerdo a un criterio para crear los componentes que
conforman cada capa. Lo importante de resaltar acá es que siempre deben ir
primero las tareas de diseño, luego las de construcción y por último, pruebas,
dentro de pequeños ciclos en cada capa. Otras tareas como documentación
están implícitas a lo largo de todo el proceso.
4.3.Organización por paquetes de trabajo
Existen casos en los cuales se cuenta con distintas personas para el desarrollo
de un solo servicio. No es lo usual, pero algunos servicios son tan grandes o la
premura de tiempo es tanta, que se vuelve necesario contar con varias
personas trabajando al mismo tiempo en distintos componentes de un mismo
servicio.
Esta situación algunas veces se torna problemática. Las herramientas de
control de la configuración ayudan un poco, pero no pueden evitar que muchas
veces dos personas lleguen a sobrescribirse mutuamente el código fuente, o
bien que alguno elimine código que ha sido incluido por el otro. También se
presenta el caso donde dos personas requieren modificar un mismo
componente en el mismo momento.
Lo recomendable en este caso, que será lo que se aplique al estándar de la
metodología, es que se creen paquetes de trabajo y que cada persona
asignada al proyecto trabaje en solamente uno de esos paquetes en un
momento específico del tiempo. Según las practicas más comunes, lo más
49
sencillo es que cada capa del modelo en la Figura 4 constituya un paquete de
trabajo que pueda asumir una persona.
Por lo general, las aplicaciones se trabajan por capa. La idea de utilizar SOA es
que las aplicaciones a gran escala se puedan estructurar a partir de una
colección de servicios SOA trabajando de manera coordinada. La estrategia
para crear esos servicios SOA también es abarcarlos por capas.
Según la secuenciación de tareas previamente expuesta, se debería
seleccionar los paquetes de inferior nivel en el modelo, para que las bases del
servicio vayan quedando primero, antes que su interfaz. De esta forma, 2 ó 3
personas podrían trabajar en un servicio sin interferir entre sí en el trabajo
porque cada uno se encarga de su paquete (o capa).
Un punto a destacar es que, la agrupación de tareas por paquetes de trabajo
es conveniente hacerlo siempre, no solo en los casos que sean varios
recursos. Aunque fuera uno solo el que va a desarrollar el servicio, esta
organización permite llevar un control y seguimiento más cercano pues cada
paquete al final se puede considerar un hito del proyecto. En caso de atraso, es
más sencillo asignar a alguien nuevo y que esa persona ingrese de una vez
con un nuevo paquete disponible.
4.4.Estructura de desglose de trabajo (EDT)
En el Anexo 12.2, se presenta una EDT completa de las tareas necesarias que
constituyen un proyecto de creación de un servicio SOA, para la DST (División
de Servicios Tecnológicos) del BCCR.
Acá se detalla el diccionario de EDT, agrupado por cada fase ó paquete de
trabajo.
50
En la fase de análisis, el diseñador y el usuario experto se reúnen para definir
la especificación del trabajo que es requerido. El usuario aporta las
necesidades y las pautas que deben ser seguidas, en caso que se requiera. El
analista debe tomar esa información y plasmarla en un “Documento de caso
de uso” como el que se encuentra en el Anexo 12.4. Este documento viene a
ser como una especie de contrato entre ambas partes, con el acuerdo del
trabajo que debe ser realizado. Las tareas de análisis son las siguientes:
• Especificación del caso de uso: El analista/diseñador elabora un
documento con la especificación técnica del servicio que se requiere. Se
detalla una descripción, precondiciones, pos condiciones, restricciones,
relación con otros componentes, alcance, etc. El usuario debe proveer los
lineamientos de negocio necesarios, en caso de ser requerido.
• Especificación de requerimientos funcionales: Una vez definida la
especificación del servicio, el analista/desarrollador debe enumerar un
listado de requerimientos funcionales mínimos que debe cumplir el servicio.
Durante la fase de diseño, el insumo principal es el documento de caso de uso
y los requerimientos funcionales. La idea es determinar, a nivel de
componentes de software, cuáles y cuántos son necesarios para implementar
el servicio SOA requerido, como se relacionan entre sí y como se va a probar el
servicio una vez desarrollado. Toda esta información queda registrada en un
documento de diseño para cada componente. Las tareas de esta fase son las
siguientes:
• Definición de capas necesarias: Un servicio SOA podría prescindir de
algunas de las capas del modelo de datos. Esto sucede sobretodo con las
capas superiores, como interfaz de usuario, que no siempre son necesarias
en todos los casos. En esta tarea se hace un análisis detallado de las capas
que aplican para el servicio en cuestión.
51
• Definición de componentes por capa: Para las capas que abarque el
servicio SOA, se determinan en cada una los componentes de software que
están en cada una. Se documenta la funcionalidad de cada componente, su
relación con otros, su alcance y cualquier particularidad, restricción o
característica importante que se deba resaltar.
• Definición de relaciones entre componentes: Una vez documentados
todos los componentes, se determinan las relaciones que existen entre
ellos. El fin de esto es verificar que todos los componentes especificados
están siendo parte que la solución que brinda el servicio. También
determinar la interacción vía mensajes de todos estos componentes, para
tener clara la arquitectura y el modo de operación del componente.
• Documento de diseño: Con toda la información de capas, componentes y
relaciones entre sí, se elabora un documento de diseño que explique
detalladamente todo esto. Los desarrolladores que trabajen en el servicio
tendrán como herramienta principal este documento de diseño. En el Anexo
12.5 se detalla el documento respectivo para el diseño. Este documento
siempre está abierto a mejoras.
• Documento de plan de pruebas general: Una vez especificado el
documento de diseño, se cuenta con información suficiente para planear
como se va a probar el servicio. Es recomendable especificar las pruebas a
este nivel para evitar sesgos posteriores asociados con la implementación.
El plan de pruebas en la etapa de diseño suele ser más objetivo y completo.
Esta especificación de pruebas es parte del documento de diseño.
• Revisión de calidad: Por medio de un formulario de revisión de diseño del
Anexo 12.6, se verifica al final de la fase que se haya cumplido con los
documentos necesarios y con el contenido de todos estos. Esto asegura
que los desarrolladores podrán contar con un documento completo y sólido
para entrar a la fase de implementación.
Como se indicó, para el desarrollo se va a utilizar una metodología bottom-up.
Esto significa que se empieza de la capa inferior hacia arriba, para facilitar las
52
pruebas unitarias de los componentes. El nivel inferior en todo modelo de
capas es la base de datos. Las tareas necesarias en este punto son las
siguientes:
• Diseño general de la base de datos: Se analiza la necesidad de datos del
servicio SOA y se hace un bosquejo general del modelo de datos que se
necesitaría para cumplir con la funcionalidad que se requiere. Es
recomendable utilizar alguna herramienta gráfica para entender mas
sencillamente cuales son las entidades de datos y sus relaciones. Por
ejemplo, está el Power Designer, herramienta que permite crear modelos de
manera gráfica y luego generar scripts con la definición de la base de datos.
• Definición de tablas: Una vez definido el alcance de la base de datos, se
procede a definir las tablas necesarias, con sus columnas, tipos, índices,
fórmulas y relaciones. Se hace un script para crear físicamente todos estos
objetos. Es importante apegarse al estándar de nomenclatura.
• Diccionario de datos: Con las tablas y todas sus columnas asociadas, se
documenta la funcionalidad de cada tabla y estas columnas. Esta
información queda en el documento de base de datos del Anexo 12.7.
• Construcción de procedimientos almacenados: Se crean scripts con
código de procedimientos almacenados para agregar, actualizar y eliminar
datos de las tablas. También para realizar funciones específicas sobre las
tablas como hacer listados de registros u obtener datos específicos.
También procedimientos que calculen fórmulas o que hagan algún
procesamiento previamente identificado como necesario en el servicio SOA.
Es importante apegarse al estándar de nomenclatura.
• Documentación interna: Para cada procedimiento almacenado, se
documenta internamente (en el script), con la información técnica más
importante que se requiere para entender que hace la rutina.
• Documento de base de datos: Con toda la información anterior se elabora
un documento de base de datos para el servicio, con toda la información
relevante a esta capa. Por ser la capa más básica, es también la que debe
53
ser más sólida, pues todo el componente descansa sobre ella. En el Anexo
12.7 se encuentra el documento que debe ser llenado. Este documento
puede tener cambios durante el proceso de desarrollo o mantenimiento,
siempre está abierto a mejoras.
• Elaboración de pruebas unitarias: Para cada procedimiento almacenado,
se crea un script de pruebas que le ingrese datos preestablecidos y espere
resultados específicos. Esto probará que el procedimiento almacenado
funciona como se espera y permite que cada vez que se le haga un cambio,
se pueda probar con este mismo script.
• Aplicación de pruebas unitarias: Se ejecutan todos los scripts de pruebas
y monitorean los resultados. Si las pruebas no son satisfactorias, entonces
se aplican cambios a los procedimientos almacenados.
• Revisión de calidad: Una vez llegado a este punto, se verifica que los
documentos estén completos y que existan todos los scripts requeridos. Se
utiliza un formulario para calidad de la base de datos del Anexo 12.8.
Cuando ya se tienen los objetos de base de datos identificados, construidos,
probados y documentados, la capa inmediatamente superior ya concierne a
software y es la de componentes de acceso a datos. Para mayor facilidad,
estos componentes se llamarán en lo sucesivo “DS” (“Data Service” ó Servicio
de Datos). Las tareas a este nivel son las siguientes:
• Diseño detallado del componente: Se detalla el diseño general que se
hizo en la fase de diseño del servicio, especificando los procesos que se
van a abarcar con la creación de este DS.
• Identificación de métodos: Se identifican todos los métodos (por lo
general públicos) que se van a implementar en el componente, cada uno
con su nombre, sus parámetros y sus valores de retorno. Además, una
descripción clara de lo que hace cada uno y como lo hace. Esta información
se registra en el “Documento de componentes de software” del Anexo 12.9.
54
• Validación de funcionalidad: Antes de iniciar la implementación, se toman
los requerimientos funcionales del documento “Caso de Uso” y se cotejan
contra los métodos que se tienen identificados, con el fin de determinar si
toda la funcionalidad requerida está dentro del alcance del DS. Es claro que
algunos requerimientos funcionales son más procesos de negocio y no
necesariamente mapean métodos en la capa de acceso a datos, sin
embargo, otros como mantenimientos de catálogos sí deberían tener sus
correspondencias a este nivel.
• Construcción del componente: Con el MS Visual Studio se construye el
componente DS con las clases y métodos especificadas en el diseño del
componente. Es indispensable adecuarse a los estándares de nomenclatura
y estilos de esta metodología.
• Documentación interna: Una vez terminados los componentes, se
documentan internamente de acuerdo al estándar.
• Documento de componentes (DS): Se completa el documento de
componentes del Anexo 12.9, con la información del diseño, métodos y
encabezados de la documentación interna.
• Elaboración de pruebas unitarias: Con el diseño y los componentes, se
elaboran los componentes de pruebas unitarias, acordes al estándar. Por
cada clase DS, se hace otra clase de pruebas que la certifique. Se puede
hacer uso de los procedimientos almacenados que ya fueron probados en la
capa de base de datos.
• Aplicación de pruebas unitarias: Se ejecutan las pruebas unitarias con
datos de prueba preestablecidos y se verifican los resultados obtenidos
versus los esperados. Se hacen correcciones en el componente de ser
necesario, hasta que se pueda obtener el resultado correcto.
• Revisión de calidad: Una vez llegado a este punto, se verifica que los
documentos estén completos y que existan todos los componentes
diseñados con los métodos indicados. Se utiliza un formulario para calidad
de componentes de software del Anexo 12.10.
55
El siguiente paso, luego de los componentes de acceso a datos son los
componentes de entidad de negocio. Se conocen como BE (“Business Entity” ó
Entidad de Negocio). En general, suelen ser pequeños y poco complejos, pues
se conforman principalmente de propiedades, no tanto de métodos, pero su
uso es de capital importancia en los servicios SOA. Las tareas para lograr esto
son las siguientes:
• Diseño detallado del componente: Se detallan los componentes de la
capa BE, el alcance de cada uno, sus interacciones entre sí y la interfaz que
van a mostrar para poder ser utilizados.
• Identificación de propiedades: Se detallan, para cada clase de SW, sus
propiedades internas y externas. Es importante tener en cuenta el estándar
de nomenclatura para las propiedades.
• Construcción del componente: Se construyen las clases de entidades de
negocio.
• Documentación interna: Se documentan internamente todas las
propiedades, como se utilizan, que parámetros reciben, etc.
• Documento de componentes (BE): Con el diseño de las entidades de
negocio, sus propiedades e interfaz de uso, se completa el documento de
componentes de software (BE) del Anexo 12.9.
• Revisión de calidad: Una vez finalizada la implementación y
documentación de las entidades de negocio, se hace la revisión de calidad
con el formulario del Anexo 12.10 para revisión de calidad.
Con el DS y BE listos y documentados, empieza la parte que siempre presenta
mayor complejidad y suele tomar más tiempo de todas: la creación de
componentes de lógica de negocio BS (“business service” ó Servicios de
negocio). Los procesos pesados del servicio SOA están en esta capa. Por lo
general, el mayor procesamiento de los volúmenes de información debe estar
muy bien diseñado para que la implementación de los componentes de BS sea
óptima. Entre más robustos sean los DS, BE y componentes de base de datos,
56
se facilita la implementación y pruebas del BS. Las tareas necesarias para
construir BS son estas:
• Diseño detallado del componente: Se detallan las clases que forman
parte del componente, su funcionalidad básica, su interacción con otras
clases y su interfaz para mensajes.
• Identificación de métodos: Se detallan los métodos, tanto públicos como
privados, que van a conformar cada una de las clases, así como los
parámetros y tipos en cada caso. Es importante seguir los estándares y
tratar de minimizar la cantidad de métodos utilizando mucho la sobrecarga
de funciones y el polimorfismo.
• Identificación de relaciones entre componentes: Cuando ya se tienen
los métodos en las clases, se determina como se relacionan unos con otros,
sobre todo en lo que se refiere al pase de parámetros o información de otro
tipo, entre componentes especializados, para optimizar el procesamiento
que va a realizar el servicio SOA.
• Validación de la funcionalidad: Cuando se identificaron las clases, sus
métodos y las relaciones entre sí, se validan los requerimientos funcionales
del “Documento de caso de uso” versus la funcionalidad que se planea
ofrezca el BS. En este caso, casi se debería mapear 100% los
requerimientos funcionales dentro del componente, como para dar por
aceptado el diseño del mismo.
• Construcción del componente: Cuando se validó la información de los
requerimientos funcionales, se procede a construir las clases y métodos, tal
y como se diseñaron.
• Documentación interna: Cuando ya se tienen los componentes, se
documentan internamente, tanto a nivel de método como a nivel de
encabezados y procesos. Hay que seguir el estándar de documentación.
• Documento de componentes: Una vez concluido todo lo anterior, se
registra todo el resultado del diseño y construcción en el documento de
componentes (Anexo 12.9).
57
• Elaboración de pruebas unitarias: Se procede a construir las clases de
pruebas que van a certificar que los componentes de lógica funcionan como
es debido de acuerdo a los requerimientos funcionales del servicio SOA.
Estos componentes de pruebas deben dejar al azar lo mínimo posible de
casos, no importa cuál sea la complejidad de construirlos o el tiempo que
tome. Se debe seguir el estándar de pruebas unitarias.
• Aplicación de pruebas unitarias: Se ejecutan los componentes de
pruebas para el BS, con datos preestablecidos y se comparan los
resultados obtenidos contra los esperados. Si hay diferencias, se ajustan los
componentes del BS hasta alcanzar los resultados esperados.
• Revisión de calidad: Una vez concluidos todos los procesos de diseño,
construcción, documentación y pruebas, se aplica el formulario de revisión
de calidad para componentes de software (Anexo 12.10), el cual certifica
que se ha contemplado todo lo necesario en el ciclo de vida del componente
de manera correcta.
Pasado el BS (al menos en su primera versión), sigue el componente que hace
que el BS pueda ser utilizado por otros servicios o por el servidor Biztalk: el
componente de interfaz de servicios (SI: Service Interface). Esta capa abstrae
toda la funcionalidad del BS, siendo el único canal de comunicación con toda la
lógica que ofrece el servicio. Las tareas en este caso son las siguientes:
• Identificación de relaciones: El primer paso es determinar que otros
servicios de software tendrán interacción con el actual y de qué manera se
va a dar esa relación.
• Diseño detallado del componente: Una vez determinado el alcance del
SI, se debe diseñar el componente, principalmente a nivel de métodos y
parámetros.
• Validación de la funcionalidad: Cuando se ha diseñado el componente,
se valida que la funcionalidad ofrecida soporte todo lo que se esperaba. Hay
que tener muy en cuenta que este es el punto de acceso a todo el servicio
58
SOA. Si no se toma en cuenta a este nivel alguna función ó método que
exponga funcionalidad, podría suceder que algunas piezas del servicio no
puedan ser utilizadas
• Construcción del componente: A este punto se puede construir el
componente, siguiendo los estándares de programación especificados.
• Documentación interna: Cuando ya se tienen los componentes, se
documentan internamente de acuerdo al estándar respectivo.
• Documentación de componentes (IS): Una vez finalizado el diseño, la
construcción y documentación interna, se registra la documentación externa
respectiva en el documento de componentes (Anexo 12.9).
• Revisión de calidad: A este punto, se aplica el formulario de revisión de
calidad del Anexo 12.10, para dar por terminado el IS (“Interface Service” ó
Interfaz de Servicios).
Finalmente, la fase de integración es la que toma todos los componentes
anteriormente generados y los prueba de manera integral dentro, dentro de un
ambiente controlado que semeja el ambiente real en el cual se va a utilizar el
servicio SOA. La idea es probar todo el conjunto en condiciones lo más reales
posibles: Las tareas en este caso son estas:
• Aplicación de plan de pruebas general: Estas pruebas fueron
especificadas en la fase de diseño. Acá se aplican para verificar que todo el
componente trabaja de manera íntegra como se espera. Se ingresan datos
de entrada preestablecidos y los resultados obtenidos se comparan con los
esperados. Hay que recordar que todos los componentes del servicio ya
debieron ser probados unitariamente, por lo cual no es de esperar que haya
errores muy básicos en el software.
• Documentar el proceso de integración: En el documento de integración
del Anexo 12.11, se registra el procedimiento para la integración de los
componentes dentro del servicio y a su vez la integración del servicio dentro
de la plataforma de software del BCCR.
59
• Documentar ayuda en línea del servicio: Se completa la información para
la ayuda en línea que va a tener el servicio SOA. Principalmente, se
detallan las funciones públicas del IS.
• Actualización de estándares: En caso de ser necesario, se actualiza algún
estándar que lo requiera. En cada implementación se puede encontrar
detalles que pueden ser incluidos para mejorar los procesos de la
metodología. Esto es parte del proceso de mejoramiento continuo.
• Actualización de buenas prácticas: En caso de ser necesario, se
actualiza la guía de buenas prácticas. En cada implementación, pueden
descubrirse detalles que contribuyen a hacer la guía más completa. Esto
también es parte del mejoramiento continuo.
Todas estas tareas, ejecutadas de manera completa y en orden, garantizan un
servicio SOA con la metodología de desarrollo para el BCCR. Existen casos
específicos donde se podrían eliminar algunos de los pasos, y otros donde más
bien es necesario incluir otras tareas no contempladas acá. Sin embargo, como
base y punto de partida, este grupo de tareas es el mínimo requerido para
contar con componentes de software sólidos y estándares, que faciliten el
desarrollo y mantenimiento.
Todas estas tareas se incluyen en un cronograma específico para cada servicio
SOA, que al final de cuentas es una herramienta básica que utilizan analistas,
desarrolladores y encargados de pruebas.
4.5.Cronograma
En el Anexo 12.3 se muestra el cronograma correspondiente a la metodología
para crear los servicios SOA propuestos. En su estructura, el cronograma es
bastante similar a la EDT, algo típico en los proyectos de corte informático.
60
La principal particularidad que tiene esta plantilla de cronograma es que
presenta ciclos que deben ser repetidos para tantos objetos como se vayan a
crear en cada proyecto específico. En estos casos, cada proyecto adecúa su
cronograma con la cantidad de ciclos que necesite.
61
5. ESTÁNDAR DE INTERFAZ E IMPLEMENTACIÓN
5.1.Componentes de software
Los componentes de software que aplican para esta metodología pueden ser
de dos tipos básicamente: componentes de base de datos o componentes de
aplicación. Ambos tipos se complementan entre sí para crear sólida
funcionalidad para las aplicaciones de servicios.
Los componentes de base de datos tienen una amplia gama de objetos
posibles de estructurar para trabajar de manera conjunta. Por ejemplo, la base
de todo es una tabla, conformada por columnas, tipos y restricciones. También
hay procedimientos almacenados, triggers, e índices.
Existen distintos motores de base de datos. Para el caso del BCCR, el estándar
es trabajar con tecnología Microsoft, por lo cual se busca que todas las
aplicaciones utilicen la versión más reciente del MS SQL Server. Las versiones
van evolucionando con el tiempo, actualmente la que se está utilizando es la
MS SQL Server Management Studio, también conocida como MS SQL Server
2005.
Los componentes de aplicación pueden ser desarrollados en muchas
herramientas de programación. Algunas son mejores que otras para los
distintos tipos de sistemas que se requieren u organizaciones que las utilizan.
Como se ha mencionado, dado que el BCCR se apoya principalmente en las
herramientas Microsoft, se ha establecido que se utilice MS Visual Studio 2005,
concretamente con el lenguaje Visual Basic.
Para efectos del estándar, los objetos de las distintas capas (DS, BS, BE, etc)
siguen reglas similares, pues todos son componentes de aplicación.
62
Los componentes de interfaz con un subconjunto de los componentes de
aplicación. Se crean con las mismas herramientas y aplican las mismas reglas,
pero tienen la particularidad de que deben ser diseñados para funcionar como
puente entre el servicio SOA en cuestión y el mundo externo donde este
servicio va a ser utilizado. Hay reglas específicas que deben ser claramente
detalladas para estos componentes, dada la importancia que tienen.
Tanto los componentes de base de datos como los de aplicación deben ser
adecuadamente documentados, tanto interna como externamente. En el
apartado de la EDT, hay tareas para documentar estos componentes, al igual
que en los formularios de revisión de calidad hay chequeos que indican si la
documentación está presente antes de dar por finalizado un trabajo.
5.2.Estándar de implementación
Empezando por los componentes de base de datos, los datos más básicos son
la definición de los acrónimos para sistemas y módulos.
En el caso de los sistemas, estos deben tener como mínimo 4 caracteres y
como máximo 6, conformados por solamente números y letras. Por ejemplo,
SDDE (Sistema de Divulgación de Datos Económicos) ó SINPE (Sistema
Nacional de Pagos Electrónicos). Deben ser únicos para toda la institución.
Los módulos siguen las mismas reglas, pero limitadas a 3 caracteres. Por
ejemplo, PBL (Publicaciones) ó ACS (Administración de Cuentas SINPE).
El nombre de la base de datos debe tener la siguiente sintaxis:
<Código del sistema>+”-”+<Tipo de la BD>+”-”+<Ambiente de la BD>
Los posibles tipos de bases de datos y ambientes aparecen en el cuadro 5:
63
Cuadro 5: Tipos y ambientes de bases de datos
Tipos de base de datos Ambiente de base de datosPRO: Producción DES: DesarrolloREP: Repositorio PRU: PruebasRPT: Reportes PRO: ProducciónAUD: AuditoríaHST: HistóricoDWH: DataWareHouseBIT: Bitácoras
Algunos ejemplos de nombres de base de datos pueden ser los siguientes:
• SINPE-PRO-PRO
• SDDE-REP-DES
• SINPE-DWH-PRU
Los roles para usuarios siguen esta sintaxis:
<Código de sistema>+”-”+<Código de Módulo>+”-”+<Descripción del rol>.
Por ejemplo: SINPE-AES-AdministradorSeguridad. En algunos casos, podría
ser que no exista un código de módulo asociado. En ese caso, se omite.
Uno de los tipos de objetos más importantes de la base de datos son las tablas.
Suelen ser las más utilizadas, pues contienen los datos y las restricciones
sobre estos. Para nombrar tablas, se utiliza el siguiente formato:
<Código de módulo>+”-”+<Nombre de la tabla>+”-”+<Tabla relacionada
(opc.l)>
En algunos casos, puede que el código de módulo no exista. Esto puede ocurrir
para sistemas pequeños, que no son separados en módulos. En estos casos,
se sustituye el código del módulo por el del sistema. El nombre de la tabla
siempre debe ser en singular y debe denotar el tipo de información que
64
mantiene. El dato de la tabla relacionada es opcional, solamente para tablas
que mantienen relaciones directas. Algunos ejemplos son:
• ACS-Encaje
• NBS-Entidad
• TFT-Transferencia-NBSEntidad
Todas las tablas deben siempre tener una llave primaria y tantas llaves
foráneas como sea requerido, sobre todo para las que son relaciones con otras
tablas.
Las tablas están conformadas por campos o columnas. Cada tabla puede tener
desde 1 hasta N columnas, cada una con un tipo y destinada a almacenar un
valor específico. La unión de todos esos valores conforma un registro y una
serie de registros da la información que mantiene la tabla.
Algunas columnas específicas de la tabla deben tener un prefijo para indicar su
tipo. Por ejemplo, las siguientes:
• Llaves primarias: deben llevar el prefijo “Cod”. Ej. CodCuenta. Por lo
general su tipo es integer o varchar.
• Identidades: deben llevar el prefijo “Id”. Ej. IdCuenta. Su tipo debe ser
identity, tipo propietario de SQLServer.
• Descripciones: deben llevar el prefijo “Des”. Ej. DesCuenta. Su tipo debe
ser varchar(60).
• Fechas: Deben llevar el prefijo “Fec”. Ej. FecCuenta. Su tipo debe ser
datetime.
• Montos: Deben llevar el prefijo “Mto”. Ej. MtoCuenta. Su tipo debe ser
money (en algunos sistemas se utiliza numeric ó decimal).
65
Los otros campos, no contemplados acá, pueden ser especificados de manera
descriptiva, sin mayor restricción más que evitar el uso de caracteres que no
sean letras ó números. Algunos ejemplos de campos pueden ser:
PrimerApellido, NombreCompleto, PorcentajeDescuento, etc.
Muy relacionados con tablas y columnas, están las llaves primarias y los
índices. Una llave primaria es el subconjunto de columnas que define, de
manera única, cada uno de los registros que están en cada tabla. Un índice es
un ordenamiento lógico de los registros de la tabla para poder hacer búsquedas
más eficientes.
La sintaxis para una llave primaria y para un índice son las siguientes,
respectivamente:
“PK-”+<Nombre de la tabla>+<Nombre de las columnas separadas por “-”>
“IX-”+<Nombre de la tabla>+<Nombre de las columnas separadas por “-”>.
Por ejemplo:
• PK-ACSCuenta-CodCuenta
• IX-ACSCuenta-CodCuenta
El otro gran conjunto de objetos de base de datos es el de los procedimientos
almacenados. Estas rutinas se encargan de ingresar, modificar, eliminar,
validar, sumarizar, mostrar, etc toda la información que se encuentra en la base
de datos. Algunos pueden ser sencillos, mientras que otros pueden ser grandes
y sumamente complejos.
La sintaxis para nombrar procedimientos almacenados es la siguiente:
“PA-”+<Código de Módulo>+”-”+<Acción>+”-”+<Descripción>.
66
Entre las posibles acciones están como principales: “Agregar”, “Actualizar”,
“Eliminar”, “Consultar”, “Listar”, “Procesar”. Podría haber más, dependiendo de
lo que se requiera hacer, la única restricción es que debe ser un verbo en
infinitivo. Algunos ejemplos son:
• PA-ACS-Agregar-CuentaSINPE
• PA-TFT-Listar-MovimientosConciliados
• PA-AVS-Procesar-CierreDiario
Los procedimientos almacenados reciben parámetros y opcionalmente
devuelven resultados. Las reglas de sintaxis para los parámetros aplican igual
que para la definición de las columnas internas de una tabla. Igualmente, las
variables que se utilicen dentro de cada procedimiento almacenado deben igual
regirse por este estándar.
Toda esta información de tablas, columnas, tipos, llaves y procedimientos
almacenados debe ser especificada gráficamente en un modelo Entidad-
Relación (ER) previo a la construcción. También deben ser documentados los
componentes con el diccionario de datos. Para referencias, se puede buscar el
anexo 12.7 de Plantilla de Base de datos.
En lo que se refiere a componentes de software, los objetos que se tienen son
clases, propiedades, variables y métodos. Para los distintos componentes de
las capas (DS, BS, BE), las reglas de estándar son similares pues todos se
trabajan con la misma herramienta de programación. Existen sus
particularidades en cada caso, pero mucho del estándar es el mismo para
todos.
Las clases que componen cada componente deben tener la siguiente sintaxis:
“c”+<Descripción de la clase>+<Iniciales de la capa a la que pertenece>. Por
ejemplo, cCuentasDS.
67
No importa si su tipo de acceso es público o privado, en ambos casos siguen el
mismo estándar. También es importante resaltar que cada una de las clases
debe ser ubicada físicamente en un archivo extensión vb de Visual Studio
separado.
El que una clase sea pública o privada depende de la capa en que se defina y
el uso para el que fue creada. Posteriormente se ahondará más en esto,
cuando se detallen las particularidades de los componentes.
Además, todas las clases deben tener activa la directiva de compilación
#Region, la cual permite agrupar funciones de acuerdo a un criterio. Esto no
afecta la funcionalidad, pero si el orden dentro del componente. Las regiones
que se deben definir y dentro de los cuales se debe poner cada uno de los
miembros son las siguientes:
• Variables internas
• Métodos o funciones públicos
• Métodos o funciones privados
• Métodos o funciones compartidos
• Interfaces
Las variables internas que se declaren dentro de las clases deben ser privadas
y solamente expuestas (las que deban serlo) a través de propiedades publicas
read/write. El estándar no contempla el uso de variables públicas dentro de las
clases.
Estas variables deben tener el prefijo “m” y sus nombres deben denotar los
tipos de datos, similar a como se nombran las columnas de las tablas en la
base de datos.
68
Las propiedades que exponen esas variables deben tener el mismo nombre
que la variable, excepto por la “m” del prefijo. Otras propiedades que hagan
validaciones u operaciones, solamente se les pone un nombre que sea
descriptivo.
Las variables y propiedades van principalmente en los componentes de entidad
de negocio (BE). Su uso es poco frecuente en BS y prácticamente no utilizado
en DS.
Un ejemplo de declaración de variable interna puede ser:
Private mCodCuenta As String,
La propiedad correspondiente a esta variable puede ser definida así:
Public Property CodCuenta() As String
Get
Return mCodCuenta
End Get
Set(ByVal Value As String)
mCodCuenta = Value
End Set
End Property
Otro componente de las clases, principalmente DS y BS, son los métodos o
funciones. La diferencia entre estos miembros de una clase (en Visual
Studio .NET definidos como “sub” y “function” respectivamente) es si se retorna
un valor resultado o no. Para efectos de este estándar, se recomienda
solamente utilizar funciones y que si no se tiene un valor que retornar, se
retorne un código 1 ó 0 para indicar si hubo un error o no.
69
Todas las funciones, sean públicas o privadas deben tener manejo
estructurado de errores. Esto es, bloques Try…Catch que permitan detectar
errores en tiempo de ejecución para tomar acciones al respecto. Un ejemplo de
un bloque sería así:
Try
<Implementación de la función>
Catch ex As Exception
<Manejo del error>
End Try
Una función debe tener un nombre que denote una acción. Esto se logra por
medio de un verbo en infinitivo. No existe una sintaxis específica para los
nombres de las funciones, solamente se debe procurar que sea bien
descriptivo. Algunos ejemplos de nombres de funciones son:
“ListarCuentasInversionista” ó “Actualizar”.
Todas las funciones tienen parámetros. Estos pueden ser de entrada,
entrada/salida o salida. El tipo de cada uno depende mucho de cómo se haga
la implementación de cada método. La única restricción en este caso es fijar
bien el tipo que se va a utilizar para no caer en excesos de definiciones que
provoquen “overhead”.
El estándar para la nomenclatura de los parámetros es el mismo que para
variables y que para columnas de una tabla. O sea, está muy relacionado con
su tipo. También, para los parámetros se utiliza el estándar “camelCase” para
mayúsculas y minúsculas.
Los siguientes son ejemplos de la definición de funciones en una clase, con
todo y sus parámetros:
70
• Public Function ListarCuentasInversionista (ByVal codEntidadPropietaria As
Short, ByVal codMoneda As Byte) As DataSet
• Public Function Actualizar (ByVal codCuenta As String, ByVal nomCuenta
As String, ByVal Justificacion As String, ByVal fecActivacion As Date, ByVal
Estado As Byte, ByVal estadoAdministracion As Integer) as Int
Las funciones pueden ser públicas, privadas ó compartidas. Los dos primeros
tipos de acceso son los más utilizados. Su uso depende de la capa en la que
se encuentre la clase a la que pertenece y también de la razón por la cual se
ha creado el método. Es similar al trato que se le da a las clases.
Específicamente, en lo que respecta al DS, el estándar recomienda crear dos
clases para cada uno de los componentes.
La primera de ellas debe ser privada (o sea, no se puede acceder desde fuera
del componente DS) y contiene la implementación de las funciones para el
mantenimiento y consulta de los datos.
Esto es, debe tener funciones para Agregar, Actualizar, Eliminar, Consultar y
Listar datos, todo directamente en la base de datos. La diferencia entre
Consultar y Listar radica en que Consultar retorna un solo registro, mientras
que Listar retorna muchos registros en un conjunto. Estos métodos son los que
proveen la implementación del componente.
Esta clase debe ser implementada con lenguaje LINQ (“.Net Language
Integrated Query” ó Lenguaje de Consultas Integradas para .NET) y sus
funciones deben ser declaradas como públicas para que se puedan utilizar
dentro del mismo componente. No se requiere la definición de variables
globales, propiedades ni funciones o métodos aparte de los especificados. Hay
que procurar que sea 100% pegada al diseño de la base de datos y a las tablas
que confirman el componente.
71
La segunda clase del DS debe ser pública. Esta clase debe tener una instancia
de la clase privada y sus métodos deben referenciar, en relación 1 a 1, a los de
la clase privada para que se pueda acceder a la funcionalidad del DS. Los
nombres de los métodos deben ser los mismos en ambas clases.
La implementación de estos métodos en la clase pública debe solamente
configurar los parámetros recibidos en formato de base de datos, y pasarlos
convertidos a la clase privada, quien realiza las funciones respectivas. La idea
es que esta clase pública del DS sirva como un puente entre la lógica de la
aplicación (BS) y el componente que hace las tareas de base de datos. Se
utiliza para que se haga una separación lógica entre la aplicación y la base de
datos (representada por la clase privada).
La aplicación solamente se comunica con la capa de acceso a datos (DS) a
través de las funciones de la clase pública.
Siempre relacionado con lo anterior, una vez construidas la clase pública y
privada del DS, el siguiente paso es crear una clase de pruebas unitarias, que
implemente una serie de pruebas sobre las funciones del DS. Esta clase debe
ser privada y debe contener al menos una función de prueba para cada uno de
los métodos de la clase pública.
Cada prueba es independiente de las otras. Esto significa que cada una de las
funciones de prueba puede ingresar directamente en la base de datos los datos
que necesite u obtener directamente los datos almacenados, con tal de validad
que las funciones de la clase pública estén cumpliendo con su función.
La idea con esta clase de pruebas es que se pueda estar ejecutando cada vez
que se hace algún cambio en el componente, para verificar que todo sigue
funcionando como se espera, antes de dar por finalizado el cambio o la mejora
72
en el componente. Tanto La clase como cada uno de los métodos deben
llamarse igual que en la clase pública, solamente que se les agregue el prefijo
“p”.
En lo que se refiere al BS, su estructura de clases puede ser un poco más
compleja. Como mínimo, se requieren 2 clases públicas: una para consultas de
la base de datos y la otra para el mantenimiento de información ahí mismo. La
idea es que una maneje transacciones y el otro solo haga consultas. La sintaxis
para los nombres debe ser, respectivamente:
“c”+<Descripción de la clase>+<Iniciales de la capa>
“c”+<Descripción de la clase>+<Iniciales de la capa>+”Tx”
Las funciones deben seguir el mismo estándar de nomenclatura que en el DS.
Igualmente con los parámetros, tipos de datos y manejo de errores. Sin
embargo, estas deben ser mucho más voluminosas en funcionalidad que las de
su capa inferior, pues llevan la implementación de todo lo que hace el servicio
SOA y la forma como lo hace.
Dada la complejidad de un BS, pueden existir tanto funciones públicas como
privadas en las clases. De hecho, puede incluso haber un número ilimitado de
clases privadas dentro del componente. Es importante hacer notar que el
componente debe mantenerse lo más específico posible para la funcionalidad
del servicio. La idea es que no crezca mucho, sino que se mantenga tan
pequeño como sea posible. Pero, eso no significa que se puedan tener tantas
clases como sea necesario, siempre y cuando se mantengan dentro del
contexto funcional.
Algunos conceptos como herencia de clases pueden ser muy útiles en el BS.
Se puede trabajar en base a clases madre que tengan funcionalidad básica y
clases heredadas que se especialicen en su funcionalidad. Es una buena
práctica de programación. También se puede utilizar la sobrecarga de
73
funciones. Esto es, utilizar el mismo nombre para distintas funciones que hacen
la misma actividad. Por ejemplo, una clase podría tener 3 funciones llamadas
agregar, que se diferenciarían entre sí por los parámetros.
Internamente, un BS puede tener tantas relaciones entre las clases como la
funcionalidad del componente lo requiera. Lo que no puede ocurrir, según a
teoría de programación orientada a objetos, es que estas clases accedan a
componentes de base de datos directamente, o bien a componentes de acceso
a datos que no sean el que pertenece a este componente. Tampoco pueden
instanciar directamente otro componente de otra capa superior, sino que
solamente puede interactuar con otras clases BS.
Al igual que en el DS, las pruebas unitarias se realizan a través de una clase
especializada en crear escenarios distintos para cada uno de las funciones
públicas de la clase de consulta y la clase de transacciones. Esta clase puede
utilizar directamente los métodos públicos de la capa de acceso a datos (la
capa inferior al DS).
Un ejemplo de clases ubicadas en su respectiva capa se muestra en la figura 6:
74
Figura 6: Ejemplo de clases y capas
5.3.Estándar de interfaz y organización de componentes
La interfaz es un punto clave en la arquitectura del componente. De su diseño y
organización depende que el componente sea tan accesible y útil como se
espera. Una interfaz debe proveer la mínima cantidad de funciones o métodos
que permitan la maximización del uso de un servicio.
En términos muy simples, una interfaz es una capa de software con clases
públicas y métodos públicos que son el único punto de acceso la capa de
reglas de negocio de un componente. Esta clase no tiene mayor código fuente
o funcionalidad más allá que servir de puente entre la lógica del BS
(prácticamente lo que le da vida al servicio) y un mundo exterior en el cual
puede haber múltiples aplicaciones, procesos u otros servicios necesitados de
la funcionalidad del servicio SOA.
75
Para empezar, es de esperar que cada método público del las clases de
consulta y transacciones del BS tenga un método correspondiente en la
interfaz, con su mismo nombre, sus mismos parámetros (en orden y tipo) y una
misma concepción para cualquiera que vaya a utilizar el servicio. Posterior a
esto, se puede tener alguna función adicional sobrecargada, que simplifique
algunos parámetros, que utiliza valores por defecto en algunos casos o que
haga llamados de tipo asincrónico al BS.
Para esta capa, la particularidad principal (y que le da sentido a su
diferenciación) es que debe ser definida como un servicio web ó webservice. Al
ser de este tipo, se garantiza que tiene implícita una gran gama de funciones
propietarias de .NET para facilitar la conexión del servicio con todo el que lo
necesite, a través de un protocolo de comunicación flexible y estándar.
Los webservice pueden ser instanciados prácticamente desde cualquier capa,
proceso, servicio o aplicación. De hecho, los estos servicios conforman una
capa implícita, que algunos autores llaman “agente de servicios” (Roch, 2006).
Si todos los servicios se pueden acceder a través de webservice, se garantiza
una alta disponibilidad de servicios en la capa superior al IS, que
potencialmente podría ser cualquier cosa.
Ligado a la interfaz, se debe especificar la arquitectura de archivos físicos de la
aplicación. Hasta este punto, los distintos componentes de software residen
juntos en un servidor de aplicaciones. Este servidor contiene los DS, BS, BE, IS
y está “cerca” del servidor de base de datos.
Cada una de las capas, al final de cuentas se va a mapear en un archivo
extensión DLL (“Dynamic Linking Library” ó Librería de Enlace Dinámico). Esto
va a simplificar la implementación de las aplicaciones y su posterior migración y
76
mantenimiento. Todos estos DLL se crean a partir de solucoines de Visual
Studio .NET, ligadas entre sí por medio de referencias.
Según este estándar, los nombres de estas soluciones (y que se extienden a
los DLL que se generan cuando se compila), se detallan en el cuadro 6 para el
servicio SOA llamado CuentaSINPE:
Cuadro 6: Nomenclatura para los DLL
Capa Nombre del DLLDS BCCR-<Descripción>DS.DLL
Ej. BCCR-CuentaSINPEDS.dllBS BCCR-<Descripción>BS.DLL
Ej. BCCR-CuentaSINPEBS.dllBE BCCR-<Descripción>BE.DLL
Ej. BCCR-CuentaSINPEBE.dllIS BCCR-<Descripción>WS.DLL
Ej. BCCR-CuentaSINPEWS.dll
Cada una de las soluciones debería poder ser desarrollada y compilada por
aparte. Evidentemente que cada capa se apoya en las inferiores para poder ser
desarrollada, pero en casos de mantenimiento, cada uno debería poder ser
tratado independientemente de los otros.
Cada solución debe contener dos proyectos. El principal contiene todos los
componentes (clases) antes descritas, así como las plantillas XML, paquetes,
módulos, reportes o bien cualquier otro objeto de Visual Studio necesario para
que funcione el componente en esa capa. El nombre de este proyecto debe ser
el mismo que el del servicio con el sufijo de la capa correspondiente.
El otro proyecto debe llamarse igual que el anterior, solamente que con el
prefijo “p” y debe agrupar las clases de prueba creadas para todos los
componentes.
77
5.4.Estándar de documentación interna
Para que un componente de software se pueda considerar completo, este debe
tener un cierto nivel de documentación interna, adicional al código fuente. Por
documentación interna se entiende una serie de comentarios en prosa que
clarifican la función del código fuente. Estos comentarios van incrustados en el
código fuente para que cualquier programador que tome un componente y vaya
a trabajar con él, pueda rápidamente leer estos comentarios y ubicarse dentro
del código para facilitar los cambios o la depuración.
Es importante hacer notar que la documentación descrita en este estándar no
es exhaustiva. Se trata de normar un mínimo de documentación, pero entre
más completa quede, es mayor la calidad del producto.
Empezando con los componentes de base de datos, la documentación interna
debe ser tanto para tablas como para procedimientos almacenados. Con las
tablas, el MS SQLServer Management Studio permite que cada tabla y cada
columna dentro de la tabla se les puedan agregar un comentario ó descripción
sobre su razón de ser. El estándar de documentación establece que todos
estos campos deben ser completados.
Los procedimientos almacenados son rutinas independientes que residen en el
servidor de base de datos. Su documentación consiste en:
• Una descripción del procedimiento: El procedimiento almacenado, en su
encabezado, lleva un comentario con el siguiente formato:
--
===========================================================
-- Autor: Juan Rodríguez Soto
78
-- Fecha/creación: 27/Abril/2006
-- Descripción: Genera los componentes del encaje para una
cuenta
--
===========================================================
• Una descripción de los parámetros: El encabezado del procedimiento
contiene los parámetros de entrada o salida. Entonces, el estándar indica
que cada parámetro se pone en una fila distinta y, a la derecha de cada
uno, se especifica una breve descripción. Por ejemplo:
CREATE PROCEDURE [dbo].[ACSCrearConceptos]
@CuentaSINPE VARCHAR(17), -- Código de la cuenta
@FechaInicial DATETIME, -- Fecha de inicio
@FechaFinal DATETIME, -- Fecha de finalización
@SaldoDisponible MONEY OUTPUT, -- Saldo disponible al momento
@MontoRetenido MONEY OUTPUT, -- Monto retenido al momento
@Error nvarchar(4000) OUTPUT -- Código del error resultante
AS
• Una descripción de los bloques de código más significativos: Aunque
un bloque de código documentable podría ser un concepto muy subjetivo,
hay algunas reglas básicas que podrían facilitar la tarea de poner
comentarios en el procedimiento almacenado. Por ejemplo, cuando se
declaran las variables al inicio del procedimiento, se puede poner un
comentario como:
-- ========================================================
-- DECLARACION DE VARIABLES --
-- ========================================================
79
Igualmente para los ciclos For o While, la invocación a otros SP o funciones de
base de datos, una secuencia de instrucciones que efectúen una tarea
específica, etc. Hay que recordar que entre más acertada sea la
documentación interna, mayor calidad tiene el producto final.
En lo referente a los componentes de software, las clases, sus métodos y
propiedades también deben tener su respectiva documentación interna. La
herramienta de desarrollo Visual Studio .NET también permite la inclusión de
comentarios dentro del código fuente, lo cual es muy útil porque como ya se
mencionó, permite guiar al programador dentro de los componentes.
Tanto para DS. BS, BE e IS, aplican las mismas reglas para documentar clases
y funciones. Cada clase debe tener en su encabezado, un bloque de
documentación así:
' --------------------------------------------------------------------------------------------------------
'Proyecto : BCCR-CuentaSINPEBS
'Clase : cCuentaSINPEBS
' --------------------------------------------------------------------------------------------------------
‘
'Resumen : Clase para la consultas de Cuentas SINPE
‘Autor : Luis Carlos García Mora
'Histórico
' Luis Carlos G.M. 18/Enero/2006 Creación
‘ Juan Rodríguez 29/Enero/2006 Método Agregar nuevo
' --------------------------------------------------------------------------------------------------------
Similarmente, cada uno de los métodos de todas las clases debe tener un
encabezado con la siguiente sintaxis:
' --------------------------------------------------------------------------------------------------------
'Propósito: Función que retorna la lista completa de cuentas SINPE del sistema
80
‘Autor: Luis Carlos G.M.
'Parámetros:
' CodCuenta: Código de la cuenta
‘ FecSaldo: Fecha solicitada para el saldo
' --------------------------------------------------------------------------------------------------------
Dentro de cada método, también es importante poner comentarios para cada
bloque de código o secuencia de instrucciones que efectúen alguna operación
específica. Algunos ejemplos de etiquetas de documentación para estos casos
pueden ser:
‘Declaración de variables
‘Ciclo que procesa transacciones
‘Se escribe en la bitácora del sistema el resultado de la operación
‘Invocación al método que totaliza el estado de cuenta.
81
6. MECANISMOS DE CONTROL PARA EL PROYECTO
6.1.Flujos de trabajo y roles
Internamente, la División de Servicios Tecnológicos del BCCR se compone de
diversas áreas, las cuales interactúan entre sí por medio de la coordinación de
recursos y tareas, para cumplir los objetivos de los proyectos.
Por ejemplo, relacionadas con esta metodología, existen áreas para
administración y manejo de bases de datos, pruebas, desarrollo y
mantenimiento. Igualmente, hay otras que no forman parte directamente del
alcance de la metodología, tales como la administración de hardware o
telecomunicaciones.
Las áreas cuyas tareas y recursos tienen relación directa con la creación de
servicios SOA son las siguientes:
• Análisis y Diseño: Esta área concentra a los analistas y diseñadores de
software. Estas personas son las que se comunican con los expertos del
negocio y obtienen de ellos los requerimientos. Luego transforman esa
información en pautas técnicas que se plasman en un diseño de
componente, que al final de cuentas es un insumo para otras áreas.
• Bases de datos: Esta área concentra los DBA (“DataBase Administrators”
ó Administradores de Base de Datos). Son las personas encargadas de
velar por el buen uso y la disponibilidad de los servidores de base de datos,
punto crítico en las aplicaciones de sistemas de información. Ellos crean los
script de base de datos, diseños de entidades, procedimientos almacenados
y pruebas unitarias a nivel de datos.
• Desarrollo: Esta área concentra a los programadores de Visual Studio
.NET. Según los requerimientos funcionales y tomando los diseños y
82
objetos de base de datos, crean los componentes de software (soluciones y
proyectos de Visual Studio) y los integran a las aplicaciones que los van a
utilizar. La fase de pruebas unitarias de las aplicaciones es un punto muy
importante de la etapa de desarrollo, pues integra mucho del trabajo de las
otras áreas. La fase de pruebas en el desarrollo debe ser la más exhaustiva
de todas.
• Verificación: Esta área concentra a los encargados de diseñar y aplicar las
pruebas para cada componente de software. La “bendición” de esta área
hacia un componente de software es indispensable a la hora de incorporarlo
a las aplicaciones del BCCR o ponerlo en producción. Dado que no existe
un área de aseguramiento de calidad propiamente dicha, las revisiones de
los procesos de calidad se asignan también a funcionarios de esta área.
Es notable que algunas de estas áreas tengan tareas que se asocian
directamente con etapas de la metodología. Esto implica que para realizar la
construcción de un servicio SOA, es probable que el equipo de proyecto esté
compuesto por una serie de personas provenientes de diversas de estas áreas.
Similarmente, hay otras consecuencias como por ejemplo que no todas las
personas ejecutan tareas al mismo tiempo (el encargado de pruebas no tiene
función asignada mientras se realiza el desarrollo) y que algunas veces, por
falta de recursos, hay tareas que podrían traslaparse de áreas (si no hay un
encargado de base de datos para construir lo procedimiento almacenados, es
probable que tenga que asumirlos el desarrollador).
En todo caso, lo importante acá es que se puede definir un flujo de trabajo
estándar para cada uno de los proyectos de creación de servicios SOA, que
permite llevar un orden en las tareas y gestionar recursos con mayor
oportunidad. Esto al final permite una administración más efectiva y una
programación más certera.
83
El flujo de trabajo propuesto se muestra en la figura 7:
Figura 7: Flujo de trabajo para crear un servicio SOA
Evidentemente, hay una relación muy cercana entre la especificación de tareas
de la EDT, el cronograma y el flujo de trabajo. Las tareas en cada caso están
estrechamente ligadas, esto hace más sencillo el entendimiento del objetivo
final.
Según este flujo, las distintas etapas se pueden asignar a distintos
responsables de las áreas anteriormente descritas, de forma que se coordine el
trabajo de la manera más conveniente para todos los involucrados.
Primeramente, existe una gran participación del analista/diseñador, quien es el
encargado del levantamiento de requerimientos y diseño general del servicio.
84
Una vez listo el diseño, el DBA inicia con la creación del script de base de
datos y los procedimientos almacenados. Por otro lado, el diseño es también
un insumo suficiente como para que el encargado de pruebas diseñe y
construya los escenarios para las pruebas globales del servicio.
Cuando el DBA ha concluido, el desarrollador inicia con la fase de construcción
de todos los componentes de software necesarios para cumplir con los
requerimientos.
Una vez finalizado todo lo anterior, se hace un chequeo de calidad por parte de
los encargados de pruebas para verificar que todas las fases anteriores hayan
cumplido con el compromiso de incorporar pruebas unitarias y registrar los
resultados obtenidos, así como de la aplicación de los formularios respectivos
en cada caso. Es muy importante hacer notar que cada persona encargada de
cada fase es responsable por la calidad de su trabajo, no es algo exclusivo de
la gente de pruebas. Para eso hay tareas en la EDT y en el cronograma que
deben ser ejecutadas en cada paso para garantizar que se están aplicando los
mecanismos correctos de aseguramiento y control de calidad.
Luego de esta revisión, se aplican las pruebas de integración especificadas por
los encargados de pruebas. Estas pruebas deben ser en ambientes
controlados y lo más parecidos a producción posible.
Finalmente, se documenta la base de conocimiento del proyecto con todas las
lecciones aprendidas sobre lo bueno y lo malo ocurrido. Esta tarea es exclusiva
del director del proyecto. El director de proyecto, evidentemente debe estar
presente en cada paso del mismo, supervisando, facilitando y controlando el
tiempo, el presupuesto y la calidad. El director de proyectos suele ser un
analista/diseñador o bien un desarrollador, pero lo importante es que tenga e
poder suficiente para controlar los recursos de las áreas que sea requerido.
85
Es normal que en ciertos momentos haya escasez de recursos. Tal vez un área
no cuenta con suficientes personas como para poder apoyar a algún proyecto
en el tiempo que es requerido. En esos casos, es válido que se haga un
traslape de funciones para no atrasar la marcha del proyecto. El ejemplo más
típico es que los desarrolladores tengan que asumir parte de la construcción de
procedimientos almacenados o del diseño de entidades porque no hay un DBA
disponible que lo pueda hacer.
Lo más importante de todo en esto de los flujos de trabajo de los proyectos es
que todos los involucrados entiendan que, aunque cada uno tiene sus tareas
de las cuales es particularmente responsable, todos son responsables de la
consecución de los objetivos del proyecto. Esto significa que aunque hayan
terminado sus tareas, igualmente deben prestar todo el apoyo que sea
requerido para mantener la buena marcha del proyecto.
Por ejemplo, los diseñadores deben estar siempre dispuestos a recibir
consultas y admitir mejoras por parte de los desarrolladores que trabajan con
sus diseños. Es normal que quieres utilicen un diseño para construir algo
puedan encontrar detalles que mejorar. Igualmente, los encargados de pruebas
deben contar con el apoyo de los desarrolladores en caso de que haya algunos
resultados distintos a los esperados, para revisar procedimientos o cambiar
programación debido a errores.
6.2.Hitos de control
Teniendo la EDT y un flujo de trabajo que especifica los roles de los
encargados y las tareas macro, la identificación de los hitos de control es una
tarea relativamente sencilla.
Por hito de control, se entiende un punto específico en el cronograma en el cual
se puede dar por concluida una etapa del proyecto y sobre la cual se puede
tomar una métrica o hacer una revisión de objetivos. Por lo general los hitos de
86
control se asocian a entregables o productos, aunque esto no necesariamente
siempre tiene que ser así.
El cuadro 7 especifica la lista de hitos para el proyecto de creación de un
servicio SOA:
Cuadro 7: Lista de hitos del proyecto
Hito DescripciónAnálisis del problema Se llega al hito cuando se tiene el documento
de Caso de Uso y se han listado los requerimientos funcionales.
Diseño general Se llega al hito cuando se ha especificado de manera completa el diseño del servicio SOA.
Componentes de BD (Base de datos)
Se llega al hito cuando se tiene el script que crea la base de datos (incluye tablas, columnas, procedimientos almacenados y pruebas unitarias). Incluye el formulario de revisión.
Construcción de DS Se llega al hito cuando se tienen los componentes de software del DS y sus pruebas unitarias. Incluye el formulario de revisión.
Construcción de BE Se llega al hito cuando se tienen los componentes de software del BE. Incluye el formulario de revisión.
Construcción de BS Se llega al hito cuando se tienen los componentes de software del BS y sus pruebas unitarias. Incluye el formulario de revisión.
Construcción de IS Se llega al hito cuando se tienen los componentes de software del IS. Incluye el formulario de revisión.
Diseño de pruebas Se llega al hito cuando se tiene la especificación de todas las pruebas de integración
Aplicación de pruebas Se llega al hito cuando se han aplicado todas las pruebas de integración y se han obtenido resultados satisfactorios.
Documentación final Se llega al hito cuando se han documentado lecciones aprendidas y otros resultados. Es la antesala del cierre del proyecto.
87
6.3.Mecanismos de control
Analizando los hitos del proyecto, se nota que prácticamente todos tienen un
formulario asociado (ver plantillas de anexos). Cada una de esas plantillas
debe ser elaborada en paralelo a la construcción de los artefactos (documentos
de diseño, script de base de datos, componentes de software). Algunas partes
de esas plantillas se completan al final de las pruebas unitarias aplicadas en
cada caso.
Entonces, como mecanismo de control primario, esta metodología propone la
presentación de la plantilla completa junto con los artefactos respectivos sobre
la finalización de cada una de las fases. Es responsabilidad del encargado de
cada fase la completitud y exactitud de los datos de la plantilla, así como del
director del proyecto la revisión de cada uno de los documentos y su
verificación contra los entregables.
Las plantillas de revisión de calidad son herramientas que asisten en estas
labores y deben ser completadas por el director del proyecto, o bien una
persona que este designe para que se pueda encargar de la calidad del
proyecto.
Todos los documentos deben ser modificados con control de versiones y deben
ser de acceso público para todos los integrantes del proyecto o bien otras
personas interesadas en obtener datos para proyectos futuros. Es importante
mantener estos documentos bien actualizados, pues constituyen la primera
referencia por parte de personal técnico que da mantenimiento o construye
nuevas aplicaciones.
88
Como segunda herramienta de control se propone efectuar reuniones
semanales entre el director del proyecto y los involucrados de las distintas
áreas que forman parte del equipo del proyecto. En el caso normal, a cada
reunión debe asistir un DBA del área de base de datos, un analista diseñador,
un encargado de pruebas y al menos un desarrollador que sería el que va a
trabajar en los componentes de software, además del director del proyecto (que
podría ser alguno de ellos).
Estas reuniones deben ser lo más ejecutivas posible. Algunos participantes que
hayan finalizado sus labores o bien que no hayan empezado, podrían
excusarse de algunas sesiones, aunque esto no constituye ninguna regla sino
que es un asunto de sentido común. En el Anexo 12.14 hay una plantilla para
las minutas de estas reuniones. Lo principal es registrar los acuerdos que se
tomen.
Cada participante debe haber actualizado el avance de las tareas antes de
llegar a esta reunión. La idea de esto es que el director del proyecto pueda
tener impreso el avance del proyecto actualizado al momento de la reunión,
para así poder analizar con todo el equipo las acciones a seguir en caso de
desviaciones de la línea base.
También se discute el trabajo para la semana siguiente y cualquier tema
administrativo que sea de interés para el proyecto. Es indispensable el tener
que hacer una minuta de la reunión. Por ser equipos de trabajo pequeños, se
puede mantener una comunicación oral muy abierta y activa entre todos los
miembros.
Dichas reuniones de seguimiento deberían tardar alrededor de media hora ó 45
minutos. Más de ese tiempo implica que no se está siendo lo puntual que
debería y solamente debería ocurrir en casos extraordinarios.
89
El tercer mecanismo de control es quizás el más simple de todos, pero a la vez
es el más importante. Consiste en que los involucrados registren en la
herramienta de control de proyectos las horas invertidas en las distintas tareas
del proyecto cada día.
Este reporte de tareas diarias debe ser hecho cada día, idealmente. Si esto no
fuera posible, al menos debe estar registrado para la reunión semanal.
Lo más difícil de esta tarea es crear la cultura en las personas de que invertir
10 minutos al día actualizando las tareas puede traer muchos beneficios al
seguimiento del proyecto.
El objetivo final de esto es disponer de una bitácora en la cual se pueda hacer
consultas por persona, por proyecto, por tarea o por periodo de tiempo, y así
maximizar el control en todos los niveles.
La idea es utilizar el Microsoft Project Server para esta labor de registro de
horas trabajadas en las distintas tareas y también para el seguimiento del
avance.
Finalmente, el cuarto mecanismo de control es responsabilidad directa del
director del proyecto, quien debe mantener una documentación escrita de todos
los eventos, situaciones ó imprevistos externos que beneficien o perjudiquen la
marcha del proyecto.
Por externos, se entiende que no son parte de tareas o actividades del
proyecto, pero que afectan de alguna forma al cronograma. Cosas como por
ejemplo una epidemia de gripe en el departamento, un curso fuera del BCCR o
un trabajo de mantenimiento prioritario pueden atrasar cronogramas y se debe
tener muy claro cuáles fueron los motivos por los que hubo que hacer ajustes
sobre lo que se ha planeado.
90
7. GUÍA DE BUENAS PRÁCTICAS
En esta metodología, las buenas prácticas para diseño ó desarrollo deben ser
suficientemente abiertas para permitir que las personas puedan tener un aporte
creativo amplio y provechoso para la plataforma tecnológica del BCCR.
Evidentemente, hay estándares que deben ser seguidos como un primer paso
hacia la consistencia y calidad de los artefactos, pero aparte de eso, no existen
tantas ataduras como para hacer que el trabajo se vuelva repetitivo o se aporte
poco a la mejora que debería dar la experiencia.
Para el análisis y diseño de las aplicaciones que dan vida a los servicios SOA,
algunas buenas prácticas pueden ser:
• Apoyarse en herramientas de diagramación para crear los modelos
conceptuales del servicio. Las capas, componentes y relaciones pueden ser
más fácilmente entendidas y desarrolladas a través de gráficos que con
solamente prosa.
• Mantener un registro de toda la información que proveen los usuarios
expertos del negocio. Esto puede ser documentos, formularios,
aclaraciones, comentarios, reglamentos, etc. Esta base de conocimiento
puede ser muy útil para eventuales consultas y como respaldo del trabajo
que efectúa el analista/diseñador.
• En el trabajo de análisis y diseño, es bien importante no asumir cosas sobre
el funcionamiento del negocio. Es preferible preguntar a los encargados del
negocio sobre todos los detalles del trabajo a realizar, antes que asumir
cosas que luego podrían desembocar en cambios costosos en etapas
posteriores.
91
• El principio de claridad y simplicidad a la hora de hacer un diseño es lo que
debería prevalecer. Entre más sencillo el diseño, más fácil es una correcta
interpretación por parte de todos los involucrados y más sencillo es el
proceso de desarrollo y mantenimiento.
• El analista/diseñador es el primero que debe estar atento a cambios que
puedan afectar su trabajo. El problema con el diseño es que cualquier
cambio afecta a todo lo demás, por lo que los cambios introducidos sobre la
marcha deben de ser encontrados y aplicados lo antes posible en la
construcción o pruebas. Otra buena práctica es prestar oídos a los eventos
o situaciones que puedan afectar al diseño.
A nivel de base de datos, algunas buenas prácticas podrían ser:
• En el MS SQL Server, completar la propiedad DESCRIPTION para cada
columna, de manera que sirva de documentación sobre su uso. Esto se
puede hacer desde el script que genera la estructura de la base de datos.
• Mantener siempre como dueño de los objetos al dbo.
• Mantener solamente un sistema en cada una de las bases de datos.
• Utilizar herramientas de diagramación para construir el modelo de entidades
y relaciones, ya que esto facilita el entendimiento del servicio y la definición
del alcance.
• Para sentencias SQL complejas, se recomienda revisar detenidamente el
plan de ejecución para encontrar formar de optimización.
• En sentencias de tipo “LIKE”, no utilizar el comodín “%” al principio de la
sentencia porque se elimina el uso de índices. Similar con el uso de
funciones (CAST, CONVERT, +, -, *, /, etc) sobre columnas de la clausula
“where”.
• Utilizar EXISTS() en vez de IN() para encontrar datos en un conjunto de
valores.
92
• Sustituir el uso común de cursores por tablas temporales u objetos tipo
tabla, que son mucho más eficientes.
• En general, completar toda la documentación de tablas y columnas, así
como de los encabezados de procedimientos almacenados.
Algunas de estas buenas prácticas son más importantes que otras. Hay las que
son solamente cuestiones de estilo mientras que otras sí afectan directamente
la eficiencia de la base de datos en momentos específicos. Lo importante es
siempre tenerlos en cuenta para que todos los programadores lo vayan
poniendo en práctica y así se vaya haciendo más común la aplicación.
Para los componentes de software de las aplicaciones, unas buenas prácticas
son:
• Procurar que todas las aplicaciones reciban como parámetro el nombre del
servidor, nombre de base de datos y otros parámetros de conexión. Esto
facilita las pruebas en distintos ambientes. Se puede utilizar el Registry de
la computadora o bien archivos de configuración.
• Procurar que las clases y su contenido se ajuste lo más posible al diseño
presentado. Esto facilitará los cambios posteriores y ofrecerá buena calidad
al producto final gracias a la consistencia.
• Las funciones de las clases deben mantenerse lo más simples posible.
Siempre es preferible declarar muchas funciones simples que unas pocas
muy complejas. Lo ideal es que cada función realice una sola tarea y se
apoye mucho en otras funciones para otras labores.
• Declarar como funciones públicas únicamente las estrictamente necesarias.
El resto debe ser privado al componente. Esto facilita la utilización de
interfaces entre componentes.
• Utilizar mucho la sobrecarga de funciones. Es una buena práctica que las
clases tengan nombres de métodos estándar, sobretodo en la interfaz
pública.
93
• Utilizar en todas las funciones el manejo estructurado de errores. Siempre
procurar que se retorne un código de error en caso de presentarse algún
problema durante la ejecución.
• Documentar internamente los bloques de código que tengan alguna
funcionalidad significativa. No significa comentar cada línea de código ni
tampoco poner solo un comentario para toda una función. Acá la
metodología apela al juicio de cada encargado, como para hacer que los
códigos fuentes sean claros y entendibles. Los comentarios deben ser
cortos y concisos. No deben entenderse más allá de lo estrictamente
necesario.
• Declarar variables locales en cada función en un solo bloque al inicio de la
misma. Nótese que el estándar de nomenclatura de estas variables debe
ser similar a las columnas de las tablas de la BD y a los parámetros. Solo
aquellas variables que cumplan una función muy importante deben ser
comentadas de manera particular.
Una buena práctica que casi siempre se deja de lado es la documentación
externa. En teoría, cada nuevo servicio SOA que se crea debería ser publicado
e integrado en la plataforma de aplicaciones del BCCR. Sin embargo,
frecuentemente se olvida que también debe ser integrado dentro de la
documentación de las aplicaciones.
El tener una documentación (en general) bien actualizada permite que tanto
personal técnico como usuarios finales sepan toda la información sobre los
sistemas, sus funciones y alcance. Pueden detectarse fácilmente carencias ó
vacios de funcionalidad y además permite un aprovechamiento pleno de todas
las aplicaciones.
Debido a que esto siempre ha sido un punto débil (no solo en el BCCR), esta
metodología incluye un pequeño formulario para documentación externa. El
conjunto de formularios de todos los servicios permitirán hacer un mapa de
94
aplicaciones que incluso puede ser publicado en una intranet, para uso
generalizado por los usuarios (información del negocio) y programadores
(información técnica).
También las buenas prácticas relacionadas con esta metodología pueden ser
mucho más generales. Por ejemplo, mantener siempre una investigación
constante sobre herramientas o procedimientos, que ayuden a mejorar o
complementar no solo la metodología, sino también el trabajo como tal.
Otra buena práctica es utilizar de manera adecuada todos los canales de
comunicación que existen dentro del proyecto. La comunicación oportuna entre
todos los involucrados es base para que los proyectos puedan llevar un buen
rumbo. Las carencias en este importante rubro suelen dar al traste con el
trabajo que se planea.
Actividades como respaldar diariamente los archivos sobre los que se trabaja,
comunicar con tiempo cuando hay atrasos en las tareas o notificar al director
del proyecto cuando un involucrado se ha quedado sin tareas asignadas, dan a
entender que las buenas prácticas en gestión de proyectos pueden ser tan
diversas como se requiera.
El objetivo debe ser procurar que todas las personas que colaboran de alguna
forma en un proyecto desarrollen una cultura de excelencia en todos los
campos posible. Claro que no todos los trabajos salen bien siempre ni todos
son fuertes en todas las áreas, pero dando lo mejor en cada oportunidad que
se tiene va a hacer que todo proyecto sea más productivo y de mayor calidad.
95
8. VALIDACIÓN DE LA METODOLOGÍA
8.1.Revisión primaria
Toda metodología, por su naturaleza, debería ser sometida a una revisión
previa antes de entrar en vigencia, por parte de las personas que van a tener
que aplicarla. Esto es una práctica muy sana porque permite que esas
personas conozcan de antemano la metodología y las implicaciones que tiene.
También ofrece un espacio para que todos los involucrados en proyectos
puedan hacer valiosos aportes que complementen los procedimientos.
La primera etapa de una revisión primaria es convocar a una reunión en la cual
se presenta la metodología a un grupo de analistas, diseñadores,
desarrolladores y encargados de pruebas de la DST. Sería preferible que
estuvieran todos, sin embargo, de antemano se sabe que es difícil por asuntos
laborales. La idea es reunir a unas 15 personas como mínimo, eso sí de las
diversas áreas, para posteriormente tomarlos en cuenta para el plan piloto.
Esta reunión puede tomar como máximo unas 4 horas y lo que se espera es
mostrar las plantillas de EDT, cronograma, descripción de las tareas, plantillas
de documentación y control y buenas prácticas. Igualmente, se describe como
se hará el proceso de validación y se atenderán todas las consultas de los
involucrados.
Posterior a esta sesión magistral, todos los productos de la metodología
(documentos, plantillas y cronogramas) se publicarán para que estos
involucrados los tengan disponibles y puedan revisarlo detenidamente. Esta
tarea no debería exceder 2 semanas. Todas las personas que hagan la revisión
pueden hacer llegar sus comentarios y sugerencias de mejora.
96
Es necesario hacer énfasis en que esta revisión de documentos se debe hacer
desde una perspectiva de los proyectos en los que cada persona está
trabajando. Esta es la mejor forma de analizar la metodología, tratando de
ubicarla dentro del contexto de lo que se hace actualmente o se ha hecho en
un pasado reciente en cuando a proyectos de desarrollo de componentes de
software.
La idea es tomar los aportes de todas las personas y analizar dentro de la
metodología esas ideas. Muchas pueden ser incluidas o bien pueden modificar
algo ya establecido. Otras podrían ser aportes para futuras versiones o bien
podrían ser incluidas a corto plazo.
Este paso también es bien importante porque involucra a todas las personas
que van a utilizar la metodología dentro del proceso de construcción,
permitiéndoles formar parte del proceso de maduración de esta herramienta y
haciendo que vayan interiorizándola de una vez.
Esta etapa de la validación se efectuó satisfactoriamente. Fue seleccionado un
grupo de funcionarios del la DST para explicarles en una sesión los principios
básicos de la metodología y además se les entregó los documentos (plantillas,
estándares, etc) para que procedieran a revisarlo y formular las observaciones.
El cuadro 8 muestra al grupo de funcionarios que colaboró en esta tarea:
Cuadro 8: Lista de funcionarios que validaron metodología
Funcionario LaboresMCI. Carlos Sánchez F. Ejecutivo a.i. del Área de Análisis y Diseño del
Departamento de Ingeniería de Software Institucional.
MCI. Yanina Barquero M. Analista programadora del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargada del Sistema de Reservas
97
Monetarias Internacionales.MCI Roneld Matamoros C. Analista programador del Área de
Implementación del Departamento de Ingeniería de Software Institucional. Encargado de dirección de varios proyectos.
Lic. Johnny Castro G. Analista programador del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargado del desarrollo de proyectos web.
Lic. Lorenzo Garita O. Analista programador del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargado de dirección de varios proyectos.
Lic. William Solís J. Analista programador del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargado de proyectos de desarrollo internos.
Entre los resultados de la revisión, hubo sugerencias y comentarios de todo
tipo. Desde aspectos de forma y estilo hasta cuestiones de fondo sobre el
rumbo que debería seguir el uso de las herramientas que software que asisten
en las labores que se hacen diariamente.
Ninguna de las sugerencias implicaba cambios complejos en la metodología.
En general, todas las personas sintieron cómodo el nivel de esfuerzo que
implica el trabajo con esta metodología y lo vieron como un buen punto de
partida para aplicar en proyectos de desarrollo. Todos están conscientes que
con la aplicación se pueden ir descubriendo mejoras que pueden
complementar los estándares y reglas.
Lo más rescatable de esta revisión que hicieron los funcionarios de la DST es
que ellos ya tienen plena consciencia de que este tipo de labores aportan
buenos resultados al trabajo que se hace todos los días. Gracias a esto, la
cultura para laborar con esquemas así se ve favorecida y facilita todo lo demás.
98
8.2.Aspectos a validar y resultados esperados
El primer paso para efectuar una validación completa es seleccionar el
proyecto (o proyectos) que van a servir como piloto para probar la metodología.
Lo ideal es que fueran un par de proyectos, no necesariamente concurrentes,
aunque por las cargas de trabajo de la DST, esto puede ser difícil de gestionar.
Es de esperar que solamente se pueda contar con 1 proyecto piloto.
Dicho proyecto debería ser corto. Esto significa que su alcance debería ser de
unos pocos meses para poder compilar los resultados y publicar la metodología
a un mediano plazo. No debería ser muy complejo para evitar que se extienda
mucho o que complique su finalización y no se pueda contar con la validación
completa. Otra característica del proyecto seleccionado es que debe contar con
todas las fases, para que la prueba sea integral. Esto significa que es preferible
que se construya todo desde 0. El proyecto piloto debe tener suficiente
trascendencia como para asegurar que no será pospuesto a medio camino,
sino que va a poder ser llevado hasta el final.
Existen varios objetivos importantes a la hora de validar la metodología. Sin
embargo, hay tres puntos clave que son claramente los criterios de éxito para
esta fase de validación y pruebas. Los aspectos claves a revisar durante esta
aplicación de la metodología piloto son los siguientes:
• Uso de plantillas de EDT y cronograma para planeamiento y control del
proyecto.
• Apego a estándares y buenas prácticas.
• Uso de plantillas para documentación y control.
La metodología es más específica, pero estos se pueden considerar las tres
grandes áreas sobre las cuales versa la mayor parte del trabajo. Poniendo
99
cuidado y atención a estas actividades macro, se cubre la parte más importante
de todo el proceso.
La plantilla de EDT debe ser adecuada al proyecto piloto para todas las
actividades de desarrollo de productos. Es importante recordar que algunas
partes de la EDT tal vez no apliquen en todos los proyectos o bien que algunos
por su naturaleza requieran más tareas o más entregables. Todos estos casos
son válidos, siempre y cuando se mantenga la estructura básica de la EDT.
Similar a la EDT, el cronograma debe ser ajustado al inicio del proyecto para
quedar consistente con el diseño de las tareas por ejecutar. Además, el
cronograma debe ser la primera fuente de información para el control del
proyecto, de ahí la importancia de reportar diariamente las horas invertidas en
las tareas y su análisis durante las reuniones de seguimiento.
La parte más compleja de verificar corresponde a los estándares y buenas
prácticas. Si bien no es algo difícil, puede tornarse laborioso por la naturaleza
tan minuciosa de las reglas que deben ser seguidas en el cumplimiento de la
metodología.
Para una revisión de estándares completa es necesario entrar al código fuente
de las aplicaciones (o bien procedimientos almacenados de base de datos) y
chequear que todos los lineamientos están siendo seguidos tal y como se
indica en este documento. Tanto para las personas que hacen el trabajo como
para aquellas que lo revisan, es sumamente difícil el poder verificar
absolutamente todas las reglas en todas las funciones de todas las clases. Sin
embargo, resulta ya de por sí provechoso el hecho de formular revisiones
generales y seleccionar casos específicos para ver detalles. Esta puede ser
una buena alternativa para no hacer el trabajo muy tedioso innecesariamente.
100
El punto más sencillo de revisar es la de las plantillas de documentación y
revisión de componentes. De antemano se conoce cuales documentos deben
ser presentados en cuales fases y así es más simple averiguar si hacen falta
algunos. Al igual que en los puntos anteriores, se debe revisar la completitud
de los documentos y su consistencia versus los productos entregados.
Ninguna metodología, por sencilla o concisa que sea, se puede interiorizar y
aplicar al 100% desde la primera vez que se ejecuta. Siempre hay un proceso
de asimilación por parte de las personas que van a trabajar con ella. Solo
practicando se puede lograr un buen resultado en una aplicación. Con el
tiempo, llegan a ser cosas muy naturales.
Esta metodología de creación de servicios SOA no es la excepción. Si bien es
cierto no es algo complejo, es de esperar que las primeras veces que se intente
utilizar en algún servicio SOA, se pueda presentar algún problema que no
permita lograr un 100% de apego. En particular, la validación de la metodología
por intermedio de un plan piloto es un proceso que no saldrá perfecto, sino que
se debe establecer un margen de error razonable para poder dar por exitosa la
validación. Es más, uno de los objetivos de la validación es justamente
encontrar algunos errores que ayuden a mejorar o complementar la
metodología, por lo cual se debe ser flexible la primera vez que se aplique el
contenido de este documento en un proyecto real.
Por ejemplo, es indiscutible que el proyecto piloto debe utilizar la plantilla para
la EDT y el cronograma. Esto es básico y cualquier proyecto que no cuente con
estos documentos, no puede ser bien administrado. Sin embargo, dado que la
plantilla de EDT puede sufrir ajustes específicos en el caso de cada aplicación
particular a un proyecto, se puede dar un pequeño margen a inconsistencias
entre la EDT y el cronograma, o bien entre el cronograma y las tareas reales
efectuadas. Igualmente, si el usuario de la metodología ubica tareas del
proyecto en ramas de la EDT donde no corresponde. Evidentemente, en un
101
proyecto real, esto no se debería presentar pero para efectos de este proyecto
piloto, se consideran situaciones que se pueden presentar por la falta de
familiaridad en el uso.
Para lo que son estándares de programación, tanto para procedimientos como
para componentes de software, la flexibilidad estará en el rubro de lo que se
quiere verificar. En las cosas más generales no habrá flexibilidad, sino
solamente en aquellas que son muy detallistas.
Por ejemplo, en aspectos como nombres de clases, nombres de funciones en
esas clases ó encabezados de documentación para estos (clases o métodos),
no se considera que puedan ser sujetos a desviaciones de la metodología. Son
los más sencillos de detectar y aplicar. De la misma forma, cosas como
ausencia de manejo estructurado de errores es algo no aceptable, ya que se
sabe que todo debe llevarlo.
Entre las posibilidades que pueden ser incorrectamente aplicadas de la
metodología, está por ejemplo la nomenclatura para variables y/o parámetros.
Podrían existir tipos de datos utilizados no contemplados en el estándar, o bien
algunos que tengan derivaciones (herencia) cuyo uso no fue contemplado en
el estándar. Igualmente, los comentarios de los bloques significativos de código
siempre será siempre un elemento muy subjetivo de hacer y verificar.
Con respecto a las buenas prácticas, dado que es tan distinto para cada
persona, lo mejor durante el proyecto piloto es atender más las cuestiones de
estilo y forma, dejando de lado lo que incida directamente en el contenido de
los productos.
Por ejemplo, es mucho más sencillo verificar que en el diseño del servicio SOA
se elaboró un diagrama del alcance del servicio (capas, clases y relaciones)
que ponerse a ver si en todos los procedimientos almacenados se utilizan o no
102
ciertas funciones ineficientes del motor de base de datos. Muchas de las
buenas prácticas sugeridas en esta metodología, o bien las que cambien o se
incluyan en un futuro, deberán ser asimiladas por medio de las aplicaciones
reales de la metodología.
Finalmente, queda como punto trascendental el uso de las plantillas, tanto para
diseño y documentación como para revisión.
Es inaceptable el obviar alguna plantilla durante el proyecto piloto. Todas
deben ser aplicadas en su fase respectiva (el proyecto piloto debe contar con
todas las fases de la metodología para un mejor aprovechamiento), de la
manera más consistente y completa posible. De hecho, es requisito para
finalizar una fase y comenzar la siguiente el tener las plantillas terminadas y
completas.
Lo que sí puede ocurrir es que algunas pruebas unitarias tal vez no se puedan
aplicar completamente o bien que no se cuenten con datos concretos como
para formularas, por lo cual estas partes de los documentos quedarían sin
llenar, pero por lo demás, las plantillas son un insumo importante para poder
dar por finalizado el proyecto como tal.
8.3.Mecanismos de validación y retroalimentación
Como se ha mencionado, el ejercicio de seleccionar al menos 1 proyecto piloto
para aplicar al 100% la metodología y obtener retroalimentación que ayude a
solidificar los lineamientos establecidos, es un proceso muy significativo para la
madurez del departamento.
Esta validación del proyecto piloto será un proceso muy constante y
meticuloso, con la idea de obtener la mayor cantidad de información posible. El
Anexo 12.12 presenta una plantilla para llenar con la validación de la
103
metodología en el servicio SOA. Esta plantilla es una especie de resumen de
todas las plantillas anteriores (tanto de documentación como de revisión).
El objetivo principal es que esta plantilla sirva como base para la revisión de
todas las etapas de la metodología y sus productos. Al cierre de cada fase del
proyecto piloto, luego de llenar las plantillas de revisión respectivas, se toma
esta otra plantilla para verificar que todos los productos se hayan hecho y sean
consistentes entre sí. Como mínimo, se debería hacer en cada fase del piloto,
nunca más allá de ese periodo para no perder oportunidad.
Esta plantilla se aplica solamente para proyectos piloto, no es requerida para
aplicaciones reales de la metodología a proyectos. Eventualmente, la Auditoría
Interna podría aprovecharla también para efectos de su trabajo.
Toda la información registrada es la retroalimentación que puede ser revisada y
compilada en acciones concretas que pueden ser incorporadas a la
metodología para mejorarla. Siempre la mejor forma de probar algo como esto
es aplicándolo y analizando los resultados para obtener datos bien
provechosos.
En el caso normal de operación, las plantillas de documentación son llenadas
por el mismo profesional que realiza el trabajo, ya sea analista, DBA o
programador. Además, la plantilla para revisión de cada fase, debería ser
llenada por un supervisor técnico o al menos el encargado de pruebas del
sistema. Sin embargo, de antemano se sabe por disponibilidad de recursos, el
mismo encargado de crear los artefactos tendrá que realizar la revisión de su
trabajo.
Para la revisión de la validación, es altamente importante que se asigne a un
encargado independientemente del proyecto y la metodología. Debe ser una
persona con amplios conocimientos técnicos de los procesos de desarrollo de
104
sistemas de software, y que además haya tenido suficiente tiempo de asimilar
la metodología. La razón de esto es que se puede aprovechar al máximo la
objetividad de una persona que no sea juez ni parte, sino que haga la
verificación lo más completa y que sus hallazgos no sean sesgados.
Incluso, si se pudiera tener 2 proyectos pilotos, esa persona se podría
mantener a lo largo de ellos para aprovechar la experiencia que va acumulando
en cada aplicación.
El anexo 12.16 muestra una propuesta de plan de implementación para esta
metodología. Este plan incluye aspectos como selección del piloto, del
personal y capacitación, ciclos de construcción de servicios SOA con la
metodología y análisis de resultados. Luego de esto, ya se puede considerar a
la metodología como apta para oficializarla.
105
9. CONCLUSIONES
• Para la implementación de un proyecto de este tipo, es indispensable el
contar con el apoyo de las altas esferas y las instancias con poder de
decisión. Esto es un reto particularmente difícil porque las instituciones
como el BCCR están sujetas a presupuestos muy limitados para actividades
como estas, lo que siempre lleva a escases de tiempo y recursos.
• Las tareas iniciales para crear un servicio SOA son bastante similares entre
sí, independientemente del sistema o negocio en el que se esté trabajando.
Las particularidades normales de cada caso empiezan a surgir conforme el
proyecto avanza, sobretodo en la parte compleja de la implementación. Esta
metodología se enfoca más en las tareas de planeación y en las etapas
iniciales del desarrollo, pero con eso busca sentar las bases para un
producto sólido. En las etapas posteriores a esto, es necesario ejercer el
correspondiente control y seguimiento.
• Con el tiempo y la evolución normal de la tecnología, la especificación de
los pasos para efectuar cada tarea pueden cambiar. Esto no significa que la
metodología esté incompleta ni que le falte información, sino que hay que
poner mucha atención a la tendencia de las nuevas herramientas que están
surgiendo constantemente, para descubrir su nueva funcionalidad y así
aplicarlo de la mejor forma a esta metodología, y por ende, a los sistemas y
aplicaciones del BCCR. Eventualmente podrían surgir nuevas tareas en
cierta área o bien algunas que se fusionen entre sí o bien que se eliminen
del todo. Esto es algo inherente a la tecnología, está en una constante
evolución y se debe mantener una constante revisión de todos los procesos.
• Estandarizar todo es imposible. Además, aunque se tratara de estandarizar
a un nivel muy minucioso, la aplicación de las reglas sería poco factible y
106
ágil, algo contrario a lo que espera de una metodología de desarrollo, pues
toma mucho tiempo y limita en mucho la creatividad de las personas. El
secreto está en encontrar el punto de equilibrio entre lo estándar y lo no
estándar, para así poder obtener el valor agregado de ambas partes.
Buscar estandarizar en las etapas iniciales del proyecto, para luego dar más
apertura es la estrategia propuesta en esta metodología.
• Es poco probable que todas las aplicaciones de una entidad, en este caso
el BCCR, se apeguen al mismo estándar. Algunos son sistemas legados
que fueron construidos con otras reglas y otras herramientas, mientras que
otros son comprados a terceros como “paquete” (o sea, no son
desarrollados en el BCCR), por lo cual no es esperable que se ajuste a este
estándar.
• Dado que para el desarrollo y mantenimiento de algunos sistemas el BCCR
subcontrata por outsourcing a empresas externas, es vital que esas
empresas se ajusten a estos estándares al igual que si fuera un desarrollo
interno por personal del BCCR.
• La calidad de las aplicaciones finales, para los usuarios de las áreas de
negocio, se verá afectada directamente de manera positiva. Las
herramientas de control de calidad propuestas van a tener una incidencia
muy positiva en los productos de software obtenidos, ya que los van a hacer
más íntegros, completos y robustos. Similar sucede con el control del
tiempo.
• En general, el enfoque de administración de proyectos dado al proceso de
creación de un servicio SOA encaja perfectamente en la naturaleza del
trabajo por realizar y la distribución de las tareas en el tiempo. El
complemento de las herramientas propuestas aporta mucha solidez en
107
todos los aspectos, lo cual redunda en mejoras en todos los niveles del
trabajo.
• En términos generales, una metodología como esta, conocida por todos y
aplicada de manera correcta, ayudará a facilitar los procesos de creación y
mantenimiento de sistemas, lo cual reducirá costos y mejorará la calidad del
soporte que se le da al negocio.
108
10.RECOMENDACIONES
• El trabajo de mantenimiento de sistemas es similar al desarrollo en algunas
características. Por ejemplo, cuando por mantenimiento hay que crear
nuevos componentes. Sin embargo, existe otra gran gama de tareas en
mantenimiento muy diversas y distintas a lo expuesto en este documento.
Es necesario establecer lineamientos paralelos a esta metodología para el
mantenimiento de sistemas.
• Mantener una constante investigación sobre nuevas herramientas y
técnicas de desarrollo de aplicaciones de software, sobre todo en lo
relacionado con el mundo Microsoft, para obtener información de primera
mano que pueda utilizarse para mejorar los procesos de construcción de
software en el BCCR.
• Como complemento a este estándar, debe ser analizado y promulgado un
estándar para la construcción de interfaces de usuario. Este estándar debe
considerar el diseño y características de pantallas de windows, formularios
web y reportes, para lograr homogeneidad en todos los sistemas, para
facilitar el uso por parte de los usuarios.
• Parte importante del diseño de aplicaciones es la seguridad. Paralelo a este
estándar se deben establecer reglas para incorporar esquemas de
autorización, autenticación, permisos, roles y privilegios para componentes
y aplicaciones.
• Esta metodología no considera aspectos de auditoría de sistemas.
Eventualmente, puede ser conveniente coordinar con los auditores de
sistemas computacionales para ver las necesidades que ellos tienen en su
109
trabajo y considerar cualquier actualización que pueda tener esta guía para
facilitarles la labor.
• En la práctica, una metodología como esta nunca se termina de aplicar.
Más bien, es un proceso cíclico de mejora continua. Esto se presenta por la
naturaleza del desarrollo de software. Debe haber un esfuerzo general por
mantener actualizados todos los tópicos que conforman esta metodología.
• Los mecanismos de control propuestos (y los nuevos que se establezcan en
un futuro) deben ser vistos como herramientas para mejorar el trabajo. Es
claro que esto implica un cambio cultural entre las personas, pero es un
paso necesario que dar. Durante mucho tiempo ha sido común que se
llenen plantillas y nunca se aprovecha en nada la información ahí contenida.
Por lo general, suelen ser documentos poco actualizados y que no aportan
mucho conocimiento. La idea es cambiar esto.
• La documentación no debe ser solamente escribir hojas y hojas por
llenarlas. Similar al nivel de estandarización a aplicar, es vital encontrar el
punto exacto de tal manera que la información sea útil y que su elaboración
y administración sea ágil.
110
11.BIBLIOGRAFÍA
Arsanjani, A. (2004). Service-oriented modeling and architecture. IBM Corporation. Extraído el 21 Octubre, 2007 de http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/
Blázquez, M. (2005). La arquitectura N-Tier: Activo fundamental para el diseño de sistemas de información avanzados. Extraído el 19 Noviembre, 2007 de http://sirmijail.blogspot.com/2005/07/la-arquitectura-n-tier-i-activo.html
Banco Central de Costa Rica. (2007). (Página WEB principal). San José, Costa Rica. Extraído el 16 Octubre, 2007 de http://www.bccr.fi.cr/.
Chamoun, Y. (2002). Administración profesional de proyectos. Una guía práctica para programar el éxito de sus proyectos. México: McGraw Hill Interamericana.
Costa Rica, Asamblea Legislativa. (1950). Ley 1130. San José, Costa Rica
Eiipe, F. (2007) Asses and improve the capabilities of an organization for managing projects, programs and portfolios to achieve its strategic goals. Explanation of OPM3 of PMI. Extraído el 28 Octubre, 2007 de http://www.12manage.com/methods_pmi_opm3.html.
Ford, R. C. & Randolph, A. (1992) Cross-functional structures: a review and integration of matrix organization and project management. Journal of Management, June.
Gido, J. & Clements, J. (2003). Administración exitosa de proyectos. México: Internacional Thompson Editores S.A. Segunda edición.
Lublinsky, B. (2007) Defining SOA as an architectural style. Extraído el 21 Octubre, 2007 de http://www.ibm.com/developerworks/library/ar-soastyle/index.html.
Oppenheimer, P. (2004). Top-down network design. España: Cisco Systems. Segunda Edición.
Pijanowsky, K. (2007). Visibility and Control in a Service-Oriented Architecture. Microsoft Corporation. Extraído el 16 Noviembre, 2007 de http://msdn2.microsoft.com/en-us/architecture/bb507204.aspx
Project Management Institute. (2004). Guía de los fundamentos de la dirección de proyectos PMBok Guide. Pennsylvannia, Estados Unidos.
111
Roch, E. (2006). SOA Design. Extraído el 20 Octubre, 2007 de http://blogs.ittoolbox.com/eai/business/archives/services-uml-uses-cases-for-soa-8980.
Shaw, M. & Garland, D. (1996). Software Architechture: Perspectives on a emerging discipline: A classical description of software architecture. Estados Unidos: Prentice-Hall.
Thiry, M. (2002). Project Management Pathways. United Kingdom: Association for Project Management.
Trowbridge, D. Mancini, D. Quick, D. Gregor, H. Newkirk, J. Lavigne, D. (2003) Enterprise solution patterns using Microsoft. NET. Estados Unidos: Microsoft Corporation.
Vega, O. (2006). Tipos de organizaciones. Ponencia presentada en el curso Introducción a la Administración de Proyectos. Universidad para la Cooperación Internacional. San José, Costa Rica.
112
12.ANEXOS
113
12.1.Charter del proyecto
ACTA (CHARTER) DEL PROYECTO
Información principal y autorización de proyecto
Fecha:9 de Octubre de 2007
Nombre de Proyecto:
Metodología para la creación de servicios SOA en la División de Servicios Tecnológicos del Banco Central de Costa Rica
Áreas de conocimiento / procesos:
Alcance, Tiempo y Calidad. Implícitamente está Integración
Área de aplicación (sector / actividad):
Sistemas de software bancarios (Banca y Finanzas)Sistemas de información
Fecha de inicio del proyecto:
8 de Octubre de 2007
Fecha tentativa de finalización del proyecto:
31 de Marzo de 2008
Objetivos del proyecto (general y específicos):
General:Dotar a la División de Servicios Tecnológicos del Banco Central de Costa Rica de una metodología que le permita crear de manera eficiente y estandarizada los servicios SOA que serán la base para construir una plataforma de software robusto y flexible
Específicos:• Identificar las tareas básicas que se requieren en un proceso de creación de un servicio SOA y la
forma en la que cada tarea debe ser efectuada, para delimitar el alcance de cada producto.• Estandarizar las interfaces e implementaciones de los servicios para todas las aplicaciones nuevas que
se solicitan por parte del negocio, para mantener uniformidad en los componentes que faciliten el entender su uso y el trabajo de mantenimiento.
• Definir los mecanismos de control que van a permitir concluir exitosamente cada uno de los servicios que se construyan bajo esta metodología.
• Definir la documentación interna y externa que va a cumplir cada uno de los servicios para contribuir con la calidad del producto y facilitar la consulta y reutilización de la funcionalidad.
• Definir un conjunto de buenas prácticas que aplique para el proceso de diseño y construcción de los servicios, a lo largo de todo el ciclo, para facilitar el mantenimiento posterior.
• Validar parcialmente la metodología, haciendo como mínimo una revisión del documento con los compañeros de las áreas involucradas en proyectos de este tipo, para verificar la aplicabilidad de la guía.
Descripción del producto y entregables (relacionados con el objetivo general y específicos respectivamente):
El producto final de este proyecto es un documento con una metodología que ayude en el desarrollo de servicios SOA. Dicha metodología debe detallar las tareas básicas que se requieren para crear un servicio y la forma en la que debe ser desarrollada cada una (ligados por lineamientos estándar). Además, debe especificar una plantilla con el cronograma estándar para cada desarrollo y todas las herramientas para el control de las actividades y el seguimiento de calidad. También debe de apoyarse en plantillas que favorezcan el seguimiento de las tareas de control y las labores de los distintos involucrados.Los entregables son una plantilla de EDT, junto con un cronograma ligado a esta plantilla, con la
114
definición y secuencia de las tareas estándar para crear un servicio. La idea de este documento es que sea base cuando se empiece un proyecto de creación de un servicio. Además, un documento con el estándar para desarrollar componentes y sus interfaces, tanto a nivel de estilo, componentes, nomenclatura, herramientas y cualquier otro aspecto técnico.También, un entregable consiste en un listado de plantillas que documenten el control y seguimiento del proyecto, sobre todo en los hitos más importantes, para garantizar un desempeño adecuado. Similarmente, se proveerá un documento con el estándar de la documentación necesaria, tanto técnica como de usuario final. Otro entregable es un listado inicial de las buenas prácticas de diseño y programación que se deben aplicar en cada paso del proceso. Es entendible que un documento de este tipo varía constantemente, pues la tecnología mejora rápidamente. La idea es que sea un planteamiento inicial que vaya evolucionando.Finalmente, el último entregable es un formulario que recolecta información sobre la aplicación de la metodología a proyectos piloto. De este formulario se puede obtener importante retroalimentación que valida la metodología y permite que se pueda mejorar antes de su publicación oficial.
Necesidad del proyecto (lo que da origen):
La necesidad principal está ligada al avance tecnológico que toda organización actual debe tener para cumplir de manera concreta y eficiente en su negocio. SOA (Service-Oriented Architecture) es la nueva tendencia de Microsoft para la creación de grandes plataformas tecnológicas en las distintas organizaciones. Dado que el Banco Central de Costa Rica es una institución que se apoya en las herramientas de Microsoft para todas sus labores de negocios, y que todas estas herramientas se conciben enfocadas en arquitecturas como SOA, este tipo de servicios serán clave en el desarrollo de nuevas aplicaciones que cubran necesidades recientes, o bien que sean migradas de arquitecturas obsoletas a otras más nuevas.
Justificación de impacto (aporte y resultados esperados):
La utilización de servicios SOA presenta muchas ventajas para las organizaciones que tienen procesos de desarrollo de sistemas. Permiten una gran flexibilidad a la hora de crear aplicaciones y además son versátiles y sencillos de mantener.Contar con una metodología que asista en la creación de estos servicios será un paso importante para construir una infraestructura de software moderna y con buenas bases, pensando en las nuevas tendencias que se menciona van a predominar en el futuro. Dicha metodología tiene un estándar que garantiza un mínimo de funcionalidad esperable en cada servicio. Igualmente, dicho estándar aumenta las posibilidades de crecimiento gracias a la uniformidad de los servicios SOA, y así se puede aspirar a nuevas aplicaciones de una manera más sencilla por la reutilización de código. Finalmente, con esta metodología, el mantenimiento de los sistemas se facilita mucho por la encapsulación de la información y la independencia en las pruebas.Es de esperar que esta metodología sea el punto de partida para la creación de todos los servicios que van a formar parte de las aplicaciones actuales y futuras del BCCR, y que con esto, se obtengan ahorros en presupuesto de mantenimiento y en tiempos de desarrollo.
Restricciones / limitantes / factores críticos de éxito:
• Los proyectos relacionados al área informática tienen la particularidad de que a nivel de costos, el único aspecto que suele tener participación es la cantidad de horas hombre. Por su naturaleza, un proyecto informático, como en este caso la creación de un servicio SOA, no requiere de herramientas o materiales adicionales, sino que las computadoras y software ya se tienen en la organización. A nivel de costo, se resume a horas trabajadas por los miembros de los equipos. Debido a esto, el manejo del costo se simplifica mucho. Para efectos de esta metodología, no se toma en cuenta la administración de costos.
• La metodología no incluye herramientas o consideraciones adicionales para la auditoría interna del BCCR. De hecho, una vez creada la metodología y estando en funcionamiento, la auditoria se basa en
115
ella para crear sus procedimientos. Antes de contar con la metodología es innecesario tener en cuenta a la auditoria pues no se sabe cómo van a proceder.
• La metodología se concentra en las tareas y procedimientos necesarios para crear un servicio nuevo, previamente inexistente y cuya necesidad no ha sido cubierta por algún otro componente de software o proceso manual. No se incluye en esta metodología los procesos que sean necesarios para dar mantenimiento a dicho servicio en caso de falla o actualización.
• La metodología no incluye elementos específicos para la seguridad de aplicaciones, certificados digitales, encripción de datos, validaciones de usuarios ni ningún otro aspecto relacionado.
• La metodología no incluye la creación de componentes de software para la interfaz de usuario final, sino solamente la interfaz de orquestación para servicios.
•Identificación de grupos de interés (stakeholders):Cliente(s) directo(s):
• Analistas/Diseñadores: Utilizan esta metodología activamente para sus labores diarias cuando es requerido analizar o diseñar un nuevo servicio. Por lo general, suelen participar activamente en todas las tareas, pero sobretodo en las primeras etapas del proyecto
• Desarrolladores: Utilizan esta metodología activamente para sus labores diarias, cuando están avocados a la construcción del servicio. Suelen participar más en las tareas finales del proyecto
• Encargados de pruebas: Utilizan esta metodología a la hora de establecer planes de pruebas y luego al aplicarlos sobre los componentes.
Clientes indirectos:
• Usuarios de negocio: Elaboran requerimientos y solicitudes de mejoras que dan pie a la creación de servicios SOA, y por lo tanto al inicio de proyectos de creación de componentes. Además, con sus comentarios o aclaraciones se obtiene valiosa información que puede ser usada para actualizar la metodología.
• Auditores: Confeccionan y aplican auditorias para comprobar que la metodología se está aplicando de la manera en la que se indicó que iba a ser utilizada.
Aprobado por: Firma:
116
12.2.Declaración de alcance
Proyecto: Metodología para la creación de servicios SOA en el BCCR
Fecha: Junio 2008
Planteo del problema (necesidad, oportunidad) y justificación del proyecto:
Existe actualmente una gran diversidad de herramientas tecnológicas para el desarrollo de sistemas de software. Esto implica también la aparición de estándares, prácticas y convenciones para los componentes de software. Si una organización tan grande y compleja como el BCCR no adopta una metodología para desarrollar sistemas, corre el riesgo de que pueda llegar a tener una mezcla de aplicaciones base, lo cual haría que se dificulte el mantenimiento de los sistemas. El BCCR se apoya en su gran mayoría en tecnología Microsoft , lo cual es ampliamente flexible y escalable. Los servicios SOA son un tipo de componente de software que constituyen una sólida base para las aplicaciones de ambiente Windows ó Web actuales, y presentan muchas ventajas de reutilización y mantenimiento. Entonces, con una metodología para crear estos servicios, se tiene un paso importante para lograr una infraestructura de software sólida y moderna, con gran capacidad de crecer en el futuro y mantenerse siempre actualizada. Todo esto al final se verá reflejado en ahorros para el mantenimiento y desarrollo de sistemas en la organización.
Objetivo(s) del proyecto:
El objetivo general de este proyecto es dotar a la División de Servicios Tecnológicos del BCCR de una metodología para crear servicios de software tipo SOA de una manera eficiente y estándar, y que puedan servir como base de la plataforma de software. Esta metodología se apoya en herramientas para la gestión y control de proyectos.Los objetivos específicos son la identificación de tareas básicas requeridas para crear un servicio SOA, el establecimiento de un estándar para las interfaces entre componentes y su implementación, la oficialización de los mecanismos de control para cada proceso de creación de servicios, los estándares de documentación interna y externa, las buenas practicas que se puedan aplicar en las etapas del proceso y la validación parcial de la metodología.
Producto principal del proyecto:
El principal producto es el documento con la metodología que guía en el desarrollo de servicios SOA
Entregables del proyecto:
Aparte de del documento con la metodología, que incluye los estándares de programación y documentación, la descripción de tareas y su secuencia (una plantilla de EDT), otros entregables son la guía de buenas prácticas de programación, un machote de cronograma con la definición y secuenciación de las tareas para crear un servicio, las plantillas para
117
documentación y control del proceso (a nivel de hitos). También, con entregable está el formulario para obtener retroalimentación de la validación.
Límites del proyectoEl proyecto no tiene consideraciones en cuanto a costos. Esto por cuanto en informática, la única variable relacionada en costos de proyectos es horas-hombre. No existen compras de materiales, equipos o subcontrataciones más allá de lo que ya tiene el BCCR.Otra limitante es con la Auditoría Interna del BCCR. Cuando se empiece a utilizar esta metodología y los auditores empiecen a validarla, se podrán aplicar ajustes concernientes a esta área. Inicialmente, no tiene sentido establecer lineamientos pues no se sabe que pueden pedir en un futuro.La metodología no toma en cuenta el proceso de mantenimiento, solamente la creación del servicio nuevo. Lo cierto es que si se aplica el procedimiento de creación, el mantenimiento se verá favorecido.Finalmente, no se toman consideraciones especiales con respecto a la seguridad de las aplicaciones. Dicho tema se maneja a otros niveles más generales, como servidores físicos ó bases de datos.
AsuncionesSe asume que ya el BCCR tiene compradas e instaladas todas las licencias y herramientas necesarias para aplicar esta metodología.Igualmente, se asume que todo el personal conoce dichas herramientas y las puede operar de la mejor manera.
RiesgosExiste un riesgo muy bajo de que Microsoft decida descontinuar las herramientas tipo SOA, lo cual obligaría a que se tenga que migrar todas las aplicaciones a un nuevo esquema.
118
12.3.EDT del Servicio SOA
119
12.4.Cronograma del Servicio SOA
120
12.5.Plantilla de Caso de Uso
Propósito:<<Sección que detalla en prosa el propósito para el cual este servicio SOA sería creado. Explica la función o funciones principales del servicio y la ventaja que se va a obtener con esto.>>
Justificación:<<Sección que detalla en prosa una justificación desde el punto de vista del negocio o de la arquitectura de los sistemas, que sirve como respaldo a la propuesta de crear un proyecto nuevo con la creación de este servicio SOA.>>
Precondiciones:<<Sección que detalla con viñetas la lista de todas las condiciones que deben existir antes de que este servicio empiece como proyecto y entre en operación, para que pueda cumplir con su función. Por ejemplo, si este servicio va a utilizar otro existente para lograr un resultado, entonces una precondición es que debe haber una interfaz entre ambos. >>
Escenarios de uso:Necesidad Respuestas del servicio
<<Explicación de una necesidad>> <<Acciones que toma el servicio para cubrir esa necesidad>>
Poscondiciones:<<Sección que detalla con viñetas la lista de todas las condiciones de datos, componentes o funciones que quedan disponibles o cambiadas a partir del momento que el proyecto termina y el servicio entra en operación. Por ejemplo, una poscondición es que se automatiza una tarea que antes era manual o un cierto dato que se utilizaba en un formato ahora se utiliza en otro a raíz de un cambio hecho en el servicio.>>
Restricciones:<<Sección que detalla con viñetas las restricciones en cuanto a funcionalidad que no forman parte del alcance de este servicio SOA.>>
Requerimientos funcionales:<<Sección que detalla con viñetas la lista de los requerimientos funcionales específicos de este servicio SOA, derivados de toda la información anterior. >>
Metodología para Creación de Servicios SOAPlantilla: Documento de Caso de UsoVersión: 1.0Fecha de elaboración: _______________________Analista encargado: _______________________Departamento/Área: _______________________
121
12.6.Plantilla para Diseño
Diseño gráfico del servicio:<<Sección que muestra un gráfico de capas, detallando las capas utilizadas, los principales componentes de software por capa y las relaciones entre estos. Se puede utilizar cualquier herramienta de graficación, siempre y cuando el detalle sea lo más claro posible>>
Componentes por capa:Capa Componente DescripciónDS <<Componente X del DS>> <<Descripción del componente X>>
<<Componente Y del DS>> <<Descripción del componente Y>>
BS <<Componente Z del BS>> <<Descripción del componente Z>>
BE <<Componente W del BE>> <<Descripción del componente W>>
Relaciones:<<Sección que detalla en prosa las distintas relaciones (interacciones) entre los diversos componentes del servicio. Aplica tanto entre capas como dentro de cada una. Es una especificación detallada del gráfico con el diseño del servicio >>
Escenarios de prueba:Escenario Prueba
<<Explicación del ambiente y funcionalidad que se desea probar. Incluye datos ó estados de entrada tan reales como sea posible.. También cualquier detalle de configuración o uso debe ser bien claro para que se pueda recrear el escenario una y otra vez en un ambiente controlado.>>
<<Descripción detallada de la prueba que se va a realizar en cada uno de los escenarios. Podría haber múltiples pruebas dentro de un mismo escenario. Deben ordenarse de las más sencillas a las más complejas. Incluye los resultados esperados (de acuerdo a los datos de entrada)>>
Metodología para Creación de Servicios SOAPlantilla: Documento de DiseñoVersión: 1.0Fecha de elaboración: _______________________Analista encargado: _______________________Departamento/Área: _______________________
122
12.7.Plantilla de revisión de calidad para Diseño
Caso de Uso:¿Existe el documento? ¿Está completo? ¿Es íntegro? ¿Es consistente?¿Todos los escenarios están apegados al servicio?¿Hay restricciones que deberían ser tomadas dentro del alcance? ¿Cuáles y por qué?¿Hay actores que no se están considerando? ¿Hay actores que sobran? ¿Cuáles y por qué?
Diseño del componente:¿Todas las capas han sido consideradas? ¿Alguna no aplica? ¿Cuál y por qué?¿Hay componentes para todas las capas que aplican en el servicio?¿Hay relaciones entre todos los componentes?
Pruebas:¿Existe al menos un escenario de pruebas?¿Existe al menos una prueba dentro de cada uno de los escenarios?¿Están considerados todos los datos de entrada y resultados esperados?
Resultados de las pruebas:Prueba Resultado
<<Descripción de la prueba>> <<Descripción del resultado de la prueba>>
Acciones de mejora:<<Descripción de las acciones de mejora aparecidas en este diseño que pueden aplicarse a otros posteriores. También debilidades, oportunidades y fortalezas detectadas. >>
Metodología para Creación de Servicios SOAPlantilla: Revisión de DiseñoVersión: 1.0 Fecha de revisión: ___________Revisor: _______________________Analista: _______________________Departamento/Área: _______________________
123
12.8.Plantilla para Base de Datos
Diseño gráfico de la base de datos:<<Sección que muestra un gráfico de entidades y relaciones de base de datos. Se puede utilizar cualquier herramienta que genere gráficos, pero lo más importante es que quede bien claro. Algunas entidades podrían ser creadas en este servicio y otras ya existen y pertenecen a otros servicios, pero acá se deben mostrar todas las involucradas. >>
Diccionario de datos:Tabla Columna Descripción
<<Tabla 1: Descripción>>
<<Columna 1>> <<Descripción de la columna 1>><<Columna 2>> <<Descripción de la columna 2>>
<<Tabla 2: Descripción>>
<<Columna 1>> <<Descripción de la columna 1>>
<<Tabla 3: Descripción>>
<<Columna 1>> <<Descripción de la columna 1>>
Procedimientos almacenados:Procedimiento Parámetro Descripción<<Proc 1: Descripción>>
<<Parámetro 1>> <<Descripción del parámetro 1>><<Parámetro 2>> <<Descripción del parámetro 2>>
<<Proc 2: Descripción>>
<<Parámetro 1>> <<Descripción del parámetro 1>>
<<Proc 3: Descripción>>
<<Parámetro 1>> <<Descripción del parámetro 1>>
Scripts de pruebas unitarias:Procedimiento Script de pruebas Descripción de las pruebas
<<Proc 1>> <<Script de pruebas Proc 1>> <<Descripción de las pruebas en el script>><<Proc 2>> <<Script de pruebas Proc 2>> <<Descripción de las pruebas en el script>><<Proc 3>> <<Script de pruebas Proc 3>> <<Descripción de las pruebas en el script>>
Metodología para Creación de Servicios SOAPlantilla: Base de datosVersión: 1.0Fecha de elaboración: _______________________Analista encargado: _______________________Departamento/Área: _______________________
124
12.9.Plantilla de revisión para Base de Datos
Entidades:¿Existe al menos una entidad nueva? ¿Está justificada su creación? ¿Es consistente en el resto de la BD?¿Todas las entidades existentes cuentan con llave primaria?¿Los nombres de las entidades y sus respectivas columnas están acordes al estándar vigente? ¿Cuáles no y por qué?
Procedimientos almacenados:¿Los nombres de los procedimientos almacenados están acordes al estándar vigente? ¿Cuál no y por qué?¿Los parámetros de los procedimientos almacenados tienen tipos definidos y nombres dentro del estándar?¿Los tipos de datos retornados son tipos definidos?
Pruebas:¿Existe al menos un escenario de pruebas?¿Existe al menos una prueba dentro de cada uno de los escenarios?¿Están considerados todos los datos de entrada y resultados esperados?
Resultados de las pruebas:Prueba Resultado
<<Descripción de la prueba>> <<Descripción del resultado de la prueba>>
Acciones de mejora:<<Descripción de las acciones de mejora aparecidas en este diseño de base de datos que pueden aplicarse a otros posteriores. También debilidades, oportunidades y fortalezas detectadas. >>
Metodología para Creación de Servicios SOAPlantilla: Revisión de Base de DatosVersión: 1.0 Fecha de revisión: ___________Revisor: _______________________Analista: _______________________Departamento/Área: _______________________
125
12.10.Plantilla para Componentes de Software
Capa: __________________Solución Visual Studio: __________________
Colección de clases:Clase Funciones Descripción de parámetros
<<Clase 1: Tipo de acceso>>
<<Función 1: Descrip.: Retorno>> <<Parámetro 1: Tipo : Descripción>><<Función 2 : Descrip.: Retorno>> <<Parámetro1: Tipo: Descripción>>
<<Clase 2: Tipo de acceso>>
<<Función 1: Descrip: Retorno>> <<Parámetro 1: Tipo: Descripción>>
<<Clase 3: Tipo de acceso>>
<<Función 1: Descrip.: Retorno>> <<Parámetro 1: Tipo: Descripción>>
Pruebas unitarias:Clase prueba Funciones prueba Descripción de pruebas unitarias
<<Clase pruebas 1>> <<Función pruebas 1: Descripción>>
<< Descripción del contenido de la función de la prueba unitaria>>
<<Función pruebas 2 : Descripción>>
<< Descripción del contenido de la función de la prueba unitaria>>
<<Clase pruebas 2>> <<Función pruebas 1: Descripción>>
<< Descripción del contenido de la función de la prueba unitaria>>
<<Clase pruebas 3 >>
<<Función pruebas 1: Descripción>>
<< Descripción del contenido de la función de la prueba unitaria>>
Metodología para Creación de Servicios SOAPlantilla: Componentes de SoftwareVersión: 1.0Fecha de elaboración: _______________________Analista encargado: _______________________Departamento/Área: _______________________
126
12.11.Plantilla de revisión para componentes de Software
Capas:¿Se especifica claramente la capa a la que pertenece el componente?¿Se especifica claramente la solución a la que pertenece el componente?¿La solución tiene nombre estándar?
Clases:¿Existe al menos una clase declarada en el componente?¿Todas las clases tienen nombres acordes al estándar? ¿Todas tienen tipos de acceso claramente definidos?¿Existe al menos una función en cada una de las clases? ¿Las funciones o propiedades tienen nombres estándar? ¿Los parámetros de todas las funciones y los tipos de datos retornados están claramente definidos y están acordes con el estándar vigente?
Pruebas:¿Existe al menos un escenario de pruebas?¿Existe al menos una prueba dentro de cada uno de los escenarios?¿Están considerados todos los datos de entrada y resultados esperados?
Resultados de las pruebas:Prueba Resultado
<<Descripción de la prueba>> <<Descripción del resultado de la prueba>>
Acciones de mejora:<<Descripción de las acciones de mejora aparecidas en este componente que pueden aplicarse a otros posteriores. También debilidades, oportunidades y fortalezas detectadas. >>
Metodología para Creación de Servicios SOAPlantilla: Revisión de SoftwareVersión: 1.0 Fecha de revisión: ___________Revisor: _______________________Analista: _______________________Departamento/Área: _______________________
127
12.12.Plantilla para documentación externa e integración
Nombre del servicio: ___________________________________________
Descripción: <<Descripción en prosa del servicio, lo más general posible. Concepción desde el punto de vista de la plataforma tecnológica y lo que va a aportar. Funcionalidad básica, restricciones y características principales, todo desde el punto de vista del negocio.>>
Interfaz pública:Funciones Descripción de parámetros Ejemplo de uso
<<Función 1: Descrip.: Retorno>>
<<Parámetro 1: Tipo : Descripción>> <<Ejemplo de uso para la función 1>>
<<Función 2 : Descrip.: Retorno>>
<<Parámetro1: Tipo: Descripción>> <<Ejemplo de uso para la función 2>>
<<Función 1: Descrip: Retorno>>
<<Parámetro 1: Tipo: Descripción>> <<Ejemplo de uso para la función 1>>
<<Función 1: Descrip.: Retorno>>
<<Parámetro 1: Tipo: Descripción>> <<Ejemplo de uso para la función 1>>
Integración técnica:<<Se detalla en prosa las consideraciones tecnológicas que se deben tomar para integrar este servicio SOA dentro de la plataforma. Por ejemplo, puede que este servicio venga a sustituir a otro u otros ya obsoletos que pueden ser eliminados>>
Integración de negocio:<<Se detalla en prosa las consideraciones a nivel de negocio que se deben tomar para incorporar este servicio a la plataforma de funciones disponibles. Aunque los usuarios no utilizarán directamente estos servicios (sino las aplicaciones que los consumen), en muchos casos el efecto indirecto de la nueva funcionalidad llega a ser percibida por el usuario final>>
Metodología para Creación de Servicios SOAPlantilla: Documentación Externa e IntegraciónVersión: 1.0Fecha de elaboración: _______________________Analista encargado: _______________________Departamento/Área: _______________________
128
12.13.Plantilla para documento de validación
Caso de uso
¿Existe el documento de caso de uso del servicio SOA?¿Se detalla el propósito para el servicio SOA?¿Se detalla una justificación válida para el servicio SOA?¿Se detallan las precondiciones para la implementación del servicio SOA? ¿Son válidas?¿Se detallan las necesidades del servicio y las correspondientes acciones que se implementan para cubrir esas necesidades?¿Se detallan las poscondiciones para la implementación del servicio SOA?¿Se detallan las restricciones para la implementación del servicio SOA?¿Se detalla la lista de requerimientos funcionales?
Diseño
¿Existe el documento de diseño del servicio SOA?¿Existe una representación gráfica del diseño del servicio? ¿Dicha representación es consistente con la descripción de capas y componentes del sistema?¿Cada componente tiene la definición de todos sus componentes en las capas inferiores?¿Existen componentes por capa que no tengan descripción asociada en el diseño?¿Existen componentes que no tengan relaciones dentro del modelo? ¿Existen relaciones circulares o relaciones que no apunten a componentes?¿Existen relaciones que salten capas o que salgan del scope del servicio sin una interfaz adecuada?¿Cada escenario de prueba está asociado a una prueba correspondiente?¿Todos los escenarios tienen definidas sus características y datos de entrada, como mínimo?¿Las pruebas para cada escenario están ordenadas de lo más sencillo a lo más complejo?¿Todas las pruebas tienen la descripción de los resultados esperados?
Metodología para Creación de Servicios SOAPlantilla: Revisión de metodología (PILOTO)Versión: 1.0Fecha de elaboración: _______________________Analista encargado: _______________________Departamento/Área: _______________________
129
¿Existe el documento de revisión del diseño para el servicio SOA?¿Se registran los resultados de la aplicación de pruebas? ¿Cuál no y por qué?¿Se detallan las acciones de mejora a ser seguidas? ¿Si no se detallan, por qué?
Base de datos
¿Existe el documento de base de datos?¿Existe una representación gráfica del diseño de la base de datos? ¿Esta representación es consistente con la definición de entidades y relaciones?¿Existe una descripción para todas las entidades (tablas) del servicio? ¿Cuál no y por qué??¿Existe una descripción para todas las columnas de todas las tablas del servicio? ¿Cuál no y por qué?¿Todos los nombres de las entidades están apegados al estándar?¿Existe una descripción para todos los procedimientos almacenados del servicio? ¿Cuál no y por qué?¿Existe una descripción para todos los parámetros de los procedimientos almacenados del servicio? ¿Cuál no y por qué?¿Todos los nombres de los procedimientos almacenados están apegados al estándar?¿Todos los procedimientos almacenados tienen al menos 1 scripts de pruebas asociado?¿Todos los script de pruebas tienen una descripción de la tarea que realizan?¿Existe el documento de revisión de la base de datos?¿Están registrados todos los resultados de las aplicaciones de script de pruebas? ¿Cuál no y por qué?¿Están registradas las acciones de mejora a ser seguidas? ¿Si no se detallan, por qué?
Componentes de software
¿Existe el documento de software?¿Se indica claramente la capa a la que pertenece el componente?¿Se indica claramente la solución de Visual Studio a la que pertenece el componente?¿Cada clase especifica su nombre y tipo de acceso?¿Todas las clases tienen nombres apegados al estándar? ¿Cuáles no y por qué?¿Todas las clases tienen al menos una función o propiedad definida?¿Todas las funciones tienen una descripción? ¿Cuál no y por qué?¿Los nombres de las funciones o propiedades están
130
apegados al estándar?¿Todos los parámetros tienen nombres apegados al estándar? ¿Cuál no y por qué?¿Todos los parámetros tienen una descripción asociada?¿Existe una clase de prueba por cada uno de las clases de la colección del componente?¿Todas las clases de prueba tienen nombres apegados al estándar? ¿Cuál no y por qué?¿Todas las clases de prueba tienen al menos un método de pruebas definido?¿Todas las funciones de prueba tienen una descripción asociada?¿Todas las pruebas unitarias tienen una descripción asociada?¿Se registran los resultados de la aplicación de todas las pruebas unitarias? ¿Cuál no y por qué?Están registradas las acciones de mejora a ser seguidas? ¿Si no se detallan, por qué?
Documentación externa
¿Existe el documento de documentación externa?¿El servicio tiene nombre claramente especificado?¿Existe una descripción adecuada para el servicio?¿Existe una interfaz pública para el servicio?¿Todas las funciones tienen su descripción y valor de retorno? ¿Cuál no y por qué?¿Todos los parámetros tienen su tipo y descripción? ¿Cuál no y por qué?¿Todas las funciones de la interfaz pública tienen ejemplos de su uso?¿Existe una descripción para la integración técnica del servicio?¿Existe una descripción para la integración de negocio del servicio?
131
12.14.Plantilla para seguimiento de reuniones
Participantes: Nombre Dependencia
<<Participante 1>> <<Dependencia participante 1>><<Participante 2>> <<Dependencia participante 2>>
Acuerdos:Acuerdo Responsable
<<Acuerdo 1>> <<Responsable acuerdo 1>><<Acuerdo 2>> <<Responsable acuerdo 2>>
Metodología para Creación de Servicios SOAPlantilla: Seguimiento de reunionesVersión: 1.0Fecha de reunión: _______________________Encargado: _______________________Departamento/Área: _______________________
132
12.15.Plantilla para solicitudes de cambio a productos
Cambios: Cambio solicitado Justificación Responsable
<<Cambio 1>> <<Justificación cambio 1>> <<Responsable 1>><<Cambio2>> <<Justificación cambio 2>> <<Responsable 2>>
Artefactos:Artefacto a cambiar Descripción de cambios
<<Artefacto 1>> <<Descripción de cambios a artefacto 1>><<Artefacto 2>> <<Descripción de cambios a artefacto 2>>
Metodología para Creación de Servicios SOAPlantilla: Solicitudes de cambio a productosVersión: 1.0Fecha de solicitud: _______________________Solicitante: _______________________Departamento/Área: _______________________
133
12.16.Plan de Implementación
Para la implementación de la metodología, es necesario considerar las
implicaciones que se tienen en cuanto a tiempo, costos y recursos, entre otros
aspectos. El siguiente cronograma detalla las tareas necesarias para lograr una
implementación eficaz de la metodología:
La primera parte de la implementación consiste en seleccionar un proyecto
piloto, el cual cumpla con ciertos requisitos para poder ser aplicar la
metodología y probarla. Entre los requisitos está que sea corto (en términos
relativos de desarrollo de software, esto puede ser 3 ó 4 meses como máximo)
y que no exista nada, sino que haya que empezarlo desde 0, para asegurar
que se cumplen todas las etapas de la metodología.
134
Parte de esta selección del proyecto implica buscar algún área o departamento
que tenga pendiente el desarrollo de alguna aplicación y que esté dispuesta a
aceptar que ese proceso de desarrollo tome más tiempo de lo que usualmente
tomaría, por el periodo de aprendizaje y maduración, aparte de todas las tareas
adicionales que la primera aplicación de la metodología implica.
Luego viene la selección de los recursos. Como se ha indicado, hay 4 áreas de
la División de Servicios Tecnológicos que deben aportar recursos para un
proyecto de este tipo. A saber: Análisis y Diseño, Base de datos,
Implementación y Validación y Verificación.
Se debe hacer un análisis para seleccionar al personal idóneo. Por ejemplo,
que tengan una carga de trabajo adecuada como para asumir este trabajo,
ojalá a tiempo completo (aunque esto es difícil de conseguir). También, que
tengan una actitud crítica hacia la mejora del proceso y que estén dispuestos a
cumplir con las tareas tan apegadas a la metodología como sea posible. Es
definitivo que no todos los recursos son aptos para aplicar en un proyecto piloto
como este, sino que algunos tienen mejor disposición que otros. Es de esperar
que sean 1 ó 2 recursos de cada una de esas áreas quienes sean
seleccionados.
Sabiendo cuales son los funcionarios que van a formar parte de este proyecto
piloto, se puede pensar en la capacitación que se va a ofrecer a todos ellos.
Básicamente, hay un proceso de inducción general para todos y luego una
etapa en la cual cada involucrado hace un análisis bien detallado de la
metodología o como mínimo la parte de la cual será responsable cada uno.
Basado en esta revisión detallada, se puede identificar una serie de mejoras
puntuales que se incorporarían en el documento, o bien que se documentarían
para futuras versiones en caso de ser cambios más grandes.
135
Paralelo a la capacitación, o seguido de esta en caso de contar con pocos
recursos disponibles, es necesario preparar el ambiente para que se pueda
aplicar adecuadamente toda la metodología al proyecto piloto. Acá hay
actividades como instalar equipos, verificar permisos en la red y en las bases
de datos, buscar espacio para el repositorio de documentos, etc.
Capacitados los recursos y configurado el ambiente, se puede empezar
propiamente con las labores de creación de los distintos servicios. En el
cronograma del plan de implementación, hay tres macro-tareas
correspondientes a tres aplicaciones del cronograma del Anexo 12.4. Esto
significa que la estimación del plan de implementación considera que se crearía
un sistema con tres servicios SOA (lógicamente esto es relativo y puede
cambiar).
Cada macro-tarea de esas se le asignó una duración de 30 días, un periodo
aceptable de tiempo para la creación de un servicio pequeño y poco complejo,
como se esperaría que fuera en el piloto. Sin embargo, este dato también es
relativo y se puede ajustar cuando se sepa la complejidad del proyecto piloto.
Para efectos prácticos, estas macro-tareas deberían ser sustituidas por
cronogramas similares al del Anexo 12.4, ya aplicados a servicios SOA
específicos. Por ser la primera ejecución de la metodología, tareas como la
revisión de plantillas y los ajustes correspondientes, tomarían más tiempo de lo
que tomaría en una ejecución posterior, cuando ya sea el único método de
trabajo y todos tengan mayor experiencia.
Finalmente, una vez construidos los servicios, hay una etapa de análisis de
resultados finales del piloto, que al final de cuentas van a ser los objetivos
principales que se persiguen con este ejercicio.
136
Por ejemplo, se analizan los resultados del tiempo empleado propiamente en
implementación versus el tiempo empleado en documentación, y se compara
con los mismos indicadores pero sin metodología. Igualmente se comparan los
productos de software obtenidos con la metodología versus los que se
construyen sin ella, en cuanto a estilo, tamaño, complejidad, etc.
La retroalimentación por parte de los involucrados en el proceso es también
una parte importante de este análisis final. La idea es documentar la
experiencia, los puntos buenos y aquellos que se pueden mejorar con ajustes
al proceso o bien con más experiencia. Toda esta información se mantiene
vigente en el tiempo, para poder tenerla a mano en aquellas oportunidades de
mejorar el documento.
Una vez efectuadas todas estas tareas de implementación, simplemente es
cuestión de oficializar la metodología y empezar a utilizarla en los nuevos
desarrollos que se vayan considerando dentro de los planes de trabajo del
departamento. Ya se tendría el ambiente preparado y la documentación lista,
como para que los funcionarios trabajen con estas reglas
Este plan de implementación se esboza para un piloto compuesto para tres
servicios SOA. Todo el proceso tiene una duración de poco más de 5 meses,
periodo razonable para casos así. A lo sumo, en un mes adicional se
extendería todo el conocimiento al resto del personal de las 4 áreas, por lo que
en 6 meses a partir del visto bueno de la metodología, es de esperar que todos
logren aplicarla en los proyectos nuevos.
Lo ideal sería contar con al menos otro proyecto similar a este, que podría
hacerse concurrente o bien posterior, con el fin de depurar y optimizar lo más
posible toda la metodología de manera íntegra. Sin embargo, ya esta opción es
poco factible por los recursos que serían necesarios, aunque es claro que es el
caso ideal.
137
12.17.Análisis Costo-Beneficio
Rubro Costo BeneficioPersonal Se debe seleccionar
algunos funcionarios de las distintas áreas involucradas, con disponibilidad para ser asignados a la capacitación y a los proyectos piloto, los cual consume tiempo.
Estos funcionarios producen aportes que mejoran la metodología y además obtienen experiencia en la aplicación para el momento en el cual se generalice su uso.
Proyectos Piloto Se debe negociar con algún área de negocio interesada en prestar 1 ó 2 proyectos para ser utilizados como piloto por esta metodología. Esto podría tener implicaciones de tiempo en la entrega final del producto, mientras se obtiene la experiencia necesaria entre todos los involucrados.
Si se obtienen sistemas completos y funcionales creados con esta metodología, es más sencillo lograr que se oficialice por parte de las esferas políticas del BCCR. Además, también se facilita el posterior presupuesto para extender la metodología e irla mejorando día con día.
Madurez de la metodología
Es improbable que en las primeras aplicaciones de la metodología se cubran todos los detalles necesarios para lograr una implementación 100% efectiva. Como muchas cosas en esta área de la tecnología, es necesario hacer pruebas y procesar la retroalimentación para lograr que se pueda considerar bien completa y correcta.
Asumiendo el costo de la madurez, se obtiene un producto más completo, más efectivo, más apto para la organización y más propenso a ser bien aplicado por los involucrados. Vale la pena invertir en el proceso de madurez de la metodología.
Retrabajo por resultados de revisiones
Durante las primeras aplicaciones de la metodología, es de esperar que haya funcionarios que no interpreten bien algún apartado de una plantilla,
El beneficio es similar al del rubro de la madurez de la tecnología y del personal. Eventualmente, estos costos de retrabajo se deberán ir disminuyendo
138
algún apartado del estándar o bien que obvien tareas preestablecidas en su proceso de diseño. Esto implica que les va a demandar tiempo en regresar a corregir los componentes y/o documentos.
con el tiempo y con el aumento de uso de la metodología.
Capacitaciones al personal
Implican tiempo que se debe sacar al personal de sus labores habituales, en pro de capacitarlos adecuadamente en el uso y los demás detalles de la metodología.
Capacitando a todo el personal acorde a un plan establecido, homologa los conocimientos entre todos los involucrados y hará que todos entiendan mejor como hacer el trabajo, lo cual reduce que se produzcan errores y el retrabajo.
Migración a terceras plataformas
Ninguno El tener la plataforma de software de los sistemas acordes a un estándar de capas, facilita posteriores migraciones, pues ya es una arquitectura abierta. La metodología favorece la construcción de servicios bajo arquitectura de sencilla migración.
Inclusión de nuevas herramientas
Ninguno El tener un estándar que ayude a construir componentes y bases de datos con tecnología Microsoft abierta, facilita la inclusión de otras herramientas que podrían ser útiles. Por ejemplo, herramientas para control de versiones, para medir rendimiento de aplicaciones o herramientas para facilitar la documentación.
Menor tiempo de mantenimiento de los servicios
Ninguno Cuando se cuente con la plataforma de software formada por componentes de estilo similar, con
139
estándares parecidos y con sólida documentación que respalda todos los procesos, será mucho más sencillo el asignar funcionarios al mantenimiento de las aplicaciones y su tiempo de trabajo será más efectivo.
Estandarización de metodología base de trabajo
Ninguno El contar con una sola forma de trabajo por parte de todos los funcionarios de tecnología, aporta muchas ventajas como facilidad de entendimiento, mejora en la disponibilidad de recursos y menor tiempo de atención de incidentes.
Facilidad de inducción a nuevos funcionarios
Ninguno Cuando haya nuevos funcionarios en las distintas áreas, será más sencillo capacitarlos en el uso de la metodología, pues ya se tiene el proceso bien definido y maduro.
Estandarización del código fuente de componentes
Ninguno El contar con código fuente estándar, al menos hasta cierto nivel, facilita las caminatas de código y el entendimiento por parte de personas diferentes a los que hicieron la construcción. Esta es una de las tareas más difíciles y laboriosas, lo cual se facilita con código estándar.
Facilidad de implementación de decisiones administrativas
Ninguno Se facilita asignar nuevo personal, verificar avances, cubrir ausencias y solicitar informes.
140
12.18.Áreas de conocimiento relacionadas
Área de conocimiento Relación con la metodologíaGestión de Integración del Proyecto
Las herramientas que presenta esta metodología contribuyen principalmente a las labores de dirección y gestión de la ejecución del proyecto, así como a la supervisión del trabajo.
Gestión de Alcance del Proyecto La metodología incluye un machote de una EDT, con las tareas básicas para crear un servicio SOA. Esta herramienta limita el alcance de cada iteración de los ciclos de creación y facilita el proceso de verificación y control.
Gestión de Tiempo del Proyecto Dado que se tiene un machote para una EDT, fácilmente se puede derivar de ahí un machote de cronograma para que sirva como base en la creación de un servicio. Este cronograma base ya tiene secuencias entre las tareas y también permite obtener datos como ruta crítica, uso de recursos, etc. Además, esto facilita la asignación de recursos a los hitos especificados.
Gestión de Costos del Proyecto En proyectos de desarrollo de software, el único costo que se tiene es el de horas-hombre. Por lo tanto, esta área de conocimiento no es considerada dentro de la metodología, pues no es necesario hacer análisis complejos de costos.
Gestión de Calidad del Proyecto Uno de los mayores aportes de la metodología es a la calidad del software generado. Las plantillas de documentación (principalmente) ofrecen una herramienta que ayuda a verificar que los diseños sean eficientes, las pruebas oportunas y que no se dejen de lado detalles que eventualmente serán caros de corregir o que van a introducir errores en el producto final. Igualmente, la metodología abre un espacio para que se documenten errores encontrados y con ese conocimiento, se introduzcan cambios para mantener la
141
mejora continua a lo largo de toda la aplicación del proceso.
Gestión de Recursos Humanos del Proyecto
Reclutamiento y selección del personal no es parte de esta metodología. Esto sale del contexto desarrollado. Aspectos como formación, evaluación, informes de personal y responsabilidades no son parte de esta metodología.
Gestión de Comunicaciones del Proyecto
En ciclos de desarrollos de componentes SOA, tal y como los describe esta metodología, la comunicación es sencilla debido a los equipos pequeños de trabajo. En este aspecto no se requieren planes concretos y complejos que deban ser oficializados y puestos en marcha como si fueran proyectos grandes.
Gestión de Riesgos del Proyecto
La gestión de riesgos en esta metodología está directamente asociada a las plantillas, tanto de documentación como de revisión. Si el diseño de un servicio es completo y correcto, implícitamente se están mitigando muchos riesgos a la hora de implementar el proceso en el negocio, a la hora de dar mantenimiento a componentes que podría acarrear errores. También, se evita dejar por fuera funcionalidad que podría ser crucial. Similar sucede con las pruebas: si estas se definen y aplican bien, entonces se van a reducir errores posteriores que de otra forma, sería caro de solventar.
Gestión de Adquisiciones del Proyecto
Por la naturaleza de esta labor y la forma de administración de contrataciones del BCCR, este tema es totalmente ajeno a la metodología.