UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

Tamaño: px
Comenzar la demostración a partir de la página:

Download "UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)"

Transcripción

1 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 REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACIÓN DE PROYECTOS San José, Costa Rica Julio, 2008

2 UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito 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

3 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 ÁREA BCCR Ing. Luis Carlos García M., M.C.I. SUSTENTANTE iii

4 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

5 INDICE DE CONTENIDO 1. INTRODUCCIÓN Antecedentes Organigrama Problemática Justificación Objetivos 4 2. MARCO TEÓRICO Marco Institucional Teoría de TI y SOA Relación con la administración de proyectos Modelos aplicados Proyectos PMI Alcance Tiempo Calidad Integración Programas Estructuras organizativas para proyectos Herramientas relacionadas MARCO METODOLÓGICO Investigaciones comunes Revisión de software EDT y cronograma Estándares Control y seguimiento Documentación Buenas prácticas para SOA Validación PLANEACIÓN DEL PROYECTO Tareas para crear un servicio SOA Secuenciación de tareas Organización por paquetes de trabajo Estructura de desglose de trabajo (EDT) Cronograma 59 v

6 5. ESTÁNDAR DE INTERFAZ E IMPLEMENTACIÓN Componentes de software Estándar de implementación Estándar de interfaz y organización de componentes Estándar de documentación interna MECANISMOS DE CONTROL PARA EL PROYECTO Flujos de trabajo y roles Hitos de control Mecanismos de control GUÍA DE BUENAS PRÁCTICAS VALIDACIÓN DE LA METODOLOGÍA Revisión primaria Aspectos a validar y resultados esperados Mecanismos de validación y retroalimentación CONCLUSIONES RECOMENDACIONES BIBLIOGRAFÍA ANEXOS Charter del proyecto Declaración de alcance EDT del Servicio SOA Cronograma del Servicio SOA Plantilla de Caso de Uso Plantilla para Diseño Plantilla de revisión de calidad para Diseño Plantilla para Base de Datos Plantilla de revisión para Base de Datos Plantilla para Componentes de Software Plantilla de revisión para componentes de Software Plantilla para documentación externa e integración Plantilla para documento de validación Plantilla para seguimiento de reuniones Plantilla para solicitudes de cambio a productos Plan de Implementación Análisis Costo-Beneficio Áreas de conocimiento relacionadas vi

7 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

8 INDICE DE CUADROS Cuadro 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

9 INDICE DE ABREVIACIONES BCCR: BD: BE: BS: CRM.: DBA: DLL: DS: DST.: EDT: ER: ERP: IS: LINQ: OPM3: PMI: PMMM: Banco Central de Costa Rica. Base de datos Business Entity (Entidad de negocio) Business Service (Servicio de negocios) Custom Relationship Management (Administradores de relaciones con los clientes). DataBase Administrador Administrador de Base de Datos Dynamic Linking Library Librería de Enlace Dinámico. Data Service (Servicios de datos) División de Servicios Tecnológicos Estructura de desglose de trabajo Modelo Entidad-Relación Enterprise Resource Planning (Sistemas de planificación de recursos empresariales) Interface Service (Interfaz de servicios).net Language Integrated Query Lenguaje de Consultas integradas para.net Organizational Project Management Maturity Model (Modelo de gestión de madurez organizacional de proyectos) Proyect Management Institute (Instituto de administración de proyectos) Program Management Maturity Model ix

10 RUP: SOA: TI.: XML: (Modelo de programa de gestión de evolución) Rational Unified Process (Proceso Unificado de Rational) Service Oriented Architechture (Arquitectura orientada a servicios). Tecnología de Información Extended Markup Language (Lenguaje extendido de etiquetas) x

11 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

12 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

13 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.

14 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

15 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.

16 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 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

17 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.

18 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,

19 finanzas, administración, estadística y, como apoyo a todos estos campos de negocio, la tecnología. 7 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):

20 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.

21 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.

22 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).

23 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:

24 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

25 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.

26 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

27 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

28 algunas empresas una serie de lineamientos que asisten en algunas de las etapas de construcción de tareas. Estos procedimientos se llaman patrones. 16 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.

29 Relación con la administración de proyectos 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

30 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

31 directamente relacionados con el principal (por ejemplo, conseguir los vestuarios para los actores de la obra de teatro). 19 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 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

32 postgrado. En resumen, casi cualquier situación que se enfrenta todos los días tiene algunas características de proyectos. 20 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 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.

33 21 Los grupos de procesos son los que se muestran en el cuadro 2 (PMI, 2004): Grupo de procesos Iniciación Planificación Ejecución Seguimiento y Control Cierre Cuadro 2: Grupo de procesos Descripción Define y autoriza el proyecto o una fase del mismo. Define los objetivos, planifica el curso de acción requerido para lograrlos y limita el alcance del proyecto Integra los recursos (personales y materiales) para llevar a cabo el plan de gestión del proyecto. Mide y supervisa el avance, para tomar medidas correctivas oportunas. 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ón Gestió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

34 22 Gestión de Riesgos Gestión de Adquisiciones asegurar la generación, recogida, distribución, almacenamiento, recuperación y destino final de la información del proyecto, en tiempo y forma Incluye los procesos relacionados con la planificación de la gestión de riesgos, su identificación, análisis, respuesta, control y seguimiento. 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 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.

35 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.

36 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 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.

