Ciclo de vida del desarrollo de software (SDLC)

La implementación de un ciclo de vida de desarrollo de software (SDLC) efectivo lo ayuda a producir soluciones de software de alta calidad rápidamente y por debajo del presupuesto.

¿Qué es Software Development Life Cycle (SDLC)?

Proceso completo de desarrollo de una solución de software con diferentes etapas y pasos para llevar el software desde la ideación hasta la construcción, implementación y mantenimiento.

Dicho proceso describe las diferentes tareas necesarias para crear, implementar y mantener una solución de software. Ayuda a los líderes a asignar tiempo, costos y recursos entre los miembros del equipo para que cada tarea se complete correctamente dentro del presupuesto y la fecha límite. Las fases involucradas en un proceso SDLC se dividen en partes más pequeñas

El ciclo de vida de desarrollo de software (SDLC) es un proceso completo con diferentes etapas involucradas en el proceso de desarrollo de software. Describe las tareas involucradas en cada fase: análisis, construcción, despliegue, y mantenimiento.

Al adherirse a un SDLC efectivo, los equipos pueden producir productos de software de calidad mientras cumplen con las expectativas de los clientes más rápido dentro del presupuesto.

Este proceso contempla 7 etapas:

Análisis de requerimientos: “Lo que el cliente realmente quiere lograr”. Esta etapa consiste en encontrar los diferentes objetivos, preferencias y expectativas que tiene el cliente frente al proyecto.

Algunas preguntas

Cómo sería el producto final
Propósito del software
Qué problemas resuelve
Qué espera el cliente del proyecto

Después de comprender los requisitos, los analistas comienzan a analizar la viabilidad del desarrollo del producto en términos de tecnicismos, operaciones, economía, legal, cronograma, etc., y despejan las dudas que puedan surgir.

Planificación o ideación: el equipo de desarrollo de software planifica la mejor manera de lograr el objetivo de crear el software. El objetivo es optimizar el proceso de creación del software en función del costo, la velocidad, el tiempo y otros factores mientras se cumplen los requisitos exactos del cliente.

En esta etapa, el equipo debe proporcionar una estimación del costo, el cronograma, los recursos y los esfuerzos para completar el proyecto. No incluye tantos tecnicismos del proyecto, sino una idea aproximada de si es realizable o no y cómo.

Diseño: En esta fase la especificación del software se convierte en un plan de diseño claramente definido, también conocido como especificación de diseño. Las partes interesadas importantes revisan este documento en función de la solidez del producto, la evaluación de riesgos, la modularidad del diseño, el cronograma, el costo y otros parámetros. Proporcionan retroalimentación y se realizan ajustes.

Diseño de bajo nivel (LLD): describe la lógica funcional de los módulos, los detalles de la interfaz, las tablas de la base de datos con tamaño y tipo, entradas y salidas, mensajes de error, problemas de dependencia y más.
Diseño de alto nivel (HLD): incluye el nombre y la descripción del módulo, la funcionalidad del módulo, las dependencias y la relación de la interfaz entre los módulos, el diagrama de la arquitectura con la descripción de la tecnología, las tablas de la base de datos con los elementos clave y más.

Desarrollo: Una vez que se realiza el documento de diseño, se entrega al equipo de desarrollo, que comienza a desarrollar el código fuente para el diseño propuesto. Esta fase es cuando se crean y ensamblan todos los componentes del software.

Muchas organizaciones emplean DevOps para cerrar la brecha entre las formas tradicionales de desarrollar el software y administrar las operaciones. En este enfoque, ambos equipos, desarrollo y operaciones, se unen desde el principio para colaborar en un proyecto y llegar a su finalización con procesos continuos de desarrollo, integración, prueba, implementación, monitoreo y mantenimiento.

Pruebas: Verificar la funcionalidad de su código y encontrar errores en él es importante para asegurarse de crear un producto de software de alta calidad basado en el requisito. Esta es la razón por la cual los equipos de desarrollo de software prueban y evalúan minuciosamente todos sus componentes y módulos una vez que se completa la codificación. Los evaluadores evalúan la funcionalidad, el rendimiento y los errores y fallas presentes en el software con la ayuda de pruebas como:

Prueba funcional: Pruebas unitarias, pruebas de sistema, pruebas de integración, pruebas de interfaz, pruebas de regresión, pruebas alfa, pruebas beta, pruebas de humo y más.
No funcional las pruebas : Pruebas de rendimiento, pruebas de estrés, pruebas de carga, pruebas de volumen, pruebas de compatibilidad, pruebas de seguridad, pruebas de usabilidad, pruebas de confiabilidad, pruebas de aceptación, etc.

