Guía para Gestionar Proyectos Externos

Los desarrolladores externos C/S y Fundeweb que usen “terminal remoto”, deben sustituirlo por la EVA "Desarrolladores". Para cualquier incidencia o problema con el servicio EVA, contactar con Juan Antonio (jaga@um.es) o Juanlu (juanlu@um.es).

Esta guía es aplicable tanto a la externalización de proyectos como de personal.

Si accedes a esta guía porque un desarrollador de tu equipo que trabajaba en el edificio ATICA, ahora lo tiene que hacer desde su empresa, pasa directamente a la sección “Recursos”.

Un proyecto externo será aquel que se desarrolla total o parcialmente desde las instalaciones del proveedor, en principio, utilizando los mismos recursos que usan nuestros equipos de desarrollo (entornos de Desarrollo y Test, Wiki, etc, accediendo mediante VPN).

Si el proyecto se externaliza completamente es conveniente aplicar el apartado sobre “Contratación“. En el caso en que solo se externalicen algunos o todos los desarrolladores, se aplicarán los apartados necesarios para dotar de los recursos necesarios que permitan el desarrollo a distancia.

El apartado Recursos de esta guía es aplicable también al personal (externo o no) q pueda haber asignado a cualquier proyecto, y que esté trabajando desde fuera de la UM, de modo que necesita acceder a los mismos recursos que cualquier integrante de un proyecto externo.

• DESARROLLO Juan José González Sánchez
• MNCS Juan Luis Serradilla Amarilla

Para cada proyecto externo debería haber un rol de Coordinador de ATICA, ya que el Jefe de Proyecto puede ser externo (si la externalización es completa). El Coordinador será el que ponga en marcha el proyecto, solicitando todos los recursos necesarios:

• Hacer encuesta de conocimientos previos a los integrantes del grupo de desarrollo externo, para detectar necesidades formativas sobre las tecnologías q usa FDW, así como MEDEA y Jira.
• Reunión de Lanzamiento del Proyecto, donde debe estar MNCS (rol MNCS)
• Solicitar, SOLO SI PROCEDE, direcciones de correo @um.es para los integrantes del grupo de desarrollo externo, usando la app https://altacorreo.um.es/. Si no procede crear direcciones de correo @um.es, habrá que habilitar otra alternativa.
• Pedir a Telemática que les asigne ips de la VPN de Desarrollo a cada uno de los emails creado anteriormente (rol TELEMATICA)
• Crear Lista de distribución con https://listas.um.es/
• Pedir a SISTEMAS alta de la nueva aplicación y entornos de Desarrollo y Test (inicialmente NO pedir Producción) (rol SISTEMAS)
• Pedir a la responsable de JIRA dar de alta en Jira el proyecto (rol JIRA)
• Pedir a MNCS configurar acceso a Jenkins para el grupo de desarrollo externos (rol JENKINS)
• Pedir a MNCS la Formación que sea necesaria en FDW2 (rol FDW)
• Pedir a MNCS la Formación que haga falta en MEDEA (rol MEDEA)
• Pedir a MNCS acceso a la wiki del Programador, secciones FDW y MEDEA (rol WIKI)

• 1. La UMU definirá el 100% de los requisitos tecnológicos de la arquitectura de la aplicación y se encargará de validar y ejecuar el 100% de su puesta en producción.
  • La empresa es responsable al 100% de la configuración previa al paso a producción, incluyendo llamadas a otros servicios de la UMU, así como la carga inical de datos que la app necesita para funcionar.
• 2. La empresa adjudicataria utilizará la infraestructura TIC de la UMU: framework JEE FundeWEB, BD Oracle, servidor JEE Weblogic, gestor documental Alfresco, BPM Intalio, plataforma de Administración Electrónica ELECTRA, Gestión de Incidencias/Proyectos JIRA, etc.
• 3. La empresa adjudicataria usará el entorno de desarrollo y las herramientas definidas por la UMU. Ejemplo Framework de Desarrollo JEE de la UMU (FUNDEWEB): Eclipse, Maven, Java EE, JSF Primefaces, Seam y CDI, EJB, JPA, Hibernate, BD Oracle 11g y 12c, servidor JEE Weblogic, SSO CAS, ServicioGente, ServicioAlfrescoCMIS, Intalio BPM, ServiciosELECTRA, ServicioBIRTUM, informes BIRT, Documentación de Usuario y Ayuda de la Aplicación con Docuwiki, etc.
  • Si surge cualquier error o problema derivado del uso de cualquier de las tecnologías propuestas y/o proporcionadas por la UMU, la empresa adjudicataria tendrá que resolverlo igualmente.
