¿Para qué me sirve esta actividad? 📚
Esta actividad te ayudará a documentar cómo tu empresa recibe, analiza, desarrolla, prueba, implementa y mantiene cambios tecnológicos y en el desarrollo de software.
La Metodología de Ciclo de Vida del Desarrollo permite definir un proceso ordenado para la creación o modificación de software, sistemas, aplicaciones e infraestructura. Su objetivo es asegurar que los aspectos de seguridad y privacidad se consideren desde el inicio del requerimiento y no únicamente antes de liberar una solución a producción.
Este documento es importante porque demuestra que tu empresa no desarrolla o modifica tecnología de forma improvisada. También permite conservar evidencia sobre los requerimientos recibidos, las decisiones de priorización, las pruebas realizadas, los cambios aprobados y las comunicaciones efectuadas durante cada etapa.
¿Qué tengo que hacer? 🚀
💡Este documento debe reflejar cómo trabaja realmente tu equipo de Tecnología. El template editable está basado en una metodología ágil como SCRUM, pero puedes adaptarlo si tu empresa utiliza otro modelo de trabajo.
Al trabajar en el template, te recomendamos primero leerlo en su totalidad para así comprender la información que deberás documentar posteriormente. Y para completarlo de forma adecuada, te recomendamos considerar lo siguiente:
Define el objetivo y alcance de la metodología.
El objetivo de este documento es regular las actividades relacionadas con el ciclo de vida del desarrollo, incorporando seguridad y privacidad desde el diseño, alcanzado todas las etapas desde la recepción o ideación de un requerimiento hasta su mantenimiento en producción.
Considera tanto desarrollos internos como cambios en sistemas existentes, infraestructura, aplicaciones, plataformas o componentes tecnológicos.
Asegúrate de que los roles definidos coincidan con la estructura real de tu empresa.
Adapta la metodología de trabajo utilizada.
El template presenta ejemplos basados en SCRUM, incluyendo Product Backlog, Sprint Planning y Sprint. Pero si tu empresa utiliza otra metodología, no es necesario conservar esos términos. Puedes reemplazarlos por las etapas, reuniones, herramientas y responsables que realmente utilice tu equipo.
Lo importante es que el documento permita demostrar cómo se gestionan los requerimientos, cambios, pruebas, aprobaciones y despliegues.
Registra los nuevos requerimientos.
Define quién recibe las solicitudes de nuevos desarrollos, cambios o funcionalidades e indica la(s) herramienta(s) donde se registran, por ejemplo Jira, Trello, Asana, GitHub, una mesa de ayuda u otra plataforma interna.
Cada requerimiento debe incluir una descripción clara, la persona o área solicitante, la justificación de negocio y los posibles riesgos de seguridad y privacidad asociados.
⚖️ Recomendación legal: Si un requerimiento implica recopilar nuevos datos personales, modificar una finalidad, incorporar inteligencia artificial, automatizar decisiones o compartir información con terceros, el impacto de privacidad debe identificarse desde esta etapa. Esto permite evaluar tempranamente si corresponde una Evaluación de Impacto a la Privacidad u otra medida adicional.
Define la priorización y planificación.
Establece cómo se priorizan los requerimientos según su impacto, criticidad, urgencia, valor para el negocio y factibilidad técnica.
Los criterios de aceptación deben incluir requisitos funcionales, técnicos, de seguridad y de privacidad cuando corresponda.
Documenta quién participa en la planificación y cómo se asignan las tareas a los responsables.
Si existe una separación entre quien solicita, desarrolla, revisa y aprueba los cambios, asegúrate de que también sea coherente con tu Matriz SoD.
Registra el seguimiento del desarrollo.
Define cómo el equipo realiza seguimiento de las tareas, impedimentos, avances y cambios durante el desarrollo.
Puedes utilizar reuniones diarias, reportes de avance, tableros de tareas o cualquier mecanismo que permita conservar trazabilidad.
El objetivo es que los responsables puedan identificar retrasos, riesgos, fallas o dependencias antes de que el cambio pase a producción.
Realiza la demostración y validación del desarrollo (opcional, dependiendo tu metodología de trabajo).
Antes de continuar con las pruebas finales o el paso a producción, es posible que se solicite presentar / demostrar el desarrollo a las personas responsables o interesadas.
Esta instancia permite comprobar si la solución cumple los criterios de aceptación definidos inicialmente, y con ello tomar decisiones más informadas y/o pedir los ajustes necesarios.
Si el resultado no es aceptado, documenta las acciones correctivas, responsables y seguimiento correspondiente.
Si es aceptado, registra la decisión y continúa con las pruebas técnicas necesarias.
Establece controles de prueba y paso a producción.
Las pruebas deben realizarse en un entorno separado de desarrollo y producción.
Define qué pruebas se realizan, quién las ejecuta, cómo se documentan los resultados y quién autoriza el paso a producción.
Si las pruebas fallan, deben definirse acciones correctivas y analizarse si el resultado requiere actualizar controles, riesgos, planes de continuidad o recuperación ante desastres.
El paso a producción debe realizarse de forma controlada, procurando reducir el impacto sobre la operación y notificando previamente a las personas interesadas.
⚖️ Recomendación legal: Siempre que sea posible, evita utilizar datos personales reales en ambientes de prueba. Utiliza datos sintéticos, anonimizados o minimizados. Si excepcionalmente se requieren datos reales, deben existir controles de acceso, una justificación documentada y medidas de seguridad reforzadas.
Define la comunicación posterior al despliegue.
Establece quién debe comunicar que el paso a producción fue exitoso y a quién (dependiendo el despliegue, podría ser necesario comunicar no solo a partes interesadas internas sino también externas como clientes u otros stakeholders).
Indica el canal de comunicación aplicable, como correo interno, Slack, Teams, herramienta de tickets u otro medio utilizado por la empresa.
Conserva evidencia de la notificación y del registro técnico del cambio implementado.
Completa el versionado del documento.
Al finalizar, completa la información de elaboración, aprobación, fecha y clasificación de la información.
Nuestro template está estructurado con actividades, responsables y salidas esperadas que te servirán para documentar el ciclo de vida del desarrollo de forma clara y ordenada, pero recuerda que debes ajustarlo al contexto real de tu empresa.
💡 Los pasos a seguir para terminar la actividad dentro de la plataforma son los siguientes:
Una vez que nuestro equipo haya aprobado la actividad, debes subir el documento final en versión PDF (no editable).
Posteriormente, debes subir la evidencia de su aprobación.
Recomendamos que esta evidencia sea a través de una minuta de sesión de comité (en ese caso, debes subir el documento en PDF de la minuta), o con una captura de pantalla de la respuesta explícita de quién o quiénes lo aprobaron.
Esto debe realizarse por algún medio de comunicación interno de la empresa, como Slack, Teams o el correo electrónico organizacional.
Y por último, debes subir la evidencia de su comunicación.
Al igual que la aprobación, la comunicación del documento puede ser por cualquier medio formal interno de la empresa. Y para esto, debes subir una captura de pantalla donde se muestre que el documento fue comunicado a todos los colaboradores interesados.
Recomendaciones ✅
Conserva evidencia de cada etapa, como tickets, criterios de aceptación, capturas, repositorios, resultados de pruebas, aprobaciones y registros de despliegue.
Define un mecanismo de reversión o rollback para cambios relevantes, especialmente cuando puedan afectar datos personales, servicios críticos o disponibilidad de sistemas.
Revisa que los responsables indicados en esta metodología coincidan también con otros documentos donde se mencionen, como en el Descriptivo de roles y responsabilidades y la Matriz SoD.
Capacita a Product Owners, desarrolladores, QA y responsables técnicos para que identifiquen riesgos de seguridad y privacidad desde el inicio de cada requerimiento.
Actualiza la metodología cuando cambien las herramientas de desarrollo, el modelo de trabajo, la infraestructura, los proveedores tecnológicos o los controles de seguridad aplicables.
Integra los incumplimientos o riesgos detectados durante el desarrollo con el análisis de riesgos, el plan de remediación de vulnerabilidades o la Evaluación de Impacto a la Privacidad, cuando corresponda.
¡Califica este artículo 👇, esto nos ayudará a mejorar nuestro contenido para ti! También puedes contactarnos por correo electrónico o a través de la plataforma, y te brindaremos la atención que necesites.