Mejora de Proceso en Proyectos de Desarrollo de Sol ...Para solucionar este problema en este...

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información

1

Mejora de Proceso en Proyectos de Desarrollo de Soluciones de Arquitectura Tecnológica de Middleware Oracle mediante la

Aplicación de Framework OEAF

Denny R. Alquinta Donders1

Huechuraba, Región Metropolitana de Santiago

[email protected] +56940135014

Resumen: En el contexto de venta y ejecución de servicios de consultoría, se consideran una serie de etapas las cuales están orientadas a capturar la necesidad tecnológica del cliente la cual finalmente es resumida en la individualización de productos y sus correspondientes requerimientos de licencias y servicios para implementarlas. Sin embargo, existe una falta de cohesión entre el proceso de venta de servicios y licencias con la implementación del proyecto en los clientes al sólo estimar los esfuerzos requeridos individualizados en jornadas-ingeniero pero en ninguna de éstas etapas se realiza una especificación técnica detallada del cómo se llevará a cabo la entrega del servicio. Como consecuencia, ésta brecha detectada en los procesos ocasiona pérdida de eficiencia y por ende, incremento en el costo e impacto en el margen de los proyectos. A partir de la aplicación de Oracle Enterprise Architecture Framework (basado en TOGAF) se propone realizar una serie de artefactos de arquitectura los cuales eliminarán o reducirán significativamente la brecha descrita. Se espera que ésta propuesta logre impactar positivamente en el margen neto de cada proyecto, eliminando los problemas de ejecución de estos al ahorrar tiempo en dictar la especificación técnica de implementación. Como método de validación, se compararán proyectos desarrollados con y sin ésta propuesta metodológica, estableciendo medidas objetivas que permitan comparar el impacto de ésta y comprobar si se producen mejoras. Palabras Clave: Soluciones de middleware, Arquitectura tecnológica, OEAF de Oracle, Estimación de esfuerzo y costos.

1 Introducción

Las compañías de consultoría poseen una vasta cantidad de oferta de servicios orientados a proveer soluciones técnicas de software y hardware que satisfagan las necesidades de negocio de sus clientes. Por ello, distintas áreas de las organizaciones internas de la compañía deben trabajar en cadena con el objetivo de lograr realizar el desarrollo y entrega de los proyectos relacionados a cubrir una problemática específica planteada por el mandante y satisfacer sus requerimientos. Luego de que el autor participara en una serie de proyectos en los cuales se han enfrentado dificultades, mayormente debidas al re-trabajo producto de la falta de definición y especificación en soluciones inicialmente propuestas, se detecta una falta de cohesión entre el proceso de venta de servicios, licencias y la implementación del proyecto tecnológico ya que sólo se estiman los esfuerzos requeridos individualizados en jornadas-ingeniero, sin embargo en ninguna de éstas etapas se realiza una especificación técnica detallada del cómo se llevará a cabo la entrega del servicio. Consecuentemente, ésta brecha detectada en los procesos ocasiona pérdida de eficiencia y por ende incremento en el costo e impacto en el margen de utilidad de los proyectos. Para solucionar este problema en este proyecto de tesina se propone la aplicación de Oracle Enterprise Architecture Framework, con el fin de definir y construir Artefactos de Arquitectura orientados a optimizar los esfuerzos y costos de entrega de proyectos de Middleware Oracle. Ésta tesina comienza por explicar el marco teórico y estado del arte, para luego plantear la hipótesis y la forma de comprobarla. Luego se analiza el estado actual, presentar la validación de propuesta para finalizar con el análisis de resultados y sus respectivas conclusiones.

1 Ingeniero Civil en Computación e Informática. Licenciado en Ciencias de la Ingeniería




2

2 Marco Teórico y Estado del Arte

2.1 Marco Teórico

Según Marianne Rønnebæk [1], el concepto básico de una buena arquitectura es que esté orientada a los principios. Ésto significa que primero son analizados los requerimientos de negocio, para luego en base a un diseño conceptual, establecer una base de trabajo fundamentada en principios para la organización y selección de componentes técnicos. El trabajo arquitectónico debe asegurar coherencia entre los requerimientos planteados y los principios definidos, con el fin de garantizar que la solución implementada será en base a la necesidad detectada y que los principios identificados siempre tienen base en los requerimientos de negocio (trazabilidad de los requisitos). Por ello, el objetivo de cualquier metodología de diseño de una arquitectura es asegurar que la visión y objetivos requeridos son cumplidos a cabalidad.

Los diferentes frameworks de arquitectura, en general presentan en común los siguientes 5 principios [1]:

- Interoperabilidad: La habilidad de los sistemas computarizados o de software de poder intercambiar y hacer uso de información.

- Seguridad: La capacidad de proteger el software ante cualquier ataque o intervención maliciosa, o cualquier otro peligro que ponga en riesgo la continuidad operacional de una solución de software.

- Apertura: La capacidad de un software de operar con estándares, interfaces, especificaciones y códigos abiertos y conocidos.

- Flexibilidad: El atributo mediante el cual un software puede adaptarse a cambios externos. - Escalabilidad: La característica de un sistema, modelo o función que describe la capacidad de soportar y

desempeñarse ante un constante incremento de su carga de trabajo. - Junto con ello, un sexto principio no documentado por [1], denominado Alta Disponibilidad, definida como la

capacidad de un sistema de garantizar un cierto nivel de servicio operacional, ante situaciones adversas.

De acuerdo a la definición entregada por Wikipedia [2]:

“La Arquitectura TI está dada por el proceso metodológico de especificaciones de tecnologías de la información, modelos y guías de implementación, utilizando una serie de notaciones, por ejemplo UML, dentro de un framework TI coherente, dando por resultado una solución de tecnología empresarial”.

Dentro del contexto de coherencia y con el fin de cumplir los 6 principios nombrados con anterioridad, se define el concepto de Building Block el cual especifica la manera en la cual se categorizan los componentes para definir una arquitectura de referencia. En 2004, Ramesh y Rakesh Radhakrishnan [3] definen los Building Blocks como Entidades de Arquitectura conocidas y modelos específicos de diseño, las cuales dan sustento al uso de patrones y frameworks de arquitectura. Por otra parte, en 2017 para Sjaak Laan [4] la infraestructura TI está basada en “Building Blocks” dados por la siguiente Figura 1.

Figura 1. Building Blocks Arquitectura TI.




3

Ésta define atributos no funcionales transversales a las soluciones entregadas, dadas en las dimensiones de Disponibilidad, Performance y Seguridad.

Con ello, se puede deducir que los Building Blocks son parte fundamental en los Frameworks de Arquitectura modernos.

En la actualidad, según la revista Forbes [5] TOGAF es el Framework de Arquitectura Empresarial que goza de mayor popularidad en la industria, definido por la estructura base expuesta en la Figura 2. [6].

Figura 2. Diagrama de Componentes de TOGAF ADM.

En la ejecución de los proyectos TI, el foco de este trabajo está en la etapa D del ciclo de TOGAF ADM. El modelo TOGAF define en ésta etapa los siguientes Building Blocks en dos niveles [7]:

- Architecture Building Block (ABB): Típicamente describe la capacidad requerida y define la forma de la especificación que está dada por un SBB. Este punto es equivalente con la definición de Laan [4]. - Solution Building Block (SBB): Representa el componente que será implementado para cubrir la capacidad

requerida. Este punto es equivalente con la definición de los hermanos Radhakrishnan [3].

Para la ejecución de un proyecto se requiere del uso de un framework coherente, el cual sea capaz de decantar en artefactos orientados a ser seguidos por el equipo de ejecución y respetados con el fin de minimizar el re-trabajo. Para el presente trabajo, se selecciona una variación propietaria de TOGAF, denominada Oracle Enterprise Architecture Framework (OEAF). Este es un Framework de Arquitectura el cual define artefactos específicos a producir en cada etapa de iteración. La Figura 3, define los Building Blocks de OEAF.

Figura 3. OEAF Building Blocks.




4

Como fue definido anteriormente, el proceso descrito en el Punto D del modelo TOGAF es el foco de este trabajo. Para OEAF, este punto se define dentro del Building Block denominado Technology Architecture [8]. Este define la producción de SBB en 4 capas de iteración consecutivas entre sí, en forma de vistas, las cuales están orientadas a documentar la solución a implementar, realizando el diseño de especificaciones de acuerdo a la necesidad del cliente. Este modelo itera basada en una Oracle Reference Architecture (ORA) [9], el cual define las referencias necesarias para establecer los conceptos de Modelo de Referencia, Arquitectura de Referencia y Arquitectura de Detalle. - Vista Conceptual: Realiza un mapeo lógico de capacidades requeridas por el cliente, típicamente en un documento

RFP [10] y las funcionalidades que buscan ser cubiertas en un macro-concepto tecnológico. Usualmente ayuda con la contextualización de la solución en una etapa temprana de desarrollo.

- Vista Lógica: Realiza una vista de componentes técnicos, traslapando el escenario anteriormente descrito y definiendo las interacciones entre dichos componentes. Ésta realiza una definición de los estándares de tecnología que se utilizarán en la implementación de la solución. Ésta se basa en la correspondiente arquitectura de referencia.

- Vista de Product Mapping: Realiza un traslape entre la etapa anterior y el producto o tecnología especifica mediante la cual Oracle cubre la necesidad detectada.

- Vista de Deployment: Realiza un diseño detallado de cómo se despliegan las tecnologías de la solución identificadas en el punto anterior, conformando una especificación para la ejecución del proyecto.

