Proceso de desarrollo de software

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Software development process" – news · newspapers · books · scholar · JSTOR (December 2010) (Learn how and when to remove this message)

En ingeniería de software , un proceso de desarrollo de software o ciclo de vida de desarrollo de software ( SDLC ) es un proceso de planificación y gestión del desarrollo de software . Por lo general, implica dividir el trabajo de desarrollo de software en pasos o subprocesos más pequeños, paralelos o secuenciales para mejorar el diseño o la gestión del producto . La metodología puede incluir la predefinición de entregables y artefactos específicos que crea y completa un equipo de proyecto para desarrollar o mantener una aplicación. ^[1]

La mayoría de los procesos de desarrollo modernos pueden describirse vagamente como ágiles . Otras metodologías incluyen la cascada , la creación de prototipos , el desarrollo iterativo e incremental , el desarrollo en espiral , el desarrollo rápido de aplicaciones y la programación extrema .

Un "modelo" de ciclo de vida a veces se considera un término más general para una categoría de metodologías y un "proceso" de desarrollo de software es una instancia particular adoptada por una organización específica. ^{[ cita requerida ]} Por ejemplo, muchos procesos de desarrollo de software específicos se ajustan al modelo de ciclo de vida en espiral. El campo a menudo se considera un subconjunto del ciclo de vida del desarrollo de sistemas .

El marco metodológico de desarrollo de software no surgió hasta la década de 1960. Según Elliott (2004), el ciclo de vida del desarrollo de sistemas puede considerarse el marco metodológico formalizado más antiguo para la construcción de sistemas de información . La idea principal del ciclo de vida del desarrollo de software ha sido "perseguir el desarrollo de sistemas de información de una manera muy deliberada, estructurada y metódica, requiriendo que cada etapa del ciclo de vida, desde el inicio de la idea hasta la entrega del sistema final, se lleve a cabo de manera rígida y secuencial" ^[2] dentro del contexto del marco que se aplica. El objetivo principal de este marco metodológico en la década de 1960 era "desarrollar sistemas empresariales funcionales a gran escala en una era de conglomerados empresariales a gran escala. Las actividades de los sistemas de información giraban en torno a rutinas intensivas de procesamiento de datos y de análisis numérico ". ^[2]

Recopilación y análisis de requisitos: la primera fase del proceso de desarrollo de software personalizado implica comprender los requisitos y objetivos del cliente. Esta etapa generalmente implica participar en debates exhaustivos y realizar entrevistas con las partes interesadas para identificar las características y funcionalidades deseadas y el alcance general del software. El equipo de desarrollo trabaja en estrecha colaboración con el cliente para analizar los sistemas y flujos de trabajo existentes, determinar la viabilidad técnica y definir los hitos del proyecto.

Planificación y diseño: una vez que se comprenden los requisitos, el equipo de desarrollo de software personalizado procede a crear un plan de proyecto integral. Este plan describe la hoja de ruta de desarrollo, incluidos los plazos, la asignación de recursos y los resultados. La arquitectura y el diseño del software también se establecen durante esta fase. Se tienen en cuenta los elementos de diseño de la interfaz de usuario (UI) y la experiencia del usuario (UX) para garantizar la facilidad de uso, la intuición y el atractivo visual del software.

Desarrollo: Una vez que se han establecido la planificación y el diseño, el equipo de desarrollo comienza el proceso de codificación. Esta fase implica escribir , probar y depurar el código del software. Las metodologías ágiles, como Scrum o Kanban, se emplean a menudo para promover la flexibilidad, la colaboración y el desarrollo iterativo. La comunicación regular entre el equipo de desarrollo y el cliente garantiza la transparencia y permite realizar comentarios y ajustes rápidamente.

Pruebas y control de calidad: para garantizar la fiabilidad, el rendimiento y la seguridad del software, se llevan a cabo rigurosos procesos de prueba y control de calidad. Se emplean diferentes técnicas de prueba, incluidas pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación del usuario, para identificar y corregir cualquier problema o error. Las actividades de control de calidad tienen como objetivo validar el software en relación con los requisitos predefinidos, garantizando que funcione según lo previsto.

Implementación y despliegue: Una vez que el software pasa la fase de prueba, está listo para su implementación y despliegue. El equipo de desarrollo ayuda al cliente a configurar el entorno de software, migrar datos si es necesario y configurar el sistema. También se proporciona capacitación y documentación para el usuario para garantizar una transición sin problemas y permitir que los usuarios maximicen el potencial del software.