• 4. La UMU liderará la toma de requisitos, para asegurar el control del conocimiento del negocio, así como una relación estrecha con los responsables funcionales, para lo cual asignará un jefe de proyecto UMU (Product Owner), que creará un documento de visión (o historias de usuario). La UMU debe verificar y validar cualquier trabajo hecho por la empresa adjudicataria.
  • La UMU podrá definir en el pliego (documento de visión) cuando debe estar terminado el proyecto (plazos), sobre todo cuando hay plazos administrativos asociados a los procesos que se están automatizando.
  • La UMU supervisará y aprobará el documento de requisitos refinado, que será elaborado por la empresa adjudicataria. El jefe de proyecto UMU asistirá a todas las reuniones de toma de requisitos.
  • Los requisitos no funcionales se definirán en el pliego, dentro del documento de visión que elabora la UMU, y además se incluirán en el apartado de niveles de servicio (SLA), por ejemplo, máximo de usuarios concurrentes, tiempo máximo de respuesta, accesibilidad, usabilidad, seguridad, etc.
• 5. La UMU también supervisará y aprobará el análisis y el diseño, asegurando que se utiliza la arquitectura, metodología y framework de la UMU (esto se hará durante todo el ciclo de vida del proyecto).
• 6. La empresa adjudicataria aplicará la Metodología de Desarrollo de la UMU (MEDEA): documento de visión, documento de requisitos (historias de usuario) y casos de uso (para pantallas complejas), análisis y diseño (diagramas UML, E/R y de actividad, estos últimos para flujos complejos), aplicar SCRUM en la fase de desarrollo (definición de sprints), integración continua con JENKINS, uso de JIRA para Gestión del Proyecto y de las Incidencias, de modo que la UMU pueda ver en JIRA la evolución del proyecto.
• 7. Definición de un sistema de niveles de servicio (SLA) y penalizaciones, que establezca el tiempo máximo para resolver defectos/incidencias/petciones/consultas/etc, así como el coste económico (penalizaciones) de los incumplimientos para la empresa adjudicataria.
  • Habrá penalizaciones de nivel máximo si no se cumplen los plazos de entrega.
  • Para definir los SLA se tendrán en cuenta el Impacto (cómo afecta a los procesos y/o número de usuarios) y la Urgencia para solucionarlo (tiempo definido conforme a las prioridades del negocio).
  • Impacto: en cuanto a indisonibilidad de la aplicación, por ejemplo, grave (100% de indisponibilidad de la aplicación), importante (100% de indisponibilidad de un módulo clave de la aplicación), leve (100% de indisponibilidad de un módulo de la aplicación que no está en uso). En cuanto al nº de usuarios afectados, por ejemplo, grave (100% usuarios), importante (25%), leve (10%).
  • Urgencia: definir tabla de prioridades, por ejemplo, inferior a 4h (prioridad 1), inferior a 24h (prioridad 2) e inferior a 4 días (prioridad 3).
  • Por ejemplo, un SLA podría ser “Un error de importancia grave de la aplicación (que suponga la parada del servicio, o pérdida de datos, etc) se resolverá en un máximo de 4h (prioridad 1)”, y la penalización podría ser “El inclumplimiento del SLA por error grave de la aplicación tendrá una penalización de un 2% del importe del pliego”.
  • Se deben definir tb SLAs relacionados con la carga y/o concurrencia, cuando esta sea importante, en cuyo caso se debe incluir en los requisitos, por ejemplo “la aplicación garantizará el acceso simultáneo de 100 usuarios con tiempo de respuesta inferior a 4 segundos.
  • Se incluirán SLAs y penalizaciones para el resto de requisitos no funcionales: accesibilidad, usabilidad, seguridad, etc.
  • Si la empresa no implementa alguno de los requisitos validado por ella (aunque no estén en el pliego), sufrirá una penalización económica equivalente a la importancia del requisito sobre el total, de modo que puede ser interesante crear una tabla (validada por la empresa), durante la toma de requisitos, que establezca este porcentaje, de modo que existirán requisitos bloqueantes (100%) q impidan el funcionamiento de la aplicación, y otros que afectarán solo a funcionalidades opcionales.