37 Control del cronograma: Se controlan los cambios del cronograma del proyecto. 25 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 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

38 de metodología, sino que va más allá. Llega incluso a ser una filosofía institucional del BCCR 26 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.

39 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 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.

40 Cerrar proyecto: Se finalizan todas las actividades de manera formal, para un proyecto o una fase. 28 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 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 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).

41 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: Proyecto Duración fija Objetivos predefinidos Enfocado en tareas Ciclo de vida de procesos Cuadro 4: Diferencias entre proyecto y programa (Thiry, 2002) Programa Duración indeterminada Objetivos negociados Enfocado en metas Ciclo de vida de productos 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.

42 Los principales tipos de estructura organizativa que existen son los siguientes (Vega, 2006): 30 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.

43 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.

44 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.

45 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ó.

46 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

47 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.

48 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.

49 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.

50 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

51 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.

52 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

53 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

54 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

55 significativa. Estos resultados se indican en el mismo formulario de validación, para identificar rápidamente las áreas más sensibles a problemas. 43 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.

56 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)

57 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.

58 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

59 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

60 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

61 sencillo es que cada capa del modelo en la Figura 4 constituya un paquete de trabajo que pueda asumir una persona. 49 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.

62 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 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.

63 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

64 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 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

65 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 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.

66 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

67 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 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 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,

68 se facilita la implementación y pruebas del BS. Las tareas necesarias para construir BS son estas: 56 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).

69 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

70 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.

71 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.

72 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.

73 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 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.

74 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:

75 63 Cuadro 5: Tipos y ambientes de bases de datos Tipos de base de datos Ambiente de base de datos PRO: Producción DES: Desarrollo REP: Repositorio PRU: Pruebas RPT: Reportes PRO: Producción AUD: Auditoría HST: Histórico DWH: DataWareHouse BIT: 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

76 mantiene. El dato de la tabla relacionada es opcional, solamente para tablas que mantienen relaciones directas. Algunos ejemplos son: 64 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).

77 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>.

78 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.

79 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.

80 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.

81 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:

82 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.

83 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

84 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

85 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:

86 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.

87 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

88 mantenimiento. Todos estos DLL se crean a partir de solucoines de Visual Studio.NET, ligadas entre sí por medio de referencias. 76 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: DS BS BE IS Capa Cuadro 6: Nomenclatura para los DLL Nombre del DLL BCCR-<Descripción>DS.DLL Ej. BCCR-CuentaSINPEDS.dll BCCR-<Descripción>BS.DLL Ej. BCCR-CuentaSINPEBS.dll BCCR-<Descripción>BE.DLL Ej. BCCR-CuentaSINPEBE.dll 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.

89 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

90 78 -- Fecha/creación: 27/Abril/ 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 VARCHAR(17), -- Código de la DATETIME, -- Fecha de DATETIME, -- Fecha de MONEY OUTPUT, -- Saldo disponible al MONEY OUTPUT, -- Monto retenido al 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 ========================================================

91 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

92 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.

93 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

94 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.

95 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.

96 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.

97 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

98 control se asocian a entregables o productos, aunque esto no necesariamente siempre tiene que ser así. 86 El cuadro 7 especifica la lista de hitos para el proyecto de creación de un servicio SOA: Hito Análisis del problema Diseño general Componentes de BD (Base de datos) Construcción de DS Construcción de BE Construcción de BS Construcción de IS Diseño de pruebas Aplicación de pruebas Documentación final Cuadro 7: Lista de hitos del proyecto Descripción Se llega al hito cuando se tiene el documento de Caso de Uso y se han listado los requerimientos funcionales. Se llega al hito cuando se ha especificado de manera completa el diseño del servicio SOA. 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. Se llega al hito cuando se tienen los componentes de software del DS y sus pruebas unitarias. Incluye el formulario de revisión. Se llega al hito cuando se tienen los componentes de software del BE. Incluye el formulario de revisión. Se llega al hito cuando se tienen los componentes de software del BS y sus pruebas unitarias. Incluye el formulario de revisión. Se llega al hito cuando se tienen los componentes de software del IS. Incluye el formulario de revisión. Se llega al hito cuando se tiene la especificación de todas las pruebas de integración Se llega al hito cuando se han aplicado todas las pruebas de integración y se han obtenido resultados satisfactorios. Se llega al hito cuando se han documentado lecciones aprendidas y otros resultados. Es la antesala del cierre del proyecto.

99 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.

100 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 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.

101 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.

102 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.

103 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.

104 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.

105 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

106 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.

107 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.

108 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: Funcionario MCI. Carlos Sánchez F. MCI. Yanina Barquero M. Cuadro 8: Lista de funcionarios que validaron metodología Labores Ejecutivo a.i. del Área de Análisis y Diseño del Departamento de Ingeniería de Software Institucional. Analista programadora del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargada del Sistema de Reservas

109 97 MCI Roneld Matamoros C. Lic. Johnny Castro G. Lic. Lorenzo Garita O. Lic. William Solís J. Monetarias Internacionales. Analista programador del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargado de dirección de varios proyectos. Analista programador del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargado del desarrollo de proyectos web. Analista programador del Área de Implementación del Departamento de Ingeniería de Software Institucional. Encargado de dirección de varios proyectos. 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.

110 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

111 cuidado y atención a estas actividades macro, se cubre la parte más importante de todo el proceso. 99 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.

