Skip to main content

Ciclo de Vida del Desarrollo de Software (SDLC)

No existe una única "documentación oficial" universal para el SDLC, el ciclo de desarrollo de software, porque es un concepto, no un producto.

Piensa en esto como tres capas diferentes de un mismo asunto:

  • Capa 1: El Concepto Fundamental

    • SDLC (Software Development Life Cycle): Este es el concepto universal y genérico de que todo software tiene un ciclo de vida: nace de una idea, es planificado, proyectado, construido, probado y mantenido. Es la idea-madre. No dice cómo hacer, solo que estas fases existen.

  • Capa 2: La Metodología (El Enfoque de Trabajo)

    • Aquí es donde eliges CÓMO tu equipo va a recorrer las fases del SDLC. Es tu filosofía de trabajo. En la mayoría de las veces será alguna metodología Ágil (Agile - como Scrum o Kanban), pero todo depende del tipo de software que queremos desarrollar. Cuando los requisitos no pueden cambiar podemos utilizar la metodología en cascada.
    • Haces todas las fases del SDLC usando estas metodologías.
    • Esta es la capa que más impacta el día a día del equipo de desarrollo. Es el motor del proceso.

  • Capa 3: El Framework o Estándar (El Blueprint Detallado):

    • Aquí están los "manuales" o "conjuntos de reglas" que definen QUÉ actividades, artefactos y controles específicos deben existir en tu proceso, independientemente de la metodología.

Existen estándares internacionales y frameworks publicados por organizaciones de renombre que son consideradas las documentaciones más próximas a "oficiales" que puedes encontrar. Establecen directrices y mejores prácticas que son adoptadas globalmente. En verdad todo depende de las exigencias que el equipo de desarrollo precisa tener.