• 8. La empresa adjudicataria aplicará el Control de Calidad definido por la UMU, que incluye Tests unitarios, de integración, funcionales y de carga:
  • Proporcionando los casos de prueba, así como el código y los resultados de todos los tests.
  • Los tests unitarios deben cubrir al menos un 60% del código.
  • Los tests de carga deben de hacerse con la carga máxima definida en los requisitos no funcionales, con tiempos de respuesta que se ajusten a los citados requisitos, simulando una carga continuada en el tiempo. Además, los tests de carga se completarán subiendo por encima de la citada carga máxima, simulando posibles picos.
  • La empresa adjudicataria se encargará de implementar el 100% de los tests.
  • La UMU no pondrá la aplicación en producción si no incluyen todos los tests necesarios, con evidencias de que han sido superados con éxito, y en caso de retrasos se aplicará las penalizaciones que correspondan a los SLAs que se hayan definido.
• 9. La empresa adjudicataria suministrará toda la Documentación Técnica siguiendo los criterios de legibilidad y mantenibilidad: documento de requisitos (el doc de visión lo hace la UMU y se incluye en el pliego), casos de uso, modelo de clases, modelo E/R, javadoc (si hay partes BPM con BPMN), casos de prueba incluyendo código y resultados de todos los tests, etc).
  • La empresa adjudicataria se encargará de redactar el 100% de la documentación.
  • La UMU no pondrá la aplicación en producción si no incluye toda la documentación técnica, y aplicará las penalizaciones que correspondan a los SLAs que se hayan definido.
• 10. El código de la aplicación será fácilmente entendible y mantenible, con comentarios (JavaDoc).
  • ¿Cómo medir esto (Jenkins)? Cuantificar el % mínimo de comentarios, y además hacer revisión de código aleatoria. Javadoc: podemos desarrollar una guía con los mínimos, por ejemplo las interfaces y métodos importantes (explicando lo que se condisera un método importante)
  • La empresa adjudicataria se encargará de implementar el 100% del código de la aplicación.
  • La UMU no pondrá la aplicación en producción si considera que el código no es entendible ni mantenible, y aplicará las penalizaciones que correspondan a los SLAs que se hayan definido.
  • Claridad del código: aplicar “clean code”, que podemos detallar para que no haya malas interpretaciones, además de de exigir que se sigan las convenciones de nomenclatura de código.
  • Usar FindBugs (Eclipse y Jenkins): Indicar que se debe usar y minimizar lo que aparezca.
  • El uso de cualquier plantilla o componente proporcionado por la UMU (como la Plantilla de Fundeweb), no exime a la empresa adjudicataria de revisar y corregir cualquier defecto en el código, aunque haya sido originado por el uso de la citada plantilla.
• 11. La depuración de errores será fácil, mediante el uso adecuado del LOG.
  • ¿Cómo medir esto (Jenkins)? Cuantificar el % mínimo de cada tipo de LOG, y además hacer revisión de código aleatoria.
  • LOG: detallar recomendaciones, como mínimo es añadir en la entrada y salida de los métodos importantes, a parte de en todas las excepciones.
  • La UMU no pondrá la aplicación en producción si considera que la depuración de errores es compleja, y aplicará las penalizaciones que correspondan a los SLAs que se hayan definido.
  • Coherencia entre la base de datos, la aplicación web y sistemas externos: la emp garantizar la integridad de los datos y el correcto mapeo de las tablas en los POJO web.
• 12. Importancia de que el equipo de trabajo tenga experiencia (senior, mínimo 3 años) en todos los roles y tecnologías necesarias: jefe de proyecto, analista y programadores.
  • La UMU debe autorizar cualquier movilidad en el equipo.
  • La movilidad de los equipos (autorizada por la UMU) supondrá una penalización para la empresa adjudicataria, que estará definida en los SLAs.
• 13. La empresa adjudicataria se encargará del 100% del Desarrollo, Pruebas (unitarias, de integración, funcionales y de carga), documentación técnica y de usuario, así como del mantenimiento correctivo.
• 14. Requisitos de seguridad: ISO-27001, ENS, LOPD, CCN-CERT, etc.
• 15. Debemos *distinguir* los pliegos de mantenimiento de los de nuevos desarrollos: en el caso de nuevos desarrollos serán aplicables todos los puntos, pero en el caso de mantenimientos hay que definir cuáles sí y cuáles no, o si hace falta algún punto adicional.

