Dependiendo de las áreas que interactúen en la revisión de un contrato de desarrollo de software es lo que veremos explicito en la obligaciones u objetos del contrato, por lo que la percepción de la necesidad del desarrollo de software se vuelve un tema de múltiples aristas, que no debe despreciar cada una de ellas y por lo tanto deben ser tomadas en consideración para cumplir con la cadena de valor que se desea por parte de la aplicación.
Para un mejor entendimiento pondré un ejemplo que podría acercarse a la vida real en la contratación de los servicios de desarrollo de software, para este ejemplo el área de marketing es la que define el proyecto, por lo que en las clausulas iniciales para la prestación del servicio de desarrollo de software se encuentran definidas con características de usabilidad de la aplicación, diseño basado en la experiencia del usuario, entendimiento del usuario, cambios que apoyaran al “Time to Market”, implementación de estadísticas de uso de la aplicación, entre otros indicadores.
Con esta definición, claramente orientada a las necesidades de entendimiento y atención del cliente, se establece un primer acercamiento con el proveedor para celebrar los acuerdos del servicio, una vez que se llega al acuerdo es muy común ver que esto llega al área de jurídico para su revisión y al llegar a esta área lo primero que denotan los abogados es que no hay una protección de la propiedad intelectual que se está generando tanto el desarrollo de software como la base de datos de los usuarios y su comportamiento, que si bien podría darse por un hecho que al celebrar el contrato se establecen los parámetros de protección por la obra contratada queda en entredicho la propiedad y la autoría, por lo que se decide realizar un conjunto de clausulas que protejan la propiedad intelectual, claro adicionando todos los elementos adicionales que ya son parte de los acuerdos mercantiles y la protección a favor de las relaciones laborales.
Ya estando en el jurídico se observa que parte de la información que se trata como parte del desarrollo de software son datos personales y que en algún momento se pueden clasificar como datos personales sensibles, lo que conlleva la inclusión de clausulas que resguarden el tratamiento de datos personales en el desarrollo del software. También denota que existen diversos requisitos regulatorios sectoriales como pueden ser accesibilidad, términos y condiciones, reglas de protección al consumidor, mismas que agrega y brindan un formalismo de cumplimiento con base en la legislación nacional y sectorial.
Una vez que se han agregado estas cláusulas legales, debido a la experiencia necesaria sobre procesos de tecnologías de información se involucra al área encargada de los recursos tecnológicos que en su revisión de los objetos del contrato determina:
- La definición del lenguaje de programación que es importante para dar un soporte futuro al desarrollo sin dependencia del proveedor de servicio
- La necesidad de un modelo de interacción con las aplicaciones actuales y soporte al producto final de la aplicación
- La definición de niveles de servicio óptimos para el despliegue y trasmisión de conocimiento a los funcionales y operativos de TI
- La necesidad de documentación de la aplicación y los procesos
- Los ambientes que se tendrán para desarrollo, pruebas y productivo
- Pruebas de desempeño de la aplicación con base en las cargas proyectadas, en las que se incluirán pruebas de calidad de la aplicación (QAT), pruebas de usuario (UAT), pruebas canarias, pruebas…
- Gestión de cambios, para dar seguimiento a los elementos no tomados en consideración durante las etapas iniciales de la solución
- Modelo arquitectónico de la solución propuesta
- Metodología de proceso del ciclo de vida de desarrollo de software, en el cual se define si las iteraciones con el equipo de trabajo serán recurrentes o por etapas y si la metodología es Agile, en cascada, prototipo, entre otras.
En este último punto sistemas o tecnologías de la información determina que hace falta la visión del departamento de proyecto o también denominado PMO (Project/Porfolio Management Office), en la cual se deben incluir algunas características al contrato que van enfocadas en los siguientes aspectos:
- Cumplimiento de objetivos organizacionales, que deben estar alineado a los diversos proyectos que se tienen en la cartera y por lo tanto se deben adecuar al resto de los desarrollos en la cartera
- Determinación de los recursos de personal que se utilizaran dentro del proyecto, así como los puntos de contacto para la interacción entre ambas partes del desarrollo
- Tiempos sobre cada una de las fases del desarrollo dependiendo de la metodología, incluyendo las fechas de las reuniones de avances y los “Milestones” definidos para cada etapa
- Métricas de calidad de la aplicación, aglomerando las definidas por tecnologías de la información, marketing y jurídico
- Definición del modelo de riesgo sobre el proyecto en aras de cumplimiento de los puntos anteriormente descritos.
En este punto, el departamento de jurídico cuenta con elementos que le aseguran tener un mejor control de la relación con el proveedor y el servicio de desarrollo de software, alineado a procesos de la organización y con buenas prácticas de Operación de TI, Proyectos y Marketing Digital, además de contar con cumplimiento legal sobre los elementos planteados a nivel nacional en el sector de mercado, por lo que se manda a revisión por parte del proveedor.
Durante las iteraciones de las clausulas del contrato con el proveedor, personal de la empresa contratante se entera de una vulneración en los desarrollos de software de una empresa multinacional del sector financiero, en la cual se denotan algunas practicas inadecuadas en la gestión del ciclo de vida de desarrollo de software, por lo que se integra a la revisión del contrato al personal de seguridad de la información y a través de esta área se determinan las siguientes sugerencias para adicionarlas al contrato:
- El modelo de riesgos debe contemplar los riesgos de seguridad de la información durante el proyecto y después de su entrega y liberación
- Definir el modelo de protección de la información que se intercambia para el desarrollo de la aplicación y los datos de prueba
- Capacitación del personal del proveedor en las políticas de desarrollo seguro del cliente, o en su defecto la capacitación del personal del proveedor en buenas prácticas de desarrollo seguro.
- La arquitectura del software debe contemplar una capa de seguridad en el control de accesos (autorización, autenticación y registro de actividades) que permita una auditoria constante y eficiente de las actividades de los usuarios
- La arquitectura de datos debe ser contemplada por el equipo de desarrollo para evitar que se realice la exposición de los datos a través de la aplicación de forma innecesaria.
- En caso de que el desarrollo requiera de nuevos dispositivos o servidores de aplicación, estos deben ser puestos a disposición con la configuración de seguridad mínima avalada por el cliente en términos de buenas practicas del mercado.
- La documentación debe incluir:
- Inventario de los elementos desarrollados, así como los parámetros de entrada y salida de cada uno de los componentes.
- inventario de los elementos de seguridad y configuraciones realizadas para el desempeño óptimo de la aplicación.
- Como parte de las pruebas se debe incluir pruebas de análisis estático y dinámico de código con las actualizaciones establecidas por los estándares de evaluación tales como OWASP, por parte del proveedor o por un tercero no interesado, además de permitir al cliente realizar estas pruebas por su cuenta y con sus medios. Se sugiere ampliamente utilizar los elementos de verificación de OWASP ASVS en su versión actual.
- Los ambientes de desarrollo, pruebas y productivos deben estar separados de otros clientes y en ambientes de colaboración cerrados que no se encuentren públicos en internet.
- Los repositorios de código y ambientes deben ser administrados por el cliente y dar accesos restringidos al personal de desarrollo.
- En caso de realizar desarrollo en ambiente de cloud como parte de la arquitectura tecnológica es importante que los componentes se encuentren asegurados bajo las mejores practicas del fabricante o proveedor.
- Declarar un proceso de auditoria y diligencias de seguridad al proceso de desarrollo de software del proveedor a través de los recursos propios o de un tercero en caso de ser necesario o al existir alguna discrepancia.
- Declarar un proceso de análisis de vulnerabilidades y corrección de las estas por parte del proveedor cuando estas sean imputables a él.
Una vez que jurídico establece estas cláusulas en el contrato, tiene la certidumbre de tener una visión holística de la contratación del servicio de desarrollo de software y solo será necesario acordar un precio justo para cubrir con las necesidades con el proveedor y generar una cadena de valor a los servicios principales de la organización cliente.
En esta descripción trata de determinar una necesidad muy puntual que lleva de la mano la interacción de las áreas solicitantes de la organización con las áreas de soporte como pueden ser el área de jurídico, proyectos, tecnologías de la información y seguridad de la información, sin embargo no se debe descartar que existen necesidades desde el punto de operativo, recursos humanos y fiscales que deben ser tomadas en cuenta en los proyectos de desarrollo de software.
Iván Díaz González como parte de su formación académica cuenta con:
• Ingeniería en Sistemas Computacionales
• Licenciatura en Derecho
• Maestría en Gestión de Tecnologías de la Información
• Doctor en Derecho
Ha obtenido diferentes certificaciones en el ámbito de tecnologías y seguridad de la información entre las que destacan CISSP, CISM, CDPSE (Protección de datos personales), CCSK, ISO 27001, ISO22301, Ciberinteligencia, Hackeo, ITIL y COBIT.
Cuenta con 16 años de trayectoria en el ámbito de las tecnologías y seguridad de la información y comunicaciones. Es socio de LEX INFORMÁTICA ABOGADOS.
Ha fungido como perito informático en procedimientos penales, civiles y mercantiles, en el periodo 2020-2022 ha sido miembro de la lista de personas que pueden fungir como peritos para el Poder Judicial de la Federación.