Despliegue: Después de probar el software y solucionar los problemas, queda listo para su implementación en el entorno de producción. También puede pasar pruebas de software de aceptación del usuario para verificar si cumple con las expectativas de sus clientes creando una réplica y permitiendo que sus desarrolladores y clientes la prueben.
Operaciones y mantenimiento: Su trabajo no está completo en el manejo del software para su cliente; aún necesita monitoreo, actualización y mantenimiento continuos para que siga funcionando en un estado óptimo. Por lo tanto, el equipo de operaciones se mantiene atento al funcionamiento del software al monitorear continuamente y verificar si hay problemas. Si detectan alguna funcionalidad de rendimiento o problemas de seguridad, deben informarse y diagnosticarse de inmediato para mantener intacta su calidad.

Beneficios del SDLC

Objetivos claros:
Proceso más rápido
Costo mínimo
Alta calidad
Orientación al cliente

Algunos Modelos SDLC

Modelo de cascada

El modelo Waterfall es el enfoque más utilizado y más antiguo para un ciclo de vida de desarrollo de software. Es sencillo y sigue un camino lineal en el que el resultado obtenido en una fase se utiliza como entrada para la fase siguiente. Aquí, la siguiente fase comienza solo cuando se completa la fase anterior.

Agil Modelo de

El proyecto se divide en compilaciones incrementales más pequeñas lanzadas en iteraciones llamadas "sprints". Aquí, cada compilación se incrementa en función de las características. Cada sprint puede durar de dos a cuatro semanas, y al final de las cuales, el propietario del producto valida el producto. Si aprueban el producto, se le entregará al cliente.

Este modelo es popular hoy en día y ofrece velocidad para crear e implementar el producto y flexibilidad para adaptarse rápidamente a los cambios.

Modelo incremental o iterativo

Este modelo requiere que divida el software en partes más pequeñas. Por ejemplo, puede crear una función primero, probarla e implementarla, recopilar comentarios e iterar. Una vez que esto esté completo, trabaje en la siguiente característica.

Prototipos Rápidos

En este modelo, los prototipos se desarrollan antes de crear el producto real. Los prototipos tienen funciones y rendimiento limitados, pero son suficientes para evaluar las necesidades de los clientes, recopilar comentarios y mejorar el producto hasta que sea aceptado.

Espiral

El modelo espiral de SDLC incluye prototipos y enfoques iterativos. Tiene cuatro fases: planificación, evaluación de riesgos, desarrollo y evaluación que los equipos siguen en iteraciones hasta que obtienen el producto de software deseado que cumple con los requisitos y estándares de calidad de los clientes. Ideal para proyectos grandes

Modelo V

El modelo de verificación y validación (V-Model) involucra la fase de desarrollo y prueba trabajando en paralelo. Es igual que el modelo Waterfall, excepto que la planificación y las pruebas del software comienzan antes. Tiene dos partes -

Fase de verificación: Incluye análisis de requisitos, diseño de sistemas y codificación.
Fase de validación: Implica pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación.

Ideal para proyectos más pequeños.

Lean

La metodología ajustada se inspira en los principios y prácticas de fabricación ajustada. Alienta a los equipos a crear un mejor flujo de trabajo y desarrollar una cultura de mejora continua. Sus principios son: reducir el desperdicio, tomar decisiones conscientemente, amplificar el aprendizaje, entregar más rápido, capacitar a los equipos y construir de manera integral con integridad.

La importancia de la seguridad en el SDLC

Uno de los problemas más comunes en el desarrollo de software es que la seguridad se aborda en una etapa demasiado avanzada del proceso: la de pruebas, después de haber completado las tareas más importantes de diseño e implementación. En muchos casos, los controles de seguridad que se ejecutan en esa etapa son superficiales, es decir, se limitan al análisis y las pruebas de intrusión. Por eso es posible que se pasen por alto problemas de seguridad más complejos que, de detectarse, podrían retrasar la llegada del sistema a la producción. Además, la resolución de los problemas lleva mucho tiempo y es más costosa, ya que puede requerir que se vuelva a desarrollar y probar todo el software.

El ciclo de vida de desarrollo del software seguro (S-SDLC)

La implementación de procesos de seguridad eficaces requiere que los equipos tomen las medidas de protección desde las primeras etapas del desarrollo del software y en cada una de ellas. Hay ciertos pasos que se pueden seguir en cada etapa para lograr el ciclo de vida de desarrollo del software seguro (S-SDLC). Por ejemplo:

Etapas SDLC	Medidas de seguridad
Análisis de los requisitos	Evaluar los riesgos y el panorama de las amenazas a la seguridad Evaluar el posible impacto de los incidentes de seguridad, como el riesgo para la reputación de la empresa
Planificación	Incluir los requisitos de seguridad Comprender e incorporar los requisitos de cumplimiento normativo
Diseño	Elaborar modelos de amenazas Incluir las consideraciones de seguridad como parte integral del plan de arquitectura Evaluar el impacto que tiene la seguridad en las decisiones de la etapa de diseño, como la plataforma y la interfaz de usuario
Desarrollo	Capacitar a los desarrolladores sobre las prácticas de codificación seguras Incorporar herramientas de prueba de la seguridad en el proceso de desarrollo Evaluar las dependencias del software y reducir los riesgos de seguridad
Documentación	Documentar los procesos y los controles de seguridad Reunir la información para preparase para las auditorías, los controles de cumplimiento normativo y las revisiones de seguridad
Pruebas	Implementar procesos de revisión del código Realizar pruebas estáticas o dinámicas de la seguridad de las aplicaciones
Implementación	Evaluar la seguridad del entorno de implementación Revisar las configuraciones de seguridad
Mantenimiento	Supervisar el sistema para detectar amenazas Prepararse para eliminar los puntos vulnerables y solucionar las intrusiones

Fases del S-SDLC

Las empresas necesitan un conjunto de procesos y prácticas que se actualicen de manera constante para poder enfrentar las crecientes amenazas a la seguridad. En el S-SDLC, los puntos y los controles de seguridad deben implementarse desde el principio del proceso de desarrollo e implementación. Las empresas adoptan el enfoque de DevOps y los canales automatizados de integración e implementación continuas (CI/CD) para poder implementar mejoras de manera permanente y rápida. Para evitar los bloqueos, la seguridad debe ser un proceso constante y automatizado, y los equipos de desarrollo deben encargarse de la protección de las aplicaciones, además del diseño, el desarrollo, las operaciones y el mantenimiento.

DevSecOps es un conjunto de prácticas que incluyen personas, procesos y tecnologías para mejorar la velocidad y la eficiencia del desarrollo del software, mientras que ofrecen mayor seguridad, uniformidad, capacidad de repetición y colaboración. La clave está en compartir la responsabilidad entre los equipos de desarrollo, de operaciones y de seguridad. Estos son algunos de los objetivos de DevSecOps:

Mejorar la seguridad y disminuir los riesgos
Aumentar la eficiencia y la velocidad de los ciclos de lanzamiento de DevOps
Disminuir los riesgos y aportar claridad

Las cuatro etapas del modelo de DevSecOps permiten garantizar que se incorpore la seguridad al canal de CI/CD y que se adapte a medida que cambien las condiciones en la empresa o en el mundo. Open Web Application Security Project® (OWASP) es una fundación sin fines de lucro que ofrece proyectos de software open source de la comunidad para mejorar la seguridad de los sistemas y generar conciencia sobre este tema. También brinda proyectos, herramientas y documentos gratuitos que pueden utilizarse para mejorar el ciclo de vida de desarrollo de la seguridad.

Propiedades elementales del software seguro

Integridad: capacidad que garantiza que el código del software, activos manejados, configuraciones y comportamientos no puedan ser o no hayan sido modificados o alterados.
Disponibilidad: capacidad que garantiza que el software es operativo y accesible por usuarios.
Confidencialidad: capacidad de preservar que cualquiera de sus características, activos manejados, estén ocultos a usuarios no autorizados.

S-SDLC – Threat Modeling

El Modelado de Amenazas, como metodología y práctica de Ingeniería de Software, se introduce dentro del S-SDLC, constituyendo un framework específico para el proceso de análisis de riesgo estructurado, que permite identificar las amenazas de una aplicación, cuantificar los riesgos a los que la misma estará expuesta, y definir contramedidas de mitigación. Permite contar, desde las etapas iniciales del desarrollo, con una visión de la seguridad que alcanza todo el ciclo de vida, a través de la evaluación de riesgos y la determinación de contramedidas. El objetivo del modelado de amenazas es asegurar las propiedades esenciales de Integridad, Disponibilidad y Confidencialidad que constituyen un Software Seguro.

Amenaza: “Causa potencial de un incidente no deseado, el cual puede ocasionar daño a un sistema o a una organización.” ISO/IEC 27000:2014
Vulnerabilidad: “Defecto o debilidad en el diseño, implementación u operación de un sistema que habilita o facilita la materialización de una amenaza. ” Magerit:2012
Riesgo: “El riesgo de seguridad de la información se relaciona con la posibilidad de que las amenazas exploten vulnerabilidades de un activo o grupo de activos de información y causen daño a una organización.” ISO/IEC 27000:2014

Metodologías para el desarrollo seguro de software

Las metodologías de desarrollo seguro de software sitúan a la seguridad en el centro del proceso. Existen distintos modelos, concebidos por grandes compañías, organizaciones nacionales y bajo paradigmas de código abierto. En BETWEEN te hablamos de algunos de los más destacados:

S-SDLC (Secure Software Development Life Cycle)