112 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

113 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

114 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 presenta una plantilla para llenar con la validación de la

115 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). 103 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

116 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 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.

117 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

118 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

119 todos los aspectos, lo cual redunda en mejoras en todos los niveles del trabajo. 107 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.

120 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

121 trabajo y considerar cualquier actualización que pueda tener esta guía para facilitarles la labor. 109 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.

122 BIBLIOGRAFÍA Arsanjani, A. (2004). Service-oriented modeling and architecture. IBM Corporation. Extraído el 21 Octubre, 2007 de 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 Banco Central de Costa Rica. (2007). (Página WEB principal). San José, Costa Rica. Extraído el 16 Octubre, 2007 de 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 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 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 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 Project Management Institute. (2004). Guía de los fundamentos de la dirección de proyectos PMBok Guide. Pennsylvannia, Estados Unidos.

123 Roch, E. (2006). SOA Design. Extraído el 20 Octubre, 2007 de 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. 111

124 12.ANEXOS 112

125 Charter del proyecto Fecha: 9 de Octubre de 2007 ACTA (CHARTER) DEL PROYECTO Áreas de conocimiento / procesos: Alcance, Tiempo y Calidad. Implícitamente está Integración Fecha de inicio del proyecto: 8 de Octubre de 2007 Información principal y autorización de proyecto 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 Área de aplicación (sector / actividad): Sistemas de software bancarios (Banca y Finanzas) Sistemas de información Objetivos del proyecto (general y específicos): Fecha tentativa de finalización del proyecto: 31 de Marzo de 2008 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

126 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 114

127 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. 115 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:

128 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

129 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 proyecto El 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. Asunciones Se 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. Riesgos Existe 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. 117

130 12.3.EDT del Servicio SOA 118

131 12.4.Cronograma del Servicio SOA 119

132 Plantilla de Caso de Uso Metodología para Creación de Servicios SOA Plantilla: Documento de Caso de Uso Versión: 1.0 Fecha de elaboración: Analista encargado: Departamento/Área: 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 <<Explicación de una necesidad>> Respuestas del servicio <<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. >>

133 Plantilla para Diseño Metodología para Creación de Servicios SOA Plantilla: Documento de Diseño Versión: 1.0 Fecha de elaboración: Analista encargado: Departamento/Área: 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ón DS <<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 <<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.>> Prueba <<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)>>

134 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é? Metodología para Creación de Servicios SOA Plantilla: Revisión de Diseño Versión: 1.0 Fecha de revisión: Revisor: Analista: Departamento/Área: 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 <<Descripción de la prueba>> Resultado <<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. >>

135 Plantilla para Base de Datos Metodología para Creación de Servicios SOA Plantilla: Base de datos Versión: 1.0 Fecha de elaboración: Analista encargado: Departamento/Área: 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: <<Columna 1>> <<Descripción de la columna 1>> Descripción>> <<Columna 2>> <<Descripción de la columna 2>> <<Tabla 2: Descripción>> <<Tabla 3: Descripción>> <<Columna 1>> <<Descripción de la columna 1>> <<Columna 1>> <<Descripción de la columna 1>> Procedimientos almacenados: Procedimiento Parámetro Descripción <<Proc 1: <<Parámetro 1>> <<Descripción del parámetro 1>> Descripción>> <<Parámetro 2>> <<Descripción del parámetro 2>> <<Proc 2: Descripción>> <<Proc 3: Descripción>> <<Parámetro 1>> <<Descripción del parámetro 1>> <<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>>

136 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é? Metodología para Creación de Servicios SOA Plantilla: Revisión de Base de Datos Versión: 1.0 Fecha de revisión: Revisor: Analista: Departamento/Área: 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 <<Descripción de la prueba>> Resultado <<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. >>

137 Plantilla para Componentes de Software Capa: Solución Visual Studio: Metodología para Creación de Servicios SOA Plantilla: Componentes de Software Versión: 1.0 Fecha de elaboración: Analista encargado: Departamento/Área: Colección de clases: Clase Funciones Descripción de parámetros <<Clase 1: Tipo <<Función 1: Descrip.: Retorno>> <<Parámetro 1: Tipo : Descripción>> de acceso>> <<Función 2 : Descrip.: Retorno>> <<Parámetro1: Tipo: Descripción>> <<Clase 2: Tipo de acceso>> <<Clase 3: Tipo de acceso>> <<Función 1: Descrip: Retorno>> <<Función 1: Descrip.: Retorno>> <<Parámetro 1: Tipo: Descripción>> <<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 del contenido de la función de la prueba unitaria>> Descripción>> <<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>>

138 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? Metodología para Creación de Servicios SOA Plantilla: Revisión de Software Versión: 1.0 Fecha de revisión: Revisor: Analista: Departamento/Área: 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 <<Descripción de la prueba>> Resultado <<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. >>

139 Plantilla para documentación externa e integración Metodología para Creación de Servicios SOA Plantilla: Documentación Externa e Integración Versión: 1.0 Fecha de elaboración: Analista encargado: Departamento/Área: 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.: <<Parámetro 1: Tipo : Descripción>> <<Ejemplo de uso para la función 1>> Retorno>> <<Función 2 : Descrip.: Retorno>> <<Parámetro1: Tipo: Descripción>> <<Ejemplo de uso para la función 2>> <<Función 1: Descrip: Retorno>> <<Función 1: Descrip.: Retorno>> <<Parámetro 1: Tipo: Descripción>> <<Ejemplo de uso para la función 1>> <<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>>