Aquí están las documentaciones más importantes y reconocidas que sirven como estándar para el SDLC:

  1. Estándares Internacionales (Lo más próximo a "Oficial") ISO/IEC/IEEE 12207: Systems and software engineering — Software life cycle processes

    • Este es el principal estándar internacional para procesos de ciclo de vida de software. Fue desarrollado por la ISO (Organización Internacional de Normalización), IEC (Comisión Electrotécnica Internacional) e IEEE (Instituto de Ingenieros Eléctricos y Electrónicos).
    • Es un estándar formal, reconocido mundialmente, que define una estructura común para que cualquier organización pueda desarrollar, adquirir y mantener software. Detalla todas las actividades y tareas necesarias.
    • La documentación de la ISO es generalmente de pago y puede ser adquirida a través del sitio oficial de la ISO o de revendedores nacionales.
    • Es más importante en:
      • Gobierno y Sector Público: En licitaciones para desarrollo o adquisición de software, es muy común que los pliegos exijan que la empresa proveedora siga los procesos descritos en la ISO 12207 (o en su versión española, la UNE-ISO/IEC 12207). Esto sirve como una garantía de que el dinero público está siendo invertido en un proyecto con un mínimo de organización, documentación y calidad.
      • Industrias Altamente Reguladas: En sectores donde un fallo de software puede tener consecuencias graves (riesgo de vida, pérdidas financieras enormes), la adhesión a estándares rigurosos es obligatoria.
        • Aeroespacial y Defensa: Empresas como Airbus y proveedores de las fuerzas armadas precisan de un nivel altísimo de trazabilidad y seguridad.
        • Médica: Softwares para equipos médicos (como un tomógrafo o una bomba de infusión) precisan ser aprobados por agencias reguladoras (como la AEMPS), que exigen prueba de un proceso de desarrollo robusto.
        • Automovilística y Ferroviaria: El software que controla los frenos de un coche o el sistema de señalización de un tren precisa ser extremadamente fiable.
        • Bancario y Financiero: Para garantizar la seguridad de las transacciones y el cumplimiento con las regulaciones del Banco de España.
      • Grandes Contratos Internacionales y Outsourcing: Cuando una gran empresa (ej: una multinacional) contrata a otra para desarrollar un software, generalmente exige conformidad con la ISO 12207 en el contrato. Esto garantiza que ambas partes "hablen el mismo idioma" en términos de procesos, entregas y documentación.
    • Menos usada en:
      • Startups y Empresas de Pequeño/Mediano Tamaño: El foco principal es la velocidad de entrega y la rápida adaptación al mercado. La formalidad y la burocracia asociadas a la implementación completa de una norma ISO pueden ser vistas como un obstáculo. Siguen procesos, pero de forma mucho más ligera y flexible.
      • Equipos Ágiles y DevOps "Puros": Metodologías como Scrum y Kanban ya proporcionan un framework de procesos. Un equipo que hace sus daily meetings, sprints, y tiene un product backlog bien definido está, en la práctica, cumpliendo el espíritu de muchos de los procesos de la ISO 12207 (tener requisitos, desarrollar, probar, entregar), pero de una manera mucho más dinámica y menos enfocada en documentación pesada.

    Es un error pensar que la ISO 12207 y el desarrollo Ágil son enemigos. La norma describe "qué" precisa ser hecho (los procesos que deben existir), pero no prescribe "cómo" deben ser implementados. El proceso de análisis de requisitos puede ser implementado a través de User Stories en un backlog y el proceso de pruebas puede ser automatizado con pipelines.

  2. Estándares Gubernamentales (Altamente Influyentes)

    • NIST SP 800-218: Secure Software Development Framework (SSDF)
      • Publicado por el NIST (Instituto Nacional de Estándares y Tecnología de los EE.UU.), este documento define un conjunto de prácticas de desarrollo de software seguro. No dicta un modelo de SDLC específico, pero describe prácticas de seguridad que deben ser integradas en cada fase de cualquier modelo que uses (Agile, DevOps, etc.).
      • Es un estándar gubernamental de los EE.UU. y, debido a la influencia del NIST en la industria de tecnología y ciberseguridad, se convirtió en una referencia global para la creación de un "Secure SDLC" (SSDLC).
      • Dónde encontrar: Es gratuito y está disponible públicamente en el sitio del NIST.

  3. Frameworks de la Industria (Estándares de Facto)

    • Aunque no sean "oficiales" en el sentido de un órgano de estandarización internacional, los siguientes frameworks son tan influyentes que se convirtieron en estándares de facto en la industria:
      • Microsoft Security Development Lifecycle (SDL)
      • Es la metodología que Microsoft creó e implementa para garantizar que su software sea seguro desde el inicio. El Microsoft SDL fue uno de los primeros y más completos esfuerzos para formalizar un ciclo de vida de desarrollo seguro.
      • Debido al éxito y a la amplitud, se convirtió en un modelo para muchas otras empresas crear sus propios programas de seguridad de aplicaciones.
      • Microsoft disponibiliza toda la documentación, herramientas y prácticas gratuitamente. Puedes encontrar todo en el sitio oficial del Microsoft SDL.

  4. OWASP Software Assurance Maturity Model (SAMM)

    • El OWASP SAMM es un framework para ayudar a las organizaciones a formular e implementar una estrategia para seguridad de software, adaptada a sus riesgos específicos.
    • Es mantenido por OWASP, la principal fundación sin fines lucrativos enfocada en seguridad de software, y es ampliamente adoptado como una guía práctica para madurar las prácticas de SDLC.
    • Es gratuito y de código abierto, disponible en el sitio del OWASP SAMM. Enlace para el PDF
    • El OWASP SAMM no es un proceso para construir el software, sino una guía para añadir prácticas de seguridad al proceso.

