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.
Roles
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)
-
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)
Requisitos Técnicos a incluir en el Pliego de Contratación
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.
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.
Contratación
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/exportació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 realizados 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 necesarias 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“.
Recursos
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
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.
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
Ejemplo
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:
Metodología
FAQs
Desarrollo Remoto
Si eres un desarrollador remoto (casa, oficina externa, etc), debes trabajar del siguiente modo:
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.
-
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.
Configurar VPN
Desarrollo desde EVA
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.
Qué SW hay instalado en la EVA Desarrolladores
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 la EVA Desarrolladores NO se VEN BIEN los COLORES
En “http://eva.um.es”, selecciona “Preferencias” (arriba a la izquierda) y configura “Colores de pantalla” a “32 bits”
Haz COPIAS de Seguridad de TUS DATOS en la EVA Desarrolladores
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.
Accesos desde VPN
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.
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:
Solicitar la autorización de acceso a red Sara.
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.
Si se usa VPN hay que configurar el perfil ICARUM en lugar de RPVUM.
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.
Trabajar con SQL y PL/SQL
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.
Trabajar con FundeWEB
Configurar Escritorio Remoto
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.
IP fija y VPN
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