140 Plantilla para documento de validación Metodología para Creación de Servicios SOA Plantilla: Revisión de metodología (PILOTO) Versión: 1.0 Fecha de elaboración: Analista encargado: Departamento/Área: 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?

141 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

142 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?

143 Plantilla para seguimiento de reuniones Metodología para Creación de Servicios SOA Plantilla: Seguimiento de reuniones Versión: 1.0 Fecha de reunión: Encargado: Departamento/Área: 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>>

144 Plantilla para solicitudes de cambio a productos Metodología para Creación de Servicios SOA Plantilla: Solicitudes de cambio a productos Versión: 1.0 Fecha de solicitud: Solicitante: Departamento/Área: 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>>

145 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.

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) METODOLOGÍA PARA ADMINISTRAR PROYECTOS DE TECNOLOGÍA BASADOS EN ARQUITECTURA ORIENTADA A SERVICIOS

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) METODOLOGÍA PARA ADMINISTRAR PROYECTOS DE TECNOLOGÍA BASADOS EN ARQUITECTURA ORIENTADA A SERVICIOS UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) METODOLOGÍA PARA ADMINISTRAR PROYECTOS DE TECNOLOGÍA BASADOS EN ARQUITECTURA ORIENTADA A SERVICIOS JEFFRY AGÜERO CORDERO PROYECTO FINAL DE GRADUACION

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

PROPUESTA PARA LA IMPLEMENTACIÓN DE UNA OFICINA DE ADMINISTRACIÓN DE PROYECTOS

PROPUESTA PARA LA IMPLEMENTACIÓN DE UNA OFICINA DE ADMINISTRACIÓN DE PROYECTOS PROPUESTA PARA LA IMPLEMENTACIÓN DE UNA OFICINA DE ADMINISTRACIÓN DE PROYECTOS PMO (Parte 1 de 2) Sergio Salimbeni Mayo, 2014 CONTENIDO 1. Abstract... 4 2. Planteamiento del problema... 5 3. Justificación...

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) GUÍA PARA LA ELABORACIÓN DEL PLAN DE GESTIÓN DE CALIDAD DE LOS PROYECTOS EN LA DIRECCIÓN TÉCNICA DESRROLLO Y EJECUCIÓN DE PROYECTOS DEL ICE ARIANA HERNÁNDEZ

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Cuarta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

Más detalles

AUTOMATIZACIÓN DEL PROCESO DE ATENCIÓN DE REQUERIMIENTOS DE LA AUTORIDAD PORTUARIA NACIONAL

AUTOMATIZACIÓN DEL PROCESO DE ATENCIÓN DE REQUERIMIENTOS DE LA AUTORIDAD PORTUARIA NACIONAL UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS AUTOMATIZACIÓN DEL PROCESO DE ATENCIÓN DE REQUERIMIENTOS DE LA AUTORIDAD PORTUARIA NACIONAL PROYECTO PROFESIONAL

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE ESTANDARIZACION DE PROCESOS EN LA UNIDAD DE TECNOLOGIAS DE INFORMACION DE LA OFICINA DE ADMINISTRACION FINANCIERA DE LA UNIVERSIDAD DE COSTA

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

Project 2013. Ing. Christian Ovalle

Project 2013. Ing. Christian Ovalle 2013 Ing. Christian Ovalle PROJECT Antes de comenzar un proyecto se necesitan definir los objetivos de un proyecto y luego determinado, cuales son las tareas que necesita realizar para alcanzar ese objetivo.

Más detalles

Metodología para la Gestión de Proyectos de Tecnologías Informáticas

Metodología para la Gestión de Proyectos de Tecnologías Informáticas Universidad Técnica Nacional Dirección de Gestión de Tecnología de Información Metodología para la Gestión de Proyectos de Tecnologías Informáticas Capítulo 1. Normas de Aplicación General. Norma 1.5.

Más detalles

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS SISTEMA DE GESTION DE REQUERIMIENTOS DE SOFTWARE PROYECTO

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

MODELO DE ORDENAMIENTO Y CONTROL DE PRODUCTO EN PROCESO EN ENSAMBLE TEXTIL

MODELO DE ORDENAMIENTO Y CONTROL DE PRODUCTO EN PROCESO EN ENSAMBLE TEXTIL UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA INDUSTRIAL MODELO DE ORDENAMIENTO Y CONTROL DE PRODUCTO EN PROCESO EN ENSAMBLE TEXTIL RESUMEN EJECUTIVO Presentado por: Roberto

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

PRINCE2 & TickIT. Jorge Armando Medina Morales. Código 1700321660. U n i v e r s i d a d D e C a l d a s. F a c u l t a d D e I n g e n i e r í a s

PRINCE2 & TickIT. Jorge Armando Medina Morales. Código 1700321660. U n i v e r s i d a d D e C a l d a s. F a c u l t a d D e I n g e n i e r í a s PRINCE2 & TickIT Jorge Armando Medina Morales Código 1700321660 U n i v e r s i d a d D e C a l d a s F a c u l t a d D e I n g e n i e r í a s I n g e n i e r í a D e S i s t e m a s O c t u b r e 2010

Más detalles

MÁSTER EN DIRECCIÓN Y GESTIÓN DE PROYECTOS