Se basa en verificar los requisitos de seguridad a lo largo de las distintas fases de construcción del software: análisis, diseño, desarrollo, pruebas y mantenimiento. Sobre todo, durante las dos primeras, ya que gran parte de las debilidades de los sistemas se generan incluso antes de comenzar las tareas de programación. Las claves del S-SDLC son la atención al detalle, para favorecer la identificación inmediata de las vulnerabilidades; y la mejora continua.

CLASP (Comprehensive Lightweight Application Security Process)

CLASP (Proceso de seguridad en aplicación completo y ligero) proporciona un enfoque bien organizado y estructurado para mover las inquietudes de seguridad a las fases iniciales del ciclo de vida de desarrollo de software, cuando esto sea posible.

Un proyecto del OWASP que establece una serie de actividades, roles y buenas prácticas dirigidas a coordinar los procesos de desarrollo seguro de software. La organización OWASP CLASP se asienta en cinco perspectivas o vistas que abordan los conceptos generales de esta metodología, la distribución de funciones, la valoración de las actividades aplicables, la implementación de estas actividades, y el listado de problemas que pueden dar lugar a la aparición de vulnerabilidades.

Las actividades de la metodología CLASP están descritas en la siguiente Figura 6, debido a que está definido en un modelo basado en perfiles o roles dentro de un grupo de buenos lineamientos.

La estructura que constituye la metodología CLASP se desarrolla a través de 5 etapas:

Vista de conceptos: Proporciona una introducción de alto nivel a la metodología. Describe de manera breve la interacción de las diferentes vistas, las mejores prácticas, en que secuencia aplicar los componentes.

Esta vista se divide en:

Descripción estructurada de cada uno de los componentes.
preparar alternativas razonables para el uso de las mejores prácticas de seguridad dentro del ciclo de vida del proyecto.

Vista basada en roles: Contiene instrucciones del proceso basadas en funciones. Acá se crean los relojes requeridos para la implementación de las prácticas de seguridad
Vista de evaluación de actividades: Ayuda a los responsables de proyecto a evaluar las actividades más idóneas para aplicar durante el desarrollo. CLASP proporciona cierto soporte para ayudar a elegirlas.
Vista de implementación de actividades: Contiene todas las actividades CLASP de seguridad que pueden ser integradas en el desarrollo del software. Las actividades de SDLC generan un software seguro gracias a las actividades evaluadas y aceptadas durante la evaluación.
Vista de vulnerabilidades: Está formada por un catálogo de diferentes problemas identificados previamente por CLASP que forman la BBDD de vulnerabilidades que se generan en el código fuente del software. Estas se clasifican en cinco categorías diferentes. Además, asociados a esta vista, se describen las condiciones en las que los servicios de seguridad suelen tener vulnerabilidades en la capa de aplicación. También se proporcionan ejemplos prácticos muy sencillos de entender relacionándolos con el origen de la falla y sus posibles soluciones.

SSDF (Secure Software Development Framework)

Iniciativa del NIST (National Institute of Standards and Technology de Estados Unidos), provee indicaciones para evangelizar a la organización acerca de la importancia de la seguridad informática; proteger el software de uso habitual ante hipotéticos ataques; orquestar un desarrollo seguro de software; y detectar y solucionar con rapidez cualquier vulnerabilidad.

Esta es una metodología ideal para cualquier tipo de organización, sin importar su tamaño o mercado. Las prácticas dentro de esta metodología están organizadas en 4 grupos:

Preparar la organización (PO): las organizaciones deben asegurarse que su personal, procesos y tecnología esté preparada para gestionar un proceso de desarrollo de software seguro en todos los niveles organizacionales. Dichas prácticas deberán ser aplicables de manera transversal a los procesos organizacionales y a diferentes escalas.
Proteger el software (PS): las organizaciones deberán proteger todos los componentes de software de acceso y manipulación no autorizada.
Producir Software bien asegurado (PW): las organizaciones deberán producir software con mínimas vulnerabilidades en sus despliegues.
Responder a las vulnerabilidades (RV): las organizaciones deberán identificar las vulnerabilidades residuales de sus productos de software y dar una respuesta apropiada , direccionando esas vulnerabilidades y previniendo vulnerabilidades similares en el futuro.

Metodología opensamm

El Modelo de Madurez de Software Assurance (OpenSAMM), es un modelo abierto que permite a las organizaciones formular e implementar una estrategia para la seguridad del software. Este modelo intenta resolver, en específico los riesgos de seguridad de software que enfrenta la organización. La metodología OpenSAMM ayudarán a:

La metodología OPENSAMM define cuatro categorías o actividades para garantizar el éxito del proceso:

Gobernabilidad
Construcción
Verificación
Implementación

Buscar este blog

Portafolio Yeison Betancur IU Pascual Bravo

Seguridad en las fases del desarrollo de software