Análisis y desarrollo de una licitación técnica en el sector de las TIC

TRABAJO FINAL DE GRADO TÍTULO: Análisis y Desarrollo de una Licitación Técnica en el Sector de las TIC TITULACIÓN: Grado en Ingeniería de Sistemas de Telecomunicación AUTOR: Francisco González Fontan DIRECTOR: Gabriel Montoro López SUPERVISOR: Tomás González Fontán ENTIDAD COLABORADORA: Alten FECHA DEPÓSITO: 05/02/2025 TÍTULO: Análisis y Desarrollo de una Licitación Técnica en el Sector de las TIC TITULACIÓN: Grado en Ingeniería de Sistemas de Telecomunicación AUTOR: Francisco González Fontan DIRECTOR: Gabriel Montoro López SUPERVISOR: Tomás González Fontán ENTIDAD COLABORADORA: Alten FECHA DEPÓSITO: 05/02/2025 Resumen El siguiente proyecto, se enmarca en la colaboración en la empresa de consultoría de ingeniería y tecnología, ALTEN, dentro del departamento de proyectos del sector público a nivel nacional.  El objetivo principal de este proyecto consiste en dos partes. La primera parte es teórica, donde se hace un estudio de las inversiones y tendencias que ha habido en España en el sector TIC en los últimos años, y posteriormente, también en una comunidad autónoma concreta. Se detalla también todo el proceso de licitación de un organismo público, desde el momento en que se publica el proyecto y los requerimientos específicos, hasta que se adjudica a un proveedor concreto. También se identifican los diferentes proyectos que se licitan en el sector público, a modo de clasificación.  Por último, se incluye en esta parte, muchos de los conceptos clave involucrados en la gestión de proyectos, para el posterior análisis de un proyecto licitado por un organismo público. La segunda parte, es práctica, donde se da una respuesta detallada a una licitación pública específica, formulando una propuesta técnica. Esta propuesta incluye el análisis de los requisitos del pliego, tanto técnicos como económicos.  Para la resolución de la propuesta técnica, se hace investigación de los roles involucrados en un proyecto de software, herramientas utilizadas, metodologías¿ para poder responder a todos los requisitos que se solicitan en el desglose de la puntuación de cada oferta que puedan realizar los distintos proveedores. Finalmente, se da una visión global acerca de la planificación, y adaptación de soluciones a la problemática de los organismos públicos. Además, se comenta los conocimientos aprendidos tanto el conocimiento teórico como prácticos, destacando las herramientas clave para abordar proyectos en consultoría tecnológica y gestión de proyectos. TITLE: Analysis and Development of a Technical Tender in the ICT Sector DEGREE: Bachelor's Degree in Telecommunications Systems Engineering AUTHOR: Francisco González Fontan DIRECTOR: Gabriel Montoro López SUPERVISOR: Tomás González Fontán COLLABORATING ENTITY: Alten SUBMISSION DATE: 05/02/2025 Abstract The following project is part of the collaboration in the engineering and technology consulting company, ALTEN, within the department of public sector projects at national level.  The main objective of this project consists of two parts. The first part is theoretical, where a study is made of the investments and trends in the ICT sector in Spain in recent years, and subsequently, also in a specific autonomous community. It also details the entire bidding process of a public body, from the moment the project is published and the specific requirements, until it is awarded to a specific supplier.  It also identifies the different projects that are tendered in the public sector, by way of classification.  Finally, this part includes many of the key concepts involved in project management, for the subsequent analysis of a project tendered by a public agency. The second part is practical, where a detailed response to a specific public bid is given, formulating a technical proposal. This proposal includes the analysis of the requirements of the specifications, both technical and economic.  For the resolution of the technical proposal, research is done on the roles involved in a software project, tools used, methodologies... to be able to respond to all the requirements that are requested in the breakdown of the score of each offer that can be made by the different suppliers. Finally, a global vision is given about the planning and adaptation of solutions to the problems of public organizations. In addition, the knowledge learned both theoretical and practical knowledge is discussed, highlighting the key tools to address projects in technology consulting and project management. Índice 1 INTRODUCCIÓN ..................................................................................................................... 1 1.1 Motivación ....................................................................................................................... 1 1.2 Objetivos ......................................................................................................................... 2 1.3 Estructura ........................................................................................................................ 2 2 CONTEXTO ............................................................................................................................. 3 3 PARTE 1TEÓRICA ................................................................................................................ 5 3.1 Licitación Pública ........................................................................................................... 5 3.1.1 Principios de una licitación ....................................................................................... 5 3.1.2 Tipos de licitaciones .................................................................................................. 6 3.1.3 Pliego ........................................................................................................................ 6 3.1.4 Unión Temporal de empresas .................................................................................. 8 3.1.5 Evaluación ................................................................................................................ 8 3.1.6 Ámbitos de negocio .................................................................................................. 8 3.1.7 CPV ........................................................................................................................... 9 3.2 Metodologías de Seguimientos de Proyectos ........................................................... 10 3.2.1 Waterfall .................................................................................................................. 10 3.2.2 Scrum ...................................................................................................................... 11 3.2.3 Agile ........................................................................................................................ 12 3.2.4 Kanban .................................................................................................................... 12 3.2.5 Scrumban ................................................................................................................ 12 3.2.6 Lean ........................................................................................................................ 13 3.2.7 Prince2 .................................................................................................................... 13 3.3 Herramientas para el desarrollo de software ............................................................ 14 3.3.1 Principales Herramientas ........................................................................................ 14 3.3.2 Integración continua................................................................................................ 15 3.4 Roles en los equipos de Software .............................................................................. 16 3.4.1 Analista ................................................................................................................... 16 Desarrolladores Full-stack ...................................................................................... 16 3.4.2 16 3.4.3 Diseñadores UI/UX ................................................................................................. 17 3.4.4 Ingenieros de control de calidad ............................................................................. 17 3.4.5 Arquitecto de software ............................................................................................ 17 3.4.6 Ingeniero DevOps ................................................................................................... 17 4 PARTE 2 – BUSINESS CASE ............................................................................................... 19 4.1 Tendencias de proyectos TIC ...................................................................................... 19 4.2 Organismos relevantes ................................................................................................ 20 4.2.1 Organismos relevantes en la Comunidad Valenciana ............................................ 20 4.2.2 Organismos públicos en Cataluña: ......................................................................... 20 4.3 Proveedores relevantes ............................................................................................... 21 4.4 Análisis de Datos .......................................................................................................... 21 4.4.1 Principales licitadores ............................................................................................. 22 4.4.2 Principales adjudicatarios ....................................................................................... 23 5 PARTE 3 – RESOLUCIÓN .................................................................................................... 25 5.1 Solución técnica ........................................................................................................... 26 5.1.1 Resumen ejecutivo ................................................................................................. 26 5.1.2 Solución técnica Propuesta .................................................................................... 27 5.1.3 Equipo de Trabajo ................................................................................................... 29 5.1.4 Modelo de relación, gestión, seguimiento y calidad ............................................... 30 5.1.5 Modelo de plan de devolución del servicio ............................................................. 30 5.2 Propuesta económica .................................................................................................. 31 6 ESTUDIO DE SOSTENIBILIDAD .......................................................................................... 32 7 CONCLUSIONES .................................................................................................................. 35 8 BIBLIOGRAFÍA ..................................................................................................................... 37 Índice de figuras Fig. 1 Portal de Licitaciones Públicas ........................................................................................... 5 Fig. 2 Código CPV ......................................................................................................................... 9 Fig. 3 Fases de la metodología Waterfall .................................................................................... 10 Fig. 4 Fases Metodología SCRUM.............................................................................................. 11 Fig. 5 Jira ..................................................................................................................................... 14 Fig. 6 Confluence ........................................................................................................................ 14 Fig. 7 SonarQube ........................................................................................................................ 14 Fig. 8 Selenium............................................................................................................................ 14 Fig. 9 AWS .................................................................................................................................. 15 Fig. 10 Docker ............................................................................................................................. 15 Fig. 11 Kubernetes ...................................................................................................................... 15 Fig. 12 Jenkins ............................................................................................................................ 15 Fig. 13 DevOps y CI/CD .............................................................................................................. 16 Fig. 14 Tendencias de proyectos TIC ......................................................................................... 20 Fig. 15 Inversión y número de adjudicaciones del CPV 480 ...................................................... 22 Fig. 16 Inversión y número de adjudicaciones del CPV 720 ...................................................... 22 Fig. 17 Principales licitadores ...................................................................................................... 22 Fig. 18 Principales adjudicadores ............................................................................................... 23 Fig. 19 Administración Abierta de Cataluña ................................................................................ 25 Fig. 20 Perfiles de la licitación ..................................................................................................... 31 Fig. 21 Desglose económico de la licitación ............................................................................... 31 Índice de tablas Tabla 1 Sueldos de los perfiles ................................................................................................... 31 Tabla 2 Coste total de los perfiles ............................................................................................... 32 Tabla 3 Beneficio de la licitiación ................................................................................................ 32 Glosario IT Information Technology CPV Common Procurement Vocabulary PCAP Pliego de Cláusulas Administrativas Particulares PPT Pliego de Prescripciones Técnicas IoT Internet of Things CI/CD Integración continua/Despliegue continuo DevOps Desarrollo y Operaciones AWS Amazon Web Services TIC Tecnologías de la Información y de la Comunicación API Application Programming Interface SW Software HW Hardware IA Inteligencia Artificial PARTE 1TEÓRICA 7 o Poder adjudicador: Entidad pública que publica la oferta de la licitación. Es quien establece las bases y las condiciones del concurso. Tiene la responsabilidad de adjudicar el contrato al mejor ofertante después de haber evaluado todos los puntos de todas las empresas participantes. o Objeto del contrato: En este punto, la tarea es describir con la mayor claridad la necesidad de la oferta y así, todas las empresas participantes entiendan aquello que se demanda. Normalmente, se incluye en este apartado el CPV para facilitar su identificación. o Presupuesto: Indica el gasto máximo del poder adjudicador. Esto sirve para que las empresas ofertantes tengan en todo momento la noción del gasto máximo y calcular los costos sin superar dicho límite. o Requisitos: Se detallan los diferentes requisitos técnicos como podrían ser la experiencia en el sector, nivel técnico, etc. Estos requisitos deben ser acordes al objeto del contrato. o Procedimiento y forma de adjudicación del contrato: En este apartado se define el tipo de procedimiento a seguir, es decir si será de tipo abierto, restringido, etc. o Plazo de ejecución o duración del contrato: Importante para planificar los trabajos a realizar. o Plazo de garantía: El objetivo es asegurar la calidad de los trabajos y dar la seguridad al poder adjudicador sobre la finalización del trabajo. o Criterios para la adjudicación: Se detallan los pesos de los diferentes puntos de la licitación como serían el coste, la calidad técnica, el plazo de ejecución entre otros. o Cláusulas especiales: Son aquellas cláusulas que se deben tener en cuenta en caso de que haya afectaciones medioambientales o sociales. o Modificaciones del contrato: Posibles alteraciones en el contrato siempre y cuando haya justificación. Como ejemplo podemos decir la ampliación de la ejecución debido a trabajos imprevistos en el inicio.  PPT (Pliego de prescripciones técnicas): Este documento incluye las especificaciones técnicas y es un documento esencial para cualquier licitación, ya que reúne todas las características y requisitos que se deben cumplir para poder realizar los diferentes trabajos. Si nos centramos en una licitación orientada a Software podríamos incluir los siguientes puntos [6]: o Niveles de calidad/servicio: Aquí, deben estar descritas las pruebas necesarias para cumplir con los estándares de calidad entre los que se puede incluir, por ejemplo, la velocidad de respuesta de la aplicación, la carga de usuarios, etc. o Arquitectura de Software: Se describe que tipo de lenguaje, framework, bases de datos, etc. También, se debe incluir la compatibilidad entre los diferentes sistemas operativos, dispositivos. Además, se debe describir la seguridad con la que se tratan los datos. o Procedimientos de evaluación de conformidad: Varias verificaciones se deberán llevar a cabo para garantizar el correcto funcionamiento del trabajo realizado. Entre ellas puede haber certificaciones que avalen este punto. o Plazos de garantías: Plazo en el cual el adjudicatario prestará servicios al adjudicador para reparar cualquier fallo de servicio, ya que es la empresa adjudicataria la responsable de la funcionalidad del servicio. o Servicios de mantenimiento: Se indica un plazo en el que la empresa debe atender la petición y otro plazo en el que se indica el tiempo hasta su solución. 8 PARTE 1TEÓRICA 3.1.4 Unión Temporal de empresas La unión temporal de empresas (UTE) es aquella donde dos o más empresas se asocian temporalmente para realizar una participación en una licitación donde si cada una trabajara por su cuenta no podrían realizar por falta de recursos. Es decir, que cada empresa ofrece diferentes servicios que cumplen parte de los requisitos de la licitación. Esto es realmente útil en proyectos de grandes dimensiones donde se requieran diferentes ámbitos de conocimiento como podría ser ingeniería, logística entre otros. Es por ello que al unirse diferentes empresas aporten ideas que se complementen con el conocimiento de las demás y esto lleve a cabo soluciones más creativas y más resolutivas. En caso de haber una UTE, se presentará como una sola entidad, pero debe quedar detallado que es la unión de varias empresas. Dentro de esta explicación debe haber las responsabilidades que cada empresa asumirá en el proyecto [7], [8] . 3.1.5 Evaluación El punto más crítico de la licitación podría ser esta, ya que es donde se evaluarán los distintos puntos de la licitación. Como mencionamos antes, en el PCAP se presenta el presupuesto de la licitación. Uno de los puntos que tiene mucho peso a la hora de evaluar una licitación es el precio que cada empresa tiene acordado. No obstante, para que esto no sea una oferta al mejor postor, se tienen en cuenta los diferentes criterios cualitativos. De esta manera, aparte del precio final, se evalúa:  Solución técnica: En este apartado, hay que reforzar las diferencias entre nuestro servicio ofrecido. Cuanta más innovadora, más eficaz sea nuestra solución, más atractiva será nuestra oferta. Es por ello, que la elección de la metodología, el proceso de control del servicio del producto a desarrollar y el conocimiento técnico tienen mucho peso en la evaluación final.  Equipo: La experiencia y la organización es clave para el desarrollo para la evaluación, por tanto, un buen equipo es importante para poder realizar las diferentes tareas.  Gestión y Seguimiento: El modelo de relación con el cliente a través de reuniones, canales de comunicación e informes de seguimiento, es clave para resolver los acuerdos. La gestión del tiempo y del equipo para garantizar el cumplimiento del objetivo. Obviamente, cada licitación es diferente y este es un ejemplo de los posibles puntos a tener en cuenta para evaluar la licitación. 3.1.6 Ámbitos de negocio Las inversiones públicas, están profundamente influenciadas por la política, ya que las decisiones sobre cómo, dónde y en qué invertir son tomadas por los gobiernos, que a su vez están guiados por objetivos políticos, ideologías y prioridades específicas.  Infraestructura: Como hemos visto en la carrera, cada vez más abunda el despliegue de nuevas redes de comunicaciones. Todo eso incluye obras civiles para obtener nuevos tramos de fibra óptica para conseguir mejor conectividad y también despliegue de redes 5G. Es por ello que los gobiernos hacen tanto ímpetu en invertir en la creación de nueva infraestructura para poder tener un alcance cada vez mayor y mejorar la cobertura.  Educación: En el ámbito de educación es muy frecuente nuevos proyectos de transformación digital. De esta manera, se abarcan varios de los temas en línea con herramientas donde los estudiantes aprenden mediante juegos o temario digital. Además, varios museos cuentan con realidad aumentada lo que ayuda a tener una inmersión mucho más profunda y facilitar el aprendizaje. PARTE 1TEÓRICA 9  Salud: En el área de la salud, las inversiones públicas juegan un papel muy importante. El uso de nuevas tecnologías en el área de la salud es cada vez mayor. Es por ello, que se hacen inversiones como por ejemplo en la gestión de datos. Actualmente, con Big Data se puede predecir enfermedades comunes y encontrar diferentes patrones entre los pacientes. Otra de las implementaciones que se están haciendo es la posibilidad de tener consultas a distancia, llamado Telemedicina. Estos son algunos de los muchos ejemplos donde se realizan inversiones públicas a nivel tecnológico.  Ciudades inteligentes: Cada vez más, la idea de tener una ciudad inteligente es cada vez más cercana, donde los servicios que usamos diariamente están siendo transformados hacia un diseño innovador. Hay numerosos ejemplos, pero podríamos mencionar la mejora en el transporte público mediante el desarrollo de aplicaciones capaces de rastrear en todo momento la ruta del autobús. Otro ejemplo reciente, sería el uso de la inteligencia artificial para el cuerpo de policía en China. Se trata de un robot esférico capaz de patrullar tanto en tierra como en agua y así ayudar a la detección de criminales y no poner en riesgo a los policías en barrios muy conflictivos [9].  Medio Ambiente: En el medio ambiente tenemos ámbitos de inversión muy interesantes. En Europa la incentivación por hacer uso de energía limpia es cada vez mayor y, por tanto, el gobierno invierte dinero para hacerlo posible. Por ejemplo, en Canarias, se está invirtiendo en energía geotérmica para poder transformar la energía de la tierra en energía eléctrica de manera totalmente limpia. Otra de las inversiones sería en el sector del reciclaje donde la automatización favorece al desperdicio de materiales [10]. 3.1.7 CPV Todas las licitaciones de la unión europea van identificadas con el código CPV que proviene del inglés y significa vocabulario común de contratación pública. Es una manera de clasificar las diferentes licitaciones según la prestación que se demanda y que se entienda dentro de la Unión Europea, ya que a veces las traducciones no son del todo precisas. Este código puede estar formado de hasta 9 dígitos en los cuales se dividen en grupos, clases y categorías. Para facilitar la búsqueda de licitaciones lo que se suele hacer es indicar el código de la licitación y después añadir una palabra clave para encontrarla en caso de que el código sea erróneo. Por ejemplo, el código CPV del sector TIC es el 72 pero si se quiere ajustar más la descripción se pondría el código 72200000-7 que se refiere a “Servicios de programación de software y consultoría” [11], [12]. Fig. 2 Código CPV 10 PARTE 1TEÓRICA 3.2 Metodologías de Seguimientos de Proyectos Las diferentes metodologías de seguimiento de proyectos se basan en utilizar herramientas y técnicas para guiar la planificación, ejecución y el control de un proyecto. De esta manera hay un seguimiento de principio a fin, para garantizar en todo momento el conocimiento del estado del proyecto. De esta manera, se asegura que el equipo trabaje de manera estructurada y así minimizar riesgos a la hora de la entrega del proyecto. Comentaremos los principales. 3.2.1 Waterfall La metodología Waterfall o en cascada, está basada en realizar las distintas fases del proyecto una detrás de otra y nunca a la vez. Aunque, su origen se basó en la construcción, ya que una casa sin suelo no se puede construir, se puede encontrar esta metodología en el desarrollo de software. Por lo general, su forma de visualizarse es en diagramas de flujo o diagramas de Gantt. Consta de diferentes fases las cuales se describen a continuación [13]: Como primera fase encontramos los requerimientos. Se detallan todos los objetivos del proyecto y, sobre todo, hay que tener previsión de las necesidades, puesto que cada fase depende de la anterior. Debe quedar claro los recursos necesarios, el personal de cada etapa, el cronograma de cada etapa, etc. La segunda fase es la de diseño. Concretamente, en el desarrollo de Software se debe dejar claro el lenguaje a utilizar, el entorno, el hardware principal y demás detalles clave. Cada miembro debe detallar en todo momento la tarea realizada para que los trabajadores de la siguiente etapa sepan desde donde partir. En la tercera fase, viene la etapa de implementación o desarrollo. En esta se llevan a cabo todas las diferentes tareas descritas en los requerimientos y en el diseño. En la cuarta fase, encontramos la etapa de pruebas. En este punto, se entrega el proyecto al departamento de calidad donde los verificadores buscaran cualquier error para reportarlo y que éste sea arreglado. Entrando en el tramo final, encontramos la quinta fase llamada despliegue. En este apartado se entrega al usuario el software final. Por último, la última fase una vez ya se haya entregado el producto final es la etapa de mantenimiento. En caso de que haya que actualizar alguna versión del software o de arreglar algún error no descubierto anteriormente. Fig. 3 Fases de la metodología Waterfall PARTE 1TEÓRICA 11 3.2.2 Scrum Scrum es una metodología que se basa en llevar a cabo entregas parciales y regulares del proyecto final. Normalmente, las entregas se presentan cada dos semanas donde deben cumplir unos ciertos objetivos para ir avanzando donde el valor de la entrega aumente con cada una y cada entrega se llama “Sprint”. Su principal objetivo es llevar una dinámica colaborativa de tal manera que sea un soporte para ayudar a los compañeros y obtener el mejor resultado posible. Esta práctica es muy útil en proyectos complejos donde se necesiten resultados rápidos donde la innovación y la productividad son clave. Por ello, es un sistema muy eficaz para adaptarse a los diferentes cambios de necesidades del cliente. Fig. 4 Fases Metodología SCRUM Consta de 4 roles que son [14], [15]:  Product Owner: quien hace de contacto entre cliente y equipo de desarrollo. Es el responsable de transmitir al equipo todas las necesidades del cliente.  Scrum Master: Responsable de garantizar que el equipo siga la metodología y solventar los diferentes obstáculos que surjan. Es el mentor del equipo  Equipo de desarrollo: Los diferentes integrantes que desarrollan las diferentes tareas para cumplir con las necesidades del proyecto. Son la pieza esencial para garantizar la funcionalidad del proyecto.  Roles auxiliares: Este rol no está bien bien dentro del equipo, sino que son colaboradores, pero no directamente asignadas al proyecto. Hay diferentes fases por las que pasa la metodología Scrum hasta su entrega final. La primera fase es la planificación donde recibe el nombre de Product Backlog . En esta fase, se establecen las tareas con mayor prioridad y la obtención de la información general del proyecto. Son el Product Owner junto a su equipo los encargados de listar lo indispensable para el proyecto. La segunda fase son los Sprints anteriormente nombrados. Definir el plazo de entrega de cada uno de los Sprints. El tiempo máximo de entrega es de un mes y es donde se va desarrollando el producto final con cada uno. 12 PARTE 1TEÓRICA Como tercera fase tenemos las “Daily Scrum” y los “Burn Down Chart”. En este apartado se refiere a las reuniones diarias para reportar información de cómo va avanzando el proyecto. Para poder hacer un seguimiento de las tareas que quedan se usa el Burn Down Chart que es una herramienta que permite visualizar el trabajo pendiente a comparación el tiempo restante para la entrega. La última fase es la “Review” y la “Retrsopsective”. Después de haber hecho la entrega, el equipo lo revisa y da una retrospectiva. En este punto, se detectan los errores y se establecen próximos objetivos para el siguiente Sprint. 3.2.3 Agile Como bien indica su nombre en inglés, es una metodología ágil puesto que así lo requiere el Proyecto. Está pensado para proyectos muy cambiantes. Viene de la mano de Scrum, ya que la filosofía es la misma: Colaborar entre todos. A diferencia de Scrum Agile no tiene tantas reglas fijadas ni tiene Roles definidos. Cada uno va aportando parte del trabajo y esto puede suponer un ambiente de trabajo más cooperativo y no depender de jerarquías rígidas. 3.2.4 Kanban Kanban viene del japonés y significa “Señal Visual”. Se basa en tarjetas donde se indica el estado de cada tarea y esta se irá moviendo por el tablero el cual son columnas con los diferentes estados de las tareas. El tablero se compone de:  Señales visuales como podrían ser post-it, pegatinas, etc.  Columnas: para indicar el estado de cada tarea. Normalmente, los procesos son: Backlog, en progreso, en testeo, y completado  Límites: Toda columna debe tener un límite de procesos en ese estado. Hay unas prácticas las cuales componen la metodología Kanban:  Visualización: Hacer que la tarea sea identificada rápidamente y saber su progreso. De esta manera, se pueden identificar cuellos de botella.  Limitar procesos: Establecer metas accesibles para no excederse con la cantidad de trabajo a realizar y también, ayudar a reducir la presión laboral.  Gestionar el flujo: el principal objetivo de este punto es minimizar los retrasos de las entregas y maximizar la productividad.  Quedarse con lo esencial: Eliminar aquello que resulta descartable y detectar los problemas y reajustar los procesos a causa de ello.  Mejorar colaborativamente: El equipo es el responsable de llevar a cabo todas las diferentes tareas. Por tanto, es indispensable colaborar para hacerlo posible. 3.2.5 Scrumban Como bien podemos deducir de su nombre, es una metodología que combina técnicas de Scrum y de Kanban. Este método es útil cuando una empresa desea migrar de Scrum a Kanban o viceversa y de esta manera el proceso es de fácil adaptación. En particular este método consta de los siguientes puntos:  Se mantiene el tablero de Kanban: Se usa el tablero Kanban, pero con la diferencia de que se añaden más etapas. Este detalle nos recuerda un poco a Scrumban con las entregas parciales en cada Sprint.  Flexibilidad con las entregas: En este caso, las entregas no son fijas como Scrum. Podríamos encontrar pequeñas diferencias en los plazos de entrega asegurando una mejor calidad. PARTE 1TEÓRICA 13  No hay jerarquías: Aquí, otra diferencia respecto Scrum. Todo el equipo tienes las mismas posibilidades de decisión en el proyecto, así el equipo no es liderado por nadie, sino que él mismo se autogestiona.  Límite de procesos: De nuevo, nos encontramos limitaciones de procesos para no crear cuellos de botellas y focalizarnos más en cada entrega. Como ventajas de esta metodología se encuentran:  Ahorro de tiempo: Como en la metodología Kanban no hay una cierta organización, de esta manera se pueden reducir las entregas obligadas en el sprint, como en el caso de Scrum, y que estas no aporten valor. También, se consigue que no se dupliquen trabajos al haber un seguimiento del proyecto.  Autonomía del equipo: A diferencia de Scrum, Scrumban no dispone de jerarquías lo que hace que el equipo sea más autónomo y dependa menos de roles superiores.  Entregas a largo plazo: Como los sprints en este caso no son necesarios y se busca un trabajo de flujo constante, el equipo se puede adaptar mejor a los posibles cambios del proyecto. Es por eso que, en las entregas a largo plazo, donde los cambios son muy frecuentes, son una buena opción para usar Scrumban. 3.2.6 Lean Esta metodología tiene como objetivo buscar la optimización de los diferentes procesos eliminando tareas cuyo valor sea nulo para el cliente. Se enfoca en conseguir el máximo valor con el mínimo de recursos. Los logros a conseguir son:  Eliminar actividades que no agregan valor: Como hemos comentado antes, intentar agregar valor el producto con algo innecesario hace que el valor no varíe y sea en vano.  Mejora continua: Se podría utilizar la técnica Kaizen, es decir, haciendo pequeñas mejoras continuas en el desarrollo.  Cambiar el enfoque de la empresa: Un buen ejemplo sería cambiar la técnica de producción. En vez de generar mucho producto y después intentar ofertar el producto, producir según las necesidades del cliente. 3.2.7 Prince2 Su nombre proviene del inglés “Projects in controlled Environments”, es decir, Proyectos en entornos controlados. Prince2 tiene 7 principios los cuales ayudan a prosperar y entregar los proyectos exitosamente:  Justificación comercial continua: El principal objetivo de este principio es encontrar el ROI (retorno de la inversión) del proyecto. Por tanto, hay que analizar si la cantidad de tiempo invertido y el coste es directamente proporcional con el beneficio a obtener.  Aprendizaje continuo: Este punto es compartido por la metodología anterior donde constantemente hay que ir aprendiendo de las experiencias para optimizar los diferentes procesos.  Funciones definidas: Al igual que Scrum, Prince2 también tiene muy definido las funciones que cada rol ha de realizar. Por tanto, si cada uno sabe lo que está haciendo y que hará el compañero, llegan al objetivo en colaboración.  Gestión por fases: En este apartado se definen las diferentes fases de cada uno de los proyectos y posteriormente, una revisión antes de pasar a la siguiente etapa.  Requisitos de referencia: Al iniciar el proyecto los costos, los plazos y los riesgos son definidos. De ese modo, los altos cargos delegan las responsabilidades a los diferentes encargados y así, solo actuar en casos de emergencia.  Orientado a la calidad: Comparación continua entre el proyecto a entregar y los objetivos establecidos. Así, poder garantizar un producto de calidad y detectar cualquier incoherencia y arreglarlo antes de su entrega.  Enfoque personalizado: En este sentido, cada proyecto se puede amoldar a cambios durante el desarrollo del producto. 14 PARTE 1TEÓRICA 3.3 Herramientas para el desarrollo de software 3.3.1 Principales Herramientas - Github: Plataforma de desarrollo donde se pueden almacenar los diferentes proyectos de código y un equipo puede acceder a él y trabajar al mismo tiempo en ese proyecto. Al estar el código guardado en una nube, se puede acceder a cualquiera de las anteriores versiones y poder a trabajar en ella si es necesario. Otra de las opciones que se integra en la plataforma es la de poder crear diferentes “branches” (ramas) donde los colaboradores pueden trabajar de forma aislada y posteriormente realizar un “pull request”, que vendría a ser una solicitud para integrarlos en la rama principal después de una revisión del código. Por otra parte, es una herramienta muy útil, ya que los diferentes usuarios pueden explorar códigos abiertos de otros usuarios y ver otros proyectos. De esta manera, existe la posibilidad de buscar errores comunes que tienen los usuarios y encontrar una solución a ellos [16]. - Jira: Es una herramienta para gestionar proyectos y seguimiento de errores. Su uso es muy extendido entre las empresas debido a su permitida personalización. Por tanto, se puede adaptar dependiendo del tipo de proyecto que se requiera y modificar la visualización al gusto. También, es una manera fácil de visualizar el progreso de los proyectos y encontrar posibles cuellos de botella. Además, ofrece la opción de integrarse con otros programas como podría ser Git que lo hemos mencionado anteriormente [17]. - Confluence: En este caso, nos encontramos con otra herramienta la cual fue desarrollada por la misma empresa que Jira, es decir, Atlassian. El objetivo es bastante similar, tiene como propósito la organización de los proyectos con equipos. A diferencia de Jira que está más enfocado a la ejecución y al seguimiento de los proyectos, Confluence se centra en la elaboración de la documentación previa a los proyectos. Existe la posibilidad de vincular los problemas creados en Jira y así poseer, de manera estructurada, las diferentes documentaciones y poder visualizarlo rápidamente[18]. - Test: Una vez tenemos las herramientas para poder desarrollar el proyecto, es turno de las herramientas de testeo para verificar que los procesos de desarrollo son correctos o existen problemáticas. o SonarQube: Esta plataforma permite el análisis del código y posteriormente indica los errores de la misma. La adaptabilidad de esta plataforma es muy amplia, ya que admite más de 19 lenguajes de programación, obviamente incluyendo Java, C, C++, etc. A parte de analizar los errores, se centra en la evaluación de la arquitectura y diseño. Todo esto se ve reflejado con métricas y gráficas donde se puede observar la calidad del código[19]. o Selenium: Esta otra herramienta sigue la misma filosofía que la anterior. Es decir, analizar el código y ver si es correcto o no. No obstante, hay ciertas diferencias. En primer lugar, la diferencia más significativa es que sirve para analizar códigos de aplicaciones web y es compatible con Chrome, Firefox, etc. En segundo lugar, dispone de un proceso de automatización de código, como por ejemplo autocompletar parte del código y también automatizar test complejos que ocupan una gran parte de tiempo[20]. Fig. 5 Jira Fig. 6 Confluence Fig. 7 SonarQube Fig. 8 Selenium PARTE 1TEÓRICA 15 - AWS: En este caso, nos encontramos con una herramienta diferente. Amazon Web Services, es un servidor donde se almacena la información en la nube y esta es capaz de procesarla. Además, tiene varios servicios como podrían ser programación, bases de datos, inteligencia artificial y un largo etcétera. ¿Qué ventaja tiene sobre las demás? Como ventaja encontramos la posibilidad de prescindir de ordenadores potentes y costosos a cambio de un pago por uso del servicio[21]. - Docker: Siguiendo la filosofía de AWS, Docker también funcionaría como una especie de máquina virtual, aunque mejor optimizada. En este caso se crea un “contenedor”, el cual es capaz de funcionar en cualquier sistema operativo que tenga instalado el programa Docker. De esta manera, nos podemos evitar el problema, muy frecuente, de que funcione en un terminal, pero no en otro. A su vez, proporciona una gran eficiencia dado que solo tienen lo estrictamente necesario para hacer funcionar la aplicación[22]. - Kubernetes: Este caso, es muy parecido a Docker, ya que también funciona con contenedores, aunque con algunas diferencias. La primera, sería que Kubernetes trabaja con varios contenedores a la vez, de manera que puede repartir la carga de trabajo según necesite cada uno. Y la segunda, sería que en caso de que un contenedor fallara, Kubernetes lo reemplaza por uno nuevo si es que no se puede reiniciar el anterior. Por lo que no necesita ninguna intervención manual [23] [24]. - Jenkins: Jenkins introduce una nueva manera de compilar y testear Software de forma continua. Funciona de la siguiente manera: o Primero: el equipo que se encargue del desarrollo de la aplicación hace un commit, es decir, sube el código a la plataforma. o Segundo: Jenkins revisa cada cierto tiempo el repositorio para detectar cambios de código. Cada vez que haya cambios, Jenkins compila el código y prueba si da fallos. En caso afirmativo, notifica al equipo o Por último: de nuevo, se prepara para analizar frecuentemente los cambios en el repositorio [25]. 3.3.2 Integración continua La integración continua es aquella práctica la cual automatiza el desarrollo de código. El principal objetivo es la prevención de errores y facilitar el proceso. Lo que hace es básicamente es tras subir en un repositorio una nueva versión, se detectan los errores y se notifican para que no se fusione con las versiones anteriores. Con herramientas donde los desarrolladores pueden ir subiendo distintas versiones y estas habiendo comprobado que el código funciona, la posibilidad de agilizar el proceso aumenta considerablemente. Antes hemos explicado una herramienta que incorpora esta práctica que es Jenkins. Aprovechando que también hemos explicado GitHub, existe otra herramienta llamada GitLab que tiene incorporada esta práctica. Fig. 9 AWS Fig. 10 Docker Fig. 11 Kubernetes Fig. 12 Jenkins 16 PARTE 1TEÓRICA Fig. 13 DevOps y CI/CD 3.4 Roles en los equipos de Software En el desarrollo de software, se identifican diferentes roles dentro de un equipo. A continuación, se detallan las características de los diferentes roles y las responsabilidades de cada uno [26], [27], [28], [29]. 3.4.1 Analista - Funcional: Es el encargado de transmitir al equipo toda la información necesaria sobre los requerimientos del cliente. Como debe tener altos conocimientos de programación, normalmente, este tipo de perfil suele haber sido programador en sus inicios. Las principales funciones que desarrolla este tipo de perfil son: o Gestión de los cambios: Durante el desarrollo del proyecto, es la figura que gestiona las diferentes variaciones en todo el ciclo del proyecto. o Documentación: Todo lo establecido con el cliente debe quedar registrado en la documentación, incluido las instrucciones del software a utilizar. o Boceto/Demo: Para que los programadores entiendan bien como debe ser gráficamente el software a desarrollar, el analista funcional realiza una demostración visual de cómo se espera que sea. - Programador: Responsable de entender todas las directrices que le comanda el Analista Funcional. Debe tener conocimientos en el lenguaje de programación correspondiente al proyecto en cuestión. Generalmente, en un proyecto de software se usa los lenguajes como Java, Python y C++ entre otros. También, deberá hacer pruebas para comprobar que el código sea funcional y correcto que posteriormente, los ingenieros de QA realizarán con mayor profundidad. En programación existen dos tipos de desarrollo de código: programación Front-End y Back-End. o Front End: Aquella programación que tiene que ver con lo visual, es decir como el usuario final va a ver la versión final. o Back End: Todo lo relacionado con la programación de las distintas funciones lógicas, base de datos, seguridad, etc. 3.4.2 Desarrolladores Full-stack El desarrollador Full-stack es aquel que tiene tanto conocimientos del desarrollo de Front-End como de Back-End. De modo que es capaz de desarrollar la aplicación de principio a fin. Es una ventaja ya que una persona puede entender los dos entornos y podría facilitar el control de las diferentes versiones sin depender de terceros. Esta posición es muy demandada, ya que este perfil puede programar tanto el desarrollo Front-End como Back-End. PARTE 2 – BUSINESS CASE 23 Como era de esperar, los dos sectores punteros han sido la salud y la tecnología. Aunque la mayor cantidad de licitaciones ha sido por parte del sector TIC, el sector de la salud ha sido el sector que más ha invertido en los proyectos. Esto se debe en parte, por la alta demanda de la transformación digital y también en las inversiones de mejora de las infraestructuras de los servicios sanitarios. Ambos sectores son muy importantes para la economía de un país. Anteriormente, explicamos los ámbitos de negocio de las inversiones públicas y se comenta que últimamente, en el sector TIC las inversiones están en tendencia alcista. En mi caso, al tener la parte técnica de la carrera, es favorable que el área TIC esté demandando muchas licitaciones, puesto que es un área donde se requieren conocimientos técnicos como hemos podido ver en otras secciones y varios de ellos se han visto en la carrera. Por tanto, es una oportunidad para aplicar la teoría en un área más empresarial, pero sin dejar de lado el lado técnico. 4.4.2 Principales adjudicatarios Por el contrario, en este apartado lo veremos del lado empresarial. Es decir, se representan las empresas las cuales han ganado la mayor cantidad de licitaciones. Fig. 18 Principales adjudicadores Se observa que la empresa con mayores adjudicaciones ganadas es Telefónica, con 34 licitaciones y un valor de más de 100 millones de euros. Para ser exactos el valor fue de 100.693.282,24 €. De nuevo, predomina el sector TIC en las licitaciones de Valencia. Le sigue la empresa Oracle Ibérica, una consultora especializada en el área de la informática. En este caso, el valor baja considerablemente, pero no por ello de menor importancia, puesto que las cifras ascienden a 14.406.558,60 €. No obstante, aunque veamos que Telefónica es un gigante a comparación a los demás, vemos que sigue habiendo diferentes empresas que también tienen papel en las licitaciones. Por lo cual, al existir cierta competencia entre ellas, es un buen indicador para poder competir con ellas. 24 PARTE 2 – BUSINESS CASE PARTE 3 – RESOLUCIÓN 25 5 PARTE 3 – RESOLUCIÓN El concurso público que se va a analizar es para el organismo AOC (Administració Oberta de Catalunya). El objetivo principal de AOC es de a poco impulsar la transformación digital para facilitar la interacción entre ciudadano y administración pública. De esta manera conseguir tener un sistema más eficaz, ya que cualquier ciudadano podrá hacer sus trámites digitalmente desde su casa[31]. Fig. 19 Administración Abierta de Cataluña En concreto, se va a analizar el expediente con identificador AOC-2025-7 que tiene como título: “DESENVOLUPAMENT EVOLUTIU, MANTENIMENT CORRECTIU I SUPORT DE TERCER NIVELL DELS APLICATIUS PSIS I SIGNADOR”. Como primer paso, hay que revisar la documentación en el portal de contratación pública de Cataluña (enlace: https://contractaciopublica.cat/ca/detall-publicacio/d7332022-1f7c-41ff-a172a206c7b7d924/300289293). Como hemos visto en el apartado 3.1.3, la documentación de un pliego administrativo donde nos indica las características propias del concurso público y requisitos para poder dar respuesta al pliego. Como los pliegos suelen ser de una longitud extensa (85 páginas el pliego administrativo y 41 páginas el pliego técnico), vamos a resumir los puntos más críticos de la licitación:  Concurso: Desarrollo evolutivo, mantenimiento correctivo i soporte de tercer nivel de los aplicativos PSIS i SIGNADOR.  Objeto del contrato: o Tareas de desarrollo evolutivo sobre la arquitectura actual de cada aplicativo, en tecnología JAVA, tanto para PSIS como para el SIGNADOR. Estas tareas estarán enfocadas tanto en la implementación de nuevas funcionalidades, actualizaciones sobre las existentes, como en la mejora del rendimiento de ambos servicios. o Mantenimiento correctivo de PSIS y el SIGNADOR. o Ofrecer soporte técnico especializado en cuanto a la detección, diagnóstico y resolución de incidencias técnicas en cualquiera de los dos servicios.  Expediente: AOC-2025-7  CPV: 72212217-3 Servicios de desarrollo de software de proceso de transacciones  Organismo adjudicador: Consorci Administració Oberta de Catalunya (Consorci AOC)  Presupuesto Base de licitación: 327.255,50 €  Duración del contrato: 12 meses + 3 prórrogas de 12 meses  Puntuación: o Criterios económicos: 51 puntos  Jefe de Proyecto: 16 puntos  Ingeniero de Software: 15 puntos  Desarrollador Java/J2EE: 10 puntos 26 PARTE 3 – RESOLUCIÓN  Ingeniero de Kubernetes DEVOPS: 10 puntos o Sujetos a juicio de valor: 49 puntos  Solución técnica propuesta: 16 puntos  Solución técnica propuesta por el desarrollo de nuevas funcionalidades.  Solución técnica propuesta por la prestación del servicio de mantenimiento correctivo i soporte avanzado.  Mecanismos de control de la calidad que se establecerán.  Metodología de trabajo.  Equipo de trabajo: 30 puntos  Equipo de trabajo detallando su currículum. Se valorará que la experiencia de cada perfil sea superior a la mínima requerida en el apartado de adscripción de medios (apartado G4).  Experiencia en firma electrónica del ingeniero de software: Se valorará que el ingeniero de software tenga experiencia en firma electrónica de al menos 5 años.  Experiencia en firma electrónica de los desarrolladores: Se valorará que los desarrolladores Java/J2EE tengan experiencia en firma electrónica como mínimo de 1 año.  Modelo de relación, gestión, seguimiento y calidad: 1 punto  Descripción del modelo de relación, gestión i seguimiento (reuniones, canales de comunicación, seguimiento de tareas, informes de seguimiento, etc.).  Descripción del modelo de gestión de calidad propuesto (indicadores propuestos para evaluar la calidad de los trabajos y medidas para garantizar el cumplimiento del acuerdo de nivel de servicio).  Modelo de plan de devolución del servicio: 2 puntos Consideraciones: Para proceder a hacer una propuesta de solución técnica, se sobrentiende que la empresa que ejecutaría el proyecto, en caso de ser adjudicataria, cumpliría la solvencia requerida tanto económica como técnica. Además, deberá estar en posesión de unos certificados ISOs que se piden como requisitos mínimos. La presentación de los perfiles que se presentan como parte de la oferta técnica no se corresponden a la realidad, y simplemente se ponen como ejemplos. 5.1 Solución técnica 5.1.1 Resumen ejecutivo El objetivo de esta licitación como bien dice el título es dar soporte a las aplicaciones PSIS y SIGNADOR:  PSIS (Plataforma de Servicios de Identidad y Firma): es un servicio el cual permite la creación y validación de sellos y firmas electrónicas. Está presente en todas las administraciones públicas catalanas para asegurar la veracidad y tratado de estos documentos. PARTE 3 – RESOLUCIÓN 27  El SIGNADOR es otra herramienta de generación de firmas electrónicas basada en certificados digitales. Está integrada en las páginas web de las administraciones públicas catalanas. Por tanto, los principales objetivos del proyecto es la realización de tareas de desarrollo evolutivo sobre la arquitectura de las dos aplicaciones. En ambos casos, la tecnología a usar va a ser en lenguaje Java. A parte de las tareas de mantenimiento, hay nuevas funciones que deberán ser implementadas, la mejora del rendimiento en ambas aplicaciones y también soporte técnico para resolver cualquier incidencia desde el 1 de enero de 2025 hasta el 31 de diciembre de 2025. Para ello, se tienen que hacer pruebas de testeo exhaustivas y soluciones que sean compatibles con la normativa de la Unión Europea El periodo de este contrato dura todo 2025, es decir desde el 1 de enero de 2025 hasta el 31 de diciembre de 2025. No obstante, puede ser prorrogable hasta 4 años adicionales. El presupuesto inicial de la licitación es de 327.255,50€ hasta 1.636.277,50€ en caso de obtener la prórroga. 5.1.2 Solución técnica Propuesta 5.1.2.1 Solución técnica propuesta para el desarrollo de nuevas funcionalidades. Actualmente, el servicio está en lenguaje XML y en la misma licitación nos indica que el cliente espera poder usar el lenguaje JSON. Por tanto, una solución sería añadir una nueva API para que la aplicación sea utilizable con JSON, pero mantener la anterior API para que los integradores de XML no deban solicitar otra licitación para que se les cambie toda la integración a JSON. Esto se debe a que mayoritariamente los organismos públicos no disponen de desarrolladores propios. A parte, el uso de dos diferentes APIs tiene varias ventajas: - Actualizaciones: Cada vez que haya una nueva actualización podemos proceder a actualizar solo el API necesaria sin afectar en nada a la otra. Esto nos facilita posibles conflictos de código que puedan aparecer. - Programación: Al tener el código separado en dos APIs separadas, hace que la programación de cada una sea más organizada y limpia al tener cada una con su respectivo lenguaje. El desarrollador agradece que la estructura sea más fácil de visualizar y entender si tiene el código bien redactado. - Seguridad: Introducción de diferentes protocolos de seguridad en cada API. Esto nos protege en el caso de que exista un problema de seguridad en una API, al tener diferentes protocolos con la otra API esa problemática no se reproduzca en la otra - Optimización: Como JSON es más moderno y eficaz, al contrario que XML que tiene un procesamiento más lento, optimizar cada API por separado es mucho más eficiente. - Migración: Al tener dos APIs diferentes, los clientes pueden ir migrando de XML a JSON de manera gradual y al mismo tiempo seguir usando XML en la transición. Otro punto a parte es la introducción de métricas de rendimiento para mejorar la optimización y verificar que el código tiene una mejor fluidez. Este punto, nos ayuda a la detección de posibles cuellos de botella y poder ver en qué parte del código se puede realizar una optimización. 28 PARTE 3 – RESOLUCIÓN Dado que también se nos solicita que el control de versiones esté almacenado en GitHub, el uso de GitLab para la integración continua y de esta manera automatizar flujos de trabajo. La función de GitLab hace que el código pase por un proceso de testeo antes de ser lanzado a producción. La detección temprana de errores es posible gracias a esta herramienta. De esta manera, el tiempo de desarrollo se reduce dado que se ahorra tiempo en la detección de errores. Para la seguridad de la aplicación ya que indican que se debe usar AWS, se añade un firewall llamado AWS WAF, que nos ayuda a protegernos de posibles ciberataques. Cada petición pasa por el firewall y si detecta algún parámetro que estaba definido en sus reglas, este lo bloquea. Hacer uso de este firewall es útil para el bloqueo de ataques en las bases de datos SQL y no permite de inyección de scripts maliciosos en la aplicación. Adicionalmente, restringe el acceso de bots y de ciertos usuarios, de esta manera mantenemos protegidos los datos sensibles. 5.1.2.2 Solución técnica propuesta para la prestación del servicio de mantenimiento correctivo y soporte avanzado. Para el mantenimiento, se propone el uso de Jira para la revisión de tickets. Es una manera ágil de detectar las diferentes problemáticas y de proponer una solución rápidamente. Cada vez que haya una incidencia se crea un ticket donde se explica con pruebas la problemática y lo que realmente se esperaba. Una vez, el equipo de desarrollo haya solventado el problema se realizan pruebas para verificar totalmente que no se sigue reproduciendo el error. Acabada la verificación, se procede a cerrar el ticket. Todos los tickets se clasifican en orden de prioridades para poder solventar los más urgentes en el menor tiempo posible. De este modo, logramos interrumpir lo menos posible en los diferentes servicios. Los tickets que llevan la etiqueta de “críticos” son los de mayor importancia, por ejemplo, que el inicio de sesión en la aplicación no funcionase. Si este fuera el caso, ningún usuario podría hacer uso de la aplicación. Por tanto, la necesidad de resolver la incidencia es muy prioritaria. 5.1.2.3 Mecanismos de control de calidad que se establecerán Dado que el lenguaje de código para el desarrollo es JAVA, necesitamos una herramienta para asegurar el control de calidad y minimizar la cantidad de errores: Para ello, se utiliza la herramienta Selenium y aparte hacer uso de una de las funciones muy utilizadas son el autocompletado de código y, por tanto, facilitar su ejecución. De este modo, verificamos que el comportamiento de la aplicación sea el correcto. 5.1.2.4 Metodología de trabajo. La metodología a realizar es Scrum, por tanto, se realizan las dailys diarias para el informe del estado. El jefe de proyectos será quien sea el Scrum master y se encargará de que todos los que forman parte del equipo sigan la dinámica. Tanto los ingenieros como el programador serán los encargados de realizar los trabajos y también de seguir bien la metodología entregando los sprints cada dos semanas para ver la evolución del proyecto. PARTE 3 – RESOLUCIÓN 29 5.1.3 Equipo de Trabajo Los perfiles profesionales para este proyecto son los siguientes: • Jefe de proyectos (1 persona):  Experiencia mínima de 5 años en funciones de gestión de equipos responsables del desarrollo, testeo, mantenimiento correctivo y evolutivo de aplicaciones Java, y en especial de aplicaciones críticas en entornos productivos.  Experiencia mínima de 5 años liderando equipos de al menos 4 integrantes. Las tareas que desempeñará este puesto son: - Gestión económica: Gestionar bien el presupuesto, asignando los recursos necesarios. Cada mes entregar al cliente un formulario con cada uno de los trabajadores del proyecto, indicando la dedicación de cada uno en este para poder obtener el salario cada mes. - Gestión de tareas: Encargado de repartir las tareas entre los diferentes roles del equipo, teniendo en cuenta la carga de trabajo de cada una. - Requisitos cliente: Responsable de cumplir y entender todos los requerimientos del cliente. Ese punto es un poco complicado porque le cliente a veces no cede ni acepta cambios, aunque estos vayan a mejor. - Organización: Definir las tareas que debe hacer cada uno de los integrantes. - Informes: Redactar el estado del proyecto para poder notificarlo al cliente - Cumplimiento de la calidad: Asegurar la calidad acordada con el cliente antes de entregar el proyecto. - Comunicación: Entregar toda la información de manera clara y concisa a todo el equipo. • Ingeniero de software (1 persona):  Experiencia mínima de 5 años como responsable tecnológico de aplicaciones Java/J2EE y bases de datos relacionales SQL.  Experiencia mínima de 3 años en aplicaciones java desplegadas en la nube AWS e integración con servicios AWS. Las principales tareas de este perfil son: - Base de datos: Encargado de la implementación de la base de datos en formato SQL que sean compatibles con el servicio de AWS. - Diseño: Desarrollar una arquitectura robusta, que ofrezca seguridad y sea eficaz - Código: Revisar que en el código no se encuentren errores y en caso afirmativo, proceder a repararlos. • Desarrollador Java/J2EE (3 personas):  Experiencia mínima de 3 años en tecnologías Java y J2EE.  Experiencia en aplicaciones java desplegadas en la nube AWS e integración con servicios AWS. Las principales tareas de este perfil son: - Desarrollo: implementar la aplicación usando lenguaje Java. - Depuración: Depurar el código en busca de errores y poder encontrar una solución - Seguridad: implementar protocolos de seguridad para hacer robusta la aplicación y protegerla ante ataques maliciosos. - Escalabilidad: Debe asegurar que la aplicación sea escalable dado el alto número de peticiones que se van a realizar y poder gestionarlas sin empeorar el rendimiento 30 PARTE 3 – RESOLUCIÓN • Ingeniero Kubernetes y DevOps (1 persona):  Experiencia mínima de 3 años en Kubernetes.  Experiencia mínima de 3 años como ingeniero DevOps. Las principales tareas de este perfil son: - Integración CI: Para facilitar el desarrollo de verificación, es importante tener una integración continua para automatizar procesos. - Contenedores: Gestionar los diferentes contenedores de Kubernetes - Optimización: Para que el rendimiento sea mejor y la aplicación sea más fluida, se necesita usar técnicas de optimización como gestionar el uso de memoria 5.1.4 Modelo de relación, gestión, seguimiento y calidad Para poder relacionarnos con el cliente y que sepa en todo momento que tareas se hacen, procedemos a organizar una reunión diaria (daily). A parte de cumplir con la condición de seguir una metodología ágil. Sirve, básicamente, para mantener al cliente informado y repasar algún tema prioritario. De esta manera, todo el equipo está presente en la reunión y en tan solo 15 minutos de son capaces de explicar lo que se hizo ayer, lo que se va a hacer hoy y si hay algún problema para las entregas de los diferentes Sprints. Aprovechando que debemos usar Jira, se puede hacer un seguimiento añadiendo documentación en JIRA para tenerlo todo más organizado. 5.1.5 Modelo de plan de devolución del servicio 5.1.5.1 Informes En la fase de planificación se adecua al nuevo adjudicatario al plan de transición. En este punto se deben llevar a cabo las siguientes acciones: - Informe de situación actual: Se explica el estado del proyecto, los incidentes abiertos y sus respectivos estados, evolutivos pendientes con su estado, - Equipo: Como está formado el equipo y las principales funciones. 5.1.5.2 Devolución del servicio Durante un periodo de 4 semanas, es nuestra responsabilidad la fase de devolución del servicio. Tres semanas serán dedicadas a la transferencia de conocimientos y una para dar soporte ante inconvenientes. Por tanto, en esta fase se realizarán las siguientes funciones: - Código: Se debe entregar todo el código que se haya desarrollado hasta la fecha incluyendo comentarios para facilitar el entendimiento del mismo. - Documentación: Toda documentación que se haya generado a lo largo del servicio también deberá ser entregada. - Sesiones formativas: 4 sesiones formativas de traspaso funcional y 4 sesiones adicionales de traspaso técnico. PARTE 3 – RESOLUCIÓN 31 5.2 Propuesta económica En el pliego se nos indica en un cuadro que sea adjunta a continuación, el desglose de precio por hora de cada perfil profesional y la cuantía total de horas que trabajará en el proyecto. En el segundo cuadro, se presenta el desglose económico ponderado además del importe del IVA, se tienen en cuenta gastos varios, como por ejemplo los de infraestructura o licencias, y tiene incluido un margen del 10% por beneficio industrial. Fig. 20 Perfiles de la licitación Fig. 21 Desglose económico de la licitación Con este cuadro podemos proceder a hacer cálculos y buscar los sueldos de los diferentes perfiles y sacar también un beneficio de ello. Lo primero, es buscar un rango de sueldos que puede tener cada perfil profesional e ir haciendo un presupuesto con esos números. Después de tener en cuenta los años de experiencia y los diferentes requisitos del proyecto, llegamos a la conclusión de que los sueldos para cada perfil son los siguientes: Tabla 1 Sueldos de los perfiles No obstante, no son los únicos costes que tenemos que tener en cuenta. Para ello, tenemos que añadir la Seguridad Social a cada sueldo que, aunque el trabajador no vea reflejado ese número, para la empresa representa un 33% del sueldo bruto de cada trabajador. Otro coste que tenemos que añadir es el de los diferentes elementos de oficina que va a utilizar cada trabajador. De modo simplificado, se generaliza un coste de 1.000€ por cada uno. Por tanto, una vez teniendo todos los costes, nos quedaría una tabla de la siguiente manera: Jefe de Proyecto (JP) 1 60,000.00 € Ingeniero de Software (ISw) 1 50,000.00 € Ing. Kubernetes y Devops (IKub) 1 50,000.00 € Desarrollador (Dev) 3 40,000.00 € 32 PARTE 3 – RESOLUCIÓN Perfil Nº Sueldo Bruto Sueldo + SS Elementos de Oficina Coste Coste por hora Coste Ponderado JP 1 60,000 € 79,800 € 1,000.0 € 80,800 € 45.9 € 6,886.40 € ISw 1 50,000 € 66,500 € 1,000.0 € 67,500 € 38.4 € 67,500.00 € IKub 1 50,000 € 66,500 € 1,000.0 € 67,500 € 38.4 € 11,505.70 € Dev 3 40,000 € 53,200 € 1,000.0 € 54,200 € 30.8 € 153,977.30 € 239,869.30 € Tabla 2 Coste total de los perfiles Para ver el beneficio del ejercicio, analizamos el importe máximo que se nos permite y aplicando un margen de un 10%, nos quedaría de la siguiente manera. Perfil Dedicación (horas) Precio hora máxima Precio hora venta Importe Licitación Importe Alten Jefe de Proyecto 150 63.25 € 51.01 € 9,487.50 € 7,651.52 € Ingeniero de Software 1760 56.93 € 42.61 € 100,196.80 € 75,000.00 € Ing. Kubernetes y Devops 300 50.60 € 42.61 € 15,180.00 € 12,784.09 € Desarrollador 5000 40.48 € 34.22 € 202,390.70 € 171,085.86 € 327,255.00 € 266,521.46 € Tabla 3 Beneficio de la licitación A modo resumen, tenemos un coste total de 239.869.30€ y vendemos nuestro servicio por un valor total de 265.521,46€, demostrando de esta manera el beneficio del 18.6% respecto a los 327.255,00€ del techo de la licitación. Bibliografía 39 [29] «Los roles en los equipos de desarrollo de software | StarTechUP». Accedido: 30 de enero de 2025. [En línea]. Disponible en: https://www.startechup.com/es/blog/roles-insoftware-development-teams/ [30] «Software architect · Funciones | Michael Page». Accedido: 5 de enero de 2025. [En línea]. Disponible en: https://www.michaelpage.es/advice/profesi%C3%B3n/tecnolog%C3%ADa/perfil-dearquitecto-de-software [31] «AOC Consortium - Open Administration of Catalonia». Accedido: 5 de enero de 2025. [En línea]. Disponible en: https://www.aoc.cat/en/