MÁSTER EN DIRECCIÓN Y GESTIÓN DE PROYECTOS MÁSTER EN DIRECCIÓN Y GESTIÓN DE PROYECTOS IMPARTIDO POR Fundación Aucal TÍTULO OTORGADO POR Título Propio de la Universidad Francisco de Vitoria MODALIDAD On Line COLABORACIONES Universidad Francisco

Más detalles

6a. Academia de Actualización Profesional 2009 PMO: facilitador de la administración de costos y desempeño. PwC

6a. Academia de Actualización Profesional 2009 PMO: facilitador de la administración de costos y desempeño. PwC 6a. Academia de Actualización Profesional 2009 PMO: facilitador de la administración de costos y desempeño PwC Agenda Objetivo de la charla Características principales de una PMO Principales áreas de actividades

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

PLANEAMIENTO ESTRATÉGICO E INDICADORES

PLANEAMIENTO ESTRATÉGICO E INDICADORES PLANEAMIENTO ESTRATÉGICO E INDICADORES CASO CORPORACIÓN JOSE R. LINDLEY La Corporación José R. Lindley constituye uno de los casos más interesantes de planeamiento estratégico e implementación de indicadores

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Presentación Comercial IXAYA Crédito

Presentación Comercial IXAYA Crédito Presentación Comercial IXAYA Crédito Versión: 2.0.1 Fecha: 21/04/2014 Elaboró: División Consultoría Contenido 1. Descripción de la solución....3 1.1. Beneficios....4 1.2. Modelo operativo....5 1.3. Arquitectura

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

Introducción a la Gerencia de Proyectos. Resumen. Introducción.

Introducción a la Gerencia de Proyectos. Resumen. Introducción. Introducción a la Gerencia de Proyectos Edwin Monzón C. Ing. de Planeamiento y Control de Proyectos, Compañía Minera San Martín Resumen A nivel mundial la utilización de estándares en la dirección de proyectos

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE IMPLEMENTACIÓN DEL PROCESO ADMINISTRAR PROYECTOS DE COBIT 4.0 EN ENTIDADES FINANCIERAS DE COSTA RICA. DEYLIN SEVILLA SEVILLA PROYECTO FINAL

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

El documento consiste en un resumen de los tres primeros capítulos de cada uno de los siguientes estándares:

El documento consiste en un resumen de los tres primeros capítulos de cada uno de los siguientes estándares: RESUMEN (Borrador) DE LOS CAPÍTULOS 1, 2 Y 3 DE LOS DOCUMENTOS Estándar de la Gestión de Programas Estándar de la Gestión de Portafolios Modelo de Madurez Organizacional en Gestión de Proyectos- OPM3 Nota

Más detalles

COMPILACION BIBLIOGRAFICA PMBOK - OPM3. Presentado por: LAURA MARCELA GIRALDO HOYOS Cód.: 1700622521

COMPILACION BIBLIOGRAFICA PMBOK - OPM3. Presentado por: LAURA MARCELA GIRALDO HOYOS Cód.: 1700622521 COMPILACION BIBLIOGRAFICA PMBOK - OPM3 Presentado por: LAURA MARCELA GIRALDO HOYOS Cód.: 1700622521 UNIVERSIDAD DE CALDAS INGENIERÍA DE SISTEMAS Y COMPUTACIÓN Manizales, septiembre de 2010 COMPILACION

Más detalles

Programa de Formación de Auditores

Programa de Formación de Auditores Programa de Formación de Auditores Sistemas de Gestión de la Calidad Módulo 2 Sistema de Gestión de la Calidad Requisitos Objetivo del módulo Comprender: Los requisitos de la norma ISO 9001:2008 para el

Más detalles

La Oficina de Proyecto PMO aporta valor? Basado en el estudio el Valor de las PMO realizado por Deloitte y Universidad Santa María

La Oficina de Proyecto PMO aporta valor? Basado en el estudio el Valor de las PMO realizado por Deloitte y Universidad Santa María La Oficina de Proyecto PMO aporta valor? Basado en el estudio el Valor de las PMO realizado por Deloitte y Universidad Santa María Conferenciante Ingeniero Informático, U de Chile, Diploma en Finanzas

Más detalles

Gestión del Alcance del Proyecto

Gestión del Alcance del Proyecto pm4dev, 2009 serie de gerencia para el desarrollo Gestión del Alcance del Proyecto GERENCIA DE PROYECTOS PARA ORGANIZACIONES DE DESARROLLO GERENCIA DE PROYECTOS PARA ORGANIZACIONES DE DESARROLLO Una metodología

Más detalles

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA)

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA) Espiñeira, Sheldon y Asociados * No. 12-2009 *connectedthinking Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción

Más detalles

Definición de PMO Características de una PMO

Definición de PMO Características de una PMO Definición de PMO Existen varios conceptos de una oficina de proyectos (PMO) una de ella la define como una unidad organizacional, física o virtual, especialmente diseñada para dirigir y controlar el desarrollo

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Análisis de estrategias para la gestión de proyectos informáticos. TFC Área de Gestión de Proyectos