Mantenimiento y soporte: después de implementar el software, el mantenimiento y el soporte continuos se vuelven cruciales para abordar cualquier problema, mejorar el rendimiento e incorporar mejoras futuras. Se lanzan actualizaciones periódicas, correcciones de errores y parches de seguridad para mantener el software actualizado y seguro. Esta fase también implica brindar soporte técnico a los usuarios finales y abordar sus consultas o inquietudes. Las metodologías, los procesos y los marcos varían desde pasos prescriptivos específicos que una organización puede usar directamente en el trabajo diario hasta marcos flexibles que una organización usa para generar un conjunto personalizado de pasos adaptados a las necesidades de un proyecto o grupo específico. En algunos casos, una organización "patrocinadora" o de "mantenimiento" distribuye un conjunto oficial de documentos que describen el proceso. Algunos ejemplos específicos incluyen:

Década de 1970

• Programación estructurada desde 1969
• Cap Gemini SDM , originalmente de PANDATA, la primera traducción al inglés se publicó en 1974. SDM significa Metodología de Desarrollo de Sistemas

Década de 1980

• Método de análisis y diseño de sistemas estructurados (SSADM) a partir de 1980
• Análisis de requerimientos de información/Metodología de sistemas blandos

Década de 1990

• La programación orientada a objetos (POO) se desarrolló a principios de la década de 1960 y se convirtió en un enfoque de programación dominante a mediados de la década de 1990.
• Desarrollo rápido de aplicaciones (RAD), desde 1991
• Método de desarrollo de sistemas dinámicos (DSDM), desde 1994
• Scrum , desde 1995
• Proceso de software en equipo , desde 1998
• Rational Unified Process (RUP), mantenido por IBM desde 1998
• Programación extrema , desde 1999

Década de 2000

• Proceso Unificado Ágil (AUP) mantenido desde 2005 por Scott Ambler
• La entrega ágil disciplinada (DAD) reemplaza a la AUP

Década de 2010

• Marco ágil escalable (SAFe)
• Scrum a gran escala (LeSS)
• DevOps

Desde la introducción de DSDM en 1994, todas las metodologías de la lista anterior, excepto RUP, han sido metodologías ágiles; sin embargo, muchas organizaciones, especialmente los gobiernos, aún utilizan procesos preágiles (a menudo en cascada o similares). El proceso de software y la calidad del software están estrechamente relacionados; se han observado algunas facetas y efectos inesperados en la práctica. ^[3]

Entre estos, se ha establecido otro proceso de desarrollo de software en código abierto . La adopción de estas mejores prácticas conocidas y procesos establecidos dentro de los confines de una empresa se denomina código interno .

La creación de prototipos de software consiste en crear prototipos, es decir, versiones incompletas del programa de software que se está desarrollando.

Los principios básicos son: ^[1]

• La creación de prototipos no es una metodología de desarrollo completa e independiente, sino más bien un enfoque para probar características particulares en el contexto de una metodología completa (como el desarrollo de aplicaciones incremental, en espiral o rápido (RAD)).
• Intenta reducir el riesgo inherente del proyecto dividiéndolo en segmentos más pequeños y brindando mayor facilidad de cambio durante el proceso de desarrollo.
• El cliente está involucrado durante todo el proceso de desarrollo, lo que aumenta la probabilidad de que el cliente acepte la implementación final.
• Si bien algunos prototipos se desarrollan con la expectativa de que serán descartados, en algunos casos es posible evolucionar desde un prototipo hasta un sistema funcional.

Es necesaria una comprensión básica del problema empresarial fundamental para evitar resolver los problemas equivocados, pero esto es cierto para todas las metodologías de software.

El término "desarrollo de software ágil" hace referencia a un grupo de marcos de desarrollo de software basados ​​en el desarrollo iterativo, en el que los requisitos y las soluciones evolucionan mediante la colaboración entre equipos multifuncionales autoorganizados. El término se acuñó en el año 2001, cuando se formuló el Manifiesto Ágil .

El desarrollo de software ágil utiliza el desarrollo iterativo como base, pero aboga por un punto de vista más ligero y centrado en las personas que los enfoques tradicionales. Los procesos ágiles incorporan fundamentalmente la iteración y la retroalimentación continua que proporciona para refinar y entregar sucesivamente un sistema de software.