Para la licitación de un proyecto externo, nos puede resultar muy útil la ”Guía ALIAL de Buenas Prácticas para la Licitación de Desarrollos Libres por parte de las Administraciones Locales”, donde a partir de pg 49 (apartados 2.10 a 2.25), describe cuestiones clave para cualquier proyecto de SW, pero especialmente para un proyecto externo, como por ejemplo:

• Garantia: 1 años al menos
• Especificaciones funcionales, técnicas y legales
  • Funcionales: casos de uso habituales, describir datos principales y acciones de E/S de la app, análisis funcional básico, reglas básicas de usabilidad e imagen corporativa, funcionalidades relacionadas con la seguridad y protección de datos que debe cumplir la aplicación, interacción con terceras aplicaciones …
  • Técnicas: arquitectura, plataformas en las que debe funcionar la app (en nuestro caso FDW), lenguaje de desarrollo y herramientas (FDW incluye BD Oracle y Servidor Weblogic), condiciones de actualización de la app, integración con otros servicios de la UM, tratamiento de datos (formatos, codificación, importación/expo­r­tación de datos, presentación e impresión de datos, intercambio de datos con otras apps),
  • Legales: Licencias (del software, documentación, gráficos y diseño/artwork y herramientas utilizadas para el desarrollo del software), consideraciones legales sobre la LOPD.
• Soporte y Mantenimiento: condiciones, formación al CAU, etc.
• Plan de Trabajo: la empresa debe definir claramente las funcionalidades que incorporarán las distintas versiones del programa, las fechas previstas de publicación y estabilización de cada una de ellas, así como la persona de contacto de cada una de las unidades que componen La Hoja de Ruta (Roadmap) del proyecto.
  • El Roadmap del proyecto se considera un documento vivo. Debe estar permanentemente actualizado en cualquier instante a lo largo del desarrollo del proyecto y ser accesible públicamente, con el fin de que terceros conozcan con detalle su evolución. La finalización de cada hito lleva asociado la comprobación y certificación correspondiente por parte del cliente.
  • Como parte de la fase de diseño, la empresa adjudicataria, de acuerdo con la Dirección de Proyecto, deberá presentar un plan de trabajo completo definido a nivel de tarea, con su correspondiente asignación de recursos, cumpliendo todos los requisitos establecido en el contrato que se firmará tras la adjudicación del pliego. Este plan se resume en:
    • Plan de descomposición de Trabajos a nivel de tareas (EDT/WBS) definitivo.
    • Diagrama de Gantt a nivel de tareas y con asignación de recursos.
    • Tabla resumen con la descripción de las tareas y asignación de horas de trabajo a cada una.
  • Será responsabilidad de la Dirección del Proyecto coordinar los trabajos rea­lizados por el personal de la empresa externa y verificar su nivel de calidad, registrando y entregando al responsable de la UM los informes, guías y memorias de verificaciones realizadas, además del software y otros entregables.
• Entregables: Como mínimo, a la finalización de cada hito se generará un entregable. Los entregables serán presentados en el pliego mediante una tabla simple. Cada uno de ellos debe ser descrito, con el fin de conocer su objetivo y alcance. El procedimiento de entrega y verificación del entregable debe describirse en la sección de gestión del proyecto correspondiente al pliego, así como su responsable. De esta manera, este apartado no generará duda alguna y se tenderá a homogeneizar.
• Equipo de Trabajo:
  • Roles del Equipo de Trabajo: Dirección (y Coordinación del Proyecto si la adjudicataria dirige el proyecto), Gestión de proyecto, Dirección Técnica, Documentación, Diseño Gráfico y Usabilidad, Implantación, Soporte y Mantenimiento, y Calidad.
  • Formación y Experiencia del Equipo de Trabajo: En la propia oferta se recomienda definir dos tablas en las que se visualicen fácilmente las características principales de cada uno de los miembros del equipo que forma parte de la oferta.
