Se ha sugerido que este artículo o sección sea fusionado con Proceso para el desarrollo de software. Para más información, véase la discusión. Una vez que hayas realizado la fusión de contenidos, pide la fusión de historiales aquí. Este aviso fue puesto el 10 de diciembre de 2018.

En ingeniería del software, un proceso de desarrollo del software es el proceso de dividir el trabajo de desarrollo del software en distintas fases para mejorar el diseño, la gestión del producto, y la gestión de proyecto. Es también conocido como el ciclo de vida del desarrollo de software. La metodología puede incluir la pre-definición de entregas concretas y artefactos que son creados y completados por un equipo del proyecto para desarrollar o mantener una aplicación.

La mayoría de procesos de desarrollo modernos pueden ser vagamente descritos como ágiles. Otras metodologías incluyen desarrollo en cascada, prototipado, desarrollo iterativo e incremental, desarrollo de espiral, desarrollo de aplicación rápida, y programación extrema.

Algunas personas consideran el "modelo" del ciclo de vida un término más general para una categoría de las metodologías y el "proceso" de desarrollo de software un término más concreto para referirse a un proceso concreto escogido por una organización específica. Por ejemplo, hay muchos procesos de desarrollo de software concretos que encajan en la espiral del modelo del ciclo de vida. Este campo es a menudo considerado un subconjunto del ciclo de vida del desarrollo de sistemas.

El marco de la metodología de desarrollo del software (también conocida como SDM) no emergió hasta los 60. Según Elliott (2004) el ciclo de vida del desarrollo de sistemas (SDLC) puede ser considerado el marco de metodología formalizado más antiguo por haber construido los sistemas de información. La idea principal del SDLC ha sido "perseguir el desarrollo de sistemas de la información de manera deliberada, estructurada y metódica, requiriendo cada etapa del ciclo de vida ––desde el comienzo de la idea hasta la entrega final del sistema–– para que sea realizado rígida y secuencialmente" dentro del contexto en el que el marco se aplique.^[1]​ El objetivo principal de este marco de metodología en los 60 era "para desarrollar sistemas empresariales funcionales a gran escala en una era de conglomerados de negocios a gran escala. Las actividades de los sistemas de la información evolucionaron alrededor del procesamiento de datos pesados y las rutinas de procesamiento de números".

Las metodologías, los procesos, y la gama de marcos de pasos proscriptivos específicos que pueden ser utilizados directamente por una organización en el trabajo del día a día, a marcos flexibles que una organización usa para generar un conjunto de pasos a medida según las necesidades de un proyecto específico o un grupo. En algunos casos la organización "patrocinadora" o "que aporta la manutención" distribuye un conjunto oficial de documentos que describen el proceso. Los ejemplos concretos incluyen:

1970s

• Programación estructurada desde 1969
• Cap Gemini SDM, originalmente de PANDATA, la primera traducción inglesa fue publicada en 1974. SDM se mantiene para la Metodología de Desarrollo de Sistemas

1980s

• Análisis de sistemas estructurados y método de diseño (SSADM) desde 1980 en adelante
• Análisis de los requisitos de la información/metodología del software de los sistemas

1990s

• La programación orientada a objetos (POO) se desarrolló al principio de los 60, y se convirtió en el enfoque dominante de la programación a mediados de los 90
• Desarrollo rápido de aplicaciones (RAD), desde 1991
• Método dinámico de desarrollo de sistemas (DSDM), desde 1994
• Scrum, desde entonces 1995
• Proceso de software en equipo, desde 1998
• Proceso Unificado racional (RUP), mantenido por IBM desde 1998
• Programación extrema, desde 1999

2000s

• Proceso Unificado ágil (AUP) mantenido desde 2005 por Scott Ambler
• Entrega ágil disciplinada (DAD) sustituye AUP

2010s

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

• Procesos híbridos de desarrollo de software

Es notable que desde DSDM en 1994, todas las metodologías de la lista de arriba, excepto RUP, han sido metodologías ágiles - aun así muchas organizaciones, especialmente gobiernos, todavía utilizan procesos anteriores a las metodologías ágiles (a menudo cascada o similar). El proceso de software y la calidad del software están estrechamente interrelacionados; algunos efectos y facetas inesperados han sido observados en la práctica^[2]​

Desde los inicios de los 2000s el escalado de los procesos de entrega ágil se han convertido el reto más grande para los equipos que utilizan procesos ágiles.^[3]​