Análisis de estrategias para la gestión de proyectos informáticos. TFC Área de Gestión de Proyectos Análisis de estrategias para la gestión de proyectos informáticos TFC Área de Gestión de Proyectos Consultor: Ana Cristina Domingo Trocho Autor: David Prado Romanillos Fecha de entrega: 10/01/2012 Índice

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PLAN DE GESTION DE CALIDAD DE LA EMPRESA M.S.D. CONSULTORES Y CONSTRUCTORES S.A., BAJO LA NORMA INTE-ISO/IEC 17020:2000. ING. MARGARITA SOTO DURAN PROYECTO

Más detalles

8.1 Arquitectura funcional

8.1 Arquitectura funcional 1 Colección de Tesis Digitales Universidad de las Américas Puebla Zuñiga, Víctor Alejandro 8.1 Arquitectura funcional La arquitectura de un sistema define sus componentes básicos y los conceptos importantes,

Más detalles

Gestión de las Adquisiciones. 30-11-2012 Gestión de las Adquisiciones - Proyecto FresKomercio

Gestión de las Adquisiciones. 30-11-2012 Gestión de las Adquisiciones - Proyecto FresKomercio Gestión de las Adquisiciones 30-11-2012 Gestión de las Adquisiciones - Proyecto FresKomercio Participantes Responsabilidad Propietario: Desarrollado por: Revisado por: Nombre / función FRESKOMERCIO Aitor

Más detalles

Máster en Gestión y Dirección de Proyectos Informáticos: IT Project

Máster en Gestión y Dirección de Proyectos Informáticos: IT Project Máster en Gestión y Dirección de Proyectos Informáticos: IT Project Management (Doble Titulación + 35 Titulación certificada por EUROINNOVA BUSINESS SCHOOL Créditos PDUs) Máster en Gestión y Dirección

Más detalles

Gerenciamiento de Proyectos. Estándar PMI. Cambio Organizacional UDELAR

Gerenciamiento de Proyectos. Estándar PMI. Cambio Organizacional UDELAR Gerenciamiento de Proyectos Estándar PMI Cambio Organizacional UDELAR Agenda Concepto de Proyecto Qué es la dirección de proyectos? PMI y Guía del PMBOK Dirección de Proyectos Áreas de Conocimiento 2 Definición

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

Cómo gestionar proyectos en condiciones de riesgo

Cómo gestionar proyectos en condiciones de riesgo 1 de 8 CLAVES PARA EL ÉXITO DE LOS PROYECTOS Cómo gestionar proyectos en condiciones de riesgo Las empresas necesitan desarrollar proyectos que exigen estructuras y tratamientos distintos a los tradicionales.

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

Universidad Latinoamericana de Ciencia y Tecnología. Email: jccplus@gmail.com

Universidad Latinoamericana de Ciencia y Tecnología. Email: jccplus@gmail.com 1 Máster en Administración con énfasis en Finanzas. Opta por la Maestría en Gerencia en Proyectos, de la Universidad Latinoamericana de Ciencia y Tecnología. Email: jccplus@gmail.com 1 TABLA DE CONTENIDO

Más detalles

Identificación de requerimientos

Identificación de requerimientos Licenciatura en Informática Administración de requerimientos Identificación de requerimientos Licenciatura en Informática Sirva este material como apoyo a los apuntes de la asignatura Administración de

Más detalles

CURSO DE DIRECCIÓN Y GESTIÓN DE PROYECTOS - PMP

CURSO DE DIRECCIÓN Y GESTIÓN DE PROYECTOS - PMP CURSO DE DIRECCIÓN Y GESTIÓN DE PROYECTOS - PMP Objetivos Generales: Adquirir los conceptos y las estrategias y practicar los procedimientos y técnicas necesarios para el desempeño de las funciones asociadas

Más detalles

5.1 Planificación del Alcance

5.1 Planificación del Alcance 5.1 Planificación del Alcance Procesos de un Área de Conocimiento Iniciación Planificación Ejecución Seguimiento y Control Cierre 4. Gestión de la Integración de s 4.1 Desarrollar el Acta de Constitución

Más detalles

El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los

El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los ALEXANDRA PSICA, CMC DIRECTORA GENERAL INTERIS CONSULTING INC. El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los objetivos de la organización, al nivel de riesgo inherente

Más detalles

SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES 2008

SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES 2008 SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES 2008 Por qué es Necesario Implementar un ERP? Las tendencias actuales y futuras están obligando a las empresas a aumentar su competitividad, por lo que

Más detalles

Mejorando las debilidades de RUP para la gestión de proyectos

Mejorando las debilidades de RUP para la gestión de proyectos RISI 7(2), 2010 (49-56) Revista de Investigación de Sistemas e Informática Facultad de Ingeniería de Sistemas e Informática Universidad Nacional Mayor de San Marcos ISSN 1815-0268 (versión impresa) ISSN

Más detalles

Fase de Planeación. Unidad

Fase de Planeación. Unidad Fase de Planeación. Unidad 2 Una etapa primordial en la gestión de un proyecto es la Planeación. Durante ésta se realizan actividades para estimar costos y recursos asegurando que el proyecto satisfaga

Más detalles

Gestión de Procesos de Negocios BPM

Gestión de Procesos de Negocios BPM GNU/LinuX Universidad Inca Garcilaso de la Vega XLIX CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO. Área: Gestión Gestión de Procesos de Negocios BPM Parte III: BPM Aspectos Técnicos

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

LOS INDICADORES DE GESTIÓN