• Recursos: Herramientas de desarrollo de software. Herramientas de diseño gráfico, Herramientas de generación de documentación, Herramientas de gestión, soporte y mantenimiento, Infraestructura necesaria y herramientas complementarias nece­sarias para el funcionamiento de la aplicación. En nuestro caso serán las herramientas que propone MEDEA, sobre todo FDW.
• Gestión del Proyecto: Gobernanza y organigrama del proyecto, Canales y gestión de la comunicación entre cada uno de los actores (Lista de correo, Slack y Jira), Control y seguimiento del progreso del proyecto (Jira y Agile, según indica MEDEA). Gestión de conflictos, Metodología de gestión (MEDEA con SCRUM).
• Calidad y Seguridad
  • Tests de calidad, rendimiento, seguridad, interoperabilidad con apps UM si fuese necesario, E/S e integridad de datos.
  • Usabilidad
  • Tests funcionales y técnicos
  • Evidencias relacionadas con la calidad interna: Análisis estático de código, Pruebas unitarias automatizadas y documentadas, Análisis de cobertura de las pruebas (Jenkins)
  • Evidencias relacionadas con la calidad perceptible o funcional: Pruebas de integración, Pruebas de aceptación
  • Será requisito describir en la oferta las medidas de seguridad a aplicar para asegurar la confidencialidad de los datos que se manejen conforme establece la LOPD, así como el Plan de Contingencia para casos de desastre.
• Solvencia Económica y Técnica (de la empresa externa)
  • La empresa deberá demostrar su solvencia económica/financiera.
  • La empresa debe describir en este apartado su experiencia previa en proyectos similares o directamente relacionados con alguno de sus apartados.

Para más información leer la ”Guía ALIAL de Buenas Prácticas para la Licitación de Desarrollos Libres por parte de las Administraciones Locales“.

En principio, vamos a utilizar los mismos recursos que usan nuestros equipos de desarrollo (entornos de desarrollo y tests, Wiki, etc, mediante VPN), aunque será el coordinador/jefe del proyecto el que solicite el acceso a los recursos necesarios, según las necesidades del proyecto, y el trabajo concreto que vaya a hacer cada desarrollador externo:

El coordinador/jefe del proyecto solicitará el acceso a los recursos contactando con Josefa Hernández Oller (jholler@um.es, extensión 3334).

• ACCESOS BÁSICOS
  • Correo: será necesaria una cuenta para poder acceder a todos los recursos, esta cuenta será @um.es si la persona es de la UM, y se habilitará otra alternativa en caso contrario.
  • VPN: para entrar desde el exterior es necesario acceso a la VPN de Desarrollo, que será la que les dé acceso a los entornos de desarrollo y test, SVN, Wiki, etc. En el PC del desarrollador hay 2 ficheros de configuración de FundeWEB (CAS y WEBLOGIC), donde está el nombre de host q tiene en ATICA (normalmente micorreo.atica.um.es), de modo que ahora tiene que poner el nombre de host asignado tras conectarse a la VPN. Ver Guía del Responsable Seguridad para Acceso de Desarrolladores externos.
  • JIRA: llevar mucho cuidado para que la empresa externa no vea el resto de proyectos de ÁTICA
• FORMACIÓN: será necesario comprobar la formación acreditada mediante un seminario/curso de FDW y MEDEA, para lo que es necesario que tengan los accesos anteriores, de modo que puedan acceder a una máquina EVA de prácticas, a la Wiki, etc.
  • FundeWEB
  • Oracle
  • MEDEA
• ENTORNO DE DESARROLLO LOCAL: necesitarán instalarse FDW, y acceso a un repositorio SVN, además de JIRA.
  • WIKI: acceso a las secciones FundeWEB, MEDEA y DBconnector, de la Wiki del Programador, de modo que no vean la Wiki del Programador Completa (crear una página de entrada para ellos con esos 3 enlaces)
  • FundeWEB
  • SVN
  • JIRA: para la empresa externa no vea el resto de proyectos de ÁTICA, habría que crear un grupo aparte para ellos.
  • LISTA CORREO: estaría bien crear una lista de correo para comunicarse con todos los integrantes del grupo externo
• SERVIDORES DE DESARROLLO Y TEST: en este caso tendrán los accesos habituales de un grupo de desarrollo nuestro.
  • SVN
  • ORACLE
  • WEBLOGIC
  • JENKINS

El primer proyecto ha sido “Gestión de grupos de innovación docente” (GGID), para el que Pacom, de forma excepcional, ha gestionado la petición de recursos necesarios:

• MNCS Lanzamiento de un proyecto externo https://jira.um.es/jira/browse/MDA-407
• COORDINADOR Encuesta conocimientos previos https://jira.um.es/jira/browse/MDA-401
• COORDINADOR Dar de alta los correos externos del personal de Metaenlace https://jira.um.es/jira/browse/MDA-400 La aplicación para dar de alta los correos es https://altacorreo.um.es, y requiere autorización (Pacom la tiene, como jefe de sección), además requiere firma electrónica (de Pacom en este caso).
• COORDINADOR Lista de distribución https://jira.um.es/jira/browse/MDA-405
• TELEMÁTICA Alta de usuarios en el VPN de desarrollo https://jira.um.es/jira/browse/TLMS-2381 https://jira.um.es/jira/browse/MDA-403
• SISTEMAS Alta de la nueva aplicación GGID https://jira.um.es/jira/browse/MIDWEB-1088
• JIRA Dar de alta en Jira el proyecto https://jira.um.es/jira/browse/MDA-404
• MNCS Configurar acceso a Jenkins para grupos de desarrollo externos https://jira.um.es/jira/browse/FDWH-63
• MNCS Formación en FDW2 para personal de Metaenlace https://jira.um.es/jira/browse/FRM-230
• MNCS Formación en MEDEA para personal de Metaenlace https://jira.um.es/jira/browse/FRM-229
• MNCS Dar accesos a la wiki https://jira.um.es/jira/browse/MDA-402

La Metodología a aplicar será MEDEA, para lo que hemos creado una ”Guía rápida para explicar MEDEA en 2 horas“.

Si eres un desarrollador remoto (casa, oficina externa, etc), debes trabajar del siguiente modo:

1. Usando la VPN de Desarrollo e instalando el sw necesario en el PC de tu casa o de la oficina externa, de modo que tendrás acceso a los entornos de Desarrollo y Test, pero NO al de Producción.
2. Si lo anterior no fuese viable, usando el servicio EVA "Desarroladores".
3. Si ninguna de las opciones anteriores fuese factible, usando el escritorio remoto (requiere la autorización de tu Jefe de Proyecto y del Coordinador de la Sección de Proyectos).

En cualquier caso, la situación de “desarrollador remoto” debes de comunicársela a tu Jefe de Proyecto, al Coordinador de la Sección de Proyectos y a MNCS, de modo que podamos proporcionarte los recursos necesarios para llevar a cabo tu trabajo de forma remota.

Una vez que en Redes te hayan dado de alta en la VPN de Desarrollo, tienes que instalarte el cliente de VPN siguiendo las instrucciones elaboradas por Redes https://www.um.es/atica/rpv/, y si tienes algún problema al configurar o ejecutar dicho cliente VPN, tendrás que poner un Jira a Redes notificando la incidencia.

Ver Guía del Responsable Seguridad para Acceso de Desarrolladores externos

Existe una EVA llamada “Desarrolladores” en https://eva.um.es/. Si no la ves, es normal, ya que el acceso a esta EVA está restringido solo a determinados usuarios. Si actualmente estás usando “escritorio remoto” contacta con MNCS (mncs@um.es, x-7604) para conocer los requisitos y condiciones de uso de la “EVA para Desarrolladores”.

La mejor opción para desarrollar desde fuera de ATICA es usar la VPN de Desarrollo, e instalarte el SW necesario en local, de modo que la EVA “Desarrolladores” solo es para el caso en que la opción VPN te impida realizar tu trabajo.

La EVA “Desarrolladores” requiere del visto bueno de tu jefe de proyecto y de MNCS.

La EVA Desarrolladores funciona con el cliente Novell, de modo que debes tener acceso a todo el SW de tu cuenta Novell.

NO lleva preinstalado FundeWEB, de modo que tienes que seguir las instrucciones de Instalación de FundeWEB

Además, en local (C:) está instalado:

• Astah
• Jmeter
• Soap UI
• Pencil
• Postman (pruebas REST)

En “http://eva.um.es”, selecciona “Preferencias” (arriba a la izquierda) y configura “Colores de pantalla” a “32 bits”

Tu máquina virtual (VM) del servicio EVA Desarrolladores, puede requerir operaciones de mantenimiento por parte de los gestores del servicio, que supongan la destrucción de su contenido

Para hacer copia de seguridad de tu máquina virtual (VM), puedes usar un pendrive: antes de conectar a tu EVA, pincha el pendrive a tu PC, y una vez que haya sido reconocido por el PC, te conectas a la EVA, y deberías verlo.