El modelo Agile también incluye los siguientes procesos de desarrollo de software:

• Método de desarrollo de sistemas dinámicos (DSDM)
• Kanban
• Melé
• Desarrollo de software lean

La integración continua es la práctica de fusionar todas las copias de trabajo de los desarrolladores en una línea principal compartida varias veces al día. ^[4] Grady Booch nombró y propuso por primera vez la CI en su método de 1991 , ^[5] aunque no defendió la integración varias veces al día. La programación extrema (XP) adoptó el concepto de CI y sí defendió la integración más de una vez al día, quizás hasta decenas de veces al día.

Son aceptables varios métodos para combinar metodologías de desarrollo de sistemas lineales e iterativos, siendo el objetivo principal de cada uno reducir el riesgo inherente del proyecto al dividirlo en segmentos más pequeños y brindar mayor facilidad de cambio durante el proceso de desarrollo.

Existen tres variantes principales del desarrollo incremental: ^[1]

1. Se realizan una serie de mini-cascadas, donde se completan todas las fases de la cascada para una pequeña parte de un sistema, antes de proceder al siguiente incremento, o
2. Los requisitos generales se definen antes de proceder al desarrollo evolutivo en mini cascada de incrementos individuales de un sistema, o
3. El concepto inicial del software, el análisis de requisitos y el diseño de la arquitectura y el núcleo del sistema se definen mediante un proceso en cascada, seguido de una implementación incremental que culmina con la instalación de la versión final, un sistema funcional.

El desarrollo rápido de aplicaciones (RAD, por sus siglas en inglés) es una metodología de desarrollo de software que favorece el desarrollo iterativo y la construcción rápida de prototipos en lugar de grandes cantidades de planificación previa. La "planificación" del software desarrollado mediante RAD se intercala con la escritura del software en sí. La falta de una planificación previa exhaustiva generalmente permite escribir el software mucho más rápido y facilita el cambio de requisitos.

El proceso de desarrollo rápido comienza con el desarrollo de modelos preliminares de datos y modelos de procesos de negocio utilizando técnicas estructuradas . En la siguiente etapa, se verifican los requisitos mediante la creación de prototipos, para finalmente refinar los modelos de datos y procesos. Estas etapas se repiten de forma iterativa; el desarrollo posterior da como resultado "una declaración combinada de requisitos de negocio y diseño técnico que se utilizará para construir nuevos sistemas". ^[6]

El término se utilizó por primera vez para describir un proceso de desarrollo de software introducido por James Martin en 1991. Según Whitten (2003), es una fusión de varias técnicas estructuradas , especialmente ingeniería de tecnología de la información basada en datos , con técnicas de creación de prototipos para acelerar el desarrollo de sistemas de software. ^[6]

Los principios básicos del desarrollo rápido de aplicaciones son: ^[1]

• El objetivo clave es el rápido desarrollo y la entrega de un sistema de alta calidad a un coste de inversión relativamente bajo.
• Intenta reducir el riesgo inherente del proyecto dividiéndolo en segmentos más pequeños y brindando mayor facilidad de cambio durante el proceso de desarrollo.
• Su objetivo es producir sistemas de alta calidad rápidamente, principalmente a través de prototipos iterativos (en cualquier etapa del desarrollo), participación activa del usuario y herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de interfaces gráficas de usuario (GUI), herramientas de ingeniería de software asistida por computadora (CASE), sistemas de administración de bases de datos (DBMS), lenguajes de programación de cuarta generación , generadores de código y técnicas orientadas a objetos.
• El énfasis principal está en satisfacer la necesidad del negocio, mientras que la excelencia tecnológica o de ingeniería es de menor importancia.
• El control de proyectos implica priorizar el desarrollo y definir plazos de entrega o “cronogramas”. Si el proyecto empieza a retrasarse, el énfasis se pone en reducir los requisitos para ajustarse al cronograma, no en aumentar el plazo.
• Generalmente incluye el diseño de aplicaciones conjuntas (JAD), donde los usuarios participan intensamente en el diseño del sistema , a través de la creación de consenso en talleres estructurados o interacción facilitada electrónicamente.
• La participación activa del usuario es imprescindible.
• Produce software de producción de forma iterativa, a diferencia de un prototipo desechable.
• Produce la documentación necesaria para facilitar el desarrollo y mantenimiento futuros.
• En este marco se pueden incorporar métodos estándar de análisis y diseño de sistemas.