Independientemente de la metodología las etapas conceptuales del SDLC son las mismas. La gran diferencia es cómo las ejecutas: todas de una vez (Cascada) o en pequeños ciclos repetitivos (Agile). Vamos a detallar cada una de las etapas clásicas del SDLC:

  1. Planificación y Análisis de Requisitos

    Pregunta que responde: ¿Qué vamos a construir y por qué?

    Esta es la fase de fundación. El objetivo es entender el problema de negocio y definir qué el software precisa hacer para resolverlo. Errores aquí son los más caros de corregir más tarde.

    Actividades Principales:

    • Análisis de viabilidad (técnica, económica, operacional).
    • Entrevistas con stakeholders (clientes, usuarios, gestores) para recoger necesidades.
    • Definición del alcance del proyecto (qué está dentro y qué está fuera).
    • Documentación de los requisitos funcionales (qué el sistema debe hacer, ej: "el usuario debe poder registrarse con email y contraseña") y no funcionales (cómo el sistema debe ser, ej: "la página de login debe cargar en menos de 2 segundos").

    Principales Involucrados: Gerentes de Producto (Product Managers), Analistas de Negocio (Business Analysts), stakeholders.

    Resultado Principal: Un documento de especificación de requisitos (SRS - Software Requirements Specification) o, en un mundo Ágil, un Product Backlog priorizado con las primeras User Stories.

  2. Diseño (Proyecto y Arquitectura)

    Pregunta que responde: ¿Cómo vamos a construir esto?

    Con los requisitos en mano, el equipo técnico traduce el "qué" para el "cómo". Es aquí que el esqueleto y el plano del software son creados.

    Actividades Principales:

    • Diseño de Arquitectura: Definir la estructura general del sistema (ej: microservicios vs. monolito), las tecnologías (lenguaje de programación, base de datos, cloud) y cómo los componentes van a comunicarse.
    • Diseño de Interfaz (UI/UX): Crear wireframes (bocetos básicos) y mockups (prototipos visuales) de cómo serán las pantallas y la experiencia del usuario.
    • Diseño de Datos: Modelar la estructura de la base de datos (tablas, relaciones).

    Principales Involucrados: Arquitectos de Software, Diseñadores de UI/UX, Desarrolladores Seniors (Tech Leads).

    Resultado Principal: Documentos de diseño técnico, diagramas de arquitectura, prototipos visuales.

  3. Desarrollo (Implementación o Codificación)

    Pregunta que responde: ¡Vamos a construir!

    Esta es la fase donde las ideas y los proyectos se transforman en un software funcional. Los desarrolladores escriben el código, siguiendo las especificaciones de la fase de diseño.

    Actividades Principales:

    • Escribir el código fuente en los lenguajes elegidos.
    • Crear y gestionar la base de datos.
    • Escribir pruebas de unidad para verificar pequeñas partes del código.
    • Gestionar el código en un sistema de control de versiones (como Git).

    Principales Involucrados: Desarrolladores (Front-end, Back-end, Full-stack).

    Resultado Principal: El código fuente del software, componentes funcionales.

  4. Pruebas (Verificación y Validación)

    Pregunta que responde: ¿Esto funciona correctamente y atiende a los requisitos?

    El software construido es rigurosamente inspeccionado para encontrar y corregir defectos antes de que llegue al usuario final.

    Actividades Principales:

    • Pruebas de Integración: Verificar si los diferentes componentes del sistema conversan entre sí correctamente.
    • Pruebas de Sistema: Probar el software completo de punta a punta para garantizar que cumple todos los requisitos.
    • Pruebas de Seguridad y Rendimiento: Buscar vulnerabilidades y cuellos de botella de rendimiento.
    • Prueba de Aceptación del Usuario (UAT): Presentar el software para los stakeholders o un grupo de usuarios para que validen si atiende a sus necesidades.

    Principales Involucrados: Ingenieros de QA (Quality Assurance), Desarrolladores, Stakeholders (para el UAT).

    Resultado Principal: Un software estable y con calidad validada, informes de bugs y una "señal verde" para la implantación.

  5. Implantación (Deployment)

    Pregunta que responde: ¿Cómo disponibilizamos esto para los usuarios?

    El software, ahora probado y aprobado, es liberado en el ambiente de producción para que los usuarios finales puedan acceder a él.

    Actividades Principales:

    • Preparar el ambiente de producción (servidores, nube).
    • Migrar el código y los datos para el ambiente final.
    • Realizar verificaciones finales para garantizar que todo subió correctamente. En DevOps, esta etapa es altamente automatizada (CI/CD).

    Principales Involucrados: Ingenieros de DevOps, Ingenieros de Infraestructura (Ops), SREs.

    Resultado Principal: El software ejecutándose en producción y accesible a los usuarios.

  6. Mantenimiento y Operación

    Pregunta que responde: ¿Cómo mantenemos esto funcionando bien y mejoramos con el tiempo?

    Esta es la fase más larga del ciclo de vida. El software está en uso y precisa de soporte y evolución continua.

    Actividades Principales:

    • Monitoreo de la salud del sistema (rendimiento, errores, seguridad).
    • Corrección de bugs que son descubiertos por los usuarios.
    • Soporte técnico.
    • Planificación y desarrollo de nuevas versiones con mejoras y nuevas funcionalidades, iniciando el ciclo nuevamente.

    Principales Involucrados: Equipos de Operación (Ops), Soporte, Desarrolladores.

    Resultado Principal: Un software estable, actualizado y que continúa entregando valor.

    Recuerda: en el modelo Waterfall, pasas por estas 6 etapas una única vez, en secuencia. En el modelo Ágil, tu equipo pasa por una versión "micro" de todas estas 6 etapas dentro de cada ciclo de 2 a 4 semanas (Sprint).