2.1.- PRÁCTICAS DE DESARROLLO

No es el objetivo de esta guía valorar las distintas metodologías utilizadas para la gestión del desarrollo de aplicaciones, ya que existen múltiples factores que pueden hacer recomendable el uso de una u otra. Lo que sí recogemos es una lista de buenas prácticas, recomendaciones y reglas de obligatorio cumplimiento.

• La metodología a utilizar deberá aportar el proyecto la agilidad necesaria para incluir iterativamente los requisitos transmitidos por los interlocutores del IASS, y aportará las herramientas necesarias para la validación de esos requisitos (maquetas o prototipos). Se aporta a modo de referencia la metodología SCRUM.
• El desarrollo deberá ser, en la medida de lo posible, orientado a tests para asegurar la calidad del software y su robustez ante cambios.
• Se deberá trabajar con el sistema de control de versiones corporativo para todos aquellos desarrollos donde la propiedad intelectual del producto sea del IASS. (en el caso de modificaciones a adaptaciones de los fuentes sujeto a licencia abierta habría que considerarlo aparte).
• No hay que olvidar que el software es un producto vivo. Es muy importante que cuando se desarrolle una aplicación se tenga en cuenta en su mantenimiento no sólo la evolución funcional del mismo sino también su evolución técnica, para que se vaya adecuando a la evolución de la tecnología.
• Las aplicaciones que necesiten validación de usuarios deberán implementar de manera obligatoria la integración con el CAS corporativo, el cual proveerá autenticación con LDAP (Directorio Activo) corporativo, así como mediante certificado electrónico (aceptando al menos el Certificado de Empleado Público de Camerfirma, el certificado de personal física de la FNMT y el DNI Electrónico). 
• Usabilidad y accesibilidad. Tenemos que trabajar en que nuestra aplicación facilite su uso por parte de ciudadanos o de compañeros, por lo que en cuanto a los principios de usabilidad y accesibilidad, tanto para aplicaciones web publicadas en la Intranet como en Internet, aplica lo recogido en la Norma vigente publicada a través del Observatorio de Accesibilidad Web del Ministerio de Hacienda y Función Pública. En el caso de aplicaciones de la Intranet, sin visibilidad hacia la ciudadanía, en caso de imposibilidad técnica de cumplimiento por funcionalidades específicas de la aplicación, la empresa lo deberá justificar al responsable técnico de la aplicación y éste valorará si la aplicación se publica con este déficit de accesibilidad o revisará con los responsables funciones si procede modificar esa funcionalidad.

3.1.- LA APLICACIÓN

3.1.1.- DESARROLLOS A MEDIDA

Cuando el IASS contrata el desarrollo de una aplicación, o la adaptación a sus necesidades de una aplicación ya desarrollada, necesita adquirir a su vez la posibilidad de mantenerla y evolucionarla. Para esto es fundamental disponer del código fuente de la misma y los scripts necesarios para su generación. La única manera de asegurarnos de que tenemos todo lo necesario para generar la aplicación, es precisamente poniéndonos manos a la obra y generándola, no instalando una versión que ya envíe construida la empresa. Por lo tanto el medio de entrega de las aplicaciones deberá ser el siguiente:

• La empresa o el técnico del IASS responsable del proyecto deberán subir la aplicación (código fuente, librerías, makefiles, ficheros POM o scripts de generación de contenedores, entorno Vagrant, etc) al respositorio de software corporativo, en la actualidad soportado por GIT.
• El técnico del IASS responsable del proyecto realizará la generación de la aplicación a instalar. El resultado de esta generación serán los entregables a enviar al STSI para su instalación en preproducción y en producción.
• La configuración del servidor o servidores que alojen a la misma deberán ir definidos por código haciendo uso de scripts de Puppet o Ansible.
• El personal de Informática tiene acceso al GIT corporativo. Aparte, los demás usuarios que necesiten tener cuenta propia o acceder a algún repositorio pueden solicitar el acceso.

3.1.2.- PAQUETES DE SOFTWARE SUJETOS A LICENCIA PROPIETARIA

Si estás adquiriendo un paquete de software ya desarrollado para una necesidad concreta (por ejemplo Autocad), los entregables serán los propios de este producto (CD, DVD, descarga desde su página web).

3.2.- DOCUMENTACIÓN BÁSICA

La documentación es una herramienta y no un fin en sí mismo, por lo que lo importante es que se genere aquel conjunto de conocimientos que faciliten el mantenimiento de las aplicaciones y su futura evolución. Para el pase a producción de las aplicaciones en la infraestructura corporativa, el STSI necesita al menos los siguientes documentos que le permitan saber cómo instalar la aplicación y cómo llevar a cabo las labores de operaciones de sistemas necesarias para su mantenimiento. Por lo que la presentación de estos documentos es obligatoria para la puesta en producción en la infraestructura corporativa:

• Manual de administración/explotación (copias de seguridad, tareas de explotación: parada, arranque, etc... y/o monitorización requeridas).
• Manual de instalación, incluyendo una descripción de la arquitectura de la solución.
• Protección de datos. Ficha RGPD/LOPDGDG. Durante la fase de definición del proyecto, el responsable de la aplicación por parte del área correspondiente, deberá ponerse en contacto con el STSI para saber si aplica el tratamiento de datos de carácter personal e identificar las medidas de seguridad a aplicar. Esta guía de ayuda de ayuda facilita la cumplimentación de la ficha.
• Plan de Pruebas e Informe de Ejecución de Pruebas. Se debe asegurar que el producto a instalar en la infraestructura corporativa ha pasado pruebas de usuario y su funcionamiento es conforme a lo exigido por los responsables de la aplicación. Las pruebas en el entorno de preproducción deben ir dirigidas a certificar el funcionamiento de la aplicación dentro de la infraestructura corporativa, pero no se trata de pruebas iniciales de usuario.

3.3.- DOCUMENTACIÓN NECESARIA

Para el conocimiento propio de la aplicación y para facilitar su mantenimiento, se debe disponer de la siguiente documentación:

• Análisis Funcional.
• Diseño Técnico.
• Manual de Usuario.

4.1.- SOFTWARE BASE SERVIDOR

4.2.- SOFTWARE EN EQUIPOS CLIENTES

Las aplicaciones a desarrollar para el IASS tendrán preferentemente una arquitectura web, de manera que el elemento más importante a tener en cuenta en estos equipos es el navegador. Salvo justificación expresa y aceptada por el STIC, las aplicaciones deberán ser compatibles con los estándares web actuales y deberán poderse visualizar en los navegadores más utilizados, que son los siguientes:

5.1.- Fase de contratación del proyecto

Antes de que hayas hecho la contratación, durante la definición de la necesidad y de los pliegos, ten en cuenta lo siguiente:

• Tenlo en cuenta para tus pliegos. Revisa la guía de desarrollo e incluye en tus pliegos o informes de contratación la referencia a la necesidad del cumplimiento de la misma.
• Ten presente la protección de datos. Contacta con el STSI para determinar si hay tratamientos de datos de carácter personal y en ese caso las medidas necesarias a implantar.
• Ten en cuenta a quién va dirigido. Si vas a contratar un portal visible por la ciudadanía, no olvides revisar la Norma de Accesibilidad y consultar cualquier duda con el STSI.
• No olvides el mantenimiento. Incluye un servicio de mantenimiento que te asegure la evolución funcional y técnica de la aplicación.
• Ten presente la formación. Valora si es necesario incluir una formación para la aplicación ya sea a nivel técnico o para los usuarios finales, o plantéate dar tú mismo la formación a estos últimos. Puedes hablar con el Servicio de Relaciones laborales y organización para su organización. En caso de que la empresa se encargue de la formación, se exigirá la generación de un curso on-line tipo Moodle de autoformación, que puedan seguir usuarios que se vayan incorporando en el futuro al uso de la aplicación.

5.2.- Ejecución del proyecto.

• Cierra con la empresa una planificación detallada del proyecto y lleva un seguimiento de la misma, anticipando con tiempo las interacciones (toma de requisitos, validación de documentos o pruebas) que sean necesarias con los responsables.
• Asegúrate de que la empresa solicite los accesos VPN necesarios para subir la aplicación al GIT corporativo y para la integración con otras aplicaciones en el entorno de preproducción en caso de que sea necesario. También deberán solicitar un usuario del Directorio Activo y los permisos necesarios para el acceso al GIT, a la aplicación de gestión de proyectos, herramienta de ticketing, así como a todas las aplicaciones corporativas necesarias.
• Haz las pruebas pertinentes de cada versión que entregue la empresa para asegurar que se cumplen los requisitos solicitados.

5.3.- Fase de Mantenimiento.

• Es recomendable que haya algún responsable funcional dentro de tu servicio que preste apoyo a los usuarios de la aplicación en cuanto al uso de la misma, actuando tú en caso de que haya problemas técnicos.
• Valora si vas a necesitar seguir contando con un servicio de mantenimiento y realiza los trámites administrativos de su contratación con antelación suficiente.

Que esperar del software:

• Que sea modular. Tendrá que adaptarse a las particularidades de mi entorno e ir satisfaciendo las necesidades futuras para crecer con él.
• Escalable para evitar migrar nuestros datos a otras soluciones de mayor alcance.
• Trabajará con un único modelo de datos para evitar utilizar aplicaciones externas que incrementan los costes y recursos.
• Su implantación deberá ser rápida y ágil para reducir costes y las molestias generadas en la actividad normal de la empresa.
• Garantizará una correcta y segura migración de nuestros datos.
• Su curva de aprendizaje no supondrá un freno, y disponga de suficientes recursos o soporte de formación.
• Tras su implantación el proveedor contará con un equipo de soporte técnico y un mantenimiento flexible en función de las necesidades de cada empresa. De esta forma podrá resolverse cualquier problema asociado al manejo de la herramienta.
• Ofrecerá interoperabilidad con otras plataformas externas siempre que sea necesario.
• Ofrecerá movilidad a cualquier departamento de la empresa.

Las propuestas de proveedores de software de gestión deberán dar información sobre:

- Experiencia en implantaciones del software en el sector de las administraciones públicas.

- Comunicación fluida y periódica no sólo relacionada con el desarrollo y previsión de fechas del proyecto sino de respuestas a posibles problemas.

- Características sobre el soporte de fábrica.

- Niveles de actualización.

- Garantías.

- Certificaciones acreditadas.

- Construcción de aplicaciones con software seguro con plan de seguridad.