El modelo en cascada es un enfoque de desarrollo secuencial, en el que el desarrollo se considera que fluye de manera constante hacia abajo (como una cascada) a través de varias fases, generalmente:

• Análisis de requisitos que da como resultado una especificación de requisitos de software
• Diseño de software
• Implementación
• Pruebas
• Integración , si hay varios subsistemas
• Implementación (o instalación )
• Mantenimiento

La primera descripción formal del método se cita a menudo en un artículo publicado por Winston W. Royce ^[7] en 1970, aunque Royce no utilizó el término "cascada" en este artículo. Royce presentó este modelo como un ejemplo de un modelo defectuoso y que no funciona. ^[8]

Los principios básicos son: ^[1]

• El proyecto se divide en fases secuenciales, con cierta superposición y salpicaduras aceptables entre fases.
• Se hace hincapié en la planificación, los cronogramas, las fechas objetivo, los presupuestos y la implementación de un sistema completo a la vez.
• Se mantiene un control estricto durante la vida del proyecto mediante una extensa documentación escrita, revisiones formales y la aprobación/firma por parte del usuario y la gerencia de tecnología de la información que se produce al final de la mayoría de las fases antes de comenzar la siguiente. La documentación escrita es un entregable explícito de cada fase.

El modelo en cascada es un enfoque de ingeniería tradicional aplicado a la ingeniería de software. Un enfoque en cascada estricto desalienta la revisión y modificación de cualquier fase anterior una vez que se ha completado. ^{[¿ según quién? ]} Esta "inflexibilidad" en un modelo en cascada puro ha sido una fuente de críticas por parte de los partidarios de otros modelos más "flexibles". Se le ha culpado ampliamente de varios proyectos gubernamentales a gran escala que se han excedido en el presupuesto, en el tiempo y, a veces, no han cumplido con los requisitos debido al enfoque de diseño a gran escala por adelantado . ^{[ ¿según quién? ]} Excepto cuando se requiere contractualmente, el modelo en cascada ha sido reemplazado en gran medida por metodologías más flexibles y versátiles desarrolladas específicamente para el desarrollo de software. ^{[ ¿según quién? ]} Ver Crítica del modelo en cascada .

En 1988, Barry Boehm publicó un "modelo en espiral" de desarrollo de sistemas de software formal, que combina algunos aspectos clave del modelo en cascada y metodologías de creación rápida de prototipos , en un esfuerzo por combinar las ventajas de los conceptos de arriba hacia abajo y de abajo hacia arriba . Puso énfasis en un área clave que muchos consideraban que había sido descuidada por otras metodologías: el análisis deliberado de riesgos iterativos, particularmente adecuado para sistemas complejos a gran escala.

Los principios básicos son: ^[1]

• El enfoque se centra en la evaluación de riesgos y en minimizar el riesgo del proyecto dividiéndolo en segmentos más pequeños y brindando mayor facilidad de cambio durante el proceso de desarrollo, además de brindar la oportunidad de evaluar los riesgos y sopesar la consideración de la continuación del proyecto a lo largo de su ciclo de vida.
• “Cada ciclo implica una progresión a través de la misma secuencia de pasos, para cada parte del producto y para cada uno de sus niveles de elaboración, desde un documento de concepto global de funcionamiento hasta la codificación de cada programa individual.” ^[9]
• Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar objetivos, alternativas y restricciones de la iteración, (2) evaluar alternativas; identificar y resolver riesgos; (3) desarrollar y verificar los resultados de la iteración; y (4) planificar la siguiente iteración. ^[10]
• Comience cada ciclo con una identificación de las partes interesadas y sus “condiciones ganadoras”, y finalice cada ciclo con una revisión y un compromiso. ^[11]

Shape Up es un enfoque de desarrollo de software introducido por Basecamp en 2018. Es un conjunto de principios y técnicas que Basecamp desarrolló internamente para superar el problema de los proyectos que se prolongan sin un final claro. Su público objetivo principal son los equipos remotos. Shape Up no tiene estimación ni seguimiento de la velocidad, registros de trabajo pendientes ni sprints, a diferencia de waterfall , agile o scrum . En cambio, esos conceptos se reemplazan por apetito, apuestas y ciclos. A partir de 2022, además de Basecamp, las organizaciones notables que han adoptado Shape Up incluyen UserVoice y Block. ^{[12] [13]}