LOS INDICADORES DE GESTIÓN LOS INDICADORES DE GESTIÓN Autor: Carlos Mario Pérez Jaramillo Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son señales para monitorear la gestión, así se asegura

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA PARA LA ELABORACIÓN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS PARA LA EMPRESA CONZULTEK. EBER HIDALGO RUIZ PROYECTO FINAL DE GRADUACION

Más detalles

MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DE ESTRATEGIA DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN

MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DE ESTRATEGIA DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN Página 1 de 20 MANUAL DE REGLAS DE NEGOCIO ASOCIADAS AL PROCESO DE ESTRATEGIA DEL SERVICIO DE TI PERTENECIENTES AL MACRO PROCESO GESTIÓN DE TECNOLOGÍA DE INFORMACIÓN VERSIÓN 001 Junio 2012 Página 1 Página

Más detalles

Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración

Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración Denominación de la materia SISTEMAS DE SOFTWARE N créditos ECTS = 36 carácter = OBLIGATORIO Ubicación dentro del plan de estudios y duración La materia Sistemas de Software está formada por 6 asignaturas

Más detalles

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT)

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT) CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO 6.1. Estructura Detallada del Trabajo (EDT) Un EDT es la agrupación orientada a entregables de los elementos del proyecto que organiza y define el total de los

Más detalles

Clase 1: Introducción a la Dirección y Gestión de Proyectos Clase 2: PMBOK (Project Management Body of Knowledge) Clase 3: Gestión de la Integración

Clase 1: Introducción a la Dirección y Gestión de Proyectos Clase 2: PMBOK (Project Management Body of Knowledge) Clase 3: Gestión de la Integración Project Management Objetivos - Adquirir los conocimientos y herramientas fundamentales aplicables al gerenciamiento de proyectos de acuerdo a la metodología de Project Management, contenidas en el Project

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO

SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO SEGURIDAD PARA EL ACCESO A LA INFORMACIÓN DE LAS ENTIDADES DEL ESTADO Programa de Gobierno en Línea Oficina de Coordinación de Investigación, Política y Evaluación. RESUMEN La seguridad de la información

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Administración del Tiempo en el Desarrollo de un Sistema de Información

Administración del Tiempo en el Desarrollo de un Sistema de Información Administración del Tiempo en el Desarrollo de un Sistema de Información José Jimmy Camacho Martínez (1) Ramón David Chávez Cevallos (2) Ing. Lennin Freire (3) Facultad de Ingeniería en Electricidad y Computación

Más detalles

Business Process Management(BPM)

Business Process Management(BPM) Universidad Inca Garcilaso de la Vega CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO Business Process Management(BPM) MSc. Daniel Alejandro Yucra Sotomayor E-mail: daniel@agenciati.com

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

Id. Componente del Procedimiento Responsable 1 Administración y Mantenimiento de Documentos y Registros Gerente Seguridad Operacional

Id. Componente del Procedimiento Responsable 1 Administración y Mantenimiento de Documentos y Registros Gerente Seguridad Operacional Fecha: 10/02/2010 Clave: SMS- Revisión: 1.0 Página: 1 de 7 I. OBJETIVO: La Organización busca tener información que le sea valiosa y le aporte esencia al sistema, que alimente a la organización con datos

Más detalles

ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA

ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ETB requiere que el CONTRATISTA cumpla los lineamientos para la Dirección y Gestión de proyectos, éstos últimos definidos a nivel corporativo

Más detalles

Sesión No. 11. Contextualización: Nombre de la sesión: SAP PAQUETERÍA CONTABLE

Sesión No. 11. Contextualización: Nombre de la sesión: SAP PAQUETERÍA CONTABLE Paquetería contable 1 Sesión No. 11 Nombre de la sesión: SAP Contextualización: Hasta la sesión anterior conocimos sobre distintas paqueterías contables, principalmente para pequeñas y medianas empresas

Más detalles

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do.

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do. Gobernabilidad de TI COBIT Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 2do. Cuatrimestre 2010 T. 2 Contenido Introducción a la Gobernabilidad de TI

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PLAN DE PROYECTO PARA CREACIÓN DEL NUEVO SISTEMA ADMINISTRADOR DE FONDOS KATTIA AJOY ARNAEZ

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PLAN DE PROYECTO PARA CREACIÓN DEL NUEVO SISTEMA ADMINISTRADOR DE FONDOS KATTIA AJOY ARNAEZ UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PLAN DE PROYECTO PARA CREACIÓN DEL NUEVO SISTEMA ADMINISTRADOR DE FONDOS KATTIA AJOY ARNAEZ PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL

Más detalles

GUÍA AVANZADA DE GESTIÓN DE PROYECTOS

GUÍA AVANZADA DE GESTIÓN DE PROYECTOS GUÍA AVANZADA DE GESTIÓN DE PROYECTOS Laboratorio Nacional de Calidad del Software Mayo 2009 NOTA DE EDICIÓN Esta guía ha sido desarrollada por el Laboratorio Nacional de Calidad del Software de INTECO.

Más detalles

Elementos de Control Interno para la Autoevaluación del Sistema de Control Interno Institucional 2015

Elementos de Control Interno para la Autoevaluación del Sistema de Control Interno Institucional 2015 Elementos de Control Interno para la Autoevaluación del Sistema de Control Interno Institucional 2015 Índice Pág. Metodología para la Autoevaluación del Sistema de Control Interno Institucional. 2 Elementos

Más detalles

UNIVERSIDAD NACIONAL DE INGENIERÍA