OEAF propone la creación de distintos SBB, con el fin de cubrir las dimensiones descritas de los cuales se implementaran los siguientes:

- Documento de Arquitectura de Delivery: Documento formal que detalla las 4 vistas anteriormente descritas, especificando cómo será desplegada la solución basada en las definiciones de OEAF, además cumpliendo con los 6 principios previamente definidos por Rønnebæk.

- Enterprise Deployment Workbook: Planilla de cálculo que especifica el detalle de la solución a implementar, con el fin que el ejecutor del proyecto dedique su trabajo a la entrega y no al diseño. Ésta planilla está parcialmente basada en lo que se entrega de manera oficial mediante la documentación disponible en [11]

- Artefactos de Automatización de Deployment: Artefactos de código orientados a la automatización de la post-configuración de ambientes.

2.2 Estado del Arte

Al momento de realizar una estimación de esfuerzos por parte de las áreas de ventas de la organización en estudio, ésta se hace en base a Software Delivery Kits, los cuales son cálculos estimativos en base a la complejidad de instalación y configuración de cada componente estimado en las etapas iniciales de cubicación de licencias. Éstas son puestas en una matriz de estimación, la cual termina por dar un total de Jornadas-Ingeniero que son negociadas en la etapa de venta con el cliente y luego son administradas por el jefe de proyecto. Ésta estimación no comunica ningún tipo de especificación de arquitectura tecnológica ni lineamientos de implementación, sino que solamente acota el tiempo de ejecución del proyecto. Por efectos de confidencialidad los valores descritos en este punto serán ofuscados.

Como fue investigado en el marco teórico de ésta propuesta, la implementación de proyectos de tecnología basados en Frameworks de Arquitectura, está orientada principalmente a optimizar el uso de recursos. En empresas del mismo calibre que Oracle, existen distintas propuestas de arquitecturas derivadas de TOGAF, las cuales buscan objetivos similares a los descritos recientemente.

La totalidad de las ofertas revisadas proponen soluciones en base a una arquitectura de referencia con respecto a algún tipo de tecnología en particular, como lo hace Microsoft [12] en su documento de IoT. Aquí se describen conceptos similares a los definidos por Rønnebæk.en [1]; además, agrega conceptos como heterogeneidad, definiéndolo de manera similar a la flexibilidad por Rønnebæk.

IBM [13] por otra parte, desde hace más de 10 años ha declarado principios similares, además de agregar los tipos de stakeholders requeridos para un diseño exitoso. Estos son divididos en dos tipos de arquitectos. Un Enterprise Level Architect, el cual planea la infraestructura a nivel general que dará cobertura a las necesidades planteadas por el cliente; mientras que un Application Technical Architect entiende a bajo nivel las tecnologías que soportarán los diseños preliminares, soportando cada Building Block de la manera más efectiva, dando soporte al rendimiento, conectividad y seguridad requerida.




5

Por otra parte, AWS [14] mediante su publicación de Well Architected Services también incurre en nombrar principios de arquitectura basales como los mencionados por Rønnebæk [1], agregando la variable de optimización de costos y definiéndola como la habilidad de evitar o eliminar costos innecesarios o recursos sub-óptimos. Sin embargo en contraposición a lo implicado por Oracle, IBM y Microsoft, AWS realiza una organización clásica del cómo se debe organizar un equipo de arquitectura, no dividiéndolos por funciones, sino que diluyendo su responsabilidad en equipos no expertos. Recogiendo los 6 principios de arquitectura, más las definiciones sobre una arquitectura de referencia, los diferentes roles y tipos de arquitectos que influyen en el diseño de una solución y la optimización de costos que pretende la solución final, el presente trabajo propone entregar un diseño técnico end-to-end de una solución de Middleware para una organización en particular, la cual medirá la eficiencia de su aplicación mediante el estudio real de esfuerzo utilizado en la implementación del proyecto versus el tiempo estimado en sus etapas de preventa, el cual podrá demostrar su eficacia y validar la hipótesis trazada.

3 Propuesta de Investigación

3.1 Propuesta de Solución

Se aplicará OEAF en la producción de una serie de artefactos de arquitectura, los cuales luego de su implementación comprobarán empíricamente la reducción de uso de jornadas en la implementación del proyecto.

3.2 Hipótesis

La presente tesina propone que la aplicación de un Framework de referencia como OEAF, mejorará la entrega de soluciones consultivas de tecnología, impactando positivamente en la rentabilidad obtenida en el proyecto disminuyendo las jornadas ocupadas en un set de actividades detectadas como consumidores extremos de tiempo. Se selecciona además ésta metodología al estar altamente adaptada a productos Oracle, específicamente en soluciones de Oracle Fusion Middleware.

3.3 Metodología para validar la Hipótesis

La validación de la efectividad que propone la metodología de trabajo será mediante la evaluación de su aplicación a tres proyectos tecnológicos de consultoría de similares características, comparando los esfuerzos estimados inicialmente por parte de Preventas de Servicios y lo realmente utilizado en la implementación. Los resultados se medirán en función de la eficiencia económica del ahorro, calculado en monedas referenciales ficticias y realizando comparaciones porcentuales de éstas. Se considerará un caso de control, donde no se aplique la metodología y dos escenarios donde sí se haga, donde el primero es aplicación desde cero y el segundo escenario reutilizan los colaterales producidos en el caso anterior.

3.4 Objetivos Específicos.

Los siguientes son los objetivos específicos considerados en el desarrollo de este trabajo:

Identificación de artefactos de arquitectura a ser considerados en el diseño de la propuesta metodológica, usando como referencia OEAF.

- Definición de indicadores que se considerarán en la validación. - Aplicación de la metodología a tres casos de prueba de concepto y medición de los tiempos de implementación e

impacto en margen. - Análisis e interpretación de los resultados.




6

4 Análisis de la Situación Actual en el Caso de Estudio

4.1 Contexto

Advanced Customer Services (ACS) es una organización de consultoría dentro de Oracle Corporation, la cual entrega servicios expertos de implementación, integración e instalación de productos Oracle a clientes del sector privado y público. El proceso de interacción con el cliente, comienza cuando se detecta una necesidad por parte del área de ventas de licencias, que vía procesos de levantamiento, cubica la venta de productos específicos adecuados para resolver la necesidad planteada. En este proceso inicial, solo se realiza un diseño arquitectónico conceptual, contemplando un mapeo 1:1 entre la necesidad expuesta por el cliente y el producto Oracle que la satisface, realizando la individualización de licencias relacionadas a éste. Este proceso finaliza con la venta de un conjunto de licencias a ser utilizadas por el cliente, ya sea en un ambiente on-premise o cloud. Según [15], Oracle Advanced Customer Services (ACS) es una organización altamente especializada en tecnologías Oracle, la cual provee desde hace más de 20 años servicios globales personalizados a las necesidades de sus clientes. En el contexto de este trabajo de tesina, los servicios prestados por ACS se focalizarán en la rama de Oracle On-Site Support la cual provee de los siguientes servicios:

- Technical Account Manager (TAM) [16]: Proporciona de la experiencia y orientación técnica durante la ejecución de un proyecto y luego el soporte para una adopción más rápida de la tecnología que se implementó. Un TAM trabaja con el cliente en cada paso del proyecto, brindando la planificación y gobierno basado en las mejores prácticas y la optimización de procesos, sin perder de vista los requisitos tecnológicos y los objetivos comerciales trazados en etapas tempranas.

- Advanced Support Engineers (ASE) [17]: Aseguran que las tecnologías Oracle implementadas en el proyecto se instalen y configuren de forma correcta y optimizada de acuerdo a las mejores prácticas de Oracle. Son ingenieros experimentados que aprovechan la experiencia de Global Customer Support y los equipos de desarrollo de Oracle para proveer soluciones integradas que se adapten a las necesidades del cliente. Luego de implementado el proyecto, se aseguran de utilizar herramientas de diagnóstico y monitoreo para anticipar, identificar y remediar problemas para todos los sistemas de misión crítica ofrecidos por Oracle.

- Datacenter Engineers (DCE): Ingenieros especializados en la instalación y configuración de Servidores y Storage, optimización de recursos y sistemas localizados en Datacenter de terceros, entre otros.

4.2 Definición del Problema

En la empresa donde se realizará el estudio de ésta propuesta de investigación, existen ocasiones en que el cliente requiere de la ayuda experta para la implementación de los productos adquiridos. En estos casos, el cliente solicita frecuentemente los servicios de ACS con el fin de realizar la implementación, donde el área de Venta de Servicios cumple el objetivo de realizar un cálculo exhaustivo para estimar el esfuerzo requerido para implementar la solución definida en el paso anterior. El resultado de ésta estimación consiste en definir las horas hombre (definidas como Jornadas-Ingeniero) requeridas para ejecutar la implementación del proyecto, dando inicio a un proceso denominado Sales to Delivery Handover (S2DH). Este segundo proceso tiene por objetivo entregar a la organización de ACS el alcance del proyecto, los productos y licencias a instalar y la cantidad de horas vendidas para su ejecución. Como puede verse en la Figura 4, cuando se completa el segundo proceso, el correspondiente TAM asignado debe iniciar la ejecución del proyecto, buscando recursos de Ingeniería (ASE) en los pilares técnicos disponibles, finalizando el proceso con la entrega de la solución. Los tres procesos anteriormente descritos tienen una falla fundamental. El autor luego de participar y observar la ejecución de numerosos proyectos, ha llegado a la conclusión de que la falta de una definición arquitectónica a bajo nivel, la que será implementada por ACS Ingenieria afecta directamente el tiempo de ejecución y, como consecuencia, en la rentabilidad real del proyecto. Ninguno de estos procesos realiza una especificación técnica detallada y precisa para realizar la implementación del proyecto, lo que genera retrasos en el inicio y ejecución de éste. Por lo tanto, el equipo técnico tiene solo una clara definición del qué, pero no del cómo realizar la ejecución del proyecto.




