Proceso del desarrollo del software

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.

Historia

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. 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

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.

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.

Prácticas

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]}

Integración continua

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. 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. 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.

Prototipado

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.

Desarrollo incremental

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.

Desarrollo rápido de aplicaciones

Desarrollo de Aplicación rápida (RAD) Modelo

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.

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.

Metodologías

Desarrollo ágil

Esta sección es un extracto de Desarrollo ágil de software.[editar]

En el desarrollo de software, las prácticas ágiles (a veces denominadas "Agile") consisten en la mejora de requisitos, investigación y soluciones mediante el esfuerzo colaborativo de equipos autoorganizados y multifuncionales junto con sus clientes/usuarios finales. Popularizados en el Manifiesto por el Desarrollo Ágil de Software de 2001, estos valores y principios se derivaron de, y sustentan, una amplia gama de modelos de desarrollo de software, incluidos Scrum y Kanban.

Aunque hay muchas evidencias anecdóticas de que la adopción de prácticas y valores ágiles mejora la eficacia de los profesionales del software, así como de los equipos y las organizaciones, las pruebas empíricas son dispares y difíciles de encontrar.

Desarrollo en cascada

Esta sección es un extracto de Desarrollo en cascada.[editar]

En Ingeniería de software el desarrollo en cascada, también llamado secuencial o ciclo de vida de un programa (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es un modelo de desarrollo de software que ordena las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del software.
3. Implementación.
4. Pruebas.
5. Despliegue del programa.
6. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

Desarrollo de espiral

Esta sección es un extracto de Desarrollo en espiral.[editar]

Diagrama explicando los pasos del modelo de desarrollo en espiral y sus fases: Análisis, evaluación, desarrollo, planificación.

El desarrollo en espiral es un modelo de desarrollo de software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la ingeniería de software.

Las actividades de este modelo consisten en la conformación de una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Otros

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

• Desarrollo orientado al comportamiento y gestión de procesos de negocio.
• 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).

Procesar los meta-modelos

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.

En la práctica

Los tres enfoques básicos aplicados a los marcos metodológicos de desarrollo de software.

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.

Ciclo de vida de desarrollo de software (SDLC)

Véase también

• Anexo:Filosofías del desarrollo de software
• Ciclo de vida del lanzamiento de software
• Gestión de proyectos
• Herramienta CASE
• Proceso para el desarrollo de software
• OpenUP
• Top-down y bottom-up

Enlaces externos

• 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

• Datos: Q2904257
• Multimedia: Software development methodology / Q2904257