Gestión de la Puesta en Producción
Anuncio
FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS DE INFORMACIÓN Gestión de la Puesta en Producción PROYECTO PROFESIONAL Para optar el Título de: INGENIERO DE SISTEMAS DE INFORMACIÓN AUTOR: Rivera Herbozo, Moisés Alfredo Soto Taira, Leonardo Angel ASESOR: Jorge Cabrera Berrios LIMA - PERÚ 2012 0 Dedicatoria : Este trabajo está dedicado a todas aquellas personas que han hecho posible el que estemos concluyendo nuestros estudios universitarios. TABLA DE CONTENIDO RESUMEN ......................................................................................................................................................... 6 INTRODUCCIÓN ................................................................................................................................................ 8 CAPITULO 1. ANTECEDENTES Y DECLARACION DEL PROYECTO ......................................................................... 9 ANTECEDENTES EN LA UPC SOBRE LA PUESTA EN PRODUCCION DE APLICACIONES. ................................................................. 9 Antecedentes sobre la situación en las empresas virtuales. ........................................................................... 9 Antecedentes sobre la situación en el centro de cómputo (sala de servidores) de la UPC........................... 10 Antecedentes sobre los problemas observados que la falta de un marco de trabajo para el despliegue de aplicaciones genera en las empresas virtuales de la UPC. ............................................................................ 11 Sucesos que complicaron la situación del modo en que se llevan a cabo los despliegues de las aplicaciones en las empresas virtuales. ............................................................................................................................. 12 Antecedentes sobre las necesidades de las empresas virtuales detectadas durante la recopilación de información sobre la forma de despliegue de las aplicaciones hasta ese momento (ciclo académico 201001). ................................................................................................................................................................ 13 Antecedentes sobre las expectativas declaradas para el proyecto por parte del director de la facultad profesor Jorge Cabrera Berrios. .................................................................................................................... 14 Antecedentes sobre los riesgos identificados para el desarrollo del proyecto “Gestión de la Puesta en Producción”. .................................................................................................................................................. 15 CAPITULO 2. MARCO TEORICO ........................................................................................................................ 16 GESTION DE LA PUESTA EN PRODUCCION .................................................................................................................... 16 Concepto ....................................................................................................................................................... 16 Actividades principales durante el proceso de Puesta en Producción ........................................................... 17 Planificación ............................................................................................................................................................... 17 Planificación del desarrollo ........................................................................................................................................ 17 Pruebas o Testing ....................................................................................................................................................... 18 Preparación de la entrega de la aplicación o software .............................................................................................. 18 Entrega o puesta en producción ................................................................................................................................ 18 Ventajas y beneficios de la Gestión de la Entrega ........................................................................................ 19 Objetivos ....................................................................................................................................................... 19 PROCESOS ASOCIADOS A LA GESTION DE LA PUESTA EN PRODUCCION ............................................................................... 19 2 Gestión de la Configuración .......................................................................................................................... 20 Gestión de Cambios ...................................................................................................................................... 20 CAPITULO 3. DESCRIPCION DEL PROYECTO ..................................................................................................... 22 OBJETIVO DEL PROYECTO ......................................................................................................................................... 22 Objetivo General ........................................................................................................................................... 22 Objetivo Específico ........................................................................................................................................ 23 METODOLOGIA DEL PROYECTO .................................................................................................................................. 24 PMBOK (Project Management Body of Knowledge) ..................................................................................... 24 BPMN (Business Process Modeling Notation) ............................................................................................... 25 Fundamentos de la Gestión de Servicios de IT: Basado en ITIL ..................................................................... 27 ALCANCE DEL PROYECTO .......................................................................................................................................... 28 EQUIPO DEL PROYECTO ............................................................................................................................................ 29 RIESGOS DEL PROYECTO ........................................................................................................................................... 29 CAPITULO 4. DESCRIPCION DE LOS PROCESOS PLANTEADOS PARA EL PROYECTO DE “GESTION DE PUESTA EN PRODUCCION” ................................................................................................................................................ 31 PROCESO DE PASE A LOS AMBIENTES DE DESARROLLO, PRUEBAS Y PRODUCCION. ................................................................ 31 Pase al ambiente de Desarrollo. ................................................................................................................... 32 Pase al Ambiente de Pruebas. ....................................................................................................................... 32 Pase al Ambiente de Producción ................................................................................................................... 32 MAPA DE PROCESOS................................................................................................................................................ 33 REQUERIMIENTOS DE NEGOCIO.................................................................................................................................. 33 DIAGRAMA DE OBJETIVOS. ........................................................................................................................................ 34 DIAGRAMAS BPMN DE LOS AMBIENTES DE DESARROLLO, PRUEBAS Y PRODUCCION ......................................................... 35 Pase a Desarrollo .......................................................................................................................................... 37 Pase a Pruebas .............................................................................................................................................. 42 Pase a Producción ......................................................................................................................................... 48 POLITICAS, OBLIGACIONES Y NOMENCLATURA ESTABLECIDAS PARA EL PROCESO DE PUESTA EN PRODUCCION ............................ 55 Pase al Ambiente de Desarrollo .................................................................................................................... 55 Pase al Ambiente de Pruebas ........................................................................................................................ 57 Pase al Ambiente de Producción ................................................................................................................... 57 NOMENCLATURA. ................................................................................................................................................... 58 HERRAMIENTA SOFTWARE UTILIZADA PARA EL PROCESO DE PUESTA EN PRODUCCION........................................................... 59 ¿Qué es Tortoise SVN? .................................................................................................................................. 59 Características del Tortoise SVN ................................................................................................................... 60 Conceptos Básicos ......................................................................................................................................... 62 PROYECTOS DESPLEGADOS DURANTE EL CICLO 2011-01 SOBRE LOS AMBIENTES IMPLEMENTADOS PARA LA GESTION DE LA PUESTA EN PRODUCCION .................................................................................................................................................... 67 PRUEBA PILOTO ..................................................................................................................................................... 71 RIESGOS Y PROBLEMAS IDENTIFICADOS DURANTE EL DESARROLLO DEL PROYECTO................................................................. 72 CAPITULO 5. DOCUMENTOS Y PLANES DE GESTION ASOCIADOS AL PROCESO DE PUESTA EN PRODUCCION. . 75 DOCUMENTO DE ACEPTACION DEL CLIENTE. ................................................................................................................. 75 CIERRE DE CONTRATO .............................................................................................................................................. 76 CIERRE ADMINISTRATIVO ......................................................................................................................................... 76 ANALISIS POST-MORTEM. ........................................................................................................................................ 76 GESTION DE PROBLEMAS E INCIDENTES. ...................................................................................................................... 78 GESTION DE PEDIDOS. ............................................................................................................................................. 80 GESTION DE ACCESOS. ............................................................................................................................................. 81 PLAN DE RIESGOS. .................................................................................................................................................. 82 PLAN DE COMUNICACIONES. ..................................................................................................................................... 83 Propósito del documento .............................................................................................................................. 83 Stakeholders.................................................................................................................................................. 83 Requerimientos para la comunicación. ......................................................................................................... 86 Mecanismo de comunicación ........................................................................................................................ 87 Itinerario de comunicación ........................................................................................................................... 93 PLAN DE CALIDAD DE SERVICIOS DE TI. ....................................................................................................................... 95 PLAN DE DISPONIBILIDAD. ........................................................................................................................................ 96 PLAN DE CONTINUIDAD O POST-IMPLEMENTACION. ...................................................................................................... 97 PLAN Y ESTRATEGIAS DE SEGURIDAD. ....................................................................................................................... 126 PLANES DE CONTINGENCIA. .................................................................................................................................... 127 PLAN DE OPERACION Y SOPORTE DE SISTEMAS ............................................................................................................ 129 PLAN DE MIGRACION DE SISTEMAS (SOLO SI UTILIZARAN INFORMACION HISTORICA) ........................................................... 130 ESTRATEGIAS DE DESPLIEGUE DE APLICACIONES ........................................................................................................... 130 ESTUDIOS DE FACTIBILIDAD. .................................................................................................................................... 132 PLAN DE ADMINISTRACION DE DATOS....................................................................................................................... 132 ESTRATEGIAS DE CONTROL DE RENDIMIENTO DE INFRAESTRUCTURAS............................................................................... 133 PLAN DE ADMINISTRACION DE REDES ....................................................................................................................... 134 PLAN DE CONFIGURACION DE ACTIVOS ..................................................................................................................... 134 4 CAPITULO 6. SEGUIMIENTO DE LA PUESTA EN PRODUCCION DE LOS PROYECTOS DURANTE EL CICLO 2011-02 ......................................................................................................................................................................135 PROYECTOS PRESENTADOS PARA EL CICLO 2011-02 .................................................................................................... 136 AVANCE DE LOS PROYECTOS DENTRO DEL FLUJO DE LA GESTION DE LA PUESTA EN PRODUCCION........................................... 137 PROBLEMAS ENCONTRADOS DURANTE EL DESARROLLO DE LAS ACTIVIDADES DEL PROCESO DE PUESTA EN PRODUCCION. .......... 143 GRAFICOS RESUMENES SOBRE LA GESTION DE LA PUESTA EN PRODUCCION. ..................................................................... 145 CONCLUSIONES ..............................................................................................................................................148 RECOMENDACIONES ......................................................................................................................................149 BIBLIOGRAFIA ................................................................................................................................................151 ANEXOS .........................................................................................................................................................153 RESUMEN La entrega de una aplicación software es considerada, en muchas ocasiones, un proceso aislado asociado, casi íntegramente, al desarrollo de código en los diferentes lenguajes de programación existente. Casi nunca se toma en cuenta que es un proceso complejo que posee reglas definidas y sustentadas, por ejemplo, en algún ISO1. El presente trabajo trata de ofrecer un mayor conocimiento de la importancia de este proceso que se da, por ejemplo, en las empresas dedicas al desarrollo de aplicaciones a medida. Un producto software que no está ceñido a un proceso de desarrollo desde la toma de requerimientos hasta su despliegue en un “Ambiente de Producción”2 corre un alto riesgo de presentar deficiencias que causen malestar en el usuario que lo solicitó. No es difícil entender que un producto con graves deficiencias funcionales o de performance, además del malestar en el usuario provoca una mala imagen para la empresa que lo desarrolla y puede hacer, además, que esta no prospere como se desearía. Esta situación de “caos” o desorden para la puesta en producción de una aplicación software puede, también, crear un ambiente de malestar en los empleados de la empresa que están asignados al desarrollo de los diferentes proyectos que existen en esta. Además de malestar en los empleados los retrasos o pérdida de información a causa de la falta de un proceso bien estructurado y definido son frecuentes. Para la puesta en producción de una aplicación software interviene el manejo de conceptos tales como la “Gestión de Cambios”3, “Gestión de la Configuración”4, los cuales son cruciales para el desarrollo de una aplicación y que ayudan a llevar un control del avance, conocimiento del performance e idea de la calidad del desarrollo de cada una de las funcionalidades que este posee. Otro motivo importante y válido que determina necesaria la implementación de un proceso para la puesta en producción de una aplicación software es la complejidad que, actualmente, estos presentan. Ahora es común que una aplicación software sea desarrollada no solo en un único ambiente y por un solo equipo, sino por varios equipos que, incluso, pueden estar ubicados en diferentes zonas geográficas. Por lo tanto una aplicación software y cada uno de sus componentes son desarrolladas en diferentes empresas ubicadas, en algunos casos, en 1 ISO 20000 2 UNED (2011) 3 UNED (2011) 4 UNED (2011) 6 diferentes países. Por esta complejidad el proceso del desarrollo de una aplicación debe estar normado desde que los requerimientos funcionales de este son capturados hasta que la aplicación entra en la fase de producción. INTRODUCCIÓN La definición de procesos y metodologías para el desarrollo de las diferentes actividades realizadas por el ser humano son comunes y de mucha ayuda para que estas se realicen de manera más eficiente y efectiva. Cada metodología puede ser única o producto de un conjunto de buenas prácticas obtenidas de diferentes modelos existentes. Sea cual fuese su procedimiento, sus metas son claras, como el de definir y estructurar, para una empresa, los procesos de negocio que esta realiza para incrementar ganancias, mejorar la satisfacción del usuario, conseguir un ambiente de trabajo adecuado para los empleados o quizás por una determinación legal que deben seguir si desean obtener determinados niveles de reconocimiento en los productos o servicios que ofrece. El presente trabajo busca plantear un modelo de desarrollo para la puesta en producción de las aplicaciones software que se desarrollan en la Universidad Peruana de Ciencias Aplicadas. Esta metodología está compuesta por la definición de los flujos de trabajo que componen cada una de las actividades realizadas durante la liberación de una aplicación software. Además de la definición de la metodología se realizará la implementación de estas en cada una de las empresas virtuales que, actualmente, desarrollan e implementan aplicaciones orientadas a diferentes ámbitos como salud, educación y soporte e infraestructura. 8 Capítulo 1. Antecedentes y Declaración del proyecto En el presente capítulo, se detallará la situación que existe en las empresas virtuales de la UPC con respecto a la gestión de la puesta en producción de la aplicaciones que en estas se desarrollan. Se indicará, además, los problemas que trae consigo la falta de una metodología o proceso estructurado y estandarizado para lograr la entrega de una aplicación a su usuario final. Por último, se explicará la justificación del proyecto “Gestión de la Puesta en Producción” para el cliente objetivo5. Antecedentes en la UPC sobre la puesta en producción de aplicaciones. Antecedentes sobre la situación en las empresas virtuales. Al inicio del proyecto en el ciclo 2011-01, en las todas las empresas virtuales de la UPC (Universidad Peruana de Ciencias Aplicadas) constituidas por “SALUDABLE”, “IT-Expert”, “Software Factory”, “BANKMIN”, “Educa-T” y “QA” se realizó una encuesta para conocer el modo de como llevaban a cabo el despliegue de las aplicaciones que en estas se desarrollaban. El resultado de esta encuesta que se realizó a los profesores que tenían a su cargo la gerencia de las mismas indicó que solo las empresas de “SALUDABLE”, “Software Factory” y “Educa-T” desarrollaban aplicaciones. Además, estos indicaron que no existía una metodología o marco de trabajo para llevar a cabo el despliegue de estas aplicaciones que eran presentadas por los alumnos para lograr obtener el grado de bachiller y, posteriormente, de ingeniero titulado. Este fue el primer punto para justificar la realización del proyecto de tesis de la “Gestión de la Puesta en Producción”. La falta de una metodología para el despliegue de aplicaciones tenía consecuencias evidentemente negativas y que serán tocadas a detalle en el presente capítulo. 5 GOBIERNO DE CANARIAS (2011) Antecedentes sobre la situación en el centro de cómputo (sala de servidores) de la UPC. Debido a que la encuesta realizada indicó la falta de una metodología para la ejecución de los despliegues de las aplicaciones que se desarrollaban e implementaban en las empresas virtuales se decidió investigar la situación o el modo de cómo eran almacenadas estas aplicaciones en los servidores destinados para este fin y que se encontraban en el centro de cómputo de la facultad de Ingeniería. El resultado de esta investigación indicó y dio a conocer lo siguiente: a) Las versiones de las aplicaciones que eran desplegadas sobre los servidores del centro de cómputo, no tenían un adecuado almacenamiento, es decir no se podía realizar un seguimiento al avance realizado por los alumnos durante el desarrollo de sus proyectos. Esto tenía claras consecuencias negativas como, por ejemplo, que un alumno podía indicar que había realizado un determinado avance sin que esto sea necesariamente verdad. Para evitar esta situación se podía utilizar una herramienta de versionamiento que permitiera conocer de manera inmediata los avances realizados por los alumnos a los largo de las 16 semanas académicas que tiene cada ciclo universitario y evitar que un alumnos reciba una nota que en realidad no merecía. b) Las aplicaciones y los entregables que estas generan tales como documentación, código fuente o evidencia de pruebas de funcionabilidad no eran registradas en algún repositorio que permitiera su posterior consulta. Es decir, no existía evidencia de su funcionamiento o desarrollo, por ejemplo, si una aplicación era desarrollada en el año 2010 y en caso alguna persona como profesor o cualquier alumno deseará realizar una consulta sobre esta no encontraría la documentación necesaria que le indicase que es lo que esta aplicación realizaba, cuando fue iniciada, donde fue desplegada, cuantas versiones fueron creadas o cual fue el resultados de las pruebas funcionales de la misma. c) Con respecto al punto anterior se tuvieron, durante el desarrollo de este proyecto, numerosos casos en los cuales se hacía evidente la necesidad del registro de toda esta información para poder ser utilizada posteriormente. Por ejemplo, en proyectos asociados a los que ya se tenían desplegados. Es decir, se dan casos en los cuales un proyecto de tesis depende enormemente de un proyecto que ya ha sido desplegado en ciclos anteriores. Si no existe un documento que indique, al menos, para cuáles son sus características, donde ha sido ha sido desplegado, así como las dependencias que este requiere para un correcto funcionamiento será imposible que el alumno que desea realizar el desarrollo e implementación de una aplicación asociada a esta lo logre. 10 Antecedentes sobre los problemas observados que la falta de un marco de trabajo para el despliegue de aplicaciones genera en las empresas virtuales de la UPC. Por lo expuesto en los puntos anteriores del presente capítulo no es difícil inferir los problemas que se tienen en las empresas virtuales por la falta de un proceso estructurado y estandarizado para el despliegue de cada una de las aplicaciones software desarrolladas en estas. a) La falta de un proceso para el despliegue o puesta en producción de las aplicaciones en las empresas virtuales de la UPC no permite realizar un seguimiento paso a paso de la puesta en producción de las mismas desde que son concebidas hasta su implementación y entrega final al cliente para el cual fueron construidas. Esto significa que al no hacer un seguimiento del desarrollo de estas no existe un registro, por ejemplo, de problemas que pueden darse y que de ser registrados de manera adecuada podría ayudar a que futuros proyectos que tengan los mismos problemas los resuelvan de manera más rápida o, al menos, posean una base de conocimiento para desarrollar una solución más adecuada. b) Verificar que los cambios que se realizan sobre las aplicaciones son seguros, son registrados y funcionan de manera adecuada, La falta de un manejo adecuado de las versiones que posee la aplicación dificultan la seguridad de estar trabajando con la última versión del software. Esta situación podría, por ejemplo, permitir que se despliegue una versión antigua de la aplicación sin que se vean reflejados los cambios actuales de la misma. El despliegue de una versión antigua de la aplicación también puede traer problemas para los alumnos y sus clientes en el sentido de que estos últimos no verían, de ser el caso, los recientes cambios solicitados a nivel funcional con lo que habría malestar por el trabajo que se está observando y recibiendo. Se debe tener en cuenta que para la empresa SALUDABLE, por ejemplo, el cliente es una institución de salud y la entrega de una versión antigua de la aplicación podría provocar que la UPC pierda la asociación tiene con esta con lo que se perdería un cliente real y una clara oportunidad para el alumno de conocer y desarrollarse profesionalmente en un entorno adecuado. c) Perder la posibilidad de realizar o solicitar un mantenimiento adecuado a las aplicaciones en caso de ser necesario. Durante la recopilación de información sobre la situación actual en las empresas virtuales se observó que una aplicación que estaba desplegada en los servidores del centro de cómputo requería ser utilizada. Para ello se pidió que se llame o ubique al dueño de dicha aplicación. Esto no se pudo realizar debido que no se tenía idea de quién era el alumno que lo había realizado, por supuesto, existían sospechas o se oía mencionar algún posible nombre, pero no se tenía la certeza de esto. Es claro que un gran problema de no tener una adecuada documentación sobre un determinado proyecto impide que se pueda conocer al alumno responsable de su diseño, implementación y despliegue. d) Se identificó además que en las empresas virtuales era muy difícil continuar o complementar los proyectos existentes en los servidores. En, algunas ocasiones, los alumnos de las empresas virtuales desearon continuar implementando o desarrollar una segunda versión de un proyecto ya existente en los servidores, pero la inexistencia de una adecuada fuente centralizada de conocimiento sobre los proyectos hace imposible la realización de esta tarea. Esta situación evita que se continúe con la investigación y desarrollo de algún tema de tesis que como tal es interesante de abordar, ya que una inadecuada documentación o un inadecuado almacenamiento de la misma evitará que este pueda ser abordado, comprendido y utilizado en el futuro. Sucesos que complicaron la situación del modo en que se llevan a cabo los despliegues de las aplicaciones en las empresas virtuales. La información que fue obtenida durante la investigación y documentación del modo en que eran desplegadas las aplicaciones que se desarrollaban en las empresas virtuales de la UPC nos llevó conocer una situación que agravó la, ya de por sí, mala práctica que se realizaba hasta el momento. El personal del centro de cómputo y el testimonio de algunos alumnos consultados y que ya habían egresado de la UPC permitió conocer que los servidores que existían en el centro de cómputo fueron, en algún momento del tiempo, reemplazados por otros más modernos y de mayor capacidad a los que existían. Como tal una actualización de servidores no está mal, sino por el contrario, permite tener una mayor capacidad de recursos para optimizar y dar una mayor calidad de respuesta a las aplicaciones que se alojarán en estos servidores más potentes. Pero el problema como tal surge cuando no existe una adecuada migración de las aplicaciones existentes en los servidores que serán reemplazados. Esta situación que se dio en el centro de cómputo agravó aún más la trazabilidad que se requería para las aplicaciones debido a que además de no existir una documentación clara y detallada sobre el software tampoco se tenía certeza de cuál era el servidor en el que este se encontraba. 12 Antecedentes sobre las necesidades de las empresas virtuales detectadas durante la recopilación de información sobre la forma de despliegue de las aplicaciones hasta ese momento (ciclo académico 2010-01). Las necesidades de las empresas estaban, hasta ese momento, claramente definidas en función a la información recopilada sobre el modo en el que los despliegues eran realizados. Los gerentes de las empresas virtuales constantemente requieren el despliegue de aplicaciones que ayuden a soportar los procesos y giros de negocio que cada una de estas posee. No necesariamente estas aplicaciones que requieren son las que los alumnos han desarrollado a lo largo de uno o dos ciclos académicos. Por ejemplo, según lo que se observó era muy utilizada una aplicación que permitía la toma de asistencia de los alumnos a las clases del curso de Taller de Proyecto I y Taller de Proyecto II. Entonces, en base a estos requerimientos era evidente que lo que los gerentes de estas empresas requerían era disponibilidad de sus aplicaciones y un ambiente seguro en el cual poder desplegarlas. Este ambiente y esta disponibilidad no iban a poder ser garantizados si no existe un medio claro de control y seguimiento de la configuración de los servidores y de las aplicaciones que estos poseen. Los alumnos requieren de ambientes virtuales sobre los cuales realizar los despliegues de sus aplicaciones, pero además requieren de información confiable y exacta sobre las demás aplicaciones que se encuentran desplegadas en los servidores del centro de cómputo. Esta necesidad de información como ya se mencionó en el presente capítulo se da debido a que, por ejemplo, en algún momento lo alumnos requieren conocer el comportamiento y dependencias de una aplicación porque desean continuar su desarrollo o realizar una aplicación compatible a este. Si no existe un medio estructurado de control esto no podrá ser realizado. Otra de las necesidades identificadas para los alumnos de las empresas virtuales que desarrollan aplicaciones es la seguridad en cuanto a los accesos y manipulación que cada una de estas puede tener. Esto se observó debido a que no existe un control sobre los alumnos que pueden acceder al centro de cómputo. Al no existir este control es posible que un alumno ingrese a la sala de servidores y manipule de manera intencional o casual la aplicación de otro alumno, pudiendo provocar el malfuncionamiento de una o muchas aplicaciones desplegadas. Esta necesidad se hace evidente ante la respuesta del personal que labora en la sala de servidores quienes indican que los alumnos ingresan en todo momento y no tienen idea de los componentes o aplicaciones que estos instalan, manipulan o configuran. En cuanto a la seguridad de la información los alumnos y profesores que desempeñan el rol de gerentes de las empresas virtuales indicaron que era necesaria la existencia de planes de contingencia en caso ocurra una falla en los equipos. Es lógico entender la necesidad de asegurar la información de las empresas virtuales, ya que en caso de falla de equipos puedes verse comprometidos los avances de los proyectos de los alumnos, las aplicaciones que soportan determinados procesos de las empresas y lo que es mucho mas delicado aún la información que estas aplicaciones pueden almacenar. Por los planes de seguridad o contingencia en caso de fallos deberán cubrir todas estas necesidades encontradas para los profesores y alumnos. Antecedentes sobre las expectativas declaradas para el proyecto por parte del director de la facultad profesor Jorge Cabrera Berrios. El profesor dejó claros varios aspectos que él deseaba se logren con el desarrollo del proyecto de tesis “Gestión de la Puesta en Producción”. a) Conocer claramente la situación actual de las empresas virtuales en cuanto al proceso de despliegue de aplicaciones para en base a esta información plantear una solución eficiente y adecuada. b) Plantear en base a la información recopilada sobre la investigación de la situación de las empresas una solución que satisfaga todas las necesidades de los involucrados en el proceso. Se determinó que los principales involucrados en este proceso serían los profesores, alumnos y en menor medida los empleados administrativos del centro de cómputo. c) Dar un adecuado uso y manipulación a los nuevos servidores adquiridos para ese momento (ciclo académico 2010-01), los cuales servirían para dar soporte al proceso o marco de trabajo que se plantearía en el desarrollo del proyecto “Gestión de la Puesta en Producción”. d) Sortear las limitantes técnicas que podían presentarse durante el manejo de los nuevos servidores, debido a que su uso requiere gran cantidad de conocimientos técnicos que hasta ese momento no se poseían por no ser parte del perfil requerido para los alumnos. Esta situación de bajos conocimientos técnicos serían a primera vista una de las dificultades quizás mas difíciles de superar. e) Finalmente, el planteamiento de un proceso o estructura de trabajo para el despliegue de las aplicaciones que se desarrollan en las empresas virtuales de la UPC deberían generar un valor agregado para estas. Esto significa que el uso de un marco de trabajo debe aportar un valor extra a las aplicaciones que serán desarrolladas y luego entregadas, y utilizadas por un usuario final. No es difícil intuir los beneficios que la implantación de un marco de trabajo puede generar para estas aplicaciones. Por ejemplo, una mayor facilidad de mantenimiento si es que se registra y documenta de manera adecuada las características, problemas y dependencias que esta posee. Otra clara ventaja desde el punto de vista de un cliente es que permitirá asegurar que el usuario final de la aplicación recibe un producto que ha sido sometido o, mejor dicho, ha sido desarrollado bajo determinadas actividades que buscan asegurar, entre otras cosas, su correcto funcionamiento, 14 disponibilidad y aseguramiento de las información que este posee con el uso de planes de contingencia en caso de fallas por nombrar solo algunos. Antecedentes sobre los riesgos identificados para el desarrollo del proyecto “Gestión de la Puesta en Producción”. Luego de la recopilación de información sobre la situación en las empresas virtuales y teniendo en cuenta las expectativas de los alumnos y profesores, y además de haber verificado la naturaleza y hardware disponible para el desarrollo del proyecto se identificaron dos riesgos importantes. a) El manejo del hardware que debía realizarse para llevar a cabo los despliegues de todas las aplicaciones que sean desarrolladas. Esto debido a que no existía registro o personal correctamente capacitado que pueda brindar información útil para su uso y configuración. Lo que significaba que la investigación sobre el manejo de eta debía realizarse por cuenta propia. b) Otro de los riesgos que se determinó en base al modo de como los alumnos venían realizando los despliegues iba por el lado de la implantación de una cultura de trabajo que sería necesario aplicar y que todos los involucrados en el proceso de despliegue de aplicaciones debían seguir. Por experiencias de personas que han realizado trabajos similares se sabe que implantar una cultura de trabajo de un momento a otro puede ser una tarea muy difícil y todo depende de la predisposición de las personas a aceptar y seguir las nuevas reglas de trabajo. En este caso, las nuevas reglas consistirían en actividades a seguir para asegurar que cada despliegue de una aplicación cumpla con las expectativas de todos los involucrados. Capítulo 2. Marco Teórico En el presente capítulo, se desarrollará el soporte teórico para el proceso de puesta en producción que se planteará e implementará en las empresas virtuales de la UPC. Este marco teórico entre otras cosas detallará las metodologías como, por ejemplo, ITIL que se utilizarán para el desarrollo de cada una de las actividades que constituirán este marco de trabajo. Gestión de la Puesta en Producción Concepto La Gestión de la Puesta en Producción es la implementación de un proceso integrado para lograr una entrega efectiva de un producto o servicio que satisfaga los requerimientos tanto del propio negocio de una empresa y, de ser el caso, el cliente6. Una gestión adecuada de las tecnologías de información para la puesta en producción de una aplicación permite lograr grandes niveles de satisfacción y servicio al cliente. Por el contrario, el trabajo de manera reactiva, es decir, dedicar poco tiempo a la implementación de prácticas estructuradas sobre la planificación, formación, revisión, investigación y trabajo pueden generar descontento en los clientes por lo que se limitaría el crecimiento y expansión de una empresa con estas deficiencias. Con la Gestión de una Puesta en Producción se entiende que los productos software, especialmente, las aplicaciones Web se encuentran en un ciclo continuo de desarrollo, pruebas y puesta en libertad. Además de este ciclo continuo existe una creciente complejidad de las plataformas en la que estos sistemas se ejecutan. Esto permite comprender la existencia de una gran cantidad de piezas en movimiento que deben encajar para garantizar el éxito y el valor en el tiempo del proyecto o producto software. 6 WIKIPEDIA (2011) 16 Para lograr una adecuada Gestión de la Puesta en Producción el ISO/IEC 20000 proporciona y describe buenas prácticas en este proceso de manera independiente a la organización de la empresa, la forma en la que está estructurada y el tamaño de esta. Es decir, el ISO/IEC 20000 trata de modelar y plantear el mejor modo de entregar al cliente y a la propia empresa un producto que satisfaga, de manera adecuada, las necesidades y requerimientos de los clientes u empresas con las aplicaciones. Actividades principales durante el proceso de Puesta en Producción Planificación En la planificación se establece un marco general en el que se fijan las fechas para las actividades tanto del proyecto como de la aplicación en cuestión. La planificación debe ser consensuada y aprobada por parte del solicitante y por parte del personal asignado al proyecto. En cualquier caso, la planificación debe contemplar lo siguiente: a) Alcance, contenido, riesgos y responsabilidades. b) Recursos necesarios: software, hardware y recursos humanos. c) Equipo de trabajo requerido. d) Método de colaboración con todas las partes interesadas. e) Cronograma detallado. f) Soporte7. Cuando se prepara una entrega, primero se debe estar informado de lo que se exige que cumpla la nueva entrega, estos son los requerimientos. Por ejemplo, las mejoras que deben superar las fallas en el software existente. Eso se puede organizar mediante el uso de un Sistema de seguimiento de errores (Bugtracker). Un paso paralelo es fijarse en las dependencias. El software está a menudo compuesto de muchos módulos que dependen uno del otro para trabajar. Si cambia uno, eso afectará al otro. Una vez que los requerimientos y las dependencias son conocidas se puede comenzar a planificar el desarrollo. Planificación del desarrollo Cuando nos sean conocidos los requerimientos, dependencias y plazos, comienza el build o construcción de la nueva entrega. El primer paso es el diseño de la nueva entrega. Se puede hacer usando técnicas de desarrollo de software, por ejemplo UML. El diseño es convertido en código fuente 7 UNED (2011) de algún lenguaje de programación (por ejemplo C o C#). Se da a conocer a los desarrolladores la fecha de término para cambios (congelar el repositorio). Las piezas de código, clases, archivos de configuración, etc. Son entonces traídas desde el repositorio mediante un checkout, compiladas, enlazadas y finalmente armadas en un solo programa, un built. Se debe colocar una marca (tag) en el repositorio sobre la versión que fue traída, para posteriormente conocer el estado de avance de la versión usada por el usuario8. Pruebas o Testing Cuando la aplicación ha sido implementada, es enviado al departamento de control de calidad para las pruebas estándares de aceptación. El programa es revisado para verificar que cumple con los requerimientos y dependencias y que funciona correctamente. Durante esta fase, el proceso completo es documentado para tener en el futuro una base de conocimientos. Después de la verificación final se deben actualizar los estándares de prueba para adaptarlos al nuevo software. Preparación de la entrega de la aplicación o software Cuando se tiene una entrega correcta y probada, esta entrega debe ser empacada con los documentos necesarios como pueden ser: a) Lista de fallas que han sido corregidas. b) Nombre de la entrega (versión de la aplicación que se ha desarrollado). c) Especificación del entorno para el cual se ha construido la entrega. d) Archivos de configuración. e) Informes de las pruebas realizadas. Entrega o puesta en producción Este procedimiento hace referencia a la instalación de la aplicación para que esta pueda ser utilizada por el usuario o solicitante de la aplicación. 8 GOOGLE BOOKS (2011) 18 Ventajas y beneficios de la Gestión de la Entrega Es necesario desarrollar el software para enfrentar nuevos requisitos, fallas y tecnologías. Al usar una Gestión para la Puesta en Producción se gana un desarrollo estructurado y otros beneficios al contrario de desarrollar el software en forma intuitiva a) Da la posibilidad de planificar el uso de recursos. b) Es un proceso estructurado eficiente y efectivo. c) Los cambios aparecen de una vez, limitando en el tiempo los efectos sobre el usuario. d) Ayuda a verificar la funcionalidad y su uso antes de la entrega mediante pruebas. e) Utiliza control de versiones y almacenamiento central que aseguran el uso de la versión correcta. Objetivos Los objetivos principales del proceso de Gestión de la Entrega son: a) Planificar y supervisar el paso a producción de software y hardware. b) Controlar procedimientos eficientes para la distribución e instalación de los Cambios en los sistemas TI. c) Asegurarse de que las modificaciones que se están realizando sobre el Software y hardware se registran, son seguras y sólo se instalan versiones correctas, autorizadas y probadas. d) Comunicarse con los responsables de proyectos y gestionar sus expectativas durante la planificación y desarrollo de los nuevos pases a producción. e) Implementar nuevas versiones de hardware y software utilizando los Gestión de la configuración y Gestión de Cambios. Procesos asociados a la Gestión de la Puesta en Producción Gestión de la Configuración Se denomina Gestión de la Configuración al conjunto de procesos destinados a asegurar la validez de todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema de Información (S.I.), a través del estricto control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en el citado desarrollo. Estos dos elementos (control de cambios y control de versiones de todos los elementos del Sistema de Información) facilitan también el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en cada etapa del desarrollo. La gestión de la configuración se realiza durante todas las fases del desarrollo de un sistema de información, incluyendo el mantenimiento y control de cambios, una vez realizada la puesta en producción9. Por ejemplo, si tiene un proyecto de 1.000.000 de horas donde trabajan 1.000 ingenieros en distintos países. La pregunta es: ¿Cómo se puede gestionar esto? Pueden surgir muchos problemas, por ejemplo: un equipo necesita un módulo que otro equipo está haciendo pero que aún no ha terminado, y lo necesita para probar el suyo. Como no lo tienen todavía lo simulan, pero puede ocurrir que esta simulación no se comporte igual al módulo del otro equipo. Pueden surgir también inconsistencias entre los diferentes subsistemas debidos a malos entendidos acerca de los servicios que ofrecen unos a otros, etc. La gestión de la configuración se realiza desde que comienza el proyecto hasta que termina e involucra la recolección y el mantenimiento de toda la información sobre hardware y software de los sistemas que se usen. Forma parte de un proceso más general de gestión de la calidad del software, de hecho, la misma persona o grupo que se encarga de la calidad del software puede encargarse también de este apartado. La finalidad de todo esto es tener controlados todos los cambios que se hacen sobre el software y tener toda la información necesaria en el momento del mantenimiento10. Gestión de Cambios Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda "evolución a mejor" requiere necesariamente de un cambio. Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: "si algo funciona, no lo toques". Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin 9 ITIL (2011) 10 ITIL (2011) 20 evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizadas. Las principales razones para la realización de cambios en la infraestructura TI son: a) b) c) d) Solución de errores conocidos. Desarrollo de nuevos servicios. Mejora de los servicios existentes. Imperativo legal. El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI (Tecnologías de Información). Capítulo 3. Descripción del Proyecto En el presente capítulo, se presenta el objetivo general del proyecto y sus objetivos específicos, los cuales serán la base para el desarrollo del mismo. Asimismo, se definen las metodologías a utilizar durante la realización de todo el proyecto, que además ayudarán a lograr estos objetivos. Además, se indica el alcance del proyecto, el equipo de trabajo y los riesgos del mismo para el desarrollo del proyecto11. El proyecto tendrá como finalidad inicial hacer un diagnóstico del problema, con la intención de conocer cuáles son las actividades rescatables y cuáles son las que se deben mejorar, así como mapear cada uno de los roles involucrados en el proceso, para esto el primer paso consistirá en recoger la mayor cantidad de información para poder cumplir con el objetivo ya expuesto. Luego, se procederá a crear un modelo de todo el proceso tomando como referencia la información recabada, documentos que contengan modelos anteriormente hechos, de existir los mismos, casos de éxito, alguna referencia bibliográfica y la información que podamos conseguir tanto del gerente de la Empresa (IT-EXPERT) y del especialista asignado a la misma. En paralelo, analizaremos y decidiremos qué herramienta software será la más adecuada para lograr nuestro objetivo de contar con un control de versiones adecuado para todas y cada una de las aplicaciones, y de esta manera evitar conflictos. Por último, en la segunda parte correspondiente al ciclo 2011-2, se deberá llevar a cabo la ejecución del estándar ya definido y de la herramienta de control de versiones y todo debe funcionar de manera sincronizada. Objetivo del Proyecto Objetivo General Lograr que el proceso de Gestión de Puesta en Producción, a partir de su implementación, agregue valor a los demás procesos que permiten el funcionamiento de todas las Empresas Virtuales en la UPC, generando una clara segmentación de los diferentes ambientes que este proceso involucre (desarrollo, pruebas y producción). 11 Análisis y Diseño de la Arquitectura de Procesos de una micro financiera para los procesos de RRHH y MKT V3.0 22 Objetivo Específico a) Realizar la definición y modelado de cada uno de los procesos y roles que conforman la Gestión de la Puesta en Producción. Esta definición se tendrá alineada a la información que se obtendrá de todas las empresas virtuales sobre cómo se lleva este proceso hasta el momento. b) Implementar una herramienta software para el control de versiones de las aplicaciones. c) Implementar, para el ciclo académico 2011-02, el modelo de Gestión de Puesta en Producción de aplicaciones software. d) Permitir, con el proceso establecido para el despliegue de las aplicaciones software que se desarrollan en las empresas virtuales de la UPC, conocer las características técnicas y funcionales, y su ubicación en los servidores de la universidad. Además, el proceso debe permitir llevar un registro de los problemas e incidencias, en caso existan, de estas aplicaciones. Indicadores de Éxito Para el presente proyecto se definen como indicadores de éxito: Objetivo Específico “a”. a) Cumplir con los tiempos establecidos para ambas partes del proyecto. (ciclo 201101 y ciclo 2011-02) b) Conseguir la aprobación del proyecto por parte del comité. c) Lograr la aprobación de un especialista en gestión de puesta en producción. Objetivo Específico “b” y “d” d) Lograr, a partir del control de versiones, mitigar los conflictos generados por el desorden de ubicación y nombramiento de las aplicaciones en cada una de las empresas. Objetivo Específico “c” e) Realizar una distribución adecuada del centro de cómputo para cumplir con la implementación de los diferentes ambientes necesarios planteados en este proyecto. f) Lograr configurar y crear cada uno de los ambientes propuestos (desarrollo, pruebas y producción) en el nuevo servidor con que cuenta la Universidad de Ciencias Aplicadas y que ha sido adquirido para dar soporte al desarrollo de este proyecto. Metodología del Proyecto PMBOK (Project Management Body of Knowledge) El Project Management Body of Knowledge (PMBOK) es un estándar desarrollado por el Project Management Institute, que brinda un conjunto de buenas prácticas para la gestión de proyectos, divididas en nueve áreas de conocimiento, que generalmente son comunes para todo tipo de proyectos. Las áreas de conocimiento son las siguientes12: a) Gestión de la Integración del Proyecto b) Gestión del Alcance del Proyecto c) Gestión del Tiempo del Proyecto d) Gestión de los Costos del Proyecto e) Gestión de la Calidad del Proyecto f) Gestión de los Recursos Humanos del Proyecto g) Gestión de las Comunicaciones del Proyecto h) Gestión de los Riegos del Proyecto i) Gestión de las Adquisiciones del Proyecto Durante el ciclo de vida del presente proyecto, se podrán considerar las buenas prácticas presentadas a la mayoría de las áreas del conocimiento, ya que la Gestión de los Costos y Adquisiciones del Proyecto no serán consideradas como referencia por tratarse de un proyecto académico en el cuál no se tendrán que incurrir gastos significativos para la gestión y elaboración del mismo. 12 PMBOK - Project Management Body of Knowledge 24 BPMN (Business Process Modeling Notation) BPMN es una notación gráfica estandarizada que permite el modelado de procesos de un negocio en particular, inicialmente fue desarrollada por BPMI (Business Process Management Initiative), que sufrió una fusión con OMG (Object Management Group) en Junio de 2005. Actualmente, la última versión aprobada es la 1.2, pero se está a la espera de una versión futura que sería la versión 2.0, que aún se encuentra en beta. El objetivo principal del BPMN es el de proveer una notación estándar que permita el modelamiento del negocio, de tal forma que los procesos sean entendibles, de una forma fácil y sencilla, por los involucrados e interesados del negocio. El modelado en BPMN se realiza mediante diagramas simples y con un conjunto pequeño de elementos gráficos. En la versión actual, se cuenta con 4 categorías básicas de elementos, que son los siguientes: Objetos de flujo: Definen el comportamiento de los procesos. Está compuesto por eventos, actividades y gateways (Rombos de control de flujo). o Eventos: Ocurren durante el desarrollo de un proceso de negocio y afectan el flujo del proceso. Se encuentran clasificados en 3 tipos. Figura 3.1 - Eventos BPMN Fuente: Business Process Modeling Notation Actividades: Representan actividades, las cuales pueden ser simples o compuestas, que se realiza dentro de un proceso de negocio. Los dos tipos de actividades que existen son: Figura 3. 2 - Actividades BPMN Fuente: Business Process Modeling Notation o Gateways: Son elementos que sirven para el control del flujo del proceso de negocio. Existen 5 tipos de compuertas: Compuerta exclusiva Compuerta basada en eventos Compuerta paralela Compuerta inclusiva Compuerta compleja Figura 3.3 - Gateway BPMN Fuente: Business Process Modeling Notation Objetos de conexión: Utilizados para unir dos objetos del flujo del proceso de negocio. Existen 3 tipos de objetos de conexión: o Líneas de Secuencia o Asociaciones o Líneas de Mensaje Figura 3.4 - Objetos de conexión BPMN Fuente: Business Process Modeling Notation Canales: Se utiliza para organizar las actividades del flujo en diferentes categorías visuales que representan áreas funcionales, roles o responsabilidades. Existen 2 tipos: o Pools o Lanes Figura 3.5 - Canales BPMN Fuente: Business Process Modeling Notation Artefactos: Proveen información adicional sobre el proceso de negocio. Existen 3 tipos: o Objetos de Datos o Grupos 26 o Anotaciones o Objetos de Datos Figura 3.6 - Artefactos BPMN Fuente: Business Process Modeling Notation Fundamentos de la Gestión de Servicios de IT: Basado en ITIL La Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente abreviada ITIL (del inglés Information Technology Infrastructure Library), es un marco de trabajo de las buenas prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI). Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido en el estándar mundial de facto en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización. ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones13. 13 ITIL (2011) Alcance del Proyecto El alcance del proyecto para la primera parte del mismo, es decir, el periodo correspondiente al ciclo académico 2011-1 tendrá en consideración los siguientes puntos. El Proyecto incluye: a) Revisión y diagnóstico de la forma como se está llevando a cabo el ciclo de puesta en producción en la actualidad. b) Mapeo de todos los roles, tanto internos como externos, involucrados en todo el proceso en cuestión. c) Modelado y documentado de todo el proceso y en paralelo estudio de la herramienta a utilizar para llevar a cabo el control de versiones de los aplicativos, que por cierto son el principal input de todo nuestro proceso. d) Implementación de los diferentes ambientes necesarios, según el marco de trabajo propuesto en base a la disponibilidad del equipamiento existente en el centro de cómputo. e) Puesta en producción de una aplicación utilizando el software de control de versiones. El Proyecto excluye: a) Todo proceso que se lleve a cabo antes del ingreso de solicitud de creación, corrección o mejora de los aplicativos que se manejan en las empresas de línea de la Universidad. b) El mantenimiento de los aplicativos en producción o responsabilidad respecto a cualquier problema funcional de los mismos. c) Instalación y/o configuración de los aplicativos en el ambiente de producción a nivel operativo, así como el manejo de la base de datos asociados a los mismos. d) Implementación de un Software que automatice el proceso de Gestión de Puesta en Producción de las aplicaciones software del Centro de Cómputo de la UPC. 28 Equipo del Proyecto Comité de Proyectos (Jorge Cabrera, Rosario Villalta, Carlos Raymundo) Gerente General de Empresas Virtuales (Amanda Sanchez) Gerente General de IT-Expert (William Romero) Gerente de Proyecto Asesor(a) de Proyecto (Britha Laurel) (Luis Mamani) Jefe de Proyecto e Ingeniero de Procesos Stakeholders (Moisés Rivera, Leonardo Soto) Figura3.7 – Equipo del proyecto Fuente: Elaboración propia Riesgos del Proyecto a) No contar con una línea base respecto del proceso de gestión de puesta en producción. b) No contar con uno de los integrantes del proyecto. c) No configurar adecuadamente los ambientes producción en el tiempo requerido. de desarrollo, certificación y d) No encontrar disponibilidad en los recursos identificados para levantar los ambientes o configurarlos. e) No levantar los ambientes de desarrollo, certificación y producción en el tiempo requerido. f) Poca disponibilidad de los involucrados en los procesos a modelar e implementar para brindar información respecto a la misma. g) La falta de un estándar respecto a los tipos de tecnologías que se usan (bases de datos en Oracle, SQL Server, MySQL, DB2, etc. Aplicaciones en .Net. Java. PHP, distintos framework) pues en producción será complicado contar con suficientes recursos de Hardware para soportarlas. Para mayor detalle revisar el Anexo Nro. 7.11 (Matriz de Riesgos) 30 Capítulo 4. Descripción de los procesos planteados para el proyecto de “Gestión de Puesta en Producción” En el presente capítulo, se definen y detallan cada uno de los procesos que soportan la “Gestión de la Puesta en Producción”. Se definen, por ejemplo, cada una de las actividades realizadas, la herramienta software planteada para dar soporte a cada una de estas actividades, la nomenclatura utilizada para identificar los objetos asociados a cada uno de los proyectos con el cual se está trabajando y la documentación diseñada para registrar la información relacionada a la puesta en producción de cada aplicación software. Proceso de pase a los ambientes de Desarrollo, Pruebas y Producción. Para la Puesta en Producción se han identificado y definido tres procesos bien diferenciados y soportados bajo la metodología ITIL. Estos procesos conforman el ciclo de vida de un software desde que este empieza a ser implementado hasta que comienza a ser utilizado por los usuarios finales. El siguiente gráfico soporta los ambientes creados e implementados: Figura 4.1 – Ciclo de vida de la entrega de software Fuente: Adaptado de “ITSM LIBRARY Fundamentos de gestión de servicios TI: basado en ITIL” Este diagrama se ha tomado del libro “ITSM LIBRARY Fundamentos de gestión de servicios TI: basado en ITIL” que es un libro que plantea soluciones basadas en las tecnologías de información soportados por ITIL (Information Technology Infrastructure Library) Pase al ambiente de Desarrollo. En este proceso se inicia el desarrollo de la aplicación software. Se ha utilizado una herramienta de versionamiento que ordena el desarrollo al evitar, por ejemplo, que se trabaje sobre con una versión de la aplicación que no es la última, este sistema de control de versiones se caracteriza por14: a) Proveer un mecanismo de almacenamiento de elementos que serán gestionados durante el ciclo de vida de la puesta en producción del software como, por ejemplo, imágenes, código, texto y documentos. b) Permite trabajar sobre los elementos almacenados como su ordenamiento, renombrarlos, editarlos o eliminarlos. c) Registro histórico de las actividades realizadas sobre cada uno de los elementos almacenados sobre el repositorio. Este registro permite conocer, de ser necesario, el comportamiento y avance de cada uno de los componentes del software que se está implementando. Pase al Ambiente de Pruebas. En este proceso se solicita que la aplicación de software que se ha desarrollado o aún está en proceso de desarrollo cumpla determinados requisitos para que se pueda empezar a determinar si cumple con determinados requerimientos funcionales y “no funcionales” que son parte de la definición con que fue planteado. Implementar un ambiente de pruebas es necesario para garantizar la calidad de la aplicación software y de que logrará satisfacer de manera adecuada las necesidades de los usuarios finales. Pase al Ambiente de Producción Este proceso permite el despliegue de la aplicación software luego de que ha pasado las pruebas de validación y verificación por la “Empresa QA”. Es en este ambiente de donde la aplicación será utilizada por los usuarios finales y es el proceso final asociado al ciclo de vida de la puesta en producción de la aplicación. 14 Tortoise SVN (2010) 32 Mapa de procesos. A continuación se muestra el mapa de procesos de la empresa IT-Expert, en este la gestión de la puesta en producción se encuentra en dentro del proceso “Gestión de Aplicaciones”. Figura 4.2 – Mapa de procesos de la empresa IT-Expert Fuente: Elaboración propia Requerimientos de negocio. En este punto se plantean los requerimientos del proyecto de “Gestión de Puesta en Producción” y sobre los cuales se planteará la metodología o marco de trabajo que busca llevar a cabo los despliegues de las aplicaciones de manera más eficiente y estructurada. a) Establecer todas las actividades necesarias para llevar a cabo la puesta en producción de una aplicación software desde su desarrollo hasta ubicarlo en el lugar desde donde será accedido por los usuarios finales. b) Agrupar las actividades establecidas para la puesta en producción de las aplicaciones en procesos definidos y claros con logros medibles. c) Asegurar que todos los alumnos de las empresas virtuales que desarrollan aplicaciones software utilicen un único proceso para lograr la puesta en producción de sus aplicaciones. d) Establecer cada uno de los roles que intervienen en la puesta en producción de una aplicación software. e) Guardar las versiones de las aplicaciones para controlar el avance de estas durante todo el tiempo que tarde su implementación. f) Controlar que las actividades establecidas para el proceso de puesta en producción sean llevadas a cabo en su totalidad y, en caso no se pueda, plantear nuevas actividades que permitan que el objetivo del proceso se cumpla. g) Conocer el avance de las aplicaciones software dentro del proceso de su puesta en producción. h) Almacenar información sobre los problemas que se encuentren durante la ejecución de los despliegues de las aplicaciones para que sirvan de fuente de conocimiento en futuros despliegues. i) Permitir la continuidad del proceso en el tiempo, es decir asegurar que este se siga llevando a cabo y no se deje de utilizar en los próximos ciclos académicos. Diagrama de objetivos. El diagrama de objetivos para la gestión de puesta en producción es el siguiente. 34 Figura 4.3 – Diagrama de Objetivos para la Gestión de la Puesta en Producción Fuente: Elaboración propia Diagramas BPMN de los Ambientes de Desarrollo, Pruebas y Producción Figura 4.4 – Diagrama de primer nivel de la Gestión de Puesta en Producción Fuente: Elaboración Propia 36 Pase a Desarrollo Figura 4.5 – Realizar pase a Ambiente de Desarrollo Fuente: Elaboración Propia Actividad E1 Entrada - Salida Descripción Rol Involucrado Necesidad de contar El proceso inicia con la con un ambiente para necesidad de contar con un Jefe de Proyecto desarrollar un ambiente para desarrollar un Owner aplicativo software aplicativo software Actividad Previa - Diseño de Arquitectura de A1 Software, Modelo de Datos y Solicitud de requerimientos de HW y SW Preparar y enviar solicitud de Jefe de Proyecto requerimientos de HW y SW Owner E1 Procesos Solicitud de A2 requerimientos Solicitud analizada Analizar solicitud de HW y SW Si C1 A3 A4 No (Regresa a A1) Solicitud aceptada Solicitud ¿Solicitud aceptada? Separar espacio en cada uno Solicitud Aceptada de los ambientes para nuevo proyecto Especificaciones de Enviar OK para pase a Gerente de ITEXPERT Gerente de ITEXPERT Gerente de ITEXPERT Gerente de IT- A1 A2 A2 C1 (Si) 38 Actividad Entrada Salida Descripción Rol Involucrado Aceptada uso del servidor de Desarrollo, se tiene 3 días EXPERT desarrollo, usuario y para responder al Jefe de password asignado Proyecto Owner Actividad Previa - Manual de Instalación y Configuración - Ficha de Especificaciones de uso del servidor de A5 desarrollo, usuario y password asignado Componentes -Plan de Pruebas - Set de casos de pruebas Construir la aplicación en el Jefe de Proyecto - Resultado de las ambiente de desarrollo Owner Coordinar con QA el pase al Jefe de Proyecto E3 pruebas unitarias - Componentes de la aplicación y scripts para la creación y configuración de la base de datos A6 Correo con Correo con solicitud A3 Actividad Entrada Salida Descripción Rol Involucrado solicitud para para atención en QA ambiente de certificación Owner Actividad Previa atención en QA - Manual de Instalación y Configuración - Ficha de Componentes A7. Correo de -Plan de Pruebas solicitud por - Set de casos de parte de QA pruebas para enviar ruta - Resultado de las con pruebas unitarias componentes y - Componentes de la documentos aplicación y scripts Subir componentes y documentación a ruta Jefe de Proyecto certificación de pase a Owner C1 (No) Ambiente de Certificación para la creación y configuración de la base de datos Todo subido en la ruta certificada E2 Mensaje a - Fin de proceso Jefe de Proyecto E5 40 Actividad Entrada Salida Descripción Gerente de QA Rol Involucrado Owner respecto a ruta certificada donde se subieron los componentes y documentos para pase al ambiente de certificación Tabla 4.1 – Caracterización del proceso de Pase a Desarrollo Fuente: Elaboración propia Actividad Previa Pase a Pruebas 42 Figura 4.6 – Realizar pase a Ambiente de Pruebas Fuente: Elaboración Propia Actividad E1 Entrada - A1. Estimar Correo con ruta tiempo y donde se recursos para encuentran los certificación de componentes y producto los documentos Salida Descripción Correo con ruta Correo con ruta donde se donde se encuentran encuentran los componentes los componentes y los y los documentos para su documentos respectiva certificación Rol Involucrado Actividad Previa Gerente de Proyectos y - Recursos QA Documento con estimación de tiempo para certificación y recursos Estimar tiempo y recursos Gerente de para certificación de Proyectos y producto Recursos QA E1 asignados A2. Asignar proyecto a Documento con recurso(s) para estimación de realizar las tiempo para Proyecto asignado a recurso(s) para realizar las pruebas certificación y Recurso (s) pruebas correspondientes correspondientes recursos para su asignados Asignar proyecto a para su certificación Gerente de Proyectos y A1 Recursos QA certificación A3. Verificar CheckList para Documentos y Verificar componentes y componentes y verificar que componentes documentos copiados desde Analista Tester A2 44 Actividad Entrada Salida Descripción documentos documentos y revisados la ruta certificada estén copiados desde componentes la ruta estén completos Rol Involucrado Actividad Previa Analista Tester A3 completos certificada estén completos C2. ¿Están completos? - A5. Volver a No (C2) ficha y manuales A4.Solicitar instalación y pruebas del aplicativo a IT- documentos revisados y reordenados (Hacia A3) a ruta certificada servidor para No Componentes y subir componentes, Si ¿Están completos? Volver a subir componentes , ficha y manuales a ruta certificada Jefe de Proyecto Owner C2 (No) Solicitud de servidor Documentos y para iniciar Solicitar servidor para componentes instalación, instalación y pruebas del completos configuración y aplicativo a IT-EXPERT Analista Tester C2(Si) pruebas EXPERT A6. Enviar por Solicitud de Correo con datos (ip, Enviar por correo datos Gerente de IT- correo datos servidor para usuario y password de sobre servidor para pruebas EXPERT A4 Actividad Entrada Salida sobre servidor iniciar servidor donde se para pruebas instalación, hará la instalación, configuración y configuración y pruebas pruebas del aplicativo Descripción Rol Involucrado Actividad Previa Analista Tester A6 Analista Tester A7 Analista Tester C3(Si) ¿Validado? Analista Tester A8 Certificar Aplicación Analista Tester C4(Si) software) A7. Validar Ficha de Componentes C3. ¿Validado? Ficha de Componentes - Ficha de Componentes evaluado Si No (Hacia A5) Validar Ficha de Componentes ¿Validado? A8. Validar manuales de instalación y Manual de Manual de instalación configuración instalación y y configuración junto con Jefe configuración evaluado de Proyecto Validar manuales de instalación y configuración junto con Jefe de Proyecto Owner Owner C4. ¿Validado? A9. Certificar - Si No (Hacia A5) Set de casos de Aplicación certificada 46 Actividad Entrada Componentes y Pruebas Salida Descripción Rol Involucrado Actividad Previa Analista Tester A9 Analista Tester - Documentos Componentes de la aplicación Componentes de la aplicación A10. Subir certificados, componentes y manual de documentos instalación y certificados a configuración y ruta ficha de certificados, manual de instalación y configuración y ficha de componentes Correo con ruta Fin de Proceso - Enviar donde se componentes, manual y ficha ruta ruta certificada validados encuentran documentos certificados a validados subidos a la componentes E2 Subir componentes y - correo con ruta certificada a gerente de Proyectos y Recursos de IT-EXPERT Tabla 4.2 – Caracterización del proceso de Pase a Pruebas Fuente: Elaboración propia Pase a Producción Figura 4.7 – Realizar pase a Ambiente de Producción Fuente: Elaboración Propia 48 Actividad E1 Entrada - Correo con ruta A1. Aprobar donde se Pase a encuentran los producción componentes y los documentos Salida Descripción Correo con ruta Correo con ruta donde se donde se encuentran encuentran los componentes los componentes y y los documentos que serán los documentos aprobados Rol Involucrado Actividad Previa Comité - Comité E1 Correo con aprobación de componentes y Aprobar Pase a producción documentos Se separa un ambiente en A2. Preparar Ambiente de Producción Correo con aprobación de componentes y documentos Ambiente de Producción preparado los servidores del centro de cómputo para alojar la Gerente de IT- aplicación que va a ser EXPERT A1 desplegada en “Producción”. A3. Solicitar aprobación Ambiente de de Gerente Producción General de preparado IT-EXPERT Aprobación del Solicitar aprobación de gerente general de Gerente General de IT- Gerente de IT- IT-EXPERT para la EXPERT para realizar el EXPERT realización del pase pase A2 Actividad Entrada Salida Descripción Rol Involucrado Actividad Previa para realizar el pase Aprobación del gerente general C1. Evaluar de IT-EXPERT Si Solicitud para la No (Hacia A3) ¿Aprobado? Gerente de ITEXPERT A3 realización del pase Documento con A4. Asignar recursos para instalación y asignación de Si (C1) recursos para instalación y configuración Asignar recursos para Gerente de IT- instalación y configuración EXPERT C1 configuración A5. Programar el Documento con pase y a los asignación de recursos que recursos para llevarán a instalación y cabo el configuración Documento con programación del pase y los recursos asignados Programar el pase y a los recursos que llevarán a cabo el mismo Gerente de ITEXPERT A4 mismo 50 Actividad Entrada Salida Descripción Rol Involucrado Actividad Previa Documento con C2 programación Hacia A6 del pase y los Hacia A8 Gateway en paralelo Gerente de ITEXPERT A5 recursos A6. Validar Ficha de Ficha de Ficha de Componentes Componentes componentes Certificado evaluado Validar Ficha de Implementador componentes Web C2 Si C3. Validar No(Proceso Ficha cancelado hasta ¿Ficha validada? Implementador Web A6 próximo ciclo) E2 A7. Instalar y configurar usando el manual certificado C4. ¿Instalación - - (Proceso cancelado hasta Implementador próximo ciclo) Web C3(No) Manual de Instalación y Aplicación instalada Instalar y configurar usando Implementador Configuración y configurada el manual certificado Web Si ¿Instalación y Implementador No(Proceso configuración exitosa? Web C3(Si) Certificado - A7 Actividad Entrada Salida y cancelado hasta configuración próximo ciclo) Descripción Rol Involucrado (Proceso cancelado hasta Implementador próximo ciclo) Web Actividad Previa exitosa? E3 - - A8. Validar Ficha de Ficha de Ficha de Componentes Componentes (Base componentes (Base de Datos) de Datos) evaluado Validar Ficha de componentes C4(No) DBA C2 DBA A8 DBA C5(No) DBA C5(Si) Si C5. Validar Ficha - No(Proceso cancelado hasta ¿Ficha validada? próximo ciclo) E4 - - (Proceso cancelado hasta próximo ciclo) A9. Correr scripts y Manual de configurar instalación y Base de configuración Datos del certificados Base de datos Correr scripts y configurar levantada y Bases de Datos del Proyecto configurada usando Manual certificado Proyecto 52 Actividad Entrada Salida Descripción Rol Involucrado Actividad Previa DBA A9 DBA C6(No) usando Manual certificados C6. Verificar éxito de instalación y Si - configuración - C7 - Pruebas Post Producción A11. Evaluar informe de pruebas post producción E6 ¿Instalación y cancelado hasta configuración exitosa? próximo ciclo) E5 A10. Realizar No (Proceso (Proceso cancelado hasta Viene de C4 (Si) Viene de C6 (Si) próximo ciclo) Gateway en paralelo Gerente de ITEXPERT C6(Si) Set de casos de pruebas para pruebas post Informe de pruebas Realizar Pruebas Post Producción Analista Tester C7 Comité A10 Comité A11 producción Informe de Pruebas Post Producción Nota asignada al Nota asignada al Evaluar informe de pruebas proyecto post producción - Fin de proceso Actividad Entrada Salida Descripción Rol Involucrado Actividad Previa proyecto Tabla 4.3 – Caracterización del proceso de Pase a Producción Fuente: Elaboración propia 54 Políticas, obligaciones y nomenclatura establecidas para el proceso de Puesta en Producción IMPORTANTE: Todos los proyectos que soliciten los servicios de despliegue sobre los diferentes ambientes diseñados para la Puesta en Producción serán atendidos en estricto orden de llegado, tomando como fecha de inicio el momento en que es entregada el documento de “Solicitud de Despliegue”. Pase al Ambiente de Desarrollo Para que la aplicación pueda acceder al “Ambiente de Desarrollo” debe cumplir determinados requerimientos y realizar diferentes actividades: Código Descripción Rol involucrado Se puede solicitar hasta la “semana 1” del Alumno - Dueño ciclo académico en el que se desea acceder de Proyecto AD-0001 al “Ambiente de producción”. La solicitud debe ser realizada por el Alumno - Dueño “Dueño de Proyecto” y debe contener la AD-0002 de Proyecto, firma del Gerente General de la empresa Gerente General respectiva. Si la solicitud es presentada luego de la semana 1 esta deberá tener las firmas de, al menos, dos miembros del Comité que se Dueño de Proyecto, AD-0003 encarga de aprobar los proyectos. Este Comité Comité está conformado por los Gerentes Generales de las empresas virtuales y por el Profesor Jorge Cabrera y Rosario Villalta. Código Descripción El miembro de la empresa de IT-Expert que recibe la solicitud tiene hasta un máximo de 7 días para dar respuesta a la solicitud. La respuesta a la solicitud del despliegue del proyecto sobre el “Ambiente de Desarrollo” AD-0004 puede ser aprobada o desaprobada, en el segundo caso se debe indicar de manera clara el motivo de la desaprobación y tratar de brindar al alumno solicitante una opción para el despliegue del mismo. Durante el proceso de despliegue en el “Ambiente de Producción” tanto el jefe de proyecto y su equipo, en caso exista, debe brindar y documentar las actividades realizadas para que los alumnos de la AD-0005 empresa IT-Expert adquieran los conocimientos necesarios sobre las tecnologías que se estén utilizando en dicho proyecto y puedan, posteriormente, realizar labores de apoyo y soporte al mismo, en caso sea necesario. En cuanto al horario del “Pase a desarrollo” se harán en los días de clases del curso de “Taller de Proyecto”, pudiendo variar en función a la urgencia de despliegue del AD-0006 proyecto a horarios que se acordarán entre el Gerente de Proyectos de la empresa de “ITExpert” y el Jefe de Proyecto que solicita el servicio. Tabla 4.4 – Políticas para el Pase a Desarrollo Rol involucrado Gerente de Proyectos y Recursos de ITExpert Implementador Web, DBA, Alumno - Dueño de Proyecto Alumno - Dueño de Proyecto, Gerente de Proyectos y Recursos de ITExpert Fuente: Elaboración propia 56 Pase al Ambiente de Pruebas Para que el alumno pueda realizar un despliegue sobre el “Ambiente de Pruebas” debe: Código Descripción Rol involucrado Analista QA, Enviar un mail solicitando el despliegue de Gerente de la aplicación sobre el “Ambiente de Proyectos y Pruebas” al Gerente de Proyectos de la Recursos de ITempresa “IT-Expert”. AC-0001 Expert Se verifica que el proyecto cumpla con los requisitos necesarios para realizar el Analista QA, despliegue, teniendo en cuenta que esta Alumno-Dueño de solicitud puede ser enviada solo hasta la Proyecto AC-0002 “Semana 9” del ciclo académico en curso. En cuanto al horario del “Pase a Pruebas” se harán en los días de clases del curso de Gerente de “Taller de Proyecto”, pudiendo variar en Proyectos y función a la urgencia de despliegue del Recursos de ITproyecto a horarios que se acordarán entre el Expert, Alumno – Gerente de Proyectos y Recursos de la Dueño de Proyecto empresa de “IT-Expert” y el Alumno – AC-0003 Dueño de Proyecto que solicita el servicio. Tabla 4.5 – Políticas para el Pase a Pruebas Fuente: Elaboración propia Pase al Ambiente de Producción Para el despliegue sobre el ambiente de producción se han definido las siguientes reglas y políticas: Código Descripción Rol involucrado La solicitud de despliegue en el Ambiente de Producción debe ser hecha en la “semana 13” del ciclo académico en el que se desea realizar el despliegue. Gerente de Proyectos y Recursos (empresa del Alumno-Dueño de Proyecto) Descripción El inicio del “Pase a Producción” es programada para la misma semana 13 ó, en caso no exista tiempo disponible esa semana, se pasará para la semana 14. Rol involucrado Gerente de Proyectos y Recursos de ITExpert AP-0001 Código AP-0002 AP-0003 AP-0004 AP-0005 AP-0006 Para que la solicitud sobre el despliegue en el “Ambiente de Producción” sea aceptada debe tener el “Certificado de Calidad de QA”, caso contrario, no será tomada en cuenta. Se define que el “Alumno – Dueño de Proyecto” es el encargado de validar el correcto funcionamiento de la aplicación luego del despliegue en el “Ambiente de Producción”. La programación de las fechas y horas de los despliegues sobre el “Ambiente de Producción” es hecha en estricto orden de llegada de las solicitudes de cada uno de los “Jefes de Proyecto”. Se ha acordado que los despliegues sean realizados los días de clases del curso de “Taller de Proyecto” a partir de las 7 de la noche. Además, estos pases también pueden ser programados para los fines de semana (Sábados o Domingos), debido a que la mayoría de alumnos, por motivos de trabajo, tienen un tiempo muy limitado durante la semana. Tabla 4.6 – Políticas de Pase a Producción No aplica Alumno-Dueño de Proyecto No aplica No aplica Fuente: Elaboración propia Nomenclatura. Para los tres ambientes se van a crear un repositorio único por proyecto en el cual se almacene toda la información referente al proyecto desplegado. La nomenclatura definida para estas carpetas es: Un repositorio general con el nombre: pry_[Código de Proyecto]_[nombre de la empresa] Tres subcarpetas dentro de este repositorio: a) pry_[Código de Proyecto]_[Documentos] b) pry_[Código de Proyecto]_[Compilados] c) pry_[Código de Proyecto]_[Fuentes] 58 Figura 4.8 – Estructura de carpetas para repositorio Fuente: Elaboración Propia Herramienta software utilizada para el proceso de Puesta en Producción Se ha planteado el uso de la herramienta Tortoise SVN para el manejo del versiona miento de las aplicaciones que sean desarrolladas por los alumnos de las empresas virtuales, principalmente, por las características que se muestran a continuación y además porque la Universidad Peruana de Ciencias Aplicadas ya cuenta con esta herramienta instalada en cada una de las computadoras de sus ambientes y aulas, lo que significa un ahorro en la compra de licencias y ahorro en el tiempo de instalación y configuración de una nueva herramienta de versionamiento. ¿Qué es Tortoise SVN? TortoiseSVN es un cliente gratuito de código abierto para el sistema de control de versiones Subversion. Esto es, TortoiseSVN maneja ficheros y directorios a lo largo del tiempo. Los ficheros se almacenan en un repositorio central. El repositorio es prácticamente lo mismo que un servidor de ficheros ordinario, salvo que recuerda todos los cambios que se hayan hecho a sus ficheros y directorios. Algunos sistemas de control de versiones también son sistemas de manejo de configuración del software (SCM). Estos sistemas están diseñados específicamente para manejar árboles de código fuente, y tienen muchas características que son específicas para el desarrollo de software, tales como el entendimiento nativo de los lenguajes de programación, o proporcionan herramientas para compilar software15. Subversion, sin embargo, no es uno de estos sistemas; es un sistema general que puede ser utilizado para manejar cualquier colección de ficheros, incluyendo código fuente. Características del Tortoise SVN Aquí se tiene una lista de características para “TortoiseSVN” que permiten comprender mejor su funcionamiento: a) Integración con el shell de Windows TortoiseSVN se integra perfectamente en el shell de Windows (por ejemplo, el explorador). Esto significa que puede seguir trabajando con las herramientas que ya conoce. Y que no tiene que cambiar a una aplicación diferente cada vez que necesite las funciones del control de versiones. Y ni siquiera está obligado a usar el Explorador de Windows. Los menús contextuales de TortoiseSVN también funcionan en otros administradores de archivos, y en el diálogo “Fichero/Abrir” que es común a la mayoría de aplicaciones estándar de Windows. Sin embargo, debe tener en cuenta que TortoiseSVN está desarrollado con la mirada puesta en hacerle extensión del Explorador de Windows. Por este motivo, puede que en otras aplicaciones la integración no sea tan completa y que, por ejemplo, los iconos sobreimpresionados en las carpetas no se muestren16. b) Iconos sobreimpresionados El estado de cada carpeta y fichero versionado se indica por pequeños iconos sobreimpresionados. De esta forma, puede ver fácilmente el estado en el que se encuentra su copia de trabajo. 15 Tortoise SVN (2010) 16 Tortoise SVN (2010) 60 c) Fácil acceso a los comandos de Subversion Todos los comandos de Subversion están disponibles desde el menú contextual del explorador. TortoiseSVN añade su propio submenú allí. Dado que TortoiseSVN es un cliente de Subversion, también se puede mencionar algunas de las características del propio Subversion: Versionado de carpetas CVS sólo controla la historia de ficheros individuales, pero Subversion implementa un sistema “virtual” de ficheros versionados que sigue la pista de los cambios en todos los árboles de directorios en el tiempo. Los ficheros y los directorios están versionados. Como resultado, hay comandos reales en el lado del cliente como mover y copiar que operan en ficheros y directorios. Confirmaciones atómicas Una confirmación o bien entra en el repositorio completamente, o no entra en absoluto. Esto permite a los desarrolladores construir y confirmar cambios como unidades lógicas. Metadatos versionados Cada fichero y directorio tiene un conjunto invisible de “propiedades” adjuntos. Puede inventarse y almacenar cualquier par de clave/valor que desee. Las propiedades se versionan en el tiempo, igual que el contenido de los ficheros. Elección de capas de red Subversion tiene una noción abstracta del acceso al repositorio, haciendo que la gente pueda implementar nuevos mecanismos de red fácilmente. El “avanzado” servidor de red de Subversion es un módulo para el servidor web Apache, que habla una variante de HTTP llamada Web-DAV/DeltaV. Esto dota a Subversion una gran ventaja en estabilidad e interoperatividad, y proporciona varias características importantes gratis: autentificación, autorización, compresión de la transmisión y navegación del repositorio, por ejemplo. Manejo de datos consistente Subversion expresa las diferencias entre ficheros usando un algoritmo de diferenciación binario, que funciona exactamente igual tanto en ficheros de texto (legibles por los humanos) como en ficheros binarios (que no son legibles por nosotros). Ambos tipos de ficheros se almacenan igualmente comprimidos en el repositorio, y las diferencias se transmiten en ambas direcciones por la red. Etiquetado y creación de ramas eficiente El coste de crear una rama o una etiqueta no necesita ser proporcional al tamaño del proyecto. Subverson crea ramas y etiquetas simplemente copiando el proyecto, utilizando un mecanismo similar a los vínculos duros. Por tanto estas operaciones llevan un tiempo pequeño y constante, y muy poco espacio en el repositorio. Extensibilidad Subversion no tiene lastre histórico; está implementado como una colección de librerías C compartidas con APIS bien definidas. Esto hace que Subversion sea extremadamente mantenible y se pueda utilizar por otras aplicaciones y lenguajes17. Conceptos Básicos a) El repositorio: Subversion es un sistema centralizado para compartir información. En su núcleo está un repositorio, que es un almacén central de datos. El repositorio almacena información en forma de un árbol deficheros, una jerarquía típica de ficheros y directorios. Cualquier número de clientes se conectan al repositorio, y luego leen o escriben esos ficheros. Al escribir datos, el cliente hace que la información esté disponible para los otros; al leer los datos, el cliente recibe la información de los demás. Figura 4.9 – Repositorio SVN Fuente: Tortoise SVN 17 Tortoise SVN (2010) 62 ¿Y ésto por qué es interesante? Por ahora, eso suena a la definición típica de un servidor de ficheros típico. Y de hecho, el repositorio es una clase de servidores de ficheros, pero no el habitual. Lo que hace al repositorio de Subversion especial es que recuerda todos los cambios que alguna vez se hayan escrito en él: cada cambio en cada fichero, e incluso los cambios en el propio árbol de directorios, como el añadir, borrar o reorganizar ficheros y directorios. Cuando un cliente lee datos de un repositorio, normalmente ve únicamente la última versión del árbol de ficheros. Pero el cliente también tiene la capacidad de ver estados previos del sistema de ficheros. Por ejemplo, un cliente puede hacer preguntas históricas, como "¿qué contenía este directorio el último miércoles?", o "¿quién fue la última persona que cambió este fichero, y qué cambios hizo?" Esta es la clase de preguntas que forman el corazón de cualquier sistema de control de versiones: son sistemas que están diseñados para guardar y registrar los cambios a los datos a lo largo del tiempo. b) Modelos de Versiona miento: Todos los sistemas de control de versiones tienen que resolver los mismos problemas fundamentales: ¿cómo permitirá el sistema compartir información entre usuarios, pero evitando que ellos accidentalmente se pisen unos a otros? Es demasiado sencillo que los usuarios accidentalmente sobrescriban los cambios del otro en el repositorio. La solución Bloquear-Modificar-Desbloquear Muchos sistemas de control de versiones utilizan un modelo bloquearmodificar-desbloquear para enfrentarse a este problema, que es una solución muy simple. En estos sistemas, el repositorio sólo permite que una persona cambie un fichero al mismo tiempo. Harry primero debe "bloquear" el fichero antes de que pueda empezar a hacer cambios en él. Bloquear un fichero se parece mucho a tomar prestado un fichero de la biblioteca; si Harry ha bloqueado un fichero, entonces Sally no puede hacer ningún cambio en él. Si ella intenta bloquear el fichero, el repositorio entonces denegará la petición. Todo lo que ella puede hacer es leer el fichero, y esperar a que Harry termine sus cambios y libere su bloqueo. Después de que Harry desbloquee el fichero, se acabó su turno, y ahora le toca a Sally que puede bloquear y editar. Muchos sistemas de control de versiones utilizan un modelo bloquearmodificar-desbloquear para enfrentarse a este problema, que es una solución muy simple. En estos sistemas, el repositorio sólo permite que una persona cambie un fichero al mismo tiempo. Harry primero debe "bloquear" el fichero antes de que pueda empezar a hacer cambios en él. Bloquear un fichero se parece mucho a tomar prestado un fichero de la biblioteca; si Harry ha bloqueado un fichero, entonces Sally no puede hacer ningún cambio en él. Si ella intenta bloquear el fichero, el repositorio entonces denegará la petición. Todo lo que ella puede hacer es leer el fichero, y esperar a que Harry termine sus cambios y libere su bloqueo. Después de que Harry desbloquee el fichero, se acabó su turno, y ahora le toca a Sally que puede bloquear y editar18. El problema con el modelo bloquear-modificar-desbloquear es que es un poco restrictivo, y a menudo se convierte en una calle cortada para los usuarios: Figura 4.10 – Modelos de desarollo Fuente: Tortoise SVN 18 Tortoise SVN (2010) 64 El problema con el modelo bloquear-modificar-desbloquear es que es un poco restrictivo, y a menudo se convierte en una calle cortada para los usuarios: • El bloqueo causa muchos problemas administrativos. A veces Harry bloqueará un fichero y luego se olvidará de ello. Mientras tanto, dado que Sally está aún esperando para editar el fichero, sus manos están atadas. Y Harry se va de vacaciones. Ahora Sally tiene que buscar a un administrador para que libere el bloqueo de Harry. La situación acaba causando un montón de retraso y pérdida de tiempo innecesarios. • El bloqueo puede causar procesos en serie innecesarios. ¿Qué ocurre si Harry está editando el inicio de un fichero de texto, y Sally simplemente quiere cambiar la parte final del mismo fichero? Esos cambios no se superponen en absoluto. Ellos podrían fácilmente editar el fichero de forma simultánea, y no habría ningún daño, asumiendo que los cambios se fusionarán correctamente. No hay necesidad de que se turnen en esta situación. • El bloqueo puede causar una falsa sensación de seguridad. Imagine que Harry bloquea y edita el fichero A, mientras Sally simultáneamente bloquea y edita el fichero B. Pero suponga que A y B dependen uno del otro, y que los cambios hechos a cada uno son semánticamente incompatibles. De repente A y B ya no funcionan juntos. El sistema de bloqueo no tiene forma de prevenir este problema - sin embargo, de alguna forma dió una sensación de falsa seguridad. Es fácil para Harry y Sally imaginar que al bloquear los ficheros, cada uno está empezando una tarea segura y aislada, y por tanto les inhibe de discutir sus cambios incompatibles en un momento temprano. La solución Copiar-Modificar-Fusionar Subversion, CVS y otros sistemas de control de versiones utilizan un modelo copiar-modificar-fusionar como alternativa al bloqueo. En este modelo, el cliente de cada usuario lee el repositorio y crea una copia de trabajo personal del fichero o del proyecto. Luego, los usuarios trabajan en paralelo, modificando sus copias privadas. Finalmente, las copias privadas se fusionan juntas en una nueva versión final. El sistema de control de versiones a menudo ofrece ayuda en la fusión, pero al final la persona es la responsable de hacer que ocurra correctamente. Aquí hay un ejemplo. Digamos que Harry y Sally cada uno crean copias de trabajo del mismo proyecto, copiado del repositorio. Ellos trabajan concurrentemente, y hacen los cambios al mismo fichero "A" dentro de sus copias. Sally graba sus cambios al repositorio primero. Cuando Harry intenta grabar sus cambios más tarde, el repositorio le informa que su fichero A está desactualizado. En otras palabras, que el fichero A en el repositorio ha cambiado de alguna forma desde la última vez que lo copió. Por lo que Harry le pide a su cliente que fusione cualquier cambio nuevo del repositorio dentro de su copia de trabajo del fichero A. Lo más seguro es que los cambios de Sally no se superpongan a los suyos; por lo que una vez que ambos conjuntos de cambios se han integrado, él graba su copia de trabajo de nuevo en el repositorio. La solución copiar-modificar-fusionar Figura 4.11 – Modelos de desarollo Fuente: Tortoise SVN 66 Copiar-modificar-fusionar continuado ¿Pero qué ocurre si los cambios de Sally sí se superponen a los cambios de Harry? ¿Qué hacemos entonces? La situación se denomina un conflicto, y normalmente no es mucho problema. Cuando Harry le pide a su cliente que fusione los últimos cambios del repositorio en su copia de trabajo, su copia del fichero A se marca de alguna forma como que está en un estado de conflicto: él será capaz de ver ambos conjuntos de cambios conflictivos, y manualmente podrá elegir entre ellos. Tenga en cuenta que el software no puede resolver conflictos automáticamente; sólo los humanos son capaces de entender y hacer las elecciones necesarias de forma inteligente. Una vez que Harry haya resuelto manualmente los cambios que se superponían (¡quizás discutiendo el conflicto con Sally!), puede volcar de forma segura el fichero fusionado al repositorio. El modelo copiar-modificar-fusionar puede sonar un poco caótico, pero en la práctica, funciona extremadamente bien. Los usuarios pueden trabajar en paralelo, sin que tengan que esperar nunca uno por otro. Cuando trabajan en los mismos ficheros, resulta que la mayoría de los cambios concurrentes no se superponen en absoluto; los conflictos no son frecuentes. Y el tiempo que lleva resolver conflictos es mucho menor que el tiempo perdido por un sistema bloqueante. Al final, todo se reduce a un factor crítico: la comunicación entre usuarios. Cuando los usuarios se comunican de forma pobre, aumentan los conflictos sintácticos y semánticos. No hay sistema capaz de forzar a los usuarios a comunicarse perfectamente, y no hay sistema que pueda detectar conflictos semánticos. Por lo que no hay motivo para que se le prometa falsamente que un sistema con bloqueos prevendrá de alguna forma los conflictos; en la práctica, el bloqueo parece inhibir la productividad más que otra cosa. Hay una situación común donde el modelo bloquear-modificar-desbloquear resulta mejor, y es cuando tiene ficheros no-fusionables. Por ejemplo si su repositorio contiene algunas imágenes gráficas, y dos personas cambian la imagen a la vez, no hay forma de fusionar esos cambios. O Harry o Sally perderán sus cambios19. Proyectos desplegados durante el ciclo 2011-01 sobre los ambientes implementados para la Gestión de la Puesta en Producción 19 Tortoise SVN (2010) Durante el ciclo académico 2011-01 mismo en el que se inició el desarrollo del proyecto “Gestión de la Puesta en Producción” se han desplegado, en los ambientes diseñados para este, los siguientes proyectos de las empresas virtuales de la UPC. 68 Proyecto SISREGMED: “Sistema de Registro Médico”. SISREGAME: “Sistema de Registro de Atención Médica”. SISCONFI: “Sistema de Configuración Física”. Equipo del Proyecto Empresa Virtual Ambiente Estado Admer Ríos. SALUDABLE Ambiente de Pruebas FUNCIONANDO Alex Trujillo y Karen Ferroñay. SALUDABLE Ambiente de Pruebas FUNCIONANDO Cai Aguayo y Klaussen Vargas. SALUDABLE Ambiente de Pruebas FUNCIONANDO SISCOFARMA: “Sistema Antony Jaime y Jose Luis Ambiente de SALUDABLE de Control Farmacéutico” Arroyo. Pruebas Tabla 4.7 – Proyectos desplegados durante el ciclo 2011-01 Fuente: Elaboración propia FUNCIONANDO Proyecto Equipo del Proyecto Empresa Virtual Ambiente Estado Franz Zárate. SALUDABLE Ambiente de Pruebas FUNCIONANDO Katherine Grijalva y Renzo Calderón. SALUDABLE Ambiente de Pruebas FUNCIONANDO SGE New Version Eleasar Schrader. Educa-T e-Portafolio Second Edition (ePSE) Marco Bruggmann y BorisHerrera. Educa-T AgreBussiness Minei Moromisato y Renzo Arenaza. Factoria SISGEHO: “Sistema de Gestión Horaria” SAMO: “Sistema de Administración Médica Odontológica” BussinessWork Ambiente de Pruebas Ambiente de Desarrollo, Pruebas y Producción. Ambiente de Pruebas Mayra Castillo y Luis Ambiente de Factoria Neyra. Pruebas Tabla 4.7 – Proyectos desplegados durante el ciclo 2011-01 FUNCIONANDO FUNCIONANDO FUNCIONANDO FUNCIONANDO Fuente: Elaboración propia 70 Prueba Piloto Se denomina “Prueba Piloto” al despliegue que fue realizado sobre los tres ambientes diseñados para soportar el proceso de la Puesta en Producción de un software. A esta prueba asistieron todos los “Gerentes de Proyectos” de las “Empresas Virtuales” y los “Gerentes de Procesos” de todas las empresas. El resultado de esta prueba está plasmado en el acta de reunión que se realizó en base a los resultados obtenidos y que se adjunta en el presente documento en el punto 7.1. Esta prueba abarcó cada uno de los procesos planteados la soportar una adecuada Gestión de la Puesta en Producción y se cree fue necesaria para tener un ejemplo real y medible de lo que se puede esperar cuando el proceso sea implementado de manera formal en todas las empresas virtuales desde el “ciclo 2011-02”. El acta de reunión de esta prueba se adjunta en el presente documento. Riesgos y problemas identificados durante el desarrollo del proyecto. Riesgo y/o problema identificado Falta de conocimiento técnicos para el manejo y configuración del software y hardware. Manejo inadecuado del “Alumno-Dueño del Proyecto” sobre los ambientes en el que realizan los despliegues. Descripción Plan de mitigación y/o solución Se detecta como riesgo la falta Para atacar este riesgo que durante de conocimientos y el desarrollo del proyecto se preparación para un manejo convirtió en problema se realizó: adecuado del hardware y software del ambiente de 5.1 Investigación propia para servidores de la Universidad lograr adquirir los Peruana de Ciencias conocimientos necesarios Aplicadas. La falta de este para el manejo del conocimiento podría retrasar o software y hardware. dificultar el desarrollo del 5.2 Solicitar ayuda del proyecto “Gestión de Puesta “Alumno-Dueño de en Producción”, ya que gran Proyecto” de cada uno de parte de esta se sustenta sobre los proyectos que soliciten una adecuada configuración despliegues en los de los servidores existentes. ambientes implementados. 5.3 Solicitar ayuda de los recursos de la empresa de IT-Expert. Se presentó un caso durante el desarrollo del proyecto, en el cual un alumno debido a la cantidad de permisos que poseía sobre el “Ambiente de Pruebas” lo desinstaló perjudicando a su propio proyecto y a los proyectos de los alumnos que se encontraban en ese momento desplegados. Se estableció una política de despliegue solo por parte de los alumnos de la empresa IT-Expert. Se estableció una política de usuarios y contraseñas que se entrega a cada alumno y restringe los permisos que este posee sobre los ambientes. El documento en el cual se establecen usuarios y contraseñas para los alumnos de cada empresa virtual se encuentra adjunto como anexo en el presente documento en el punto 7.2. Tabla 4.8 – Riesgos y problemas encontrados Fuente: Elaboración propia 72 Riesgo y/o problema identificado No contar con una línea base respecto del proceso de gestión de puesta en producción. Descripción Se identificó como un riesgo alto el no tener precedentes de un proceso de puesta en producción para las aplicaciones que se habían desplegado en el centro de cómputo hasta el inicio del proyecto (2011-01). El trabajo de cada uno de los No contar con uno de los integrantes dificultaría la integrantes del proyecto. permanencia o participación de ambos miembros del grupo durante la atención y desarrollo del proyecto. No configurar adecuadamente los ambientes de desarrollo, certificación y producción en el tiempo requerido. Plan de mitigación y/o solución Luego de una investigación, se determinó que las empresas virtuales de la UPC no contaban con ningún proceso de puesta en producción, por lo que se tuvo que plantear, implementar y controlar un marco de trabajo por completo, cubriendo cada detalle que este comprendía. Se conversó, en los respectivos centros de trabajo de los integrantes del proyecto, con los jefes para pedir flexibilidad en los horarios de clases y permisos que se pudiesen solicitar durante el ciclo académico en la UPC. Para mitigar el riesgo se investigó por cuenta propia el modo de configuración y manejo de los servidores, además, se solicitó ayuda a los recursos asignados que tenían experiencia en actividades de soporte de sus respectivos centros de trabajo La falta de conocimientos técnicos, podía dificultar el manejo adecuado del centro de cómputo por lo que era un riesgo alto que tendría como No levantar los ambientes consecuencia la no culminación de desarrollo, del proyecto en los tiempos certificación y producción establecidos. en el tiempo requerido. Se considera un riesgo alto el Se contactó con el Gerente de Poca disponibilidad de los que los alumnos de ciclos Proyectos y Recursos del ciclo involucrados en los anteriores puedan brindar 2010-02, para consultarle el procesos de puesta en información de cómo se modo en que eran realizados y producción para brindar desarrollaban los despliegues de obtener mayor información al información respecto a la las aplicaciones. respecto. misma. Tabla 4.8 – Riesgos y problemas encontrados Fuente: Elaboración propia Se considera un riesgo alto el Como plan de mitigación se La falta de un estándar que se puedan presentar entregó a todos los alumnos las respecto a los tipos de numerosos tipos de tecnología restricciones para el desarrollo tecnologías que se usan para ser desplegados y que por de sus proyectos y las (bases de datos en Oracle, motivos de insuficiencia de tecnologías que podrían ser SQL Server, MySQL, hardware no puedan atenderse o soportadas y atendidas para DB2, etc. Aplicaciones en desplegarse todas estas. estos por la empresa IT.Net. Java. PHP, distintos Expert. framework) pues en producción será complicado contar con suficientes recursos de Hardware para soportarlas. Tabla 4.8 – Riesgos y problemas encontrados Fuente: Elaboración propia 74 Capítulo 5. Documentos y planes de gestión asociados al proceso de Puesta en Producción. En el presente capítulo se define la documentación y planes de gestión desarrollados para el proceso de puesta en producción. Esta documentación está orientada, principalmente, a verificar y asegurar el control sobre cada una de las aplicaciones que serán desplegadas, permitiendo conocer, por ejemplo, el nivel de aceptación que tienen todos los Jefes de Proyecto con respecto al servicio recibido o el modo como se ha planeado asegurar la continuidad y cumplimiento del proceso para los próximos ciclos académicos. Documento de aceptación del cliente. Este proyecto indica que, para una adecuada puesta en producción de todas las aplicaciones que se desarrollan en las empresas virtuales de la UPC, estas tienen que pasar por un proceso que permita realizarles un seguimiento en el tiempo y se verifique su calidad de modo que se satisfagan todas las expectativas del usuario final. Este proceso supone una interacción continua con los Gerentes de las empresas virtuales, el Jefe de Proyecto de la aplicación y, principalmente, el Administrador del Centro de Cómputo que es un rol que se desarrolla en la empresa virtual IT-Expert y es, en resumidas palabras, el que se encarga de la gestión para realizar la puesta en producción de la aplicación. Por ello se crea el “documento de aceptación del cliente” para dejar sentada y registrada la impresión de los Jefes de Proyecto sobre el servicio recibido. Esta información es muy importante para poder seguir planteando nuevas actividades que mejoren la gestión de la puesta en producción de las aplicaciones, por ello este documento permite mantener el proceso en constante monitoreo de modo que se puede mantener al tanto de los riesgos, problemas o sugerencias que los alumnos ven en este A la presente memoria se adjuntan los documentos de “Aceptación del Cliente” sobre el servicio de puesta en producción recibido, se debe tener en cuenta de que los documentos solo pertenecen al del ciclo académico 2011-02 y no para los despliegues realizados en el ciclo académico 2011-01, ya que en este aún no se había planteado la utilización de este documento como contenedor del “feedback” de los alumnos involucrados en el proceso. Cierre de contrato Se entiende como cierre del contrato al documento que plasma la conformidad del servicio recibido por los “Jefes de Proyecto” para poner en producción la aplicación que han desarrollado. Para evitar la repetición de documentos y contenido se considera como evidencia suficiente de cierre el “Documento de aceptación del cliente” en el cual además de indicar que el servicio de Puesta en producción ha concluido, ya que se entrega solo si la aplicación se encuentra en producción, permite también registrar observaciones o sugerencias que ayudan a mejorar el proceso. Cierre Administrativo El cierre administrativo es utilizado por las empresas para evaluar el desarrollo y avance de los proyectos luego de un hito importante en su ciclo de vida. Para el caso del proyecto de “Gestión de Puesta en Producción” el proceso que plantea posee tres fases o hitos muy bien diferencias e importantes. Estos hitos o fases hacen referencia a los ambientes de desarrollo, pruebas y, finalmente, producción que es donde se deben desplegar las aplicaciones a fin de cumplir con el flujo establecido. Para verificar el avance y controlar aún más el proceso se aplica el documento “Cierre Administrativo” por fase del proyecto. Este documento busca registrar y consolidar información relevante sobre el avance del proyecto y poder, en caso se encuentren problemas, corregirlos de manera adecuada. El documento de “Cierre Administrativo” se genera y almacena por el “Administrador del Centro de Cómputo” cada vez que la aplicación termina de ser desplegada en “Desarrollo”, “Pruebas” y, finalmente, “Producción”. Análisis Post-Mortem. El análisis Post-Mortem hace referencia a la revisión que se hace del proyecto luego que ha sido implementado, para poder evaluar las situaciones que se dieron durante la realización del mismo. Esta evaluación de hace en función a las metas que se trazaron y plantearon al inicio del mismo. 76 Objetivo planteado Análisis de su logro La segmentación de los ambientes ayudo a generar un orden sobre el Lograr que el proceso de Gestión de Puesta proceso de puesta en producción. Este en Producción, a partir de su implementación, orden permite conocer ahora de agregue valor a los demás procesos que manera clara las características de las permiten el funcionamiento de todas las aplicaciones desplegadas así como los Empresas Virtuales en la UPC, generando problemas e incidencias que estos una clara segmentación de los diferentes presentaron, por ello se puede ambientes que este proceso involucre considera que los demás procesos que (desarrollo, pruebas y producción). estén relacionados a la puesta en producción de aplicaciones tendrán un mejor calidad de datos e información. Tabla 5.1 – Análisis Post-Mortem Fuente: Elaboración propia Objetivo planteado Realizar la definición y modelado de cada uno de los procesos y roles que conforman la Gestión de la Puesta en Producción. Esta definición se tendrá alineada a la información que se obtendrá de todas las empresas virtuales sobre cómo se lleva este proceso hasta el momento. Definir, modelar y documentar los procesos que componen la gestión de puesta en producción de aplicaciones de software. Análisis de su logro La definición de roles, procesos y el modelado de los mismos se culminaron en el ciclo académico 2011-01 y se realizó la prueba y validación de los mismos durante el ciclo académico 2011-02. Por ello se puede determinar que el objetivo se cumplió de manera adecuada. El proceso de puesta en producción se implementó de manera parcial durante el ciclo 2011-01, para el Implementar, para el ciclo académico 2011ciclo 2011-02 este se implementó de 02 en un nivel avanzado, el modelo de manera completa y se le hizo un Gestión de Puesta en Producción de seguimiento para controlar que este aplicaciones software. era seguido de manera adecuada y que, además, se ajustaba a la realidad de las empresas virtuales de la UPC. Se definió como herramienta de control de versiones al Tortoise SVN que permite llevar un control del Definir e implementar una herramienta código fuente que se desarrolla y software para el control de versiones de las además tener un repositorio aplicaciones. centralizado con toda la información asociada a cada uno de los proyectos de que desarrollan en las empresas virtuales de la UPC. Tabla 5.1 – Análisis Post-Mortem Fuente: Elaboración propia Gestión de Problemas e Incidentes. Durante el desarrollo del proyecto de Gestión de Puesta en Producción se identificaron problemas y riesgos para los cuales se planteó el siguiente manejo. 78 Problema No se logró, en algunas ocasiones, configurar los servidores sobre los cuales se encuentran los ambientes que soportan el proceso de puesta en producción planteado. Gestión del problema o incidente. a) Se planteó la investigación propia de ambos miembros del proyecto sobre el manejo y configuración de los servidores que se encuentran en el centro de cómputo. b) Se solicitó el apoyo de los recursos de la empresa IT-Expert que poseían un conocimiento técnico mayor debido a las actividades que realizaban en sus respectivos centros de trabajo. c) Se contactó con alumnos de ciclos académicos anteriores para solicitarles ayuda con respecto a información y manejo de los servidores físicos que se encontraban en el centro de cómputo y que soportarían todo el proceso de puesta en producción. Manejo inadecuado de los servidores Se restringió el acceso a los servidores, sobre los cuales se despliegan las indicando en una lista, que posee el aplicaciones de las empresas virtuales y encargado del cuarto donde estos se soportan el proceso de puesta en encuentran, los alumnos que tienen la producción. autorización para manipularlos. Tabla 5.2 – Gestión de problemas Fuente: Elaboración propia Problema Falta de colaboración de los alumnos de las empresas virtuales para aceptar las nuevas actividades planteadas en el proceso de puesta en producción. Gestión del problema o incidente. a) Se habló con los alumnos, para explicarles el porqué de cada uno de los controles y actividades establecidas en el proceso. b) Se redactaron manuales claros y didácticos que hagan más fácil y rápido el entendimiento de cada una de las actividades y obligaciones de los roles. c) Se ofreció apoyo continuo a cada uno de alumnos sobre el desarrollo del proceso, de modo que no les quedasen dudas sobe lo que debían hacer en cada fase del proceso de puesta en producción de sus aplicaciones. Tabla 5.2 – Gestión de problemas Fuente: Elaboración propia Gestión de Pedidos. Para el proyecto de la “Gestión de la Puesta en Producción” los pedidos fueron, principalmente, de información. Se comenzó pidiendo a los Gerentes de las empresas virtuales, mediante entrevistas directas, información sobre el modo en que se llevaba a cabo el despliegue de las aplicaciones, para conocer si existía algún proceso estructurado para este. Los siguientes a quienes se les pidió alguna información sobre si existía un proceso fueron a los alumnos Jefes de Proyecto para conocer como habían realizado el despliegue de sus aplicaciones hasta el momento. Para el acceso al centro se cómputo y verificar el hardware que se tenía y que tendría que ser utilizado para el proceso de puesta en producción se pidió y coordinó con el Gerente de la empresa IT-Expert quien era el encargado del envío de correos electrónicos solicitando los respectivos permisos para el ingreso a este ambiente. 80 Gestión de Accesos. Los accesos durante el desarrollo del proceso de gestión de puesta en producción giraron en torno al centro de cómputo debido a que en este se encuentra el hardware que soporta y en el que se despliegan todas las aplicaciones desarrolladas por los alumnos de las empresas virtuales. Para ello se realizó lo siguiente. a) Se indicó al Gerente General de IT-Expert la necesidad de acceder de manera continua a los servidores que se encuentran en el centro de cómputo. b) El Gerente General tramitó los permisos con las personas encargadas del centro de cómputo y se registró quienes serían las personas que podrían ingresar. c) Debido a que, en una ocasión, algunos alumnos ingresaron y realizaron un manejo inadecuado del centro de cómputo se generó una lista en la cual se indicaba que, de manera estricta, solo los alumnos que estén en esta podrían ingresar y manipular estos servidores. Esta lista, además, debía ser aprobada por el Director de la Facultad. Se tuvo también una gestión de accesos para los programas que se encontraban instalados en los servidores del centro de cómputo, debido a que alguno de estos requerían se ingrese un usuario y contraseña para poder ser utilizados. Para ello se realizó lo siguiente. a) Se contactó con los alumnos que manipularon los servidores el ciclo anterior al inicio del proyecto de la Gestión de Puesta en Producción y se les solicitó algún documento o que de manera verbal indiquen las contraseñas de estas aplicaciones. b) Al recibir estas contraseñas fueron almacenadas en un documento al que tenían acceso los recursos y el equipo de proyecto de la Gestión de Puesta en Producción. Plan de Riesgos. Las medidas que se toman para enfrentar los riesgos en el desarrollo del proceso de puesta en producción de las aplicaciones está basado en la experiencia y en el registro de los problemas identificados a los largo del seguimiento que se le realizó a cada uno de los proyectos. A continuación se listan los riesgos identificados y las acciones de mitigación adoptadas contra estos. a) En el ciclo 2011-01 un grupo de alumnos de un proyecto ingresó a la sala de servidores y manipuló de manera indebida estos, con lo que se perdieron algunos proyectos que hasta ese momento habían sido desplegados. Por ello se identificó como un “riesgo alto” el hecho de que algún alumno realice esto nuevamente. El plan de mitigación del riesgo consistió en crear una lista única de alumnos con permiso para ingresar a la sala de servidores, de este modo actualmente solo existen unos pocos alumnos que pueden ingresar, lo que, en caso se produzca el mismo problema, permitirá identificar de manera inmediata los posibles responsables. Se debe tener en cuenta que es muy baja la probabilidad de que esto suceda debido a que los alumnos con autorización para ingresar pertenecen a la empresa IT-Expert y, además, están familiarizados con el proceso de la puesta en producción y el manejo adecuado de los servidores del centro de cómputo. b) En el ciclo 2011-01 se identificó como un riesgo alto la falta de conocimientos técnicos de los alumnos para la realización de los despliegues en los servidores y, también, falta de conocimientos sobre las tecnologías usadas por los proyectos que desean pasar a producción. Ante este riesgo se insistió con la creación, por parte del “equipo del proyecto” que solicita pasar a producción, de manuales detallados que permitan el despliegue de sus aplicaciones sin mayores contratiempos. Estos manuales son considerados indispensables si alguno de los proyectos desea recibir los servicios de la empresa IT-Expert. c) En el ciclo 2011-02 se identificó como un riesgo alto el posible desconocimiento de los alumnos sobre las actividades, restricciones y obligaciones que están asociados al proceso de puesta en producción. Ante este riesgo, se ha incidido de manera especial en la creación y prueba de manuales de procedimientos didácticos y fáciles de entender para los alumnos El empeño para que los manuales sean lo suficientemente didácticos ha llevado a realizar dos “pruebas piloto” con lo que se trata de verificar que tan bien pueden desarrollar el proceso alumnos que no están familiarizados con cada 82 una de las actividades que lo componen, los resultados de estas pruebas se muestran en la parte referida al “plan post-implementación”. Plan de comunicaciones. Propósito del documento Se debe tener en cuenta que cada ciclo o incluso en un mismo ciclo se pueden actualizar los datos de las personas que desempeñan los roles del proceso o se modifican las actividades y responsabilidades de estos, por ello se indica que este plan de comunicaciones debe ser actualizado por el “Administrador del Centro de Cómputo” cada vez que alguno de estos cambios sucedan. Para el plan de comunicaciones se detallarán las obligaciones de cada uno de los roles involucrados en el proceso puesta en producción de las aplicaciones. Estas obligaciones y actividades se encuentran descritas a un mayor nivel en el documento “Proceso GPP gráfico” y que se encuentra en el “file server” en la carpeta “Gestión de la Puesta en Producción”, los detalles de esta carpeta y su contenido se indican en el punto “4.12 Plan de Continuidad”. Además, el presente documento indica los medios, canales y momentos en los que se realiza la comunicación durante la gestión de puesta en producción de las aplicaciones. Stakeholders En este punto se detallan los involucrados en el presente plan de comunicación así como sus obligaciones y un pequeño resumen de su importancia dentro del proceso. Stakeholder Descripción Responsabilidades Administrador del Centro de Cómputo Este rol se encarga de organizar y controlar todas las actividades del proceso de puesta en producción de una aplicación. a) Recepciona todas las solicitudes de servicios asociados al proceso de puesta en producción de las aplicaciones. b) Genera y envía un cronograma de desarrollo de actividades con las solicitudes recibidas. c) Crea y distribuye los usuarios y contraseñas de los repositorios para los proyectos que desean pasar por el proceso de puesta en producción. d) Realiza los despliegues de las aplicaciones sobre los distintos ambientes implementados para la puesta en producción. e) Entrega y redacta lo certificados de despliegue en producción. f) Registra información en los documentos: “Cierre administrativo” y “Consolidado de servicios”. g) Actualiza las plantillas de solicitudes de servicio cada vez que llega un nuevo proyecto. h) Actualiza el documento de “Plan de comunicación” cuando se modifique alguna de las responsabilidades de los roles que intervienen o en caso las personas que desempeñan los roles se retiren. Tabla 5.3 Administrador del centro de cómputo Fuente: Elaboración propia 84 Stakeholder Descripción Responsabilidades DBA proceso de despliegue Ejecuta el de las aplicaciones.. a) Ayuda al “Administrador del Centro de Cómputo” en la realización de los despliegues generando, y restaurando la base de datos que l aplicación requiere para funcionar de manera adecuada. Tabla 5.4 DBA Fuente: Elaboración propia Stakeholder Descripción Gerente de Proyectos y Recursos de IT-Expert Gestiona y controla todas las actividades dentro de la empresa IT-Expert Responsabilidades a) Recibe y evalúa las “solicitudes de aprobación” para pase a producción de las aplicaciones desarrolladas en las empresas virtuales. b) Entrega y recibe los “contrato de puesta en producción de la aplicación” que es el documento en el que se detalla las obligaciones tanto de la empresa IT-Expert como las del Jefe de Proyecto, durante todo el proceso de puesta en producción de la aplicación. c) Genera los certificados de Producción para las aplicaciones luego de que estas han sido desplegadas en el ambiente de producción. d) Entrega y recibe las “actas de aceptación del cliente” para conocer el grado de satisfacción que estos muestran sobre el servicio recibido para la puesta en producción de su aplicación. Tabla 5.5 Gerente de Proyectos y Recursos de IT-Expert Fuente: Elaboración propia Stakeholder Descripción Jefe de Proyecto Owner Ejecuta el proceso de despliegue de las aplicaciones.. Responsabilidades a) Envía la solicitud de aprobación de su proyecto para que pase por el proceso de pase a producción. b) Llena el “acta de aceptación del cliente” luego de que fue realizada la puesta en producción de su aplicación. c) Envía las solicitudes de servicio a lo largo de todo el proceso de puesta en producción. Tabla 5.6 Jefe de Proyecto Owner Fuente: Elaboración propia Requerimientos para la comunicación. En este punto se detallan los requerimientos necesarios para que los roles definidos para el proceso de puesta en producción puedan mantener una comunicación. Requerimiento de Descripción Comunicación Correo electrónico de Todos los involucrados en el proceso de puesta en contacto producción deben poseer una dirección de correo electrónico para permitir enviar y recibir información durante las diferentes fases del proyecto. Formatos de documentos. Durante la puesta en producción de una aplicación se requieren de formatos de documentos que permitan plasmar, registrar y conocer la información que se entrega y recibe y en base a la cual se realizan las actividades del proceso. Estos formatos se encuentran detallados en el siguiente punto (5.9.4). Tabla 5.7 Requerimientos de comunicación Fuente: Elaboración propia 86 Mecanismo de comunicación En este punto se detallan los eventos, canales de comunicación, formato y contenido de los documentos presentes durante el proceso de puesta en producción de las aplicaciones. Descripción del Rol Formato/Documento requerimiento de Evento Canal Fase información Es el documento en el que se plasma solicitud Solicitud de servicio de la Se da cada vez una que el Jefe de actividad para lograr la Proyecto Owner Desarrollo, Mail puesta en producción lo envía. Administrador de una aplicación del Centro de Documento que deja Cómputo constancia Acta de despliegue en desarrollo. final del aplicación desplegada despliegue de en el que ambiente la Al de una aplicación Mail desarrollo se encuentra sobre el ambiente funcionando de manera de desarrollo. adecuada. Tabla 5.8 – Mecanismos de comunicación Fuente: Elaboración propia Pruebas o Producción Desarrollo Descripción del Rol Formato/Documento requerimiento de Evento Canal Fase información Certificado de calidad Cada vez que el emitido por la empresa Jefe de Proyecto Administrador QA y que es requisito Owner del Centro de Certificado de QA para que la aplicación desplegar Cómputo pueda ser desplegada aplicación en el en el ambiente de ambiente Producción. Gerente Proyectos y Solicitud Recursos de aprobación IT-Expert de se evalúa la viabilidad de puesta producción aplicación. su Mail Producción de producción. Documento en el que de desea de en una Cada vez que un Jefe de Proyecto desea desplegar Mail Desarrollo su aplicación. Tabla 5.8 – Mecanismos de comunicación Fuente: Elaboración propia 88 Descripción del Rol Formato/Documento requerimiento de Evento Canal Fase información Es el documento en el que el Jefe de Proyecto Contrato de Gestión acepta y entiende sus Luego de que la de Puesta “solicitud en responsabilidades Producción de una durante todo el proceso aprobación” Gerente de Aplicación de puesta Proyectos y producción Recursos de aplicación. IT-Expert de de constancia del correcto Conformidad de funcionamiento de la despliegue en aplicación producción. Mail Desarrollo la Acta ambiente es en aceptada. Documento que deja producción de en el de Luego de un despliegue de la aplicación sobre Mail el ambiente de producción Tabla 5.8 – Mecanismos de comunicación Fuente: Elaboración propia Producción Descripción Rol del Formato/Documento Evento requerimiento Canal Fase de información Se utiliza para dejar Gerente Proyectos de y Recursos de ITExpert Documento de Aceptación del Cliente. registro de la aceptación del cliente sobre el servicio de puesta en producción de su aplicación. Nombre de la base Son los datos de la de datos, motor de base de datos que DBA base de datos a soporta la aplicación utilizar y ambiente que será puesta en virtual para creación. producción. Cada vez que una aplicación es desplegada con éxito en el ambiente de producción y se ha Mail recibido el “acta Producción de conformidad” por este despliegue. Cada vez que se solicita el despliegue de una aplicación en alguno de los ambientes virtuales. Desarrollo, Mail Pruebas o Producción Tabla 5.8 – Mecanismos de comunicación Fuente: Elaboración propia 90 Descripción del Formato/ Rol requerimiento de Documento Evento Canal Fase información Constancia de que la aplicación fue desplegada el Cada vez que el Certificado de ambiente de desarrollo alumno desea realizar despliegue en y es requisito único el despliegue de su Mail desarrollo Jefe en para que la empresa aplicación sobre Desarrollo el QA pueda iniciar el ambiente de pruebas. de Proyecto proceso Owner sobre su aplicación. Solicitud aprobación de de pruebas Resultado de la evaluación de la solicitud de puesta en producción aplicación. de su Se recibe como máximo una semana después de enviada al “Gerente de Proyecto y Recursos Expert”. Tabla 5.8 – Mecanismos de comunicación Fuente: Elaboración propia de IT- Mail Desarrollo Rol Descripción del Formato/ Documento requerimiento de Evento que la aplicación pasó de Certificado Fase información Documento que indica Jefe Canal de todo el proceso Proyecto despliegue en establecido y, Owner producción finalmente, se encuentra en producción. Se entrega cuando el Jefe de Proyecto plasma la evidencia del correcto funcionamiento de su aplicación ambiente sobre Mail Producción el de producción. Tabla 5.8 – Mecanismos de comunicación Fuente: Elaboración propia 92 Itinerario de comunicación En este punto se presentan los hitos de cada fase del proyecto de despliegue de las aplicaciones. Estos hitos delimitan el tiempo en el cual los documentos asociados a cada fase pueden ser enviados. Formato/ Semana Fase Evento Documento Académica Solicitud de Envío Aprobación al “Ambiente de Desarrollo” solicitud de la documentación. de aplicación Solicitud de Servicio Hasta la semana 3 despliegue para la aplicación Manual de Instalación Configuración Semana 1 Creación de los repositorios para Contrato de despliegue Envío y recepción del contrato de Manual Hito la aprobación del proyecto. UsuariosxRepositorio Pase de Recepción del “Manual de del “Manual de Instalación”. de Recepción Configuración”. Hasta la semana 9 Envío de solicitud de despliegue en el “Ambiente de Desarrollo” Entrega del certificado de despliegue en el ambiente de desarrollo Tabla 5.9 – Itinerario de comunicación Fuente: Elaboración propia Hasta la semana 10 Formato/ Fase Pase Documento al “Ambiente de Pruebas” Hito Evento Recepción de la solicitud de despliegue en el Hasta Servicio “Ambiente de Pruebas” Certificado de QA al Solicitud de Recepción del certificado de la empresa QA “Ambiente de Servicio “Ambiente de Producción” Producción” Despliegue en el “Ambiente de Producción” - Despliegue la semana 11 Hasta la semana 12 Hasta la Recepción de la solicitud de despliegue en el semana 14 Constancia de Recepción de la constancia de funcionamiento Hito Académica Solicitud de Despliegue en el “Ambiente de Pruebas” Pase Semana en el ambiente de producción Hasta la Semana 15 Entrega del certificado de despliegue en el ambiente de producción Tabla 5.9 – Itinerario de comunicación Fuente: Elaboración propia 94 Plan de Calidad de Servicios de TI. Para el proceso de la gestión de puesta en producción de las aplicaciones software se plantean una serie de controles que aseguran la calidad de los resultados que el proceso plantea. Estos controles fueron realizados en parte luego del seguimiento del proceso e identificando los puntos en los que faltaba reforzar el éxito y la consistencia de lo que se quería lograr para continuar con todo el flujo del proceso. Estos puntos críticos son los siguientes: a) A lo largo del proceso se dan tres momentos o puntos de quiebre vitales que se consideren como las fases de este. Estos momentos son el despliegue en el ambiente de desarrollo, pruebas y producción. Cada despliegue que se realiza permite la ejecución del siguiente, es decir, no se puede desplegar en el ambiente de pruebas sin antes haberlo hecho en el ambiente de desarrollo. Así mismo, para desplegar la aplicación en el ambiente de producción esta debe haber sido desplegada en el ambiente de pruebas. Es evidente que se necesita una evidencia del correcto funcionamiento de la aplicación en cada uno de estos amientes, para el caso del ambiente de pruebas esta evidencia la brinda la empresa de QA, pero para los otros dos ambientes se plantea el desarrollo del documento “Acta de conformidad de despliegue” en el cual se plasma las imágenes que dan fé de que la aplicación cumple su funcionalidad de manera adecuada. Si no existiese o solicitase esta prueba no habría modo de saber si la aplicación funciona de manera correcta y se estaría corriendo el riesgo de continuar con los despliegues de un software que no sirve y por lo tanto que no satisfará los requerimientos del usuario final. b) Los problemas a lo largo del proceso de puesta en producción se registran en un documento consolidado para tener un banco de datos del cual consultar en caso suceda un problema similar en el futuro, de modo que la solución sería inmediata ya que también existe registro de las soluciones aplicadas en su momento. Para mejorar la calidad del proceso con respecto a los problemas que se pueden presentar durante su ejecución se indica que el “Administrador del Centro de Cómputo” debe realizar una revisión periódica de estos y verificar si estos problemas, en caso sucedan, se deben a deficiencias en el planteamiento de las actividades y evidencias del proceso. En caso se identifiquen estas deficiencias en base a los problemas registrados se pueden modificar y replantear estas actividades con lo la calidad del proceso está siendo constante mente asegurada. c) Luego de un despliegue en producción de las aplicación es adecuado buscar una opinión o visión general de cómo se gestionó o llevo a cabo todo el proceso para la puesta en producción. Por ello se establece el “Documento de aceptación” del cliente, el cual deja registro sobre dos puntos claves del proceso que son el trato del personal y las capacidades para solucionar problemas de estos. Este documento es revisado por el “Administrador del Centro de Cómputo” una vez recibido de parte de los Jefes de Proyecto y se trata de adaptar las sugerencias de mejora, en caso existan, para reformular alguna actividad del proceso que se identifica no pueda cumplir por completo con las expectativas de los clientes. Plan de Disponibilidad. El proceso de puesta en producción de aplicaciones debe poder ser aplicado en cualquier momento del ciclo académico y, en caso de desconocimiento del mismo, consultado por ello para el plan de disponibilidad se han tomado en cuenta dos factores claves del mismo que son los servidores sobre los cuales se realiza el despliegue de las aplicaciones y el conocimiento de cada una de las actividades que componen este proceso, por ello para la disponibilidad se plantean las siguientes medidas: a) Entrega, por parte del Gerente de Proyectos y Recursos de la empresa ITExpert a todos los alumnos del curso de Proyecto I y Proyecto II al inicio de 96 cada ciclo académico del mapa de contenido de la carpeta “Gestión de la Puesta en Producción” que se encuentra en el “File server” y al que todos los alumnos tienen acceso. En este mapa se encuentra la descripción y ubicación de los manuales, plantillas, roles y sus obligaciones, y políticas utilizadas durante todo el proceso de la puesta en producción de las aplicaciones. b) Indicar al rol encargado del monitoreo del centro de cómputo deberá informar vía mail al “Administrador del Centro de Cómputo” en caso se presenten las siguientes situaciones en los ambientes virtuales sobre los cuales se despliegan las aplicaciones. a. La memoria RAM asignada a alguno de los ambientes se encuentra al 80% de su uso. b. La memoria física asignada a alguno de los ambientes virtuales se encuentra al 80% de su capacidad. c) Para el repositorio creado con la herramienta Tortoise SVN se deben crear “copias de respaldo” de la información que se encuentra en este, estas copias serán hechas por el “Administrador del Centro de Cómputo”. En los repositorios no puedan ser accedidos o se pierda la información que en estos se encuentra se contará con las copias de respaldo hechas de manera periódica. Además, hasta que los repositorios vuelvan a encontrarse operativos los Jefes de Proyecto deberán enviar toda la información vía mail y en caso esta información no pueda ser enviada por mail se deberá entregar en un dispositivo de almacenaje al “Administrador del Centro de Cómputo”, para que este la consolide. Plan de Continuidad o Post-Implementación. Para este punto se muestran una serie de actividades y sus resultados con la finalidad de asegurar la utilización del proceso en el tiempo. El proyecto de Gestión de Puesta en Producción fue implementado durante el ciclo académico 2011-01. Para asegurar su cumplimiento post-implementación se tomaron las siguientes consideraciones: Consideración 1. Realizar un seguimiento estricto y exhaustivo a tres proyectos de las empresas virtuales de la UPC durante todo el ciclo 2011-02 para verificar que tanto se ajustan estas al marco de trabajo planteado. Consideración 2. Verificar, durante el despliegue de las aplicaciones en el ciclo 2011-02, que las actividades planteadas para todo el proceso de puesta en producción se ajustan a la realidad de las empresas y, de ser necesario, modificar, mejorar o eliminar actividades innecesarias. Consideración 3. Realizar una prueba piloto con el “Administrador del Centro de Cómputo” de modo que se conozca su opinión sobre el modo en que se han documentado los procesos y actividades para la puesta en producción de aplicaciones. Es importante tomar en cuenta las ideas de este para poder corregir o mejorar los cuadros y documentos que se han creado para plasmar el proceso. La prueba piloto consiste en que el “Administrador del Centro de Cómputo” realice las actividades del proceso utilizando íntegramente los manuales desarrollados con esta finalidad y detectar falencias de detalle y claridad. Consideración 4. Realizar una prueba piloto, sobre la puesta en producción de las aplicaciones software, con el alumno que será el “Gerente de Proyectos y Recursos” el ciclo 2012-01, se considera vital la aprobación de este, ya que la labor que viene realizando en la empresa como asistente no le ha permitido conocer las reglas y políticas del proceso y por ende, de lograr entender el proceso con los manuales y documentos realizados, se asegura que pueda llevar a cabo las actividades que le corresponden, en el proceso, sin ningún problema cuando inicie el ciclo 2012-01. Consideración 5. 98 Se ha llevado a cabo una capacitación al alumno que será “Gerente de Proyectos y Recursos” en el ciclo 2012-01 de modo que se asegura conozca el proceso y pueda hacer que se cumpla cuando empiece a realizar sus funciones en la empresa el próximo ciclo y, además, pueda transmitir estos conocimientos a los futuros alumnos que se harán cargo de la gerencia. Resultado de las consideraciones: 1. Resultado de la consideración 1: Los proyectos seleccionados para el seguimiento y, de ese modo, verificar que el marco de trabajo planteado es realizado y, además, logra el objetivo de colocar estas aplicaciones en producción fueron: Empresa Virtual Código del proyecto SALUDABLE SISADPE SALUDABLE SISACS SALUDABLE SISASPA Proyecto Equipo del proyecto Sistema de administración Hector Aliaga, de Personal Tomás Lazo Sistema Administrativo Jadisha Ramírez, del Centro de Salud Larry Gallarday Sistema Administrativo de César Servicios al Paciente Villanueva Tabla 5.10 – Proyectos para el seguimiento Fuente: Elaboración propia Empresa evaluada: SALUDABLE, es la empresa virtual de la UPC que se encarga, principalmente, de realizar aplicaciones software para centros médicos. Motivo de la elección: En los dos ciclos académicos que duró el desarrollo del proyecto, la empresa virtual SALUDABLE es la que mayor cantidad de proyectos ha presentado para que sean puestos en producción con lo que el marco de trabajo establecido para este proceso pasa una adecuada prueba de consistencia y efectividad. Nivel de cumplimiento. En el siguiente cuadro se muestra a un nivel macro y detallado que tanto han avanzado las aplicaciones software seleccionadas desde su inicio hasta su puesta en producción bajo las políticas establecidas para el proceso. En este cuadro se plasman los hitos que han sido respetados del proceso y cuáles no. 100 Proyecto Etapa del Detalle del proceso proceso SISA DPE Recepción de la solicitud de aprobación del proyecto Inicio Creación de repositorios Cum plido SISASPA avanzado (%) Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% los para Cum y plido Recepción del manual de Cum instalación. plido Recepción del manual de Cum configuración. plido Despliegue en el ambiente Cum de desarrollo. plido documentación SISACS Porcentaje componentes. Pase al “Ambiente de Desarrollo”. Recepción del “Acta de Conformidad” de despliegue en desarrollo por parte de un miembro Cum plido del proyecto. Entrega del certificado de Cum despliegue en Desarrollo. plido Tabla 5.11 – Avance de los Proyectos para el seguimiento Fuente: Elaboración propia Proyecto Etapa del Detalle del proceso proceso SISADPE Recepción de solicitud de Pase despliegue en al Pruebas. “Ambiente de Despliegue Pruebas”. en ido del Cumpl Certificado de QA ido Recepción de solicitud de despliegue en Producción Despliegue en al “Ambiente de Producción”. Cumpl ido el Cumpl ambiente de Producción Pase ido el Cumpl Ambiente de Pruebas. Recepción Cumpl ido SISACS Porcentaje SISASPA avanzado (%) Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Cumplido Cumplido 100% Recepción del “Acta de Conformidad” de despliegue en Cumpl producción por parte de un miembro ido del proyecto. Entrega del certificado de despliegue Producción en Pendie nte Pendiente Pendiente 0% Tabla 5.11 – Avance de los Proyectos para el seguimiento Fuente: Elaboración propia 102 Problemas identificados durante el desarrollo del proceso de Puesta en Producción de las aplicaciones seleccionadas. Proyecto Problema identificado Medidas tomadas Imposibilidad de realizar el despliegue de la aplicación en el “Ambiente de Desarrollo”. El Jefe de Proyecto identificó e indicó que el problema se debió a una falla en l codificación de la aplicación Se le explicó al jefe de proyecto de la necesidad de registrar cada actividad realizada, para llevar a cabo Renuencia del Jefe de Proyecto a generar un mejor control de las SISADPE una solicitud por cada actividad que actividades con mayor deseaba realizar para su aplicación, por probabilidad de causar considerarla repetitiva e innecesaria. problemas y que, a largo plazo, sería adecuado y beneficioso para todos los demás proyectos incluyendo el suyo. Se solicita e indica al Jefe de Bajo nivel de detalle de los manuales de Proyecto que no se podrán instalación entregados por el Jefe de llevar a cabo los despliegues Proyecto, para llevar a cabo el en caso los manuales no despliegue de sus aplicaciones. presenten un detalle. Tabla 5.12 – Problemas sobre los Proyectos para el seguimiento Fuente: Elaboración propia adecuado Proyecto Problema identificado Con este proyecto fueron constantes los problemas técnicos para el despliegue de la aplicación en el “Ambiente de Desarrollo”, que se debió en gran medida al desconocimiento del Jefe de Proyecto del comportamiento de su aplicación fuera de su computadora personal, que es donde se empezó a desarrollar. SISACS Desconocimiento de las actividades del proceso de puesta en producción. A pesar de que antes de iniciar el ciclo académico se entregó las políticas que serían tomadas en cuenta para realizar la puesta en producción de las aplicaciones a todos los profesores que ejercen la gerencia de las empresas virtuales, el Jefe de Proyecto desconocía gran parte de las políticas del proceso. Medidas tomadas Con la ayuda del “Administrador del Centro de Cómputo” se consiguió salvar las dificultades técnicas del proyecto, logrando su despliegue adecuado en los ambientes virtuales destinados para la puesta en producción. Se le detalló el funcionamiento y capacitó de manera adecuada sobre cada una de las actividades del proceso, con lo que se observó que el Jefe de Proyecto empezó a cumplir con cada una de las actividades establecidas. Tabla 5.12 – Problemas sobre los Proyectos para el seguimiento Fuente: Elaboración propia 104 Proyecto Problema identificado Medidas tomadas Este proyecto fue el que mejor cumplió Se actuó como se hizo con el con las políticas dela puesta en proyecto “SISACS”, producción de las aplicaciones. Sin brindando embargo, mostraron en algunos deficiencias aspectos como, una se capacitación por actividades adecuada sobre que las deberían ejemplo, el conocimiento adecuado de realizar para llevar a cabo la cada una de las actividades del proceso. puesta en producción de su aplicación. SISASPA Se presentó realización un problema para la Se identificó el motivo del de las pruebas de la problema que respondía al aplicación por parte de la empresa QA. acceso al “Ambiente de Debido a un acceso inadecuado a este Pruebas”, por parte del DBA ambiente. sin que haya informado al respecto, además este empezó a realizar unos “back up” de las bases de datos existentes, lo que provocó la inestabilidad de la aplicación. Tabla 5.12 – Problemas sobre los Proyectos para el seguimiento Fuente: Elaboración propia Lecciones aprendidas: a) Las políticas para el proceso son, en muchos casos, desconocidas por los alumnos por lo que se plantea la realización, por parte de la Gerencia de IT-Expert, de capacitaciones que permitan a los alumnos conocer todo el proceso de manera íntegra. b) El control del proceso se debe centrar sobre un miembro de la empresa IT-Expert que asegure el cumplimiento de todas las actividades establecidas para este. Este rol será desempeñado por el “Administrador del Centro de Cómputo”, por ello ya se está realizando la capacitación necesaria a este sobre todas las obligaciones que debe asumir. c) Por comentario de muchos alumnos que revisaron los documentos de las políticas, se entendió que no estaban plasmados de una manera didáctica. Por ello se han hecho manuales y se han plasmados las políticas en documentos menos pesados de leer y con más gráficos e imágenes para una comprensión más rápida. 2. Resultado de la consideración 2: El seguimiento de las políticas planteadas para el proceso de puesta en producción permitió conocer muchas falencias o falta de detalle en algunas actividades que deberían realizarse, como resultado se realizaron las siguientes mejoras. 106 # Falencias de las políticas Mejora No se estableció que rol sería el Se determina que es el “Administrador del 1 encargado de recibir las solicitudes que Centro de Cómputo”, quien recibe las se dan en el proceso y que hacía con solicitudes de servicios y se encarga de estas. revisarlas y generar el cronograma para estas. Se creó la plantilla “Cronograma de Actividades”, en la el “Administrador del Centro de Cómputo” se encarga de hacer un No se estableció, de manera detallada, cronograma 2 diario de las actividades que se haría con las solicitudes recibidas (despliegues de aplicaciones, bases de datos o de los Jefes de Proyecto. peticiones en general) y entregárselo a todos los alumnos involucrados en el proceso de puesta en producción para que conozcan los tiempos con que cuenta la empresa. Se creó la plantilla “Consolidado de Servicios” en el cual el “Administrador del No se había detallado quién y donde se Centro de Cómputo” será el encargado de 3 almacenarían todas las solicitudes que consolidar todos los servicios que hayan sido llegasen a la empresa IT-Expert. solicitados a la empresa, así como los problemas que se hayan identificado y el estado de estas peticiones, Tabla 5.13 – Falencias sobre las políticas establecidas Fuente: Elaboración propia # Falencias de las políticas Mejora No se había establecido, como política necesaria, las capacitaciones al inicio de cada Se determinó que sea el “Gerente de Proyectos y 4 ciclo para todos los Jefes de Recursos” que brinde las capacitaciones necesarias para proyectos cuyas aplicaciones que los alumnos no tengan dudas de que hacer si quieren serán desplegadas ambientes que en maneja los que su aplicación sea puesta en producción. IT- Expert. Se determinó que al inicio o final de cada ciclo se envíe No se había establecido el a todos los alumnos del curso de “Proyecto I” y modo en que se haría llegar a “Proyecto II” un consolidado con todas las plantillas que 5 cada alumno la documentación les serán necesarias para cumplir con el proceso de necesaria para llevar a cabo puesta en producción. Se ha detallado además cada uno todo el proceso de puesta en de los documentos que serán enviados como la “solicitud de aprobación”, “manual de instalación”, producción. “manual de despliegue”, etc. No se tenía establecido un Se ha determinado que las políticas, plantillas y modo de acceso rápido para los manuales referidas al proceso de puesta en producción 6 alumnos conocer interesados las políticas en serán ubicadas en el “file server” que es de acceso del común a profesores y alumnos, para que puedan proceso. No se consultar la información en cualquier momento. había creado una plantilla para la recepción de 7 las solicitudes de los alumnos, estas se hacían vía mail y no se podía tener un claro control de todas estas. Se creó una plantilla de “solicitud de servicios”, en la cual se plasma todas la información necesaria para llevar a cabo el servicio solicitado y también tener registro de estas solicitudes (estado y problemas detectados). Tabla 5.13 – Falencias sobre las políticas establecidas Fuente: Elaboración propia 108 # Falencias de las políticas Mejora En un principio, solo se aceptaba como proyectos válidos aquellos que habían sido implementados en: Framework .NET. Lenguaje Java. Flexibilidad 8 en programación los lenguajes aceptados proyectos de los alumnos. para de los Y que utilizarán como motor de base de datos: SQL Server 2008 R2 ó MySQL 5.1 Pero debido a la demanda de los proyectos, se agregó el lenguaje PHP como válido. Tabla 5.13 – Falencias sobre las políticas establecidas Fuente: Elaboración propia 3. Resultado de la consideración 3: Se entregó los manuales, documentación y políticas creadas al “Administrador del Centro de Cómputo”, para que valide el detalle y la claridad que presentaban, así como los posibles problemas que se podría suscitar si eran utilizados por personas neófitas y ajenas al proceso. Los resultados y las medidas correctivas fueron las siguientes: # Vulnerabilidad u observación identificada Medida correctiva En las políticas se había indicado como “Requisito” a todo aquello que es necesario para cumplir o realizar una actividad del proceso. Y a ¿Cuál es la diferencia entre la “entrega” como los documentos que los “Jefes 1 Requisito y Entrega? No lo han de Proyecto” deben enviar para cada punto del especificado. proceso, pero gracias a la observación del “Administrador del Centro de Cómputo” se ha mantenido solo “Requisitos” para evitar ambigüedades. En el manual del proceso de Puesta en En desarrollo de los manuales no se detalla si solo se entrega 2 el manual de instalación solo la primera vez y que es lo que pasa hay aplicación. cambios en la Producción, se indica que para realizar un despliegue sobre el “Ambiente de Desarrollo” el “Jefe de Proyecto” debe entregar un “Manual de Instalación”. Pero ahora se ha hecho la aclaración que cada vez que se realice un despliegue en este ambiente y exista un cambio considerable sobre la instalación o configuración de la aplicación deberá ser actualizado. Tabla 5.14 – Vulnerabilidades y observaciones sobre las políticas establecidas Fuente: Elaboración propia 110 # Vulnerabilidad u observación identificada Medida correctiva Se colocó el tiempo para realizar cada proceso en una columna inadecuada en el manual. En base a la Si existe la columna "tiempo para 3 realizarlo", ¿por qué indican el plazo en "condiciones/restricciones"? observación del “Administrador del Centro de Cómputo” se ha decidido eliminar la columna “tiempo para realizarlo” y solo se mantiene “condiciones/restricciones” siendo en esta parte donde se coloca el tiempo asignado para cada actividad. En este caso veo las actividades de los 4 procesos pero ningún diagrama, solo caracterización. El diagrama da una visión más rápida del proceso. Se han modificado todos los manuales y documentos de procesos y políticas con imágenes que hacen la lectura más ágil y didáctica. Se había indicado en el documento sobre el lugar en Asumo que la ruta va a ser \\fs1\it5 expert\Gestión de la puesta en producción, aunque no lo mencionan el que se almacena la información “Gestión de la puesta en producción”, pero debido a que toda esta información y documentación se encontrará en el “file server” la ruta completa es “\\fs1\it- expert\Gestión de la puesta en producción”. Los plazos los ponen como 1 o 0.5 días. No están considerando que solo se deberían hacer en las horas de taller. Ejm: Se ha hecho la aclaración de que los días hábiles Según este documento, si me llega la para los despliegues son los días del curso de 6 solicitud el sábado y tengo 0.5 días para “Taller de Proyecto” y, en caso exista hacerla, debería tenerlo listo ese mismo disponibilidad de tiempo de los alumnos, los días día. Se debe considerar que los 'días sábados. hábiles' son las horas de taller en la mayoría de casos. Tabla 5.14 – Vulnerabilidades y observaciones sobre las políticas establecidas Fuente: Elaboración propia # Vulnerabilidad u observación identificada En esta y las siguientes pestañas, no indican el lugar donde almacenar los 7 documentos. Supongo que desean que se archiven las solicitudes de servicio, por ejemplo. Medida correctiva En el documento se ha agregado una columna en la que se indica dónde debe almacenarse cada documento y cuál es el rol que se encarga de esa función. Las actividades 3 y 4 del grupo 1 son En 8 base a la observación del las mismas para cualquier tipo de “Administrador del Centro de Cómputo” servicio. En vez de repetirlas, serían un se ha reestructurado el planteamiento de sub proceso. esta parte del proceso. Se ha indicado en las políticas, que el Jefe de Proyecto solo debe estar presente ¿Es necesario que el jefe de proyecto en los despliegues sobre el “Ambiente de 9 esté presente en todos los despliegues? Pruebas” la primera vez que se realice, Este ciclo no se ha hecho así en todos pero en ocasiones posteriores, debido a que ya se tiene el “know how” pueden ser los casos realizadas, directamente, por el “Administrador del Centro de Cómputo”. Tabla 5.14 – Vulnerabilidades y observaciones sobre las políticas establecidas Fuente: Elaboración propia 4. Resultado de la consideración 4: Se ha entregado la documentación sobre el proceso al alumno que se desempeñará como “Gerente de Proyectos y Recursos” en el ciclo académico 2011-02. Y se está a la espera de los comentarios sobre el modo en que se han planteado los manuales y documentos del proceso. 112 Con esta prueba se busca determinar si el alumno logra replicar todo el proceso de “Puesta en Producción” sin contratiempos y aceptar sugerencias de su parte sobre el mismo. 5. Resultado de la consideración 5: Se ha informado al alumno “Alfredo Barredo Meneses” con código U811077 de la capacitación y ha aceptado de buena manera, esta capacitación se dictará en la semana 15 del presente ciclo académico (2011-02) y servirá para asentar aún más el conocimiento del proceso de puesta en producción de las aplicaciones. Este conocimiento será, además, transmitido por este alumno en capacitaciones que el mismo brindará a los Jefes de Proyecto y Gerentes de Proyectos de las empresas virtuales a inicios del ciclo académico 2012-01. Se indica también que se debe realizar este mismo proceso al inicio de cada ciclo académico para las futuras generaciones de alumnos de la UPC. Comentarios del alumno sobre la capacitación: Luego de realizar la capacitación sobre la “gestión de puesta en producción” de las aplicaciones software el alumno indicó que “el proceso le quedó bastante claro”, además, mencionó que los manuales y documentación sobre el proceso “tienen un alto grado de detalle” que podrán permitirle continuar y aplicar el proceso desde el ciclo 2012-01 cuando empiece a desempeñarse como “Gerente de Proyectos y Recursos de IT-Expert”. Para la carpeta “Gestion de Puesta en Produccion” que se ha creado se tiene. Ubicación: //fs1/It-Expert/ Contenido de la carpeta. Carpetas Documentos que contiene Ubicación CONSOLIDADO.SERVICIOS: contiene el \\FS1\ITCONSOLIDADO consolidado de todos los servicios recibidos Expert\GESTION DE DE SERVCIOS para el proceso de puesta en producción de las LA aplicaciones. PUESTA EN PRODUCCION\ Contiene las carpetas : CICLO 2011-01, \\FS1\ITDESPLIEGUES CICLO 2011-02, CICLO 2012-00, CICLO Expert\GESTION DE REALIZADOS 2012-01, CICLO 2012-02,CICLO 2013-00, LA CICLO 2013-01, CICLO 2013-02 PUESTA EN PRODUCCION\ Tabla 5.15 – Estructura de carpetas para registrar el proceso Fuente: Elaboración propia 114 Carpetas Documentos que contiene Ubicación ACTA.CONFORMIDAD.DESPLIEGUE, CERTIFICADO.DESPLIEGUE.DESARROLLO, CIERRE.ADMINISTRATIVO.POR.FASE, CONSOLIDADO.SERVICIOS, CRONOGRAMA.ACTIVIDADES, DOCUMENTO.ACEPTACION.CLIENTE, MANUAL.ACCESO.REPOSITORIO, MANUAL.CREACION.REPOSITORIO, PLANTILLA S MANUAL.DE.CONFIGURACION, \\FS1\IT- Y MANUAL.DE.INSTALACION, Expert\GESTIO MANUALES PROCESO.GPP.GRAFICO, N DE LA DEL SOLICITUD.DE.APROBACION, PUESTA EN PROCESO SOLICITUD.SERVICIOS, PRODUCCION\ USUARIOSXREPOSITORIO. CONSOLIDADO.APLICACIONES.SOBRE.ACTIVO S Además contiene la carpeta : CONTRATO.GPP.APLICACION, contiene esta los carpeta documentos: CONTRATO.GPP.APLICACION y PROCESO.GPP.GRAFICO. POLITICAS DEL PROCESO OBLIGACIONES.Y.ACTIVIDADES.POR.PERFIL, POLITICAS.DE.PROCESO.EN.GRAFICOS, POLITICAS.GESTION.DE.PUESTA.EN.PRODUCCI ON \\FS1\ITExpert\GESTIO N DE LA PUESTA EN PRODUCCION\ Tabla 5.15 – Estructura de carpetas para registrar el proceso Fuente: Elaboración propia Carpetas Documentos que contiene USUARIOS DE REPOSITORI USUARIOSXREPOSITORIO XX \\FS1\IT-Expert\GESTION DE LA EN PUESTA PRODUCCION\ O CICLO 20XX- Ubicación Contiene la carpeta : “EMPRESAS” \\FS1\IT-Expert\GESTION DE LA EN PUESTA PRODUCCION\DESPLIEGUE S REALIZADOS\ Contiene la carpetas : BANKMIN, EMPRESAS IT-EXPERT, FACTORY, SOFTWRE SALUDABLE, SSIA.EDUCATE BANKMIN, IT-EXPERT, SOFTWRE SALUDABLE, SSIA.EDUCAT E CONFIGURA CION ACTIVOS Contiene carpetas con los nombres de los proyecto de la empresa respective, DE todos los documentos que se han generado durante su puesta en producción. CONSOLIDADO.APLICACIONES. SOBRE.ACTIVOS DE LA EN PUESTA PRODUCCION\DESPLIEGUE S REALIZADOS\CICLO 20XX-XX a su vez estas carpetas contienen FACTORY, \\FS1\IT-Expert\GESTION \\FS1\IT-Expert\GESTION DE LA EN PUESTA PRODUCCION\DESPLIEGUE S REALIZADOS\CICLO 20XXXX\EMPRESAS\<nombre de la empresa virtual> \\FS1\IT-Expert\GESTION DE LA EN PUESTA PRODUCCION\ Tabla 5.15 – Estructura de carpetas para registrar el proceso Fuente: Elaboración propia 116 Descripción de los documentos. ¿Qu Documento Ubicación de la Descripción plantilla Donde se ién lo llen almacena el documento con información a? Documento en el que se almacenan CONSOLIDADO .SERVICIOS todos los servicios realizados durante la el proceso de puesta en producción. \\FS1\IT- Adm Expert\GESTION inist DE LA PUESTA rado EN r del PRODUCCION\ centr PLANTILLAS Y o de MANUALES DEL cóm PROCESO\ puto \\FS1\ITExpert\GESTION DE LA PUESTA EN PRODUCCION\ CONSOLIDADO DE SERVCIOS\ \\FS1\ITExpert\GESTION DE LA PUESTA Documento ACTA.CONFOR MIDAD.DESPLI EGUE que \\FS1\IT- EN deja evidencia del Expert\GESTION PRODUCCION3.0 correcto \DESPLIEGUES DE LA PUESTA Jefe funcionamiento de EN de REALIZADOS\<C la aplicación en el PRODUCCION\ Proy ICLO ambiente de PLANTILLAS “Desarrollo” “Producción”. Y ecto y MANUALES DEL PROCESO\ ACADEMICO>\E MPRESAS\<EMP RESA VIRTUAL> \<CARPETA CON EL NOMBRE DEL PROYECTO> Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia Documento Descripción Ubicaci ¿Qu ón de ién Donde se almacena el la lo documento con plantill llen información a a? \\FS1\IT-Expert\GESTION \\FS1\ITCERTIFI CADO.DE SPLIEGU E.DESAR ROLLO Documento que Expert\GESTION Adm DE inist debe ser solicitado DE LA PUESTA rado LA PUESTA EN PRODUCCION3.0\DESPLI EGUES por la empresa QA, EN r del REALIZADOS\<CICLO para centr ACADEMICO>\EMPRES empezar a PRODUCCION\ realizar las pruebas PLANTILLAS Y o de AS\<EMPRESA a la aplicación MANUALES cóm VIRTUAL> \<CARPETA DEL PROCESO\ puto CON EL NOMBRE DEL PROYECTO> \\FS1\IT-Expert\GESTION CIERRE. Documento que se ADMINIS genera al final de TRATIVO cada despliegue en .POR.FAS los ambientes E virtuales. \\FS1\IT- Adm DE Expert\GESTION inist DE LA PUESTA rado LA PUESTA EN PRODUCCION3.0\DESPLI EGUES EN r del REALIZADOS\<CICLO PRODUCCION\ centr ACADEMICO>\EMPRES PLANTILLAS Y o de AS\<EMPRESA MANUALES cóm VIRTUAL> \<CARPETA DEL PROCESO\ puto CON EL NOMBRE DEL PROYECTO> Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia 118 Docume Ubicación de la Descripción nto lo plantilla llena? \\FS1\ITCRONO GRAMA .ACTIVI DADES Donde se ¿Quién almacena el documento con información Admini Documento que indica Expert\GESTION DE strador la fecha y hora en la LA PUESTA EN del que se llevará a cabo PRODUCCION\ cada uno de los PLANTILLAS servicios solicitados MANUALES centro No se almacena Y de DEL cómput PROCESO\ o \\FS1\ITExpert\GESTION DE LA PUESTA EN Documento entregado \\FS1\IT- PRODUCCION3.0 DOCUM a los Jefes de Proyecto Expert\GESTION DE ENTO.A luego de CEPTA aplicación CION.C desplegada LIENTE ambiente producción. que la LA PUESTA EN Jefe de es PRODUCCION\ en el PLANTILLAS de MANUALES Proyect Y o DEL PROCESO\ \DESPLIEGUES REALIZADOS\<C ICLO ACADEMICO>\E MPRESAS\<EMP RESA VIRTUAL> \<CARPETA CON EL NOMBRE DEL PROYECTO> Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia Donde se Documento Descripción Ubicación de ¿Quién almacena el la plantilla lo llena? documento con información \\FS1\ITExpert\GEST ION DE LA Documento que indica PUESTA EN MANUAL.ACCE cómo se debe acceder PRODUCCI Está SO.REPOSITORI y desarrolll No se almacena O utilizar los ON\ repositorios asignados PLANTILLA a cada proyecto. S ado Y MANUALES DEL PROCESO\ \\FS1\ITDocumento que indica cómo MANUAL.CREA CION.REPOSIT ORIO crear repositorio usuarios y que un sus luego serán asignados a los equipos de cada proyecto que será desplegado. Expert\GEST ION DE LA PUESTA EN PRODUCCI Está ON\ desarrolll No se almacena PLANTILLA ado S Y MANUALES DEL PROCESO\ Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia 120 Donde se Documento Descripción Ubicación de la ¿Quién almacena el plantilla lo llena? documento con información \\FS1\IT- \\FS1\ITDocumento en el que se plasma la MANUAL.D E.CONFIGU RACION configuración que debe tener aplicación la luego de ser desplegada en los ambientes virtuales. Expert\GESTI ON DE LA PUESTA EN PRODUCCIO N\ PLANTILLAS Jefe Proyecto VIRTUAL> MANUALES \<CARPETA CON EL NOMBRE CION los pasos realizar para el despliegue de las aplicaciones. DEL PROYECTO> \\FS1\IT- Expert\GESTI E.INSTALA ACADEMICO>\EMPRE SAS\<EMPRESA \\FS1\IT- que se almacenan EN PUESTA de REALIZADOS\<CICLO PROCESO\ MANUAL.D LA PLIEGUES DEL Documento en el DE PRODUCCION3.0\DES Y ON Expert\GESTION DE LA PUESTA EN PRODUCCIO N\ PLANTILLAS Expert\GESTION DE LA EN PUESTA PRODUCCION3.0\DES PLIEGUES Jefe de REALIZADOS\<CICLO Proyecto Y MANUALES DEL PROCESO\ ACADEMICO>\EMPRE SAS\<EMPRESA VIRTUAL> \<CARPETA CON EL NOMBRE PROYECTO> Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia DEL Ubicación Documento Descripción de la ¿Quién lo Donde se almacena el documento con llena? plantilla información \\FS1\ITDocumento indica PROCESO. GPP.GRAF ICO de que Expert\GES manera TION DE gráfica las políticas y LA pasos a durante Está seguir PUESTA todo desarrolllad el EN proceso de puesta en PRODUCC producción aplicaciones. No se almacena o de las ION\POLIT ICAS DEL PROCESO SOLICITU Documento D.DE.APR presenta cada Jefe de Expert\GES OBACION Proyecto para que su TION aplicación que \\FS1\IT- Jefe Proyecto DE pueda LA de \\FS1\ITExpert\GESTION DE LA EN PUESTA PRODUCCION3.0\DE iniciar el proceso de PUESTA SPLIEGUES puesta REALIZADOS\<CICL producción. en EN PRODUCC O ION\ ACADEMICO>\EMPR PLANTILL ESAS\<EMPRESA AS VIRTUAL> Y MANUALE \<CARPETA CON EL S NOMBRE DEL PROCESO\ DEL PROYECTO> Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia 122 Docume nto Ubicación de la Descripción plantilla ¿Quié Donde se almacena el n lo documento con llena? información SOLICI Documento que \\FS1\IT- Jefe \\FS1\IT-Expert\GESTION TUD.DE presenta de DE .APROB Jefe de Proyecto DE LA PUESTA EN Proye PRODUCCION3.0\DESPLI ACION para EGUES que cada Expert\GESTION su PRODUCCION\ aplicación pueda PLANTILLAS cto Y LA PUESTA EN REALIZADOS\<CICLO iniciar el MANUALES DEL ACADEMICO>\EMPRES proceso de PROCESO\ AS\<EMPRESA puesta en VIRTUAL> producción. \<CARPETA CON EL NOMBRE DEL PROYECTO> SOLICI Documento en \\FS1\IT- TUD.SE el que se plasma Expert\GESTION RVICIO la petición de un DE LA PUESTA EN Proye PRODUCCION3.0\DESPLI S servicio. EGUES PRODUCCION\ PLANTILLAS MANUALES Jefe \\FS1\IT-Expert\GESTION de DE cto Y DEL PROCESO\ LA PUESTA EN REALIZADOS\<CICLO ACADEMICO>\EMPRES AS\<EMPRESA VIRTUAL> \<CARPETA CON EL NOMBRE DEL PROYECTO> Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia Documento Descripción Ubicación de la plantilla ¿Quién Donde se almacena el lo documento con llena? información SOLICITUD. Documento en \\FS1\IT- Jefe de \\FS1\IT- SERVICIOS Proyect el que plasma se Expert\GESTION la DE LA PUESTA o Expert\GESTION DE LA PUESTA EN petición de un EN PRODUCCION3.0\DESP servicio. PRODUCCION\ LIEGUES PLANTILLAS Y REALIZADOS\<CICLO MANUALES ACADEMICO>\EMPRES DEL PROCESO\ AS\<EMPRESA VIRTUAL> \<CARPETA CON EL NOMBRE DEL PROYECTO> USUARIOS Consolidado \\FS1\IT- XREPOSITO de los usuarios Expert\GESTION RIO y Admini \\FS1\IT- strador Expert\GESTION DE LA contraseñas DE LA PUESTA del PUESTA EN del repositorio EN centro PRODUCCION\USUSUA asignado de RIOS DE REPOSITOIRO a PRODUCCION\ cada equipo de PLANTILLAS Y cómput proyecto. MANUALES o DEL PROCESO\ Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia 124 Document Descripción o CONTRA Documento Ubicación de la plantilla que \\FS1\IT- ¿Quié Donde se almacena el n lo documento con llena? información Jefe \\FS1\IT- de Expert\GESTION DE EN TO.GPP.A evidencia el Expert\GESTION PLICACI compromiso de DE LA PUESTA Proye LA ON respetar las EN PRODUCCION3.0\DES todas políticas actividades cto y PRODUCCION\ PUESTA PLIEGUES del PLANTILLAS Y REALIZADOS\<CICLO proceso de puesta en MANUALES ACADEMICO>\EMPRE producción. SAS\<EMPRESA DEL PROCESO\ VIRTUAL> \<CARPETA CON EL NOMBRE PROYECTO> OBLIGA Documento en el que \\FS1\IT- Está CIONES. se desarr registran Y.ACTIVI obligaciones DADES.P y DE LA PUESTA olllad actividades de cada EN OR.PERFI uno de los L las Expert\GESTION No se almacena o roles PRODUCCION\P involucrados en el OLITICAS DEL proceso de puesta en PROCESO producción. Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia DEL Donde se Documento Descripción Ubicación de ¿Quién almacena el la plantilla lo llena? documento con información Documento que indica de manera gráfica las POLITICAS.DE. políticas y pasos a PROCESO.EN.G seguir durante todo el RAFICOS proceso de puesta en producción de las aplicaciones. \\FS1\ITExpert\GEST ION DE LA PUESTA EN PRODUCCI ON\POLITIC AS Está desarrolll No se almacena ado DEL PROCESO \\FS1\ITExpert\GEST POLITICAS.GES Primer documento de ION DE LA TION.DE.PUEST políticas generado PUESTA EN A.EN.PRODUCC para el proceso de PRODUCCI ION puesta en producción. ON\POLITIC AS Está desarrolll No se almacena ado DEL PROCESO Tabla 5.16 – Documentos creados para el proceso Fuente: Elaboración propia Plan y Estrategias de Seguridad. El proceso de puesta en producción almacena información que es importante para conocer si se están realizando todas las actividades del proceso de manera adecuada, pero esta información no se considera de naturaleza confidencial crítica, es decir el acceso a esta información no presenta un tratamiento especial como si lo requeriría, por ejemplo, una contraseña de mail o cuenta bancaria. 126 Pero se tiene un aspecto que se puede asociar a la seguridad dentro del proceso y es el referido al manejo de usuarios por repositorio, que se da de la siguiente manera: a) Cada proyecto tiene asignado un repositorio en el que los alumnos que forman el equipo de este, almacenan toda la información asociada. Esta información es la referida a la documentación, los ejecutables del proyecto y el código fuente del mismo. b) A cada miembro del equipo del proyecto se le asigna un usuario y contraseña con el que pueden acceder y registrar u obtener información y documentación. Otro de los aspectos asociados a la seguridad del proceso es la de los servidores donde se despliegan las aplicaciones, la seguridad de estos se servidores se maneja de la siguiente manera: a) Existe una lista de alumnos que se le ha entregado al personal administrativo y que se encuentra custodiando los servidores del centro de cómputo. En esta lista se indican los alumnos que tienen autorización para ingresar y manipular estos servidores, con ello se garantiza que ningún alumno o persona ajena al proceso pueda acceder a estos y causar algún tipo de problema. b) Los ambientes sobre los cuales son desplegados los servidores cuentan con una contraseña que solo es manejada por el “Administrador del Centro de Cómputo”, “Gerente General” y “Gerente de Proyectos y Recursos” de la empresa IT-Expert. Esto permite que la realización o verificación de información en estos ambientes virtuales sea solo por personas autorizadas. Planes de Contingencia. Un plan de contingencia busca establecer un mecanismo de solución en caso se presente un problema. Los planes de contingencia que se presentan a continuación están desarrollados en función a la experiencia recogida del seguimiento del proceso durante parte del ciclo académico 2011-01 y todo el ciclo académico 2011-02. Caída de alguno de los ambientes virtuales (aplicaciones). Plan de contingencia: Si alguno de los ambientes virtuales en los que se despliegan las aplicaciones deja de funcionar, como ya ha sucedido, se debe desplegar la aplicación en alguno de los otros ambientes virtuales que se mantengan funcionando. Se debe tener en cuenta que existen tres ambientes virtuales por tecnología soportada. JAVA1: Ambiente virtual de producción para aplicaciones realizadas en el lenguaje de programación Java. JAVA2: Ambiente virtual de pruebas para aplicaciones realizadas en el lenguaje de programación Java. JAVA3: Ambiente virtual de desarrollo para aplicaciones realizadas en el lenguaje de programación Java. NET1: Ambiente virtual de producción para aplicaciones realizadas en el Framework .NET y lenguaje PHP. NET2: Ambiente virtual de pruebas para aplicaciones realizadas en el Framework .NET y lenguaje PHP. NET3: Ambiente virtual de desarrollo para aplicaciones realizadas en el Framework .NET y lenguaje PHP. Caída de alguno de los ambientes virtuales (base de datos). Plan de contingencia: Si alguno de los ambientes virtuales en los que se despliegan las bases de datos de las aplicaciones deja de funcionar, como ya ha sucedido, se debe desplegar la aplicación en alguno de los otros ambientes virtuales que se mantengan funcionando. Se debe tener en cuenta que existen dos ambientes virtuales para las bases de datos de las aplicaciones. QA1: Ambiente virtual en el que se almacenan las bases de datos de las aplicaciones que se encuentran en desarrollo y pruebas. BD2: Ambiente virtual en el que se almacenan las bases de datos de las aplicaciones que se encuentran en producción. Borrado de la información que se encuentra en las bases de datos de las aplicaciones. Plan de contingencia: Se deben realizar back up semanales de las bases de datos que se encuentran soportando las aplicaciones desplegadas. Esta actividad es realizada por el “Administrador del centro de cómputo”. Borrado de la información que se encuentra en los repositorios asignados a cada proyecto que pasa por el proceso de puesta en producción. 128 Plan de contingencia: Se deben realizar back up semanales de la información que se encuentra en los repositorios asignados a cada uno de los proyectos. Esta actividad es realizada por el “Administrador del centro de cómputo”. Plan de operación y soporte de sistemas Para el plan de operaciones del proyecto de Gestión de Puesta en Producción se tuvieron las siguientes acciones. a) Al inicio del proyecto se realiza una investigación sobre el modo en que se realizan la puesta en producción de las aplicaciones que se desarrollan en las empresas virtuales de la UPC, esto es realizado por el equipo de proyecto. b) En base a la información obtenida se inicia el modelado y documentación de los procesos y actividades para realizar la puesta en producción de las aplicaciones software que se desarrollan. c) Se inicia la implementación del proceso indicando a los alumnos que están desarrollando aplicaciones las nuevas actividades que deben de realizar, según el nuevo marco de trabajo. d) Se realiza una selección de tres proyectos de las empresas virtuales para realizarles un seguimiento estricto y verificar si las actividades planteadas para el proceso de puesta en producción son consistentes y se ajustan a la realidad de las empresas virtuales. e) La información que se obtiene del seguimiento de los proyectos es aplicada para mejorar y replantear las actividades establecidas para la puesta en producción de las aplicaciones. Plan de migración de sistemas (solo si utilizarán información histórica) El proceso de “Gestión de Puesta en Producción” no realiza el soporte de aplicaciones que han sido desplegadas antes del ciclo 2011-01 por ende no realiza migraciones de sistema. Estrategias de despliegue de aplicaciones Cabe mencionar que antes de empezar a implementar el proceso de puesta en producción se hizo una investigación sobre si, actualmente, existía una proceso o marco de trabajo establecido para poner en producción las aplicaciones que se desarrollaban en las empresas virtuales. La estrategia de implementación del proceso fue la siguiente: Primero: Se planteó y de diagramó de manera teórica cada una de las actividades e infraestructura que soportaría todo el proceso desde la implementación del software o escritura del código hasta el despliegue del mismo en el lugar desde el cual sería accedido por los usuarios finales. Del proceso planteado se determinó que se crearían tres ambientes virtuales que serían el lugar en el que se desplegarían todas las aplicaciones, cada ambiente estaba destinado a una función concreta. El primero sería para realizar el desarrollo de la aplicación o “ambiente de desarrollo”, el segundo sería el lugar en el que la empresa QA realizaría las pruebas funcionales o “ambiente de pruebas” y el tercero es el lugar donde la aplicación se queda y es accedida desde aquí por los usuarios finales o “ambiente de producción.” Segundo: Se tomó como modelo una máquina virtual que existía en el centro de cómputo y sobre la cual habían sido desplegadas todas las aplicaciones de ciclos anteriores al ciclo en que el proyecto empezó a ser implementado (ciclo 2011-01). Se creó una réplica de esta máquina virtual y se empezó a utilizar como “ambiente de pruebas” mientras que con la ya existente de utilizó como “ambiente de desarrollo”. Lo 130 siguiente fue verificar la estabilidad del ambiente virtual replicado y que ahora sería el “ambiente de pruebas”, verificando de que comportaba de manera estable y las aplicaciones sobre este se podían acceder de manera adecuada se creó una tercera réplica que se tomó como “ambiente de producción”. Tercero: Una vez listos los ambientes virtuales que soportarían las aplicaciones se empezaron a indicar las nuevas reglas y documentación necesaria a los alumnos que estaban realizando el pase a producción de sus aplicaciones. Se tuvieron dos casos en la aplicación y establecimiento de las nuevas actividades del proceso, por un lado estaban las aplicaciones que estaban en un nivel avanzado de implementación y con las cuales la aplicación del proceso era más complicada, por lo que se les exigió seguir solo algunas de políticas establecidas; por otro lado estaban los alumnos con aplicaciones que recién empezarían el proceso de puesta en producción de sus aplicaciones a quienes se les exigió seguir las políticas del proceso en su totalidad. Cuarto: A medida que se aplicaban las políticas establecidas y diseñadas en teoría, estas se iban modificando para justarlas a la realidad de las necesidades de los alumnos y de las empresas virtuales. Aún ahora se sigue monitoreando el proceso para mejorarlo cada vez más y permitir ofrecer un servicio de calidad a todos aquellos que lo requieran. En resumen la estrategia de implementación del proceso fue la siguiente: a) Planteamiento teórico de las políticas y actividades del proceso de puesta en producción. b) Replica de un ambiente virtual en el cual se habían estado desplegando todas las aplicaciones desarrolladas en las empresas virtuales hasta el momento. c) Verificación de la estabilidad de los ambientes virtuales creados para albergar todas las aplicaciones que se desarrollen. d) Implantación de las políticas en un nivel bajo para los proyectos que se encontraban en una fase avanzada de desarrollo. e) Implantación de las políticas en su totalidad a aquellos proyectos que recién iniciaban el proceso de puesta en producción. f) Monitoreo, modificación y replanteamiento de las políticas y actividades del proceso de puesta en producción a medida que se iba utilizando. g) Registro de las lecciones aprendidas durante la implementación del proceso de puesta en producción. Estudios de factibilidad. El estudio de factibilidad para la realización el proyecto tornó en función a dos parámetros que son verificar si se tenía el hardware necesario para crear los ambientes virtuales que el proceso establecía y, además, verificar si los alumnos tenían los conocimientos técnicos necesarios para realizar la manipulación de los servidores del centro de cómputo. Para el resultado del análisis de factibilidad se obtuvo. a) La UPC a inicios del ciclo académico 2011-01 adquirió un nuevo y potente servidor y lo puso a disposición de la empresa IT-Expert, lo que proporcionaba un hardware y software adecuados para crear los ambientes virtuales que soportan el proceso de la puesta en producción. b) Los conocimientos técnicos fue, quizás, la razón por la cual la factibilidad del proyecto se vio un poco afectada debido a que al iniciar el proyecto no se sabía cómo realizar el manejo y configuración de este servidor nuevo por lo que tuvo que realizarse una investigación constante del tema. c) Finalmente, un aspecto que no fue considerado y provocó problemas para la implementación del proyecto y que no se tomó en cuenta para la factibilidad fue la renuencia de los alumnos a aceptar nuevas políticas y actividades para un proceso que hasta el momento se había realizado de manera desordenada y sin ningún tipo de control o registro. Plan de Administración de Datos. La información para la puesta en producción más importante proviene de la ejecución de los servicios solicitados, por ello el resultado de la ejecución de estos servicios asociados a todo el proceso de despliegue de las aplicaciones cobra mucho interés. Para el manejo de datos se ha establecido lo siguiente. a) Al iniciar el ciclo académico se registraba solamente la ejecución si el servicio solicitado fue efectuado o no. Este registro que se hace en el “Consolidado de Servicios” por el “Administrador del Centro de Cómputo” puede reflejar la 132 eficacia del proceso, pero no la eficiencia, es decir no se toma en cuenta el tiempo que estos servicios tardan en realizarse. b) Al crear el “Cronograma de Actividades” se establece el tiempo estimado para atender el servicio. Por lo tanto se propone manejar estos datos de la siguiente manera. Si el servicio se realizó y además se hizo dentro del tiempo establecido se considera “ATENDIDO”. Si el servicio se realizó, pero tardó más tiempo del estimado este se considera “ATENDIDO CON RETRASO”. Si el servicio no se realizó por diversos motivos que también son registrados se considera “NO ATENDIDO”. Al clasificar la información de los resultados de la ejecución de los servicios de este modo se tiene un indicador claro de la “EFICIENCIA” y “EFICACIA” del proceso. Por ejemplo, si se tienen 10 servicios registrados y solo 8 tienen estado “ATENDIDO” y los otros dos tienen estado “NO ATENDIDO” la EFICACIA es del 80%. También, si se tienen 10 servicios registrados y solo 7 tienen estado “ATENDIDO” y los otros tres tienen estado “ATENDIDO CON RETRASO” la EFICACIA es del 100%, pero la EFICIENCIA es del 70%. Estos datos deben ser obtenidos y analizados por el “Administrador del Centro de Cómputo” para poder plantear estrategias que mejoren ambos aspectos en caso estas se encuentren con un porcentaje muy bajo. Estrategias de control de rendimiento de infraestructuras Para el control del rendimiento se creyó conveniente la utilización de una herramienta que permita el monitoreo de los ambientes virtuales creados para el despliegue de las aplicaciones, para este caso el proyecto “Gestión de Disponibilidad de Servicios de TI” resultaba perfecto ya que en el ciclo 2011-02 se ha implementado la herramienta “Nagios” que permite conocer el comportamiento de software y hardware del centro de cómputo en todo momento. Por ello para tener un control del rendimiento se debe controlar los siguientes parámetros: a) La memoria RAM asignada a cada uno de los ambientes virtuales para el despliegue de aplicaciones debe estar como máximo a un 80% de su capacidad. b) La memoria física asignada a los ambientes virtuales se debe encontrar siempre a menos del 80% de su capacidad. Según lo establecido el “Administrador del Centro de Cómputo” debe recibir un informe en caso no se den estas situaciones y verificar la razón por la cual se han superado los límites establecidos. Plan de Administración de Redes El manejo de las redes en la UPC está a cargo del área de informática de la facultad de Ingeniería, por ende el proceso de puesta en producción de las aplicaciones no la administra. Plan de Configuración de Activos Se consideran como activos para el proceso de puesta a producción a todos los ambientes virtuales sobre los cuales se realizan los despliegues de las aplicaciones, por ello es importante conocer cada una de las aplicaciones que se van desplegando en estos ambientes y, de ese modo, conocer siempre la configuración de los activos del proceso. Para llevar a cabo el seguimiento de la configuración de los activos se tiene el documento “Consolidado de aplicaciones sobre activos”, en el que se deja constancia de cada una de las aplicaciones desplegadas por ambiente virtual y los detalles de estas, el rol encargado de consolidar esta información es el Administrador del Centro de Cómputo y está indicado en los manuales y documentación sobre la política y actividades del proceso. El documento “Consolidado de aplicaciones sobre activos” se encuentra adjunto como anexo. 134 Capítulo 6. Seguimiento de la Puesta en Producción de los Proyectos durante el ciclo 2011-02 En el presente capítulo se detallarán los proyectos a los cuales se les está haciendo un seguimiento estricto para validar el marco de trabajo que se ha planteado para el proceso de Puesta en Producción. Para cada uno de los proyectos se tomará datos claves como el cumplimiento de tiempos para el envío de solicitudes para el despliegue en los ambientes, el tiempo de duración de los despliegues de los proyectos en cada uno de los ambientes virtuales y los problemas que se puedan dar durante el desarrollo de cada uno de las actividades para la puesta en producción. Proyectos presentados para el ciclo 2011-02 Empresa Virtual SALUDABLE Proyecto Sistema de administración de Personal SALUDABLE Sistema Administrativo del Centro de Salud SALUDABLE Sistema Administrativo de Servicios al Paciente César Villanueva DEDABET – Datamart de Evidencias Directas Stephanie Cabezas Dávalos, para ABET Rosa Soto SSIA - EDUCATE GPLACS 2D Edgar José Velásquez Flores DESAPROBADO SSIA - EDUCATE Rubric-On Enrique Rojas Gonzales APROBADO Ángelo Escudero Vía APROBADO SSIA - EDUCATE Integrantes Hector Aliaga, Tomás Lazo Jadisha Ramírez, Larry Gallarday Sistema de Seguimiento a los Egresados de las SSIA - EDUCATE Carreras de Computación (SSECC) SSIA - EDUCATE Mejora De Visualización 3D De GPLACS SSIA - EDUCATE SIGCOL 3 Paul Landauro, Elizabeth Portilla Edgar José Velásquez Flores Estado APROBADO APROBADO APROBADO APROBADO DESAPROBADO DESAPROBADO Tabla 6.1 – Proyectos Evaluados el ciclo 2011-02 Fuente: Elaboración propia 136 Avance de los proyectos dentro del flujo de la Gestión de la Puesta en Producción. Actividad Declaración del Proyecto Repositorios Desarrollo Pruebas Producción Proyecto Envío de la solicitud de proyecto Creación de los repositorios para documentación Recepción del manual de instalación Recepción del manual de configuración Despliegue en el ambiente de desarrollo Entrega del certificado de despliegue en Desarrollo Recepción de Pruebas Unitarias de la Aplicación Recepción de solicitud de despliegue en Pruebas Despliegue en el Ambiente de Pruebas Recepción del Certificado de QA Recepción de solicitud de despliegue en Producción Despliegue en el ambiente de Producción Recepción de constancia de funcionamiento en Producción Entrega del certificado de despliegue en Producción Sistema de administración de Personal Alineación al proceso REALIZADO 100% REALIZADO 100% REALIZADO REALIZADO REALIZADO 100% PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE Tabla 6.2 Avance de actividades del Proyecto: Sistema de administración de Personal Fuente: Elaboración propia 100% 50% Actividad Declaración del Proyecto Repositorios Desarrollo Pruebas Producción Proyecto Envío de la solicitud de proyecto Creación de los repositorios para documentación Recepción del manual de instalación Recepción del manual de configuración Despliegue en el ambiente de desarrollo Entrega del certificado de despliegue en Desarrollo Recepción de Pruebas Unitarias de la Aplicación Recepción de solicitud de despliegue en Pruebas Despliegue en el Ambiente de Pruebas Recepción del Certificado de QA Recepción de solicitud de despliegue en Producción Despliegue en el ambiente de Producción Recepción de constancia de funcionamiento en Producción Entrega del certificado de despliegue en Producción Sistema Administrativo de Servicios al Paciente Alineación al proceso REALIZADO 100% REALIZADO 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE PENDIENTE 50% PENDIENTE PENDIENTE Tabla 6.3 Avance de actividades del Proyecto: Sistema Administrativo de Servicios al Paciente Fuente: Elaboración propia 138 Actividad Declaración del Proyecto Repositorios Desarrollo Pruebas Producción Proyecto Envío de la solicitud de proyecto Creación de los repositorios para documentación Recepción del manual de instalación Recepción del manual de configuración Despliegue en el ambiente de desarrollo Entrega del certificado de despliegue en Desarrollo Recepción de Pruebas Unitarias de la Aplicación Recepción de solicitud de despliegue en Pruebas Despliegue en el Ambiente de Pruebas Recepción del Certificado de QA Recepción de solicitud de despliegue en Producción Despliegue en el ambiente de Producción Recepción de constancia de funcionamiento en Producción Entrega del certificado de despliegue en Producción Sistema Administrativo del Centro de Salud Alineación al proceso REALIZADO 100% REALIZADO 100% REALIZADO REALIZADO REALIZADO 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE Tabla 6.4 Avance de actividades del Proyecto: Sistema Administrativo del Centro de Salud Fuente: Elaboración propia 50% Actividad Declaración del Proyecto Repositorios Desarrollo Pruebas Producción Proyecto Envío de la solicitud de proyecto Creación de los repositorios para documentación Recepción del manual de instalación Recepción del manual de configuración Despliegue en el ambiente de desarrollo Entrega del certificado de despliegue en Desarrollo Recepción de Pruebas Unitarias de la Aplicación Recepción de solicitud de despliegue en Pruebas Despliegue en el Ambiente de Pruebas Recepción del Certificado de QA Recepción de solicitud de despliegue en Producción Despliegue en el ambiente de Producción Recepción de constancia de funcionamiento en Producción Entrega del certificado de despliegue en Producción DEDABET – Datamart de Evidencias Directas para ABET Alineación al proceso REALIZADO 100% REALIZADO 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE PENDIENTE 50% PENDIENTE PENDIENTE Tabla 6.5 Avance de actividades del Proyecto: DEDABET – Datamart de Evidencias Directas para ABET Fuente: Elaboración propia 140 Actividad Declaración del Proyecto Repositorios Desarrollo Pruebas Producción Proyecto Envío de la solicitud de proyecto Creación de los repositorios para documentación Recepción del manual de instalación Recepción del manual de configuración Despliegue en el ambiente de desarrollo Entrega del certificado de despliegue en Desarrollo Recepción de Pruebas Unitarias de la Aplicación Recepción de solicitud de despliegue en Pruebas Despliegue en el Ambiente de Pruebas Recepción del Certificado de QA Recepción de solicitud de despliegue en Producción Despliegue en el ambiente de Producción Recepción de constancia de funcionamiento en Producción Entrega del certificado de despliegue en Producción Rubric-On Alineación al proceso REALIZADO 100% REALIZADO 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE PENDIENTE Tabla 6.6 Avance de actividades del Proyecto: Rubric-On Fuente: Elaboración propia 100% 50% Actividad Declaración del Proyecto Repositorios Desarrollo Pruebas Producción Proyecto Envío de la solicitud de proyecto Creación de los repositorios para documentación Recepción del manual de instalación Recepción del manual de configuración Despliegue en el ambiente de desarrollo Entrega del certificado de despliegue en Desarrollo Recepción de Pruebas Unitarias de la Aplicación Recepción de solicitud de despliegue en Pruebas Despliegue en el Ambiente de Pruebas Recepción del Certificado de QA Recepción de solicitud de despliegue en Producción Despliegue en el ambiente de Producción Recepción de constancia de funcionamiento en Producción Entrega del certificado de despliegue en Producción Sistema de Seguimiento a los Egresados de las Carreras de Computación (SSECC) Alineación al proceso REALIZADO 100% REALIZADO 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE 100% PENDIENTE PENDIENTE PENDIENTE PENDIENTE 50% PENDIENTE PENDIENTE Tabla 6.7 Avance de actividades del Proyecto: Sistema de Seguimiento a los Egresados de las Carreras de Computación (SSECC) Fuente: Elaboración propia 142 Problemas encontrados durante el desarrollo de las actividades del Proceso de Puesta en Producción. Los problemas que aquí se detallan son los encontrados durante la aplicación y seguimiento del marco de trabajo planteado para la puesta en producción de una aplicación. Problema Falta de integración de la base de datos entregada por el jefe de proyecto con la base de datos existente en los servidores. Falta de integración de la base de datos entregada por el jefe de proyecto con la base de datos existente en los servidores. Proyecto Solución Información del problema Sistema de administración al jefe de proyecto y de Personal posterior revisión por este. Información del problema Sistema Administrativo al jefe de proyecto y del Centro de Salud posterior revisión por este. Se entregó a los alumnos una pequeña aplicación Problemas con la para que puedan registrar recepción y atención de Sistema Administrativo todas sus solicitudes y de solicitud de despliegue del Centro de Salud ese modo tener esta para la aplicación. información más centralizada y fácil de acceder. Revisión del modo en que se estaba realizando la conexión por parte del Problemas para realizar la Jefe del Proyecto. conexión de la base de Sistema de administración Posteriormente se datos MySQL con la de Personal determinó que la cadena aplicación de conexión no se había realizado de manera adecuada por lo que se modificó. Tabla 6.8: Problemas encontrados durante el desarrollo del proceso de puesta en producción Fuente: Elaboración propia Problema Proyecto Solicitudes de instalación de aplicaciones para el correcto funcionamiento de un proyecto fuera del tiempo establecido en las políticas de puesta en producción (semana 1 y 2 del ciclo académico) Sistema de Seguimiento a los Egresados de las Carreras de Computación (SSECC) Solicitudes de instalación de aplicaciones para el correcto funcionamiento de un proyecto fuera del tiempo establecido en las políticas de puesta en producción (semana 1 y 2 del ciclo académico) DEDABET – Datamart de Evidencias Directas para ABET Peticiones de despliegue de manera verbal por parte del jefe de proyecto. Sistema de Seguimiento a los Egresados de las Carreras de Computación (SSECC) Solución Se pidió a cada uno de los Jefes de proyecto revisar y reordenar las fechas de sus entregables para evitar futuros problemas similares. Además se tramitó con el personal administrativo la posibilidad de la instalación de las aplicaciones solicitadas por los alumnos. Se pidió a cada uno de los Jefes de proyecto revisar y reordenar las fechas de sus entregables para evitar futuros problemas similares. Además se tramitó con el personal administrativo la posibilidad de la instalación de las aplicaciones solicitadas por los alumnos. Se indicó al jefe de proyecto que las peticiones de despliegue deben realizarse de manera escrita por mail para tener constancia de la fecha de envío de la solicitud. Tabla 6.8: Problemas encontrados durante el desarrollo del proceso de puesta en producción Fuente: Elaboración propia 144 Problema Proyecto Muchos de los Jefes de Proyecto no tenían idea clara de las fechas de entrega y actividades que debían realizarse para el despliegue de sus aplicaciones en los servidores de la universidad Todos los proyectos desarrollados en el ciclo 2011 - 02 Solución Se recorrió cada una de las empresas virtuales para indicar las actividades y procesos que debían realizarse. Se envió, nuevamente, la documentación con las políticas de la puesta en producción a cada uno de los Jefes de Proyecto. Se conversó con el Gerente de la empresa IT – Expert para la elaboración de un sistema de carpetas en el cual se deje registro claro el modo en que se debe proceder y las actividades a realizar para el proceso de puesta en producción. TABLA 6.8: PROBLEMAS ENCONTRADOS DURANTE EL DESARROLLO DEL PROCESO DE PUESTA EN PRODUCCION Fuente: Elaboración propia Gráficos resúmenes sobre la Gestión de la Puesta en Producción. Los siguientes gráficos muestran información sobre los proyectos a los que se les ha aplicado el marco de trabajo propuesto para la puesta en producción de una aplicación. Figura 6.1 – Proyectos atendidos bajo el marco de trabajo planteado para la puesta en producción de una aplicación Fuente: Elaboración propia 146 Figura 6.2 – Proyectos vs Actividades de la Puesta en Producción Fuente: Elaboración propia Conclusiones a) La implementación de un proceso estructurado y definido para la Gestión de la Puesta en Producción es vital para lograr entregar un producto software de calidad. b) Los retos para la implementación de un proceso de Gestión de Puesta en Producción, hasta el momento, están en función al hardware que se posee. c) La definición e implementación de procesos para la «Gestión de Puesta en Producción» aporta valor a las empresas al permitir que estas trabajen la entrega de aplicaciones en un marco de trabajo estandarizado. d) La definición del proceso de la «Gestión de Puesta en Producción» debe involucrar la opinión y aceptación de todos los involucrados en esta para poder lograr un mejor resultado. e) Una de las dificultades encontradas durante el proceso de puesta en producción ha sido implantar una cultura de desarrollo y reglas para el proceso que hasta ciclos anteriores se llevaba a cabo de manera desordenada y sin seguir ningún tipo de reglas bien definidas. f) Para el ciclo 2011-02 aún se sigue observando por parte de los alumnos, especialmente, los jefes de proyecto la tendencia a no seguir las nuevas reglas y políticas para la puesta en producción. 148 Recomendaciones a) El proyecto sobre le Gestión de Puesta en Producción involucra directamente a todas las empresas virtuales de la Universidad Peruana de Ciencias Aplicadas, ante todas las actividades realizadas se demostró que se logró un avance notable involucrando directamente a todos los interesados en el proceso que, en este caso, son los Gerentes de Proyectos y Recursos de cada empresa virtual. Ante esta evidencia se recomienda, para que el proyecto sigua desarrollándose con éxito, establecer un plan de comunicación efectivo que pueda servir de modelo para cualquier otro proyecto similar. En el punto 7.16 del presente documento se adjunta el acta de una de las reuniones que se tuvo con los Gerentes de Procesos y Recursos de las empresas virtuales para validar los procesos que se estaban planteando para la Gestión de la Puesta en Producción. b) El proyecto, desde el inicio, presentó una clara limitante por el lado del Hardware existente en la sala de servidores de la Universidad Peruana de Ciencias Aplicadas, ante lo cual se recomienda la adquisición de equipos más potentes que respondan a las exigencias que el proyecto plantea. Esta recomendación se pretende sea presentada por el equipo del proyecto para el ciclo académico 2011-02 con un adecuado sustento técnico. c) Otra de las limitantes, durante el desarrollo del proyecto “Gestión de Puesta en Producción”, además del tema del hardware ha sido los conocimientos técnicos que los alumnos de la empresa IT-Expert requieren para dar soporte a las exigencias de los alumnos en diferentes temas. Por ello se recomienda destinar capacitaciones a estos alumnos a un nivel más técnico y no tan teórico como suele suceder con los cursos universitarios. Las capitaciones deberán ser planteadas por los Gerentes de Recursos y Procesos de cada empresa virtual, ya que ellos conocen de manera directa los requerimientos de las aplicaciones de sus respectivas empresas y el nivel de conocimientos con los que cuentas los Jefes de proyecto sobre estas tecnologías. Las capacitaciones realizadas deben quedar registradas en manuales detallados para poder ser posteriormente consultadas por otros alumnos de las mismas empresas que deseen conocer las tecnologías utilizadas en cada una de estas. La sugerencia de estas capacitaciones será presentada de manera formal por el equipo de este proyecto para el ciclo académico 2011-02. d) En el ciclo 2011-02 se observó de manera directa la falta de transmisión de conocimientos y detalles sobre los procesos y actividades que se han planteado para la Gestión de la Puesta en Producción de cada una de las aplicaciones desarrolladas en las diferentes empresas virtuales. Por ello se plantea : Dar a conocer las restricciones de software y hardware para cada uno de los proyectos que desee ser desplegado antes de que comience el ciclo académico, lo que dará a los alumnos tiempo de buscar tecnologías alternativas, en caso las que pretenden utilizar no estén soportadas en el centro de cómputo. Entregar las políticas de la Gestión de la Puesta en Producción antes del inicio de cada ciclo académico a los profesores de cada una de las empresas virtuales, de manera que los alumnos tengan una idea de cada uno de los requisitos que deberán cumplirse para que su aplicación cumpla de manera adecuada todo el ciclo establecido. Brindar en la primera semana de cada ciclo académico una capacitación en la cual se explique de manera clara cada una de las actividades planteadas para el proceso de puesta en producción. Esta charla debe estar orientada a cada uno de los gerentes de recursos y procesos de las empresas virtuales. Además, sugerir a estos gerentes que luego de recibida la charla la repliquen a cada uno de los Jefes de proyecto de sus respectivas empresas. Creación de una estructura de carpetas en el directorio compartido de las empresas o “File Server” para dejar registrado cada una de las incidencias, problemas y soluciones dadas durante la puesta en producción de las aplicaciones de las empresas virtuales, para que esta información pueda ser explotada por cada uno de los alumnos, profesores, jefes de proyecto y todo aquel involucrado con las actividades que aquí se realizan. 150 Bibliografía ITSM LIBRARY Fundamentos de gestión de servicios TI: basado en ITIL GOBIERNO DE CANARIAS (2011) Página Web sobre el desarrollo de un proyecto de Sistemas de Información llevado a cabo en España. (http://www.gobiernodecanarias.org/cpj/temas/cibercentro/docs/DGTNT-010912-TSIPRC_Procedimiento_Gestion_de_la_Entrega.pdf) (Consulta 4 de Abril) GOOGLE BOOKS (2011) (http://books.google.com.pe/books?id=nmw4zEMcyhsC&pg=PT116&lpg=PT116&dq =roles+para+la+gestion+de+la+entrega+de+software&source=bl&ots=mMKB7Ri01&sig=TrnbOy6Vivl5unjgR30DSdw86do&hl=es&ei=HAarTcKbCMrAg Qfy6bnzBQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBMQ6AEwAA#v =onepage&q&f=false) (Consulta 4 de Abril) DIASDESANTOS (2011) Página oficial de publicaciones http://www.diazdesantos.es/libros/bon-jan-van-fundamentos-de-la-gestion-deservicios-de-ti-basada-en-itil-v3-C0311130600032.html#contenido ITIL (2011) Página Web sobre el uso de ITIL para un proyecto de IT. (http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_cambios/vision_gen eral_gestion_de_cambios/vision_general_gestion_de_cambios.php) (Consulta 5 de Abril) ITIL (2011) (http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion_TI /que_es_ITIL/que_es_ITIL.php) (Consulta 10 de Abril) ISO 20000(2011) Página Web en la cual se describe la Gestión de Servicios basados en ITIL. (http://www.overti.es/iso-20000/) (Consulta 17 de Abril) Proyecto de Tesis realizada por alumnos de la Universidad Peruana de Ciencias Aplicadas “Análisis y Diseño de la Arquitectura de Procesos de una micro financiera para los procesos de RRHH y MKT V3.0” UNED (2011) Página oficial de la Universidad Nacional de Educación a Distancia de España (http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node68.html ) 15 de Abril) (Consulta Tortoise SVN (2010) (http://subversion.tigris.org/)(Consulta 05 de Junio) 152 Anexos 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 10.12 10.13 10.14 10.15 10.16 10.17 10.18 10.19 10.20 10.21 10.22 ACTA.CONFORMIDAD.DESPLIEGUE USUARIOSXREPOSITORIO CERTIFICADO.DESPLIEGUE.DESARROLLO CIERRE.ADMINISTRATIVO.POR.FASE CONTRATO.GPP.APLICACION CRONOGRAMA.ACTIVIDADES DOCUMENTO.ACEPTACION.CLIENTE CONSOLIDADO.SERVICIOS PLAN.PROJECT ACTA.REUNION.PRUEBA.PILOTO CARACTERISTICAS.AMBIENTES.HABILITADOS CERTIFICADO.QA201101 ACTA.REUNION.GERENTES.EMPRESAS.VIRTUALES MANUAL.ACCESO.REPOSITORIO MANUAL.DE.INSTALACION MANUAL.DE.CONFIGURACION PROJECT.CHARTER MANUAL.CREACION.REPOSITORIO PROCESO.GPP.GRAFICO SOLICITUD.DE.APROBACION OBLIGACIONES.POR.PERFIL CERTIFICADO.QA201102