7

Figura 4. Procesos Centrales de un Proyecto en el Ciclo de Vida del Desarrollo de una Solución.

4.3 Estimación de Licenciamiento Relacionada a Implementación

El cálculo de licenciamiento es un proceso clave para realizar una instalación correcta y que quede en concordancia con las reglas de licenciamiento especificadas por Oracle. Éstas se realizan en base a tres factores distintos, según lo consultado en [18] [19] y [20] el cálculo se realiza de la siguiente manera:

Para Ambientes Productivos (PRD, QA)

Tabla 1. Calculo de Licenciamiento para Ambientes Productivos y Quality Assurance.

Processor Perpetual Core vCPU

� 2� 4�

Para Ambientes Pre-Productivos (DEV)

Tabla 2. Calculo de Licenciamiento para Ambientes de Desarrollo.

NUP Core vCPU

�

��: �� :�� → � � 2�

��

��: �� : �� → � � 2�

�

2�

Este cálculo debe realizarse al momento de la implementación, cuando el licenciamiento ya se encuentra otorgado y se comienza a realizar la instalación del software relacionado.

4.4 Estimación de Esfuerzos y Desagregación de Costos

Cada tipo de proyecto cuenta con una pre-cubicación de esfuerzos dada por un Software Delivery Kit la cual describirá unidades de dinero estándar para este trabajo. Este estima los esfuerzos estándar (en jornadas laborales de 8 horas) y las correspondientes tarifas que corresponden a éste. Éstas son estimadas en dos rangos: Ingeniero Estándar e Ingeniero Senior. Por efectos de mantener confidencialidad en el caso de estudio, se define una Unidad Monetaria de Trabajo ($UMT) orientada a mostrar las relaciones económicas y mantener la consistencia de este trabajo. Estas unidades no tienen ninguna relación con los valores reales ni guardan ninguna proporción con ellas. La siguiente tabla establece la relación de una jornada, separada por Ingeniero Estándar e Ingeniero Senior:

Arquitectura de Licencias

• Orientado a aplicar un marco conceptual de solucion y detectar la problematica especifica del cliente para luego realizar un mappeo 1:1 entre el problema y el software Oracle a utilizar para resolverlo

• Produce como resultado la venta de licencias de software para el uso on-premise o cloud de softwares de Oracle

Arquitectura de Servicios

• Orientado a diseñar el esfuerzo y prizing del proyecto en relacion a la ejecucion de las licencias detectadas en el proceso anterior. Se apoya por ingenieros de preventa tecnicos, los que tienen conocimientos de mediana profundidad en los productos a implementar

• Produce como resultado un contrato de servicios para el cliente, con el fin de implementar la solucion donde el cliente requiera hacerlo

Delivery de Proyecto

• Orientado a realizar la implementacion (Delivery) del proyecto diseñado en los procesos anteriores. El area Tecnica de ACS, Liderado por un Project Manager, Instala, configura y documenta la solucion, en los parametros establecidos en pasos anteriores (sizing de acuerdo a licenciamiento, esfuerzo cubicado por Venta de Servicios)

• Produce como resultado la instalacion y configuracion del software adquirido, basado en el licenciamiento disponible con el fin de disponiblizar la infraestructura requerida por el cliente para cubrir la necesidad detectada.




8

Tabla 3. Relación de Perfil de Ingeniero vs Tarifa por Jornada ($UMT)

Tipo de Ingeniero Costo ($UMT)/Jornada Tarifa ($UMT)/Jornada

Ingeniero Estándar $100 $190 Ingeniero Senior $160 $320

Para efectos de ésta tesina, se define el Software Delivery Kit el cual permite realizar la desagregación de costos y tarifas en función de $UMT, para el producto de Oracle Fusion Middleware, Oracle Service Bus (OSB). Éste tipo de implementación es una de las más comunes dentro del trabajo realizado por la organización, por lo que se selecciona como caso de prueba, en función de su estimación estándar de esfuerzos. Este Kit estima los esfuerzos relacionados a realizar la instalación y configuración de OSB teniendo los siguientes supuestos:

- La instalación será adecuada a la necesidad del cliente. - Solo se realizarán instalaciones certificadas al momento de realizar el proyecto. - Se aplicarán los últimos parches recomendados disponibles a la fecha de finalizar el proyecto. - Se aplicarán donde fuere posible, las mejores prácticas de software. - Se incluyen 6 instancias dentro de un cluster para la instalación del software. - Se deben tener al menos 3 ambientes disponibles para efectos de Producción (PRD), Quality Assurance (QA) y

Desarrollo (DEV). - Este set de esfuerzos no incluye la estimación de Instalación y Configuración de Base de Datos, por no ser un

producto de Middleware. - Se provisiona un total de 10% adicional de costo y tarifa por imprevistos y riesgo.

Con los puntos antes definidos, se establece el siguiente Software Delivery Kit, que establece la relación entre actividades, esfuerzos y perfil de ingeniero por ambiente:

Tabla 4. Des-agregación de costos en función de Tareas y Entregables vs Perfil requerido, Costo, Tarifa en $UMT AS-IS.

Descripción de Tarea Perfil Ingeniero

Costo Jornadas

Costo Ingeniero ($UMT)

Tarifa ($UMT)

Coordinación con Jefe de Proyecto Senior 0,5 $ 80 $ 160 Realizar reunión preliminar de orientación y contexto

Senior 0,5 $ 80 $ 160

Revisar documentación disponible Estándar 0,5 $ 50 $ 95 Creación de Máquinas Virtuales requeridas

Senior 1 $ 160 $ 320

Creación de Puntos de Montaje y Configuración en OS

Senior 1 $ 160 $ 320

Ejecutar Repository Creation Utility e Instalar binarios de productos relacionados

Estándar 2 $ 200 $ 380

Aplicar parches mandatorios y realizar si se aplica, configuraciones post-instalación

Estándar 1 $ 100 $ 190

Configurar Sistema (6 instancias) Senior 15 $ 2.400 $ 4.800 Realizar validación de configuración Estándar 1 $ 100 $ 190 Preparar documentación relacionada Senior 2 $ 320 $ 640 Realizar reunión final de revisión de documentación de instalación y recomendaciones

Senior 1 $ 160 $ 320

Total 25,5 $ 3.810 $ 7.575 Total, más Riesgo Estándar (10%) 28,05 $ 4.191 $ 8.333

Las actividades descritas están diseñadas para alcanzar un margen esperado del 50%.




9

4.5 Proceso de Implementación de Proyecto

En el actual contexto de ejecución de proyectos de tecnología, el TAM procede a ejecutar los siguientes pasos mostrados en la Figura 5.

Figura 5. Proceso de Partida de Proyecto AS-IS.

Según el Software Delivery Kit definido, el trabajo asociado ahora debería seguir el siguiente flujo:

Figura 6. Proceso de Delivery de Proyecto de Software AS-IS.

Sales to Delivery

Handover

• El area de ventas de servicio, puntualiza los servicios vendidos al cliente y entrega el scope acordado via contratos, detallando los entregables acordados y los plazos determinados para la ejecucion total de el proyecto, entregando el esfuerzo cubicado.

Busqueda de recursos

ASE

• En funcion de la especialidad requerida para el proyecto, el TAM procede a buscar recursos en forma global, para ejecutar el proyecto. Estos recursos son asignados de forma manual via un Resource Manager, el cual de acuerdo a la utilizacion del ingeniero y al nivel de seniority y expertise requerida asigna al recurso para el trabajo

Ejecucion del Proyecto

• El ingeniero asignado, comienza la ejecucion del proyecto, basado solo en lo determinado por el set de actividades identificadasen el Kit de Entrega de Software, sin embargo no cuenta con estandares de instalacion ni guia de implementacion.

• Etapa preliminar donde el Jefe de Proyecto se reune con el equipo asignado al proyecto con el fin de explicar el alcance, tareas y entregables del proyecto a ejecutar1. Coordinacion con Jefe de Proyecto

• Reunion inicial con el cliente, conocida como Kick-Off. 2. Reunion Preliminar de Contexto

• Los ingenieros asociados al proyecto, revisan la documentacion relacionada a los productos a instalar y configurar con el fin de iniciar la ejecucion del proyecto3. Revision de Documentacion Disponible

• Se inicia la creacion de las maquinas virtuales asociadas al proyecto a configurar. Estas deben contener la cantidad correcta de vCPU y los puntos de montaje requieridos para iniciar la instalacion de binarios

4. Creacion de Maquinas Virtuales

• Creacion de los correspondientes puntos de montaje en la unidad de storage, con la quota de disco correspondiente y la presentacion de estos a las maquinas donde se

realizara la implementacion del software

5. Creacion de Puntos de Montaje y Configuración en OS

• Se inicia la instalacion de binarios de la solucion adquirida. Ademas se realiza la configuracion de los esquemas de base de datos requeridos para la configuracion del OSB

6. Ejecucion de RCU e Instalacion de Binarios