Otras metodologías de proyectos de software de alto nivel incluyen:

• Desarrollo impulsado por el comportamiento y gestión de procesos de negocio. ^[14]
• Modelo de caos : la regla principal siempre resuelve primero el problema más importante.
• Metodología de financiación incremental : un enfoque iterativo
• Metodología ligera : término general para métodos que solo tienen unas pocas reglas y prácticas.
• Método de análisis y diseño de sistemas estructurados : una versión específica de la cascada
• La programación lenta, como parte del Movimiento Slow , enfatiza el trabajo cuidadoso y gradual sin presiones de tiempo (o con presiones mínimas). La programación lenta tiene como objetivo evitar errores y cronogramas de lanzamiento demasiado rápidos.
• Modelo V (desarrollo de software) : una extensión del modelo en cascada
• El Proceso Unificado (UP) es un marco metodológico iterativo de desarrollo de software, basado en el Lenguaje Unificado de Modelado (UML). UP organiza el desarrollo de software en cuatro fases, cada una de las cuales consta de una o más iteraciones ejecutables del software en esa etapa de desarrollo: concepción, elaboración, construcción y directrices.

Algunos " modelos de proceso " son descripciones abstractas para evaluar, comparar y mejorar el proceso específico adoptado por una organización.

• ISO/IEC 12207 es el estándar internacional que describe el método para seleccionar, implementar y monitorear el ciclo de vida del software.
• El modelo de integración de madurez de capacidades (CMMI) es uno de los modelos líderes y se basa en las mejores prácticas. Las evaluaciones independientes califican a las organizaciones en función de lo bien que siguen sus procesos definidos, no en función de la calidad de esos procesos o del software producido. CMMI ha reemplazado a CMM .
• La norma ISO 9000 describe los estándares para un proceso formalmente organizado de fabricación de un producto y los métodos de gestión y seguimiento del progreso. Aunque la norma se creó originalmente para el sector manufacturero, las normas ISO 9000 también se han aplicado al desarrollo de software. Al igual que CMMI, la certificación con ISO 9000 no garantiza la calidad del resultado final, solo que se han seguido procesos empresariales formalizados.
• La norma ISO/IEC 15504 Tecnología de la información: evaluación de procesos, también conocida como determinación de la capacidad de mejora de procesos de software (SPICE), es un "marco para la evaluación de procesos de software". Esta norma tiene como objetivo establecer un modelo claro para la comparación de procesos. SPICE se utiliza de forma muy similar a CMMI. Modela procesos para gestionar, controlar, guiar y supervisar el desarrollo de software. Este modelo se utiliza luego para medir lo que una organización de desarrollo o un equipo de proyecto hace realmente durante el desarrollo de software. Esta información se analiza para identificar debilidades e impulsar la mejora. También identifica fortalezas que se pueden continuar o integrar en la práctica común para esa organización o equipo.
• ISO/IEC 24744 Ingeniería de software: metamodelo para metodologías de desarrollo , es un metamodelo basado en tipos de potencia para metodologías de desarrollo de software.
• Metodología de sistemas blandos : un método general para mejorar los procesos de gestión.
• Ingeniería de métodos : un método general para mejorar los procesos del sistema de información.

A lo largo de los años se han desarrollado diversos marcos de trabajo de este tipo, cada uno con sus propias fortalezas y debilidades reconocidas. No siempre es posible utilizar un marco de trabajo de metodología de desarrollo de software en todos los proyectos. Cada uno de los marcos de trabajo de metodología disponibles es el más adecuado para tipos específicos de proyectos, en función de diversas consideraciones técnicas, organizativas, de proyecto y de equipo. ^[1]

• Ciclo de vida del desarrollo de sistemas
• Ingeniería de software asistida por computadora (algunas de estas herramientas admiten metodologías específicas)
• Lista de filosofías de desarrollo de software
• Esquema de ingeniería de software
• Gestión de proyectos de software
• Desarrollo de software
• Estimación del esfuerzo de desarrollo de software
• Ciclo de vida del lanzamiento de software
• Diseño de arriba hacia abajo y de abajo hacia arriba#Ciencias de la computación

Wikimedia Commons tiene medios relacionados con Metodología de desarrollo de software .

• Selección de un enfoque de desarrollo en cms.hhs.gov.
• Gerhard Fischer, "La tecnología del software del siglo XXI: de la reutilización de software al diseño colaborativo de software", 2001