Entre estos, otro proceso de desarrollo del software ha sido establecido en código abierto. La adopción de estas buenas prácticas conocidas y procesos establecidos dentro de los límites de una compañía se llama fuente interior.

Varias aproximaciones del desarrollo del software han sido utilizadas desde el origen de tecnología de la información, en dos categorías principales .^{[cita requerida]} Normalmente una aproximación o una combinación de aproximaciones es escogida por un equipo de gestión o de desarrollo .^{[cita requerida]}

Las metodologías "tradicionales" como la de cascada, que tiene distintas fases, son a veces conocidas como metodologías del ciclo de vida de desarrollo de software (SDLC), aunque este término también podría ser utilizado de manera más general para referirse a cualquier metodología.^{[cita requerida]} Un enfoque del "ciclo de vida" con distintas fases contrasta con los enfoques de las ágiles que definen el proceso de iteración, pero donde el diseño, la construcción, y el despliegue de partes diferentes pueden ocurrir simultáneamente .^{[cita requerida]}

La integración continua es la práctica de juntar todas las copias del trabajo de los desarrolladores en una rama principal compartida varias veces al día.^[4]​ Grady Booch primero denominó y propuso el CI en su método de 1991, a pesar de que no defienda hacer la integración varias veces al día.^[5]​ La programación extrema (XP) adoptó el concepto de CI y defendió que se hiciera la integración más de una vez al día – quizás tantas veces como decenas de muchos como decenas de veces al día.

El prototipado de software consiste en la creación prototipos, p.e. las versiones incompletas del software de un programa siendo desarrollado.

Los principios básicos son:

• El prototipado 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 incremental, espiral o rápido de aplicaciones (RAD)).
• Intentos de reducir los riesgos inherentes del proyecto a base de dividir un proyecto en pequeños segmentos proporcionando facilidad de cambio durante el proceso de desarrollo.
• El cliente está implicado durante el proceso de desarrollo, lo cual aumenta la probabilidad de que el cliente acepte la implementación final.
• Mientras algunos prototipos están desarrollados con la expectativa de que serán descartados, es posible que en algunos casos evolucionen de prototipo a sistema operativo.

Una comprensión básica del problema fundamental del negocio es necesaria para evitar resolver los problemas equivocados, pero esto se cumple para todas las metodologías del software.

Varios métodos son aceptables para combinar metodologías de desarrollo de sistemas lineales e iterativos, con el objetivo principal de reducir el riesgo inherente del proyecto al dividir un proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.

Hay tres variantes principales de desarrollo incremental

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

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo del software, que favorece desarrollo iterativo y la construcción rápida de prototipos en lugar de grandes cantidades de planificación inicial. La "planificación" del software desarrollado utilizando RAD se intercala con la escritura del propio software. La falta de una planificación previa extensa generalmente permite que el software se escriba mucho más rápido, y hace que sea más fácil cambiar los requisitos.

El proceso de rápido desarrollo comienza con el desarrollo de modelos de datos preliminares y modelos de procesos de negocios utilizan técnicas estructuradas. En la siguiente etapa, los requisitos se verifican mediante el prototipado para eventualmente refinar los modelos de datos y procesos. Estas etapas se repiten iterativamente; un mayor desarrollo da como resultado "una declaración de requisitos técnicos y diseño técnico combinados que se utilizará para construir nuevos sistemas".

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:

• El objetivo clave es el rápido desarrollo y la entrega de un sistema de alta calidad a un costo de inversión relativamente bajo.
• Intenta reducir el riesgo inherente del proyecto dividiendo un proyecto en segmentos más pequeños y proporcionando más facilidad de cambio durante el proceso de desarrollo.
• Tiene como objetivo producir sistemas de alta calidad rápidamente, principalmente a través de prototipos iterativos (en cualquier etapa de 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 Ordenador (CASO), Sistemas de Administración de Bases de Datos (SGBD), lenguajes de programación de cuarta generación, generadores de código y técnicas orientadas a objetos.
• El control del proyecto implica priorizar el desarrollo y definir plazos de entrega o "cajas de tiempo". Si el proyecto comienza a decaer, hay que hacer énfasis en reducir los requisitos para adaptarse a la caja de tiempo, no en aumentar el plazo.
• Control de proyecto implica priorizar desarrollo y definiendo fechas límite de entrega o “timeboxes”. Si los inicios de proyecto para resbalar, el énfasis encima está reduciendo requisitos para caber el timebox, no en crecientes la fecha límite.
• Generalmente incluye el diseño de aplicaciones conjuntas (JAD), donde los usuarios participan intensamente en el diseño del sistema, a través de construir consensuadamente ya sea en talleres estructurados, o en una interacción facilitada electrónicamente.
• La participación activa del usuario es imprescindible.
• Produce iterativamente software de producción, a diferencia de un prototipo desechable.
• Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.
• Los métodos estándar de análisis y diseño de sistemas pueden incluirse en este marco.

El "desarrollo ágil de software" se refiere a un grupo de metodologías de desarrollo de software basadas en el desarrollo iterativo, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos multifuncionales autoorganizados. El término fue acuñado en el año 2001 cuando se formuló el Manifesto Ágil.

El desarrollo ágil de software utiliza el desarrollo iterativo como base, pero aboga por un punto de vista más ligero y más 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.

Hay muchas metodologías ágiles, incluyendo:

• Método de desarrollo de sistemas dinámicos (DSDM)
• Kanban
• Scrum

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

• Análisis de requisitos que resulta en una especificación de requisitos de software
• Diseño del software
• Implementación
• Testeo
• Integración, si hay múltiples subsistemas
• Despliegue (o Instalación)
• Mantenimiento

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

Los principios básicos son:

• El proyecto se divide en fases secuenciales, con algunas superposiciones y salpicaduras aceptables entre fases.
• El énfasis está en la planificación, los horarios, las fechas objetivo, los presupuestos y la implementación de todo un sistema a la vez.
• Se mantiene un estricto control a lo largo de la vida del proyecto a través de una extensa documentación escrita, revisiones formales y aprobación por parte del usuario, y la administración de la tecnología de la información que se realiza al final de la mayoría de las fases antes de comenzar la siguiente fase. La documentación escrita es un entregable explícito de cada fase.

El modelo de cascada es un enfoque de ingeniería tradicional aplicado a la ingeniería de software. Un enfoque de cascada estricto desalienta la revisión y revisión de cualquier fase previa una vez que esté completa. Esta "inflexibilidad" en un modelo de cascada pura ha sido una fuente de críticas por parte de los partidarios de otros modelos más "flexibles". Se le ha culpado ampliamente a varios proyectos gubernamentales a gran escala que superan el presupuesto, a lo largo del tiempo y en ocasiones no cumplen con los requisitos debido al enfoque de Big Design Up Front . Excepto cuando se requiere por contrato, el modelo de cascada ha sido ampliamente reemplazado por metodologías más flexibles y versátiles desarrolladas específicamente para el desarrollo de software. Ver el la critica del modelo de Cascada.

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

Los principios básicos son:

• Se centra la atención en la evaluación de riesgos y en minimizar el riesgo del proyecto al dividir un proyecto en segmentos más pequeños y brindar mayor facilidad de cambio durante el proceso de desarrollo, así como brindar la oportunidad de evaluar los riesgos y evaluar la continuación del proyecto a lo largo del 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 de operación general hasta la codificación de cada programa individual".^[8]​
• Cada viaje alrededor de la espiral pasa por cuatro cuadrantes básicos: (1) determinar objetivos, alternativas, y limitaciones de la iteración; (2) evaluar alternativas; Identificar y resolver riesgos; (3) desarrollar y verificar entregables de la iteración; y (4) planear la iteración próxima.^[9]​
• Empieza cada ciclo con una identificación de las partes interesadas y sus "condiciones de victoria", y finaliza cada ciclo con una revisión y compromiso.

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

• Desarrollo orientado al comportamiento y gestión de procesos de negocio.^[10]​
• Modelo de caos - La regla principal siempre es resolver primero el problema más importante.
• Metodología de financiamiento incremental - un enfoque iterativo
• Metodología ligera - un término general para métodos que solo tienen algunas reglas y prácticas.
• Análisis de sistemas estructurados y método de diseño - una versión específica de cascada.
• La programación lenta, como parte del Movimiento Lento más grande, enfatiza el trabajo cuidadoso y gradual sin presiones de tiempo (o mínimas). La programación lenta apunta a evitar errores y programas de lanzamiento demasiado rápidos.
• Modelo en V (desarrollo de software) - una extensión del modelo de cascada
• Proceso unificado (UP) es un marco de metodología de desarrollo de software iterativo, basado en Modelo Unificado del Lenguaje (UML). UP organiza el desarrollo del software en cuatro fases, cada una de las cuales consta de una o más iteraciones ejecutables del software en esa etapa de desarrollo: creación, elaboración, construcción y directrices. Existen muchas herramientas y productos para facilitar la implementación de UP. Una de las versiones más populares de UP es el Proceso Unificado Racional (RUP).

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.Capability Maturity Model Integration
• La Integración de Modelos de Madurez de Capacidad (CMMI) es uno de los modelos líderes y se basa en las mejores prácticas. Las evaluaciones independientes califican a las organizaciones sobre la forma en que siguen sus procesos definidos, no sobre la calidad de esos procesos o el software producido. CMMI ha reemplazado a CMM.
• ISO 9000 describe los estándares para un proceso organizado formalmente para fabricar un producto y los métodos de administración y seguimiento del progreso. Aunque el estándar se creó originalmente para el sector de fabricación, los estándares 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 se han seguido los procesos de negocios formalizados.
• ISO/IEC 15504 tecnología de la Información — La evaluación de procesos, también conocida como Determinación de capacidad de mejora de procesos de software (SPICE), es un "marco para la evaluación de procesos de software". Este estándar tiene como objetivo establecer un modelo claro para la comparación de procesos. SPICE se usa como CMMI. Modela procesos para gestionar, controlar, guiar y hacer el seguimiento del desarrollo de software. Este modelo se usa para medir lo que realmente hace una organización de desarrollo o un equipo de proyecto durante el desarrollo de software. Esta información se analiza para identificar las debilidades e impulsar la mejora. También identifica fortalezas que pueden continuarse o integrarse en la práctica común de esa organización o equipo.
• SPEM 2.0 por el Grupo de Gestión de Objetos
• Metodología de sistemas blandos - un método general para mejorar los procesos de gestión.
• Ingeniería de método - un método general para mejorar los procesos del sistema de la información.

Una variedad de dichos marcos han evolucionado a lo largo de los años, reconociendo sus propias ventajas y desventajas. Un marco de metodología de desarrollo de software no es necesariamente adecuado para el uso de todos los proyectos. Cada uno de los marcos metodológicos disponibles se adapta mejor a tipos específicos de proyectos, en función de diversas consideraciones técnicas, organizativas, de proyecto y de equipo.

Las organizaciones de desarrollo de software implementan metodologías de proceso para facilitar el proceso de desarrollo. A veces, los contratistas pueden requerir metodologías empleadas, un ejemplo es la industria de defensa de los EE. UU., que requiere una calificación basada en modelos de procesos para obtener contratos. El estándar internacional para describir el método de selección, implementación y seguimiento del ciclo de vida del software es ISO/IEC 12207.

Durante décadas, el objetivo ha sido encontrar procesos repetitivos y predecibles que mejoren la productividad y la calidad. Algunos intentan sistematizar o formalizar la tarea aparentemente ingobernable de diseñar software. Otros aplican técnicas de gestión de proyectos al diseño de software. Un gran número de proyectos de software no cumple con sus expectativas en términos de funcionalidad, coste o calendario de entregas - ver Lista de proyectos de software personalizados fallidos y con exceso de presupuesto para algunos ejemplos notables.

Las organizaciones pueden crear un Grupo de Procesos de Ingeniería de Software (SEPG), que es el punto focal para la mejora de procesos. Compuesto por profesionales en la línea que tienen habilidades variadas, el grupo está en el centro del esfuerzo de colaboración de todos los miembros de la organización que participan en la mejora del proceso de ingeniería de software.

Un equipo de desarrollo común también puede definir los detalles del entorno, como qué entorno de desarrollo integrado está utilizando, y uno o más paradigmas de programación dominantes, reglas de estilo de programación o la elección de bibliotecas de software o marcos de software específicos. Estos detalles generalmente no están dictados por la elección del modelo o la metodología general.

• Systems development life cycle
• Herramienta CASE
• Anexo:Filosofías del desarrollo de software
• Outline of software engineering
• OpenUP
• Gestión de proyectos
• Proceso para el desarrollo de software
• Software development effort estimation
• Ciclo de vida del lanzamiento de software
• Top-down and bottom-up design#Computer science

• Selecting a development approach at cms.hhs.gov.
• Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design", 2001
• Subway map of agile practices at Agile Alliance