• Se realiza la configuracion e instalacion de los ultimos parches disponibles en My Oracle Support, con efecto de dejar la plataforma cubierta contra los ultimos y mas comunes problemas reportados globalmente. Esto tipicamente implica implementar los ultimos PSU disponibles para la plataforma

7. Aplicacion de Ultimos Parches

• Conlleva la creacion y configuracion de los dominios asociados a Oracle Service Bus. Realizar la configuracion inicial de los 6 servidores mas la instancia de administracion, luego la configuracion completa del dominio para utilizar MAA/OFA/EDG y luego la configuracion de automatizacion de manejo de ciclo de vida de este.

8. Configuracion de Sistema

• Validacion basica del funcionamiento del dominio y la correspondiente recoleccion de evidencias necesarias para realizar la documentacion de la instalacion y configuracion.

9. Validacion de Instalacion

• Preparacion de la documentacion asociada al proyecto, conocida como SiteLog. Esta es la evidencia requerida para finalizar el hito de facturacion del proyecto10. Preparacion de Documentacion

• Reunion de entrega y clarificacion de dudas por parte del cliente. 11. Reunion de Finalizacion




10

4.6 Identificación y Diagnóstico de Áreas de Impacto utilizando OEAF

En función de las sucesivas experiencias de implementación de proyectos tecnológicos, se determina que los puntos que se encuentran en el alcance inmediato es conseguir mediante la aplicación de la metodología la reducción de los costos asociados a la instalación y configuración del software con el fin de incrementar el margen de utilidad del proyecto. Estos costos se encuentran asociados a los puntos descritos en la Tabla 4 y Figura 6 respectivamente. Después de la aplicación de criterio experto (por parte de los TAM asociados a los proyectos evaluados y los ASE asociados a éstos) sobre estas actividades, se definen que los siguientes puntos son foco común de re-trabajo durante la implementación debido a la falta de definición para la implementación:

- Coordinación con Jefe de Proyecto: Definido en el punto 1 de la Figura 6, este proceso está mayormente afectado por el hecho de que los jefes de proyecto no cuentan como parte de función tener un perfil técnico profundo, lo cual genera una serie de retrasos en la definición inicial del proyecto. Ésta etapa suele tener muchas iteraciones sin tener una definición técnica clara para comenzar la implementación.

- Creación de Máquinas Virtuales y puntos de Montaje requeridos: Definido en el punto 4 de la Figura 6, este punto es típicamente afectado por la inexistencia de un cálculo correcto de licenciamiento lo que se traduce a la creación de infraestructura con la cantidad incorrecta de vCPU y puntos de montaje requeridos para que la solución funcione correctamente, segregando la instalación en puntos factibles de respaldo en caso de desastre. Para efectos de des-agregación, como fue definido en la Tabla 4, este punto significa una estimación base de 2 Jornadas de Perfil Ingeniero Senior, por cada ambiente configurado.

- Configurar Sistema: Definido en el punto 7 de la Figura 6, este punto es afectado por la inexistencia de un estándar de implementación, lo que causa errores en la instalación y configuración de los productos, teniendo que realizarlos nuevamente de forma frecuente. Éste punto en particular funciona como variable dependiente de la cantidad de instancias a configurar, por lo que en la mayoría de los casos es el punto que tiene mayor impacto en el adelanto o retraso del proyecto. Para efectos de des-agregación, como fue definido en la Tabla 4, este punto significa una estimación base de 15 Jornadas de Perfil Ingeniero Senior y verifica que es el punto más sensible de la instalación y configuración de la solución entregada.

Mediante los SBB y ABB definidos por OEAF, se construirán los artefactos requeridos para que éstas áreas sufran de menor impacto al reducir la incertidumbre de implementación. Con ello se espera reducir las jornadas invertidas en dichos puntos y como consecuencia reducir los costos asociados.

5 Propuesta de Solución

5.1 Resumen de propuesta

La solución propuesta se enfoca a reducir la brecha de incertidumbre que existe en la estimación de esfuerzos que se produce entre el segundo proceso de venta del servicio y el tercer proceso donde se realiza la implementación real, agregando una fase facturable de Arquitectura de Delivery, orientada mediante OEAF al diseño y construcción de especificaciones más precisas, que redunde finalmente en reducción de gasto de jornada y por ende ahorro de costos, evitando el re-trabajo debido a implementaciones erróneas. Éstas especificaciones permitirán diseñar todos los puntos de error detectados por el autor en las implementaciones on-site y reutilizar la mayor cantidad de artefactos producidos con el fin de disminuir los tiempos de ejecución y aumentar el margen de cada proyecto. Con ello, se propone la inclusión de la etapa denominada Delivery Architecture entre los pasos 2 y 3 definidos en la Figura 6, transformándolo en el Proceso de Delivery de Proyecto TO-BE.

5.2 Descripción de Casos donde se aplicará metodología

La metodología se aplicará en tres proyectos de similares características, donde se tomará como variable de control un proyecto donde no se aplique y luego dos más donde sí se aplique OEAF. Estos tendrán como objetivo implementar una arquitectura estándar de Oracle Service Bus, como fue introducido en el punto 4.6, aplicando estándares de Máxima Disponibilidad, Enterprise Deployment Guide y Oracle Flexible Architecture. Los tres casos descritos constan de un despliegue en cluster de Alta Disponibilidad, de similares características para mantener la fidelidad de la comparación.




11

5.3 Definición de Indicadores de Medición de Mejora (IMM)

Con el fin de comparar los resultados entre los escenarios evaluados, se adoptan las siguientes convenciones de nombre: - Jornadas Senior Realmente Utilizadas: Js

Estimador relacionado a las Jornadas de Ingeniero Senior Realmente usadas dentro de la implementación - Jornadas Estándar Realmente Utilizadas:!�

Estimador relacionado a las Jornadas de Ingeniero Estándar Realmente usadas dentro de la implementación - Costo Senior Utilizado:"#

Costo asociado a las jornadas de Ingeniero Senior, realmente usadas en la implementación del proyecto - Costo Estándar Utilizado:"�

Costo asociado a las jornadas de Ingeniero Senior, realmente usadas en la implementación del proyecto - Ambiente: �

Definición de Ambiente, el cual varía entre DEV, QA y PRD. Luego se definen los siguientes IMM:

IMM Totales:

- $#�!��#%&'( � ∑ !# + ∑ !� - "�#��%&'( � ∑"# + ∑"� - ��#��+#��,��-./0'1'2 � !��#32456'1'2 − (∑ !# + ∑ !�) - ��#��"�#�� "�#��32456'1'2 − (∑"# + ∑"�)

- :�;�� <'/5='>?.24.@ABC

<'/5='∙100

- E,��F'/G&0 � H�;��F'/G&0 −:�;��

IMM Por Ambiente:

- $#�!��#%&'((�) � ∑ !#(�) + ∑ !�(�) - "�#��%&'((�) � ∑"#(�) + ∑"�(�) - ��#��+#��,��-./0'1'2(�) � !��#32456'1'2(�) − (∑ !#(�) + ∑ !�(�)) - ��#��"�#��(�) � "�#��32456'1'2(�) − (∑"#(�) + ∑"�(�))

- :�;��(�) �<'/5='(I)>?.24.@ABC(I)

<'/5='∙ 100

- E,��F'/G&0(�) � H�;��F'/G&0(�) − :�;��(�)

5.4 Identificación y Justificación de Artefactos de Arquitectura

Aplicando OEAF y con el fin de impactar directamente el desempeño de las áreas individualizadas en el punto 4.6 se requieren construir los siguientes artefactos: Documento de Arquitectura de Delivery: Este documento contiene los siguientes SBB: Vista Conceptual: Consiste en explicar diagramáticamente, la manera en la cual la solución se pone en contexto, las correspondientes capas de arquitectura que tendrá y cuáles son los principios descritos por Marianne Rønnebæk [1] a cubrir. Ésta vista no afectará directamente el desempeño en las áreas identificadas en el punto 4.6, sin embargo es necesaria para comenzar la iteración de la metodología. La Figura 7, muestra ésta vista desde el punto de vista de Integración de Servicios:




12

Figura 7. Vista Conceptual de Solución de Integración y Mediación de Servicios

Vista Lógica: Ésta vista realiza una relación entre los escenarios a cubrir y que fueron puestos en contexto en el punto anterior, con los componentes técnicos y las relaciones entre sí. Éste artefacto se construye a manera de presentar a alto nivel cuáles son los componentes lógicos de la solución. Éste artefacto cumple una función fundamental para proveer de un contexto tangible al TAM, de cuáles son los componentes y cómo interactúan en el ecosistema tecnológico del cliente, con el fin de reducir en mayor medida las precisiones realizadas en el primer ciclo del proyecto (Ver: Coordinación con Jefe de Proyecto). Para el caso de ésta tesina, la implementación de OSB, se encuentra en la capa de mediación mencionada en la Figura 8.




13

Vista de Mappeo de Productos: Ésta vista se construye sobre la anterior y se mapea en capacidades, identificadas con anterioridad, con los productos a implementar. Esto provee también de contexto técnico al TAM, para realizar el pareo con el contrato de servicios el cual especifica los productos a instalar y configurar y cómo éstos se ubican en el

ecosistema tecnológico de la compañía y del cliente. Una muestra de este artefacto, es expuesta en la Figura 9.

Figura 9. Vista de Mappeo de Productos de Solución de Integración y Mediación de Servicios.

Vista de Deployment: Ésta vista muestra el despliegue técnico final, el cual debe ser implementado por el ASE involucrado en el proyecto. Este artefacto es fundamental para la construcción de la especificación de detalle denominada Enterprise Deployment Workbook, mediante el cual se pretende impactar el área de creación de máquinas, puntos de montaje y configuración de dominios Middleware para OSB. Por ende, este artefacto es el más relevante en función de evaluación de reducción de costos de implementación. Una muestra de este artefacto, es expuesta en la Figura 10.

Figura 8. Vista Lógica de Solución de Integración y Mediación de Servicios




14

Figura 10. Vista de Deployment de Productos de Solución de Integración y Mediación de Servicios.

Junto con las vistas descritas en los puntos anteriores, el artefacto de Arquitectura de Delivery, además debe incluir:

- Diseño de Ambiente, incluyendo la infraestructura donde se implementará. - Convenciones de Nombre a utilizar en la implementación. - Cálculo de Licenciamiento según [18] [19] y [20]. - Definición de Máquinas Virtuales a crear. - Definición de Shared File Systems y Puntos de Montaje. Enterprise Deployment Workbook: Denominado EDW, de aquí en adelante; este artefacto definido inicialmente en [11], consiste en una planilla de cálculo orientada a entregar el diseño técnico detallado para la implementación de la solución. Para mayores detalles en la arquitectura de referencia de WebLogic Server [21] y Oracle Service Bus [22], consultar las documentaciones citadas. Al ser una planilla, ésta puede ser integrada con cualquier artefacto de automatización vía herramientas de scripting, como Python. Los contenidos de este Workbook son los siguientes:




15

- Diseño Arquitectónico: Diseño general ya realizado en el Documento de Arquitectura de Despliegue. - Información y Cálculo de Licenciamiento: Orientado a automatizar el cálculo de licenciamiento en función de lo

adquirido por el cliente. - Especificaciones de Creación de Maquinas: Especificaciones detalladas de creaciones de máquinas virtuales, las

cuales incluyen nombre, IP asignada, cantidad de vCPU y RAM, además del stack al cual pertenece. - Especificaciones de Creación de Dominios: Especificaciones detalladas de cómo deben crearse los dominios de

Middleware asociados a la solución. Estos incluyen detalles como: Host, IP, Nombre de Servidor, Nombre de Cluster (si aplica), puerto a utilizar, Rango de puerto de Coherence, Puerto de Node Manager, Dirección de Cluster, Asignación de Memoria a JVM.

- Especificaciones de Creación de FileSystems: Especificaciones detalladas del cómo debe ejecutarse la creación de los proyectos dentro del storage asociado a la solución, incluyendo detalles como el nombre de la unidad, su punto de montaje y las quotas asignadas además de la distribución creada, para seguir los estándares Oracle Flexible Architecture [23] y Maximum Availability Architecture [24].

Este artefacto, al igual que el Documento de Arquitectura de Delivery, impacta de manera directa los puntos de Creación de Máquinas Virtuales, Puntos de Montaje y Configuración de Sistema Una muestra de este documento es la mostrada en la Figura 11.

Artefactos de Automatización de Despliegue: Mediante la creación de una planilla de cálculo estandarizada, se procede a crear un artefacto de automatización vía Python, el cual simplifica gran parte de la configuración post-creación del dominio con el fin de reducir el error humano y afectar directamente sobre el puntos de Creación de Máquinas Virtuales, Puntos de Montaje y Configuración de Sistema. La Figura 12, muestra un extracto del script de automatización creado.

Figura 11. Muestra de Enterprise Deployment Guide Workbook.




16

Figura 12. Muestra de Script de Automatización Post-Configuración.

6 Validación de la Propuesta

6.1 Metodología de Validación

Para efectos de validación, se actualiza el Software Delivery Kit para ampliar la capacidad de lo definido en la Tabla 4, incluyendo el proceso de Arquitectura de Delivery, utilizando OEAF. Para más Detalles, ver Anexo 11.1

En ésta nueva definición se incluye un costo de UMT $800, extra por cada ambiente, con el fin de realizar los artefactos definidos en el punto 5.4. Con ésta información, se define el costo y tarifa para los tres ambientes definidos en el punto 4.4, en la Tabla 5. Se calcularán los estimadores definidos en el punto 6.3, basado en los tiempos reales utilizados proporcionados por los TAM asociados a los proyectos tomados como referencia. Para efectos de la evaluación, se definen tres escenarios, los cuales se detallan a continuación:




17

- Escenario 1: Escenario de Control, sin la utilización de OEAF. - Escenario 2: Escenario Inicial de uso de OEAF. - Escenario 3: Escenario donde se reutilizan artefactos de OEAF.

Mediante el cálculo de indicadores se realizará la evaluación de impacto sobre la implementación del proyecto.

Tabla 5. Des-agregación de costos en función de Tareas y Entregables vs Perfil requerido, Costo, Tarifa para 1 y 3 ambientes (TO-BE).

Costo/Tarifa unitario Ambiente Costo/Tarifa por 3 Ambientes DEV - QA - PRD


Costo Jornadas


Tarifa ($UMT)

Costo Jornadas


Tarifa ($UMT)

Coordinación con Jefe de Proyecto

Senior 0,5 $ 80 $ 160 1,5 $ 240 $ 480

Realizar reunión preliminar de orientación y contexto

Senior 0,5 $ 80 $ 160 1,5 $ 240 $ 480

Arquitectura de Delivery Senior 5 $ 800 $ 1.600 15,0 $ 2.400 $ 4.800

Revisar documentación disponible

Estándar 0,5 $ 50 $ 95 1,5 $ 150 $ 285

Creación de Máquinas Virtuales requeridas

Senior 1 $ 160 $ 320 3,0 $ 480 $ 960

Creación de Puntos de Montaje y Configuración

en OS

Senior 1 $ 160 $ 320 3,0 $ 480 $ 960

Ejecutar Repository Creation Utility e Instalar

binarios de productos relacionados

Estándar 2 $ 200 $ 380 6,0 $ 600 $ 1.140

Aplicar parches mandatorios y realizar si se aplica, configuraciones

post-instalación

Estándar 1 $ 100 $ 190 3,0 $ 300 $ 570

Configurar Sistema (6 instancias)

Senior 15 $ 2.400 $ 4.800 45,0 $ 7.200 $ 14.400

Realizar validación de configuración

Estándar 1 $ 100 $ 190 3,0 $ 300 $ 570

Preparar documentación relacionada

Senior 2 $ 320 $ 640 6,0 $ 960 $ 1.920

Realizar reunión final de revisión de documentación

de instalación y recomendaciones

Senior 1 $ 160 $ 320 3,0 $ 480 $ 960

Total 30,5 $ 4.610 $ 9.175 91,5 $ 13.830 $ 27.525

Total, más Riesgo Estándar (10%)

33,55 $ 5.071 $ 10.093 100,65 $ 15.213 $ 30.278




18

7 Análisis de Resultados

7.1 Escenarios Recolectados

Escenario 1: Escenario de Control, sin la utilización de OEAF

La Tabla 6 muestra los indicadores calculados para el Escenario de Control.

Tabla 6. Tabla resumen IMM Escenario 1.

IMM Total DEV QA PRD

Uso de Jornadas Real 148 48,5 52,5 47

Costo Real $ 22.570 $ 7.430 $ 8.010 $ 7.130

Desviación en Estimación de Jornadas

-73 -23,5 -27,5 -22

Desviación de Costo $ -11.140 $ -3.620 $ -4.200 $ -3320

Margen 1% 2% -6% 6%

Impacto en Margen -49% -48% -55% -44%

Escenario 2: Escenario Inicial de uso de OEAF

La Tabla 7, muestra los indicadores calculados para el Escenario 2, primero donde se aplicó OEAF:

Tabla 7. Escenario 2. Tabla resumen IMM Escenario 2


Uso de Jornadas Real 73 30,5 23 19,5

Costo Real $ 10.960 $ 4.640 $ 3.440 $ 2.880


2 -5,5 2 5,5

Desviación de Costo $ 470 $ -830 $ 370 $ 930

Margen 52% 39% 55% 62%

Impacto en Margen 2% -11% 5% 12%

Escenario 3: Escenario donde se reutilizan artefactos de OEAF La Tabla 8, muestra los indicadores calculados para el Escenario 3, donde se reutilizan los artefactos realizados para el Escenario 2:

Tabla 8. Escenario 3. Tabla resumen IMM Escenario 3


Uso de Jornadas Real 56 21 19 16

Costo Real $ 8.300 $ 3.180 $ 2.800 $ 2.320


19 4 6 9

Desviación de Costo $ 3.130 $ 630 $ 1.010 $ 1.490

Margen 63% 58% 63% 69%

Impacto en Margen 14% 8% 13% 20%




19

7.2 Análisis de Indicadores

Reducción de Jornadas Reales Utilizadas

La siguiente gráfica, construida en base a los IMM de la sección anterior, muestra el desempeño a la baja de la Utilización de Jornadas:

Gráfica 1. Impacto en Jornadas Total.

Como muestra la regresión polinomial aplicada, la baja de utilización de jornadas se observa profundamente desde el escenario de control, hacia el escenario 2, bajando de 148 a 73 jornadas, mostrando un decremento de 51%. Para la transición desde el Escenario 2 al Escenario 3, se muestra una bajada de 73 a 56 jornadas, mostrando un decremento de 23%. Si realizamos la comparación del Escenario 1 de control versus el escenario final, mostramos un decremento del 62% lo cual se traduce en impacto directo en el margen de los proyectos, a evaluar en puntos siguientes. Esto implica necesariamente que la inversión de 15 jornadas extra, implica un ahorro neto de 92 jornadas. Con esto se puede inferir que la introducción del proceso de Arquitectura de Delivery impactó positivamente en la ejecución total del proyecto.