También puedes usar UMUbox, para lo cual tienes que instalar el cliente, siguiendo las instrucciones del Servicio UMUbox http://www.um.es/atica/umubox, enlace “Clientes de sincronización para UMUbox”. Si usas UMUbox para hacer la copia de seguridad, revisa los posibles errores.

Y otra opción para hacer la copia de seguridad es usar el unidad H: de Novell, aunque es bastante lenta, y puede dar problemas a la hora de copiar muchos ficheros, como es el caso de proyectos FundeWEB.

Desde la VPN tienes acceso tanto al entorno de Desarrollo (BD y servidores de aplicaciones), como al de Test, pero NO al de Producción, y tampoco hay acceso a red Sara.

Existe una VPN para el grupo EADMIN con acceso a red Sara, ya que son ellos (EADMIN) los que desarrollan los servicios de administración electrónica que requieren acceso a la citada red.

El acceso a red Sara desde fuera de la UMU solo se autorizará a aquellas personas que lo necesiten, con el visto bueno de su jefe de proyecto, del Coordinador de Proyectos, del responsable de Seguridad, y del responsable de dicho servicio en la UMU (Alfsonso Caja de REDES). En el jira https://jira.um.es/jira/browse/REDES-8143 están explicados los pasos necesarios:

1. Solicitar la autorización de acceso a red Sara.
2. Es necesaria una IP “fija” de la UMU, bien mediante VPN o usando EVA Desarrolladores, y solicitar a REDES (Alfonso Caja) el acceso a red Sara para dicha IP.
3. Si se usa VPN hay que configurar el perfil ICARUM en lugar de RPVUM.
4. Si se usa EVA Desarrolladores hay que tomar nota de la MAC de la VM asignada, de modo que si la VM se destruye y se vuelve a crear, hay que solicitar a Soporte EVA (Jaga) que le vuelva a asignar la MAC original (ya que la IP “fija” que autorizará Redes estará asociada a dicha MAC). Además se usará el nombre DNS de la VM para identificarla, en lugar de la IP.

Para trabajar con SQL y PL/SQL, la mejor opción es Oracle SQLdeveloper (no requiere licencia y es gratuito). Lo puedes descargar desde la página de Herramientas de MEDEA (https://wiki.um.es/wikis/programador/doku.php?id=mda:herramientas), y lo tienes tanto para Win como para Linux.

Si una vez instalado SQLdeveloper en tu PC, te sigue dando error al conectar a la BD de Desarrollo, es posible q haya algún problema de acceso con la IP q te asigna la VPN (antes de arrancar SQLdeveloper, conéctate a la VPN).

Para trabajar con Forms puedes usar la EVA "Desarrolladores", que incluye Novell.

Como alternativa 100% local, desde Soporte (antonio.soriano@um.es - 7145) propone copiar el SW necesario en un CD (cliente Oracle, Forms y aplicación C/S hecha en Forms, SIN Toad (usa Oracle SQL Developer)), y replicarlo en un directorio del equipo cliente, de modo que dicho directorio sea mapeado como “unidad I:”. Además habría que ejecutar un fichero ”.reg“ proporcionado por Soporte para configurar adecuadamente el registro.

Para trabajar con FundeWEB necesitas en el equipo cliente Windows-7 y seguir las instrucciones de instalación que hay en la Wiki de FundeWEB.

En el equipo cliente hay que Configurar el CAS (local) y la IP de escucha en Weblogic con la IP dada por la VPN

Si la opción VPN+FundeWEB no es viable en tu caso, puedes solicitar usar la EVA "Desarrolladores".

Si temporalmente necesitas acceder a un PC remoto, lee esta guía para Configurar el Escritorio Remoto.

OJO, la solución Escritorio Remoto tiene graves problemas de seguridad, de modo que debe ser usada solo en caso de urgencia, mientras se configura el puesto de trabajo en la empresa externa, por lo que debe tener el visto bueno del jefe y/o coordinador del proyecto por parte de ATICA.

Desde Telemática nos dicen que NO dan IPs fijas por VPN, de modo que se ha reservado un rango de IPs para desarrolladores remotos, por lo que el control de acceso a los servicios necesarios debe hacerse sobre dicho rango de IPs (por ejemplo el CAS está configurado con dicho rango de IPs).

Si el equipo cliente usa FundeWEB hay que Configurar el CAS (local) y la IP de escucha en Weblogic con la IP dada por la VPN