UNIVERSIDAD NACIONAL DE INGENIERÍA UNIVERSIDAD NACIONAL DE INGENIERÍA FACULTAD DE INGENIERÍA CIVIL EVALUACION DE LAS FASES DE ÉXITO EN EL PROYECTO CONSTRUCCION DEL ALMACEN DE PRODUCTOS TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE: INGENIERO

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

MANUAL DEL SISTEMA DE GESTIÓN DE LA CALIDAD - Versión 23. Basado en la norma ISO 9001:2008. Abril, 2014. 1. Índice. _Sección Contenido_

MANUAL DEL SISTEMA DE GESTIÓN DE LA CALIDAD - Versión 23. Basado en la norma ISO 9001:2008. Abril, 2014. 1. Índice. _Sección Contenido_ MANUAL DEL SISTEMA DE GESTIÓN DE LA CALIDAD - Versión 23 Basado en la norma ISO 9001:2008 Abril, 2014 1. Índice _Sección_ _Contenido_ 0 Carátula General 1 Índice 2 Acerca del Manual del SGC de FACPCE 2.1

Más detalles

INICIO PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO Y CONTROL CIERRE. Etapas de un proyecto. Conoce las 5 etapas por las que todo proyecto debe pasar.

INICIO PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO Y CONTROL CIERRE. Etapas de un proyecto. Conoce las 5 etapas por las que todo proyecto debe pasar. 1 2 Etapas de un proyecto Conoce las 5 etapas por las que todo proyecto debe pasar. Etapas de un proyecto Todo lo que debes saber INICIO para gestionarlas de manera eficiente PLANIFICACIÓN 3 4 5 EJECUCIÓN

Más detalles

ESTUDIO DE LA MADUREZ DE GESTIÓN DE PROYECTOS PARA EL C.E.E.

ESTUDIO DE LA MADUREZ DE GESTIÓN DE PROYECTOS PARA EL C.E.E. ESTUDIO DE LA MADUREZ DE GESTIÓN DE PROYECTOS PARA EL C.E.E. Henry Paúl Dávila Egresado del Programa Administración de la Construcción, de la Universidad de las Fuerzas Armadas ESPE, henrypauldavila@gmail.com.

Más detalles

ERP. SOLUCIÓN PARA PYMES?

ERP. SOLUCIÓN PARA PYMES? ERP. SOLUCIÓN PARA PYMES? Febrero 2011 Introducción La Planificación de Recursos Empresariales, o simplemente ERP (Enterprise Resourse Planning), es un conjunto de sistemas de información gerencial que

Más detalles

GESTION DE PROYECTOS SEGÚN LA GUIA DEL PMBOK

GESTION DE PROYECTOS SEGÚN LA GUIA DEL PMBOK GESTION DE PROYECTOS SEGÚN LA GUIA DEL PMBOK Rocío Zelada Rück AGENDA Introducción a algunos conceptos clave Qué es un proyecto? La múltiple restricción La administración de proyectos Qué es un Gerente

Más detalles

TEMA 6.- LA PUESTA EN MARCHA DE PROYECTOS. LOS ASPECTOS A TENER EN CUENTA

TEMA 6.- LA PUESTA EN MARCHA DE PROYECTOS. LOS ASPECTOS A TENER EN CUENTA TEMA 6.- LA PUESTA EN MARCHA DE PROYECTOS. LOS ASPECTOS A TENER EN CUENTA El Programa para el Fomento de la Intraemprendeduría en Ciclos Formativos de Formación Profesional es un proyecto financiado por

Más detalles

Sistematización y automatización de procesos en el BBVA de Paraguay con SharePoint 2010

Sistematización y automatización de procesos en el BBVA de Paraguay con SharePoint 2010 SharePoint Server Caso de éxito Sistematización y automatización de procesos en el BBVA de Paraguay con SharePoint 2010 Resumen Región: Paraguay Industria: Banca Perfil del cliente BBVA es un grupo financiero

Más detalles

Crítica constructiva de los Sistemas de Gestión de la Calidad (Según la norma ISO 9001:2000)

Crítica constructiva de los Sistemas de Gestión de la Calidad (Según la norma ISO 9001:2000) Crítica constructiva de los Sistemas de Gestión de la Calidad (Según la norma ISO 9001:2000) El año que inicia nos traerá una nueva versión de la norma ISO 9001, para los Sistemas de Gestión de la Calidad,

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA

UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA UNIVERSIDAD ALBERT EINSTEIN FACULTAD DE INGENIERIA Estudio de las herramientas TOAD y DBArtisan para la administración e integración de bases de datos relacionales. PREVIA OPCION AL TÍTULO DE: INGENIERO

Más detalles

UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI) PROPUESTA DE UN PLAN DE GESTIÓN DE PROYECTOS PARA LA INSTALACIÓN DE CABLEADO ESTRUCTURADO PARA INTEGRADORES DE SISTEMAS. LUIS DIEGO LOPEZ O. PROYECTO

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Quinta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

Modelos de Madurez en la Administración de Proyectos. Prof. Bernardo López González, MAP

Modelos de Madurez en la Administración de Proyectos. Prof. Bernardo López González, MAP Modelos de Madurez en la Administración de Proyectos Prof. Bernardo López González, MAP Modelos de Madurez en la Administración de Proyectos Existen varios estándares que en materia de administración de

Más detalles