Gráfica 2. Impacto en uso de Jornadas, Comparación por Ambiente.

Al analizar comparando el desempeño por ambientes, podemos ver que sin aplicar OEAF, el comportamiento de utilización de jornadas en el escenario de control es errático, sin embargo una vez aplicado OEAF, se observa un patrón en el cual el primer ambiente construido, sin realizar reutilización de SBB, está ligeramente por sobre el target, sin embargo conforme avanza el proyecto, los siguientes ambientes están siempre bajo el target esperado. Ésta observación se puede extrapolar hacia las subsecuentes implementaciones reutilizando los artefactos construidos, exponiendo una tendencia hacia la baja.

148

73

56

76,5

91,5 91,5

R² = 1

0

20

40

60

80

100

120

140

160

Escenario 1 (Control) Escenario 2 Escenario 3

Impacto en Jornadas Total

Jornadas Target Polinómica (Jornadas)

48,5

30,5

21

52,5

2319

47

19,516

0

10

20

30

40

50

60


Impacto en Uso de Jornadas, Comparación por Ambient e

DEV QA PRD




20

Aumento de Margen de Proyectos Evaluados La siguiente grafica construida en base a los IMM definidos en las secciones anteriores, muestra el desempeño al alza como consecuencia directa de la reducción de uso de jornadas descrita en el punto inmediatamente anterior:

Gráfica 3. Impacto en Margen Total.

Como se muestra en la gráfica, el impacto entre el Escenario de control y el Escenario 2, genera las garantías de alcance de margen de forma inmediata, superando el target de 50%, teniendo cero reutilización de SBB. Por otra parte, conforme los artefactos se van re-utilizando, el margen se ve impactado en un 11%. La regresión polinomial aplicada a la gráfica muestra la tendencia al alza de manera creciente. El aumento de margen entra en resonancia directa como es demostrado en el punto anterior, con el decremento de uso de jornadas, en los puntos detectados como críticos en el punto 4.6.

Gráfica 4. Impacto en Margen Comparación por Ambiente.

La gráfica anterior, muestra que sin la aplicación de OEAF, la gran cantidad de traspiés detectados en las etapas de instalación y configuración, afectan profundamente al margen del proyecto. El solo hecho de utilizar inicialmente las 15 jornadas cubicadas para arquitectura, eliminan el factor de incertidumbre. Además, se evidencia que el primer ambiente construido siempre es afectado desempeñándose de peor manera, sin embargo, desde el segundo en adelante, las instalaciones y configuraciones superan el target en un mínimo de un 5% y un máximo de 19%.

1%

52%

63%

50% 50% 50%

R² = 10%

10%

20%

30%

40%

50%

60%

70%


Impacto en Margen Total

Margen Target Polinómica (Margen)

2%

39%

58%

-6%

55%

63%

6%

62%69%

-10%

0%

10%

20%

30%

40%

50%

60%

70%

80%


Impacto en Margen Comparación por Ambiente

DEV QA PRD




21

Impacto General y efecto en áreas de Impacto utilizando OEAF

Gráfica 5. Costos y Jornadas vs Targets.

Como muestra la gráfica, las tendencias a la mejora quedan demostradas, exponiendo bajas en costos y usos de jornadas, lo que demuestra que el uso de la metodología es acertado. Por otra parte, con el fin de evaluar el efecto en las áreas de impacto identificadas en el punto 5.6, se realiza la des-agregación de estos ítems, con el fin de entender porcentualmente cuál es el área mayormente impactada por la aplicación de OEAF. Para ello se define la siguiente tabla, definiendo el cálculo con los siguientes cambios:

-Escenario N: Suma total de jornadas del ítem relacionado. - ∆: Diferencia entre lo cubicado menos lo utilizado dividido por lo cubicado. - Promedio 2 y 3: Promedio de Jornadas utilizadas en los escenarios 2 y 3, para el ítem relacionado. - Impacto Porcentual: Diferencia entre promedio de los escenarios 2 y 3 menos el valor del Escenario 1 dividido por el promedio de 2 y 3.

Tabla 13. Comparación de Escenarios.

Actividad Escenario 1

∆ Escenario 2

∆ Escenario 3

∆ Cubicado Promedio 2 y 3 Impacto Porcentual

Coordinación con Jefe

de Proyecto

24 -

1500%

3 -100% 4 -

167%

1,5 4 -586%

Creación de Máquinas

Virtuales requeridas

12 -300% 3 0% 2 50% 3,0 2 -433%

Creación de Puntos de

Montaje y

Configuración en OS

7 -133% 2 50% 2 50% 3,0 2 -367%

Configurar Sistema (6

instancias)

66 -47% 26 42% 20 56% 45,0 23 -187%

Con ello, podemos ver que el mayor impacto es causado en las reuniones de coordinación del jefe de proyecto, seguido de la creación de máquinas virtuales y puntos de montaje, relacionados al cálculo de licenciamiento y en último lugar la configuración de las instancias.

$ 22.570

$ 10.960 $ 8.300

$ 11.430

$ 13.830 $ 13.830

148

7356

76,5

91,5

91,5

$ -

$ 5.000

$ 10.000

$ 15.000

$ 20.000

$ 25.000

0

20

40

60

80

100

120

140

160


Costos y Jornadas vs Targets

Costo Real Target Costo Uso Jornadas Real Target Jornadas




22

8 Conclusiones Finales y Trabajo Futuro

Luego de la realización del análisis de los Indicadores de Medición de Mejora (IMM), se concluye que la aplicación de OEAF tiene un impacto positivo en el uso de jornadas y el margen del proyecto, siendo recomendada su aplicación. Se concluye que la metodología impacta altamente el desempeño del TAM, al ahorrar significativamente en los tiempos relacionados a la coordinación inicial del proyecto definiendo el alcance derivado de la implementación de la tecnología a implementar. Se concluye por ello que este ítem a pesar de tener una baja estimación de esfuerzo, afecta ampliamente en el margen del proyecto y se infiere lo importante que es contar con una definición técnica clara al momento de iniciar la implementación de tecnología.

Se concluye además que la reutilización de SBB en proyectos subsecuentes, tiene un impacto positivo en la reducción de esfuerzos de arquitectura, significando ahorros a mediano-largo plazo.

Al aplicar la metodología, se concluye que como mínimo se garantiza el margen modelado inicialmente para el proyecto. Además, se evidencia que consecuentemente ambientes de similares características conforme se reutilizan los artefactos comienzan a realizarse en menos tiempo, sin embargo, el primer ambiente entregado siempre usará una mayor cantidad de jornadas de manera fija y en proporción decreciente.

La información capturada, además muestra que el impacto del uso de la metodología tiene menor efecto en el primer ambiente configurado, lo que tiene relación con la falta de familiaridad para con la metodología por parte de los ingenieros. Esto se propone como área de mejora, al introducir en etapas futuras entrenamiento de cómo usar los artefactos antes de comenzar las implementaciones, con el fin de disminuir los tiempos muertos a su mínima expresión.

Se puede observar además que el expertise técnico del ingeniero, directamente relacionado a su tarifa, tiene un impacto positivo en la ejecución de tareas complejas. Sin embargo, no es factible ejecutar todo con el nivel más alto de experiencia, debido a su impacto negativo en el costo. Este punto se comporta como variable independiente.

Se propone como trabajo futuro, el trabajo en implementación de servicios Infrastructure as Code (IaC), basado en DevOps, con el fin de tomar como entrada los SBB producidos en este trabajo y automatizar el despliegue y creación de máquinas, puntos de montaje y dominios, con el fin de reducir al mínimo la intervención humana y orientar la participación del ingeniero a las áreas consultivas del producto, esto es realizar troubleshooting y consultoría sobre el uso de ésta.




23

9 Referencias




24

[1] M. Rønnebæk, «White Paper on Enterprise Architecture,» Working Grouo on IT Architecture within the Coordinating Information Comittee - Ministry of Science, Technology and Innovation, Copenhaggen, pp. 40 - 45, 2003.

[2] Wikipedia, "Information technology architecture," 27 07 2017. [Online]. Available: https://en.wikipedia.org/wiki/Information_technology_architecture. [Accessed 06 01 2018].

[3] R. R. Ramesh Radhakrishnan, «IT Infrastructure Architecture,» Sun Professional Services (Now Oracle Advanced Customer Services), 01 05 2004. [En línea]. Available: https://www.opengroup.org/architecture/0404brus/papers/rakesh/abb-1.pdf.

[4] S. Laan, IT Infrastructure Architecture - Infrastructure Building Blocks and Concepts, Lulu.com, 2017.

[5] F. Magazine, «Forbes Magazine,» 07 08 2014. [En línea]. Available: https://www.forbes.com/sites/jasonbloomberg/2014/ 08/07/enterprise-architecture-dont-be-a-fool-with-a-tool/#45914d3a7860. [Último acceso: 04 06 2018].

[6] T. O. G. A. F. (TOGAF), «TOGAF®, an Open Group standard,» [En línea]. Available: http://www.opengroup.org/subjectareas/enterprise/togaf. [Último acceso: 06 01 2018].

[7] The Open Group, «TOGAF Online > Part I: Introduction > Core Concepts,» The Open Group, 2009. [En línea]. Available: http://www.togaf.info/togaf9/chap02.html. [Último acceso: 06 01 2018].

[8] Oracle Corporation via Robert Covington, Hamza Jahangir, "The Oracle Enterprise Architecture Framework," pp. 1-12, 01 01 2009.

[9] O. Corporation, «IT Strategies from Oracle,» [En línea]. Available:https://community.oracle.com/community/fusion_middleware/architecture/it-strategies-from-oracle/content?filter ID=contentstatus[published]~category[oracle-reference-architectures]&customTheme=otn. [Último acceso: 01 04 2018].

[10] Wikipedia, «Request for Proposal,» 02 01 2018. [En línea]. Available: https://en.wikipedia.org/wiki/Request_for_proposal. [Último acceso: 07 01 2018].

[11] Oracle Corporation, "Oracle Enterprise Deployment Guide," 01 01 2015. [Online]. Available: https://docs.oracle.com/middleware/1213/soasuite/SOEDG/edg_workbook.htm#BABDFJGH. [Accessed 18 04 2018].

[12] Microsoft Corporation, «Microsoft Azure IoT Reference Architecture,» Microsoft Corporation, 01 01 2016. [En línea]. Available:http://download.microsoft.com/download/A/4/D/A4DAD253-BC21-41D3-B9D9-87D2AE6F0719/Microsoft_ Azure_IoT_Reference_Architecture.pdf. [Último acceso: 11 01 2018].

[13] IBM Corporation, «Developing a Technical Architecture for Web-Based Enterprise Software,» IBM Corporation, 01 06 2002. [En línea]. Available: https://www.ibm.com/developerworks/library/wa-techarch/index.html. [Último acceso: 18 12 2017].

[14] Amazon Web Services (AWS), «Well-Architected Framework,» Amazon, 2017. [En línea]. Available: https://d0.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf.

[15] Oracle Corporation, "Advanced Customer Services Home Page," Oracle Corporation, 01 01 2015. [Online]. Available: https://www.oracle.com/support/advanced-customer-support/index.html. [Accessed 14 04 2018].

[16] Oracle Corporation, "Oracle TAM DataSheet," 01 01 2017. [Online]. Available: http://www.oracle.com/us/support/advanced-customer-services/resource-library/technical-account-manager-4006120.pdf. [Accessed 14 04 2018].

[17] Oracle Corporation, «Oracle ASE Datasheet,» 01 01 2015. [En línea]. Available: https://www.oracle.com/us/assets/oracle-support-engineer-3662258.pdf. [Último acceso: 14 04 2018].

[18] Oracle Corporation, «License Definitions and Rules,» Oracle Corporation, 22 04 2018. [En línea]. Available: http://www.oracle.com/us/corporate/pricing/olsadef-ire-v122304-070549.pdf . [Último acceso: 22 04 2018].

[19] Oracle Corporation, "Core Factor Calculation," Oracle Corporation, 01 01 2017. [Online]. Available: http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf. [Accessed 22 04 2018].

[20] Oracle Corporation, «Partitioning Policy,» Oracle Corporation, 01 01 2017. [En línea]. Available: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf. [Último acceso: 22 04 2018].

[21] Oracle Corporation, «Oracle WebLogic Server Documentation,» Oracle Corporation, 01 01 2017. [En línea]. Available: https://docs.oracle.com/middleware/12213/wls/index.html. [Último acceso: 02 05 2018].

[22] Oracle Corporation, «Oracle Service Bus Documentation,» Oracle Corporation, 01 01 2017. [En línea]. Available: https://docs.oracle.com/middleware/12213/lcm/INOSB/index.html. [Último acceso: 02 05 2018].

[23] Oracle Corporation, «Oracle Flexible Architecture,» Oracle Corporation, 01 01 2017. [En línea]. Available: https://docs.oracle.com/database/121/LADBI/appendix_ofa.htm#LADBI7916. [Último acceso: 02 05 2018].

[24] Oracle Corporation, «Maximum Availability Architecture,» Oracle Corporation, 01 01 2017. [En línea]. Available: http://www.oracle.com/technetwork/database/features/availability/maa-096107.html. [Último acceso: 02 05 2018].




25

10 Glosario

Término Definición

OEAF Oracle Enterprise Architecture Framework. Framework utilizado para el desarrollo de esta tesina.

ABB Capacidad Requerida dentro de un ambiente arquitectado.

SBB Componente implementado para cubrir la capacidad definida dentro de un ABB.

UML Unified Modeling Language.

Middleware Capa media de interacción de software, orientada a abstraer el funcionamiento y comunicación entre el cliente y la capa de datos.

TOGAF The Open Group Architecture Framework. Framework de Arquitectura ampliamente usado en la Industria.

ORA Oracle Reference Architecture. Arquitectura de Referencia utilizada para la implementación de tecnología Oracle.

ACS Advanced Customer Services. Organización de Consultoría perteneciente a Oracle Corporation.

TAM Technical Account Manager. Jefe De Proyectos a cargo de la ejecución de uno o más proyectos tecnológicos dentro de la organización de ACS.

ASE Advanced Support Engineer. Ingeniero a cargo de la implementación de uno o más proyectos tecnológicos dentro de la organización de ACS.

DCE DataCenter Engineer. Ingeniero a Cargo de la instalación y configuración de los servidores físicos dentro de soluciones de Datacenter.

S2DH Sales to Delivery Handover. Proceso en el cual el area de arquitectura de servicios presenta el proyecto vendido al area de ACS.

PRD Producción.

QA Quality Assurance.

DEV Desarrollo.

UMT Unidad Monetaria de Trabajo. Unidad monetaria ficticia creada para efectos de estandarización de costos en esta tesina.

IMM Indicador de Medicion de Mejora. Indicadores clave de medición de mejora para esta tesina.

Js Jornadas de Ingeniero Senior Realmente Utilizadas.

Je Jornadas de Ingeniero Estándar Realmente Utilizadas.

Cs Costo de Ingeniero Senior.

Ce Costo de Ingeniero Estándar.

OSB Oracle Service Bus. Software de Integración propiedad de Oracle Corporation. Sirve para integrar y converger tecnologías de distinto tipo en una arquitectura orientada a servicios.

EDW Enterprise Deployment Workbook. SBB creado para diseñar las soluciones de middleware cubiertas en esta tesina.




26

OFA Oracle Flexible Architecture. Modelo de implementación arquitectónico adaptado a la escalabilidad y resiliencia de ambientes bajo tecnología Oracle.

MAA Maximum Availability Architecture. Arquitectura orientada a ofrecer la máxima disponibilidad posible, en función de los recursos adquiridos y licenciados.

SDK Software Delivery Kit. Lista de tareas lógicas requeridas para la ejecución de un proyecto tecnológico.

11 Anexos 11.1 Tablas de Desagregación de Costos y Tarifas Ambiente Único Tabla Anexa. Des-agregación de costos en función de Tareas y Entregables vs Perfil requerido, Costo, Tarifa en $UMT TO-BE


Costo Jornadas


Tarifa ($UMT)

Coordinación con Jefe de Proyecto

Senior 0,5 $ 80 $ 160

Realizar reunión preliminar de orientación y contexto

Senior 0,5 $ 80 $ 160

Arquitectura de Delivery Senior 5 $ 800 $ 1.600 Revisar documentación

disponible Estándar 0,5 $ 50 $ 95


Senior 1 $ 160 $ 320


Senior 1 $ 160 $ 320

Ejecutar Repository Creation Utility e Instalar binarios de

productos relacionados

Estándar 2 $ 200 $ 380

Aplicar parches mandatorios y realizar si se aplica,

configuraciones post-instalación

Estándar 1 $ 100 $ 190

Configurar Sistema (6 instancias)

Senior 15 $ 2.400 $ 4.800

Realizar validación de configuración

Estándar 1 $ 100 $ 190

Preparar documentación relacionada

Senior 2 $ 320 $ 640

Realizar reunión final de revisión de documentación de instalación y recomendaciones

Senior 1 $ 160 $ 320

Total 30,5 $ 4.610 $ 9.175 Total, más Riesgo Estándar

(10%) 33,55 $ 5.071 $ 10.093




27

11.2 Detalle Muestra de Comportamiento Escenario de Control

Uso Real Jornadas Costo Total ($UMT)

Descripción de Tarea Costo Cubicado Jornadas

Perfil Ingeniero

DEV QA PRD DEV QA PRD

Coordinación con Jefe de Proyecto 0,5 Senior 8 6 10 $ 1.280 $ 960 $ 1.600 Arquitectura de Delivery - Senior - - - $ - $ - $ - Realizar reunión preliminar de orientación y contexto

0,5 Senior 1 1 0,5 $ 160 $ 160 $ 80

Revisar documentación disponible 0,5 Estándar 0,5 0,5 0,5 $ 50 $ 50 $ 50


1 Senior 4 5 3 $ 640 $ 800 $ 480


1 Senior 2 3 2 $ 320 $ 480 $ 320


2 Estándar 2 2 2 $ 200 $ 200 $ 200


1 Estándar 1 1 1 $ 100 $ 100 $ 100

Configurar Sistema (6 instancias) 15 Senior 22 25 19 $ 3.520 $ 4.000 $ 3.040 Realizar validación de configuración 1 Estándar 2 3 3 $ 200 $ 300 $ 300 Preparar documentación relacionada 2 Senior 5 5 5 $ 800 $ 800 $ 800 Realizar reunión final de revisión de documentación de instalación y recomendaciones

1 Senior 1 1 1 $ 160 $ 160 $ 160

Uso Total Jornadas 25 148 49 52,5 47 Costo Total Real $ 22.570 $ 7.430 $ 8.010 $ 7.130 Desviación de Estimación -73 -24 -27,5 -22 Desviación de Costo -$ 11.140 -$ 3.620 -$ 4.200 -$ 3.320 Margen por Ambiente 2% -6% 6% Impacto en Margen (Target 50%) -49% -48% -55% -44% Margen Total Proyecto 1%

11.3 Detalle Muestra Escenario 2. Utilización de Artefactos OEAF inicial




28



Perfil Ingeniero


Coordinación con Jefe de Proyecto 0,5 Senior 2 0,5 0,5 $ 320 $ 80 $ 80 Arquitectura de Delivery 15 Senior 5 5 5 $ 800 $ 800 $ 800 Realizar reunión preliminar de orientación y contexto

0,5 Senior 1 1 0,5 $ 160 $ 160 $ 80

Revisar documentación disponible 0,5 Estándar 1 1 1 $ 100 $ 100 $ 100


1 Senior 1 1 1 $ 160 $ 160 $ 160


1 Senior 0,5 0,5 0,5 $ 80 $ 80 $ 80


2 Estándar 1 1 1 $ 100 $ 100 $ 100


1 Estándar 1 1 1 $ 100 $ 100 $ 100

Configurar Sistema (6 instancias) 15 Senior 12 8 6 $ 1.920 $ 1.280 $ 960 Realizar validación de configuración 1 Estándar 1 1 1 $ 100 $ 100 $ 100 Preparar documentación relacionada 2 Senior 4 2 1 $ 640 $ 320 $ 160 Realizar reunión final de revisión de documentación de instalación y recomendaciones

1 Senior 1 1 1 $ 160 $ 160 $ 160

Total Estimación Proyecto 25 73 31 23 20 Costo Total $ 10.960 $ 4.640 $ 3.440 $ 2.880 Desviación de Estimación 2 -5,5 2 5,5 Desviación de Costo $ 470 -$ 830 $ 370 $ 930 Margen por Ambiente 39% 55% 62% Impacto en Margen (Target 50%) 2% -11% 5% 12% Margen Total Proyecto 52%

11.4 Detalle Muestra Escenario 3. Re-utilización de Artefactos OEAF.




29



Perfil Ingeniero


Coordinación con Jefe de Proyecto 0,5 Senior 2 1 1 $ 320 $ 160 $ 160

Arquitectura de Delivery 10 Senior 3 3 2 $ 480 $ 480 $ 320 Realizar reunión preliminar de orientación y contexto

0,5 Senior 1 1 1 $ 160 $ 160 $ 160

Revisar documentación disponible 0,5 Estándar $ - $ - $ - Creación de Máquinas Virtuales requeridas

1 Senior 0,5 0,5 0,5 $ 80 $ 80 $ 80


1 Senior 0,5 0,5 0,5 $ 80 $ 80 $ 80


2 Estándar 1 1 1 $ 100 $ 100 $ 100


1 Estándar 1 1 1 $ 100 $ 100 $ 100

Configurar Sistema (6 instancias) 15 Senior 8 7 5 $ 1.280 $ 1.120 $ 800

Realizar validación de configuración 1 Estándar 1 2 2 $ 100 $ 200 $ 200 Preparar documentación relacionada 2 Senior 2 1 1 $ 320 $ 160 $ 160

Realizar reunión final de revisión de documentación de instalación y recomendaciones

1 Senior 1 1 1 $ 160 $ 160 $ 160

Total Estimación Proyecto 25 56 21 19 16 Costo Total $ 8.300 $ 3.180 $ 2.800 $ 2.320 Desviación de Estimación 19 4 6 9 Desviación de Costo $ 3.130 $ 630 $ 1.010 $ 1.490 Margen por Ambiente 58% 63% 69% Impacto en Margen (Target 50%) 14% 8% 13% 20% Margen Total Proyecto 63%

11.5 Script de automatización import sys import os import datetime def create_dir(path): if not os.path.exists(path): os.makedirs(path) # Global Variables print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Global Variables' ofa='/u01' domain_name='prd_osb_domain' dserver=ofa+'/app/oracle/admin/domains/'+domain_nam e log_dir=ofa+'/app/oracle/admin/logs/'+domain_name jms_dir=ofa+'/app/oracle/admin/jms/'+domain_name+'/ stores' sep='/' cookie_name='ADMINCONSOLE_'+domain_name usr='weblogic' pwd='foobarpasword' as_host="foprd01adminin" as_host_priv=as_host+'-priv' as_port="10000" as_socket='t3://'+as_host_priv+':'+as_port as_name='AdminServer' # Connect




30

print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Connecting to Admin Server' connect(usr,pwd,as_socket) edit() startEdit() # Domain Global Config # Exalogic Optimizations print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Exalogic Optimizations' cd('/') cmo.setExalogicOptimizationsEnabled(true) print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Console logs and cookie' cd('/') pwd() cd('/Log/'+domain_name) cmo.setFileName(log_dir+'/'+domain_name+'.log') cmo.setFileCount(30) cmo.setNumberOfFilesLimited(true) cmo.setRotationType('byTime') cd('/') cmo.setArchiveConfigurationCount(15) cmo.setConfigBackupEnabled(true) cmo.setClusterConstraintsEnabled(false) cd('/AdminConsole/'+domain_name) cmo.setCookieName(cookie_name) print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Cluster to Unicast' cd('/Clusters/') # List of Servers clusters=cmo.getClusters() for cluster in clusters: myclus=cluster.getName() cd('/Clusters/'+myclus) cmo.setClusterMessagingMode('unicast') print '['+ str(datetime.datetime.now().strftime("%Y -%m-%d %H:%M:%S")) + '] Setting Log redirection, Server System Properties' cd('/Servers/') # List of Servers servers=cmo.getServers() for server in servers: mysrv=server.getName() create_dir(log_dir+sep+mysrv) create_dir(log_dir+sep+mysrv+sep+'dump') cd('/Servers/'+mysrv+'/Log/'+mysrv) cmo.setFileName(log_dir+sep+mysrv+sep+mysrv+'.log' ) cmo.setNumberOfFilesLimited(true) cmo.setFileCount(30) cmo.setRotationType('byTime') cmo.setRedirectStderrToServerLogEnabled(true) cmo.setRedirectStdoutToServerLogEnabled(true) cd('/Servers/'+mysrv+'/WebServer/'+mysrv+'/WebServ erLog/'+mysrv) cmo.setFileName(log_dir+sep+mysrv+sep+'access.log' ) cmo.setFileCount(30) cmo.setNumberOfFilesLimited(true) cd('/Servers/'+mysrv+'/DataSource/'+mysrv+'/DataSo urceLogFile/'+mysrv) cmo.setFileName(log_dir+sep+mysrv+sep+'datasource. log') cmo.setNumberOfFilesLimited(true) cmo.setRotateLogOnStartup(true) cmo.setFileCount(30) cd('/Servers/'+mysrv+'/DefaultFileStore/'+mysrv)




31

create_dir(jms_dir+sep+mysrv+sep+'tlogs') cmo.setDirectory(jms_dir+sep+mysrv+sep+'tlogs') if mysrv == as_name: print '['+ str(datetime.datetime.now().strftime(" %Y-%m-%d %H:%M:%S")) + '] Configuring AdminServer' cd('/Servers/'+mysrv) cmo.setAcceptBacklog(500) cd('/Servers/'+mysrv+'/ServerStart/'+mysrv) cmo.setArguments('-Xms3g -Xmx3g -Djava.security .egd=file:/dev/./urandom -Dweblogic.data.canTransferAnyFile=true -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:'+log_dir+sep+mysrv+sep+' gc.log -Djava.net.preferIPv4Stack=true -Dweblogic.nodemanager.ServiceEnabled=true -XX:+Heap DumpOnOutOfMemoryError -XX:HeapDumpPath='+log_dir+sep+mysrv+sep+'dump -Dweblogic.Stdout='+log_dir+sep+mysrv+sep+mysrv+'.ou t') cd('/Servers/'+mysrv+'/SSL/'+mysrv) cmo.setEnabled(false) cmo.setLoginTimeoutMillis(25000) if mysrv != as_name: print '['+ str(datetime.datetime.now().strftime(" %Y-%m-%d %H:%M:%S")) + '] Configuring Managed Servers' cd('/Servers/'+mysrv) cmo.setAcceptBacklog(500) cd('/Servers/'+mysrv+'/ServerStart/'+mysrv) cmo.setArguments('-Xms4g -Xmx4g -Djava.security.e gd=file:/dev/./urandom -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+Prin tHeapAtGC -Xloggc:'+log_dir+sep+mysrv+sep+'gc.log -Djava.net.p referIPv4Stack=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath='+l og_dir+sep+mysrv+sep+'dump -Dweblogic.Stdout='+log_dir+sep+mysrv+sep+mysrv+'.ou t' ) cd('/Servers/'+mysrv+'/SSL/'+mysrv) cmo.setEnabled(false) cmo.setLoginTimeoutMillis(25000)

11.6 Enterprise Deployment Workbook

Mejora de Proceso en Proyectos de Desarrollo de Sol ...Para solucionar este problema en este...

Documents

Transcript of Mejora de Proceso en Proyectos de Desarrollo de Sol ...Para solucionar este problema en este...