En ingeniería de software , un proceso de desarrollo de software es el proceso de dividir el trabajo de desarrollo de software en pasos o subprocesos más pequeños, paralelos o secuenciales para mejorar el diseño , la gestión de productos y la gestión de proyectos . También se conoce como ciclo de vida de desarrollo de software ( SDLC ). La metodología puede incluir la pre-definición de entregables y artefactos específicos que son creados y completados por un equipo de proyecto para desarrollar o mantener una aplicación. [1]
La mayoría de los procesos de desarrollo modernos se pueden describir vagamente como ágiles . Otras metodologías incluyen cascada , creación de prototipos , desarrollo iterativo e incremental , desarrollo en espiral , desarrollo rápido de aplicaciones y 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 un término más específico para referirse a un proceso específico elegido por una organización específica. [ cita requerida ] Por ejemplo, hay muchos procesos de desarrollo de software específicos que 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 .
Historia
El marco de la metodología de desarrollo de software (también conocido como SDM) no surgió hasta la década de 1960. Según Elliott (2004), el ciclo de vida de desarrollo de sistemas (SDLC) puede considerarse el marco metodológico formalizado más antiguo para la construcción de sistemas de información . La idea principal del SDLC ha sido "perseguir el desarrollo de sistemas de información de una manera muy deliberada, estructurada y metódica, requiriendo cada etapa del ciclo de vida - desde el inicio de la idea hasta la entrega del sistema final - para llevarse a cabo de forma rígida y secuencial " [2] en el contexto del marco que se aplica. El objetivo principal de este marco metodológico en la década de 1960 era "desarrollar sistemas comerciales funcionales a gran escala en una era de conglomerados comerciales a gran escala. Las actividades de los sistemas de información giraban en torno al procesamiento pesado de datos y las rutinas de procesamiento de números ". [2]
Las metodologías, procesos y marcos varían desde pasos proscriptivos 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 a la medida de las necesidades de un proyecto o proyecto específico. grupo. En algunos casos, una organización "patrocinadora" o de "mantenimiento" distribuye un conjunto oficial de documentos que describen el proceso. Los ejemplos específicos incluyen:
- 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
- Decenio de 1980
- Método de diseño y análisis de sistemas estructurados (SSADM) desde 1980 en adelante
- Análisis de requisitos de información / metodología de sistemas blandos
- Decenio de 1990
- La programación orientada a objetos (OOP) 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 del equipo , desde 1998
- Proceso unificado racional (RUP), mantenido por IBM desde 1998
- Programación extrema , desde 1999
- 2000
- Proceso unificado ágil (AUP) mantenido desde 2005 por Scott Ambler
- Entrega ágil disciplinada (DAD) Reemplaza AUP
2010
- Marco ágil escalado (SAFe)
- Scrum a gran escala (LeSS)
- DevOps
Es notable que desde DSDM en 1994, todas las metodologías en la lista anterior, excepto RUP, han sido metodologías ágiles; sin embargo, muchas organizaciones, especialmente los gobiernos, todavía usan procesos pre-ágiles (a menudo en cascada o similares). El proceso del software y la calidad del software están estrechamente relacionados entre sí; En la práctica se han observado algunas facetas y efectos inesperados [3].
Entre estos, se ha establecido otro proceso de desarrollo de software en código abierto . La adopción de estas mejores prácticas procesos conocidos y establecidos dentro de los límites de una empresa se denomina fuente interna .
Creación de prototipos
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 incrementales, en espiral o rápido (RAD)).
- Intenta reducir el riesgo inherente del proyecto dividiéndolo en segmentos más pequeños y proporcionando más facilidad de cambio durante el proceso de desarrollo.
- El cliente participa 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 se descarten, en algunos casos es posible evolucionar de prototipos a sistemas operativos.
Es necesario tener una comprensión básica del problema empresarial fundamental para evitar resolver los problemas incorrectos, pero esto es cierto para todas las metodologías de software.
Metodologías
Desarrollo ágil
El "desarrollo de software ágil" 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 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 ágil también incluye los siguientes procesos de desarrollo de software: [4]
- Método de desarrollo de sistemas dinámicos (DSDM)
- Kanban
- Melé
- Cristal
- Atern
- Desarrollo esbelto
Integración continua
La integración continua es la práctica de fusionar todas las copias de trabajo del desarrollador en una línea principal compartida varias veces al día. [5] Grady Booch nombró y propuso IC por primera vez en su método de 1991 , [6] aunque no abogó por la integración varias veces al día. La programación extrema (XP) adoptó el concepto de CI y defendió la integración más de una vez al día, tal vez hasta decenas de veces al día.
Desarrollo incremental
Se aceptan 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 dividiendo un proyecto en segmentos más pequeños y proporcionando 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
- Los requisitos generales se definen antes de proceder al desarrollo evolutivo en mini-cascada de incrementos individuales de un sistema, o
- 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 a través de Waterfall, seguido de la implementación incremental, que culmina con la instalación de la versión final, un sistema en funcionamiento.
Desarrollo rápido de aplicaciones
El desarrollo rápido de aplicaciones (RAD) 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 inicial. La "planificación" del software desarrollado con RAD está intercalada con la escritura del propio software. La falta de una planificación previa exhaustiva generalmente permite que el software se escriba mucho más rápido y facilita el cambio de requisitos.
El proceso de desarrollo rápido comienza con el desarrollo de modelos de datos preliminares y modelos de procesos comerciales utilizando técnicas estructuradas . En la siguiente etapa, los requisitos se verifican mediante la creación de prototipos, eventualmente para refinar los modelos de datos y procesos. Estas etapas se repiten iterativamente; un mayor desarrollo da como resultado "una declaración combinada de requisitos comerciales y diseño técnico que se utilizará para construir nuevos sistemas". [7]
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 impulsada por datos , con técnicas de creación de prototipos para acelerar el desarrollo de sistemas de software. . [7]
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 costo de inversión relativamente bajo.
- Intenta reducir el riesgo inherente del proyecto dividiéndolo 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 interfaz gráfica 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 clave está en satisfacer las necesidades comerciales, mientras que la excelencia tecnológica o de ingeniería es de menor importancia.
- El control del proyecto implica priorizar el desarrollo y definir plazos de entrega o “timeboxes”. Si el proyecto comienza a fallar, se hace hincapié en reducir los requisitos para ajustarse al calendario, no en aumentar el plazo.
- Generalmente incluye el diseño de aplicaciones conjuntas (JAD), donde los usuarios están intensamente involucrados en el diseño del sistema , a través de la construcción de consenso en talleres estructurados o interacción facilitada electrónicamente.
- La participación activa del usuario es imperativa.
- Produce software de producción de forma iterativa, a diferencia de un prototipo desechable.
- Produce la documentación necesaria para facilitar el desarrollo y el mantenimiento futuros.
- Los métodos estándar de análisis y diseño de sistemas pueden adaptarse a este marco.
Desarrollo en espiral
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 . Hizo hincapié en un área clave que muchos consideraron que otras metodologías habían descuidado: el análisis de riesgos iterativo deliberado, especialmente adecuado para sistemas complejos a gran escala.
Los principios básicos son: [1]
- El enfoque está 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 más facilidad de cambio durante el proceso de desarrollo, así como brindar la oportunidad de evaluar los riesgos y sopesar la consideración de 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 general de concepto de operación hasta la codificación de cada programa individual". [8]
- Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar los objetivos, las alternativas y las limitaciones de la iteración; (2) evaluar alternativas; Identificar y resolver riesgos; (3) desarrollar y verificar los entregables de la iteración; y (4) planifique la próxima iteración. [9]
- 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. [10]
Desarrollo de cascada
El modelo de cascada es un enfoque de desarrollo secuencial, en el que se considera que el desarrollo fluye de manera constante hacia abajo (como una cascada) a través de varias fases, por lo general:
- 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 como un artículo publicado por Winston W. Royce [11] 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 que no funciona. [12]
Los principios básicos son: [1]
- El proyecto se divide en fases secuenciales, con algunas superposiciones y salpicaduras aceptables entre las fases.
- El énfasis está en la planificación, los cronogramas, las fechas objetivo, los presupuestos y la implementación de un sistema completo al mismo tiempo.
- Se mantiene un control estricto durante la vida del proyecto a través de una extensa documentación escrita, revisiones formales y aprobación / aprobación por parte del usuario y la gestión de la 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 de cascada estricto desalienta volver a visitar y revisar cualquier fase anterior una vez que esté completa. [ según quién? ] Esta "inflexibilidad" en un modelo de cascada pura ha sido 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 superan el presupuesto, a lo largo del tiempo y, a veces, no cumplen con los requisitos debido al enfoque de Big Design Up Front . [ según quién? ] Excepto cuando se requiere por contrato, 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 Waterfall .
Metodologías avanzadas
Otras metodologías de proyectos de software de alto nivel incluyen:
- Desarrollo impulsado por el comportamiento y gestión de procesos comerciales [13]
- Modelo del caos : la regla principal siempre es resolver primero el problema más importante.
- Metodología de financiación incremental : un enfoque iterativo
- Metodología ligera : un término general para los métodos que solo tienen algunas reglas y prácticas.
- Método de diseño y análisis de sistemas estructurados : 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 (o mínimas) presiones de tiempo. La programación lenta tiene como objetivo evitar errores y programas de lanzamiento demasiado rápidos.
- V-Model (desarrollo de software) : una extensión del modelo en cascada
- Unified Process (UP) es un marco de metodología de desarrollo de software iterativo, basado en Unified Modeling Language (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: inicio, 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 Rational Unified Process (RUP).
- Metodología Big Bang: un enfoque para proyectos pequeños o indefinidos, que generalmente consiste en poca o ninguna planificación con alto riesgo.
Procesar metamodelos
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.
- La Integración del modelo 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 en función de qué tan bien siguen sus procesos definidos, no según 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 gestión y seguimiento del progreso. Aunque la norma se creó originalmente para el sector de fabricación, 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 de negocio formalizados.
- ISO / IEC 15504 Tecnología de la información: la 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 usa de manera muy similar a CMMI. Modela procesos para administrar, controlar, guiar y monitorear el desarrollo de software. Este modelo se utiliza luego para medir lo que hace realmente una organización de desarrollo o un equipo de proyecto durante el desarrollo de software. Esta información se analiza para identificar debilidades e impulsar la mejora. También identifica las fortalezas que pueden continuar o integrarse 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.
- 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étodos : un método general para mejorar los procesos del sistema de información.
En la práctica
A lo largo de los años han evolucionado diversos marcos de este tipo, cada uno con sus propias fortalezas y debilidades reconocidas. Un marco de metodología de desarrollo de software no es necesariamente adecuado para todos los proyectos. Cada uno de los marcos metodológicos disponibles se adapta mejor a tipos específicos de proyectos, basándose en diversas consideraciones técnicas, organizativas, de proyecto y de equipo. [1]
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 EE. UU . , Que requiere una calificación basada en modelos de proceso para obtener contratos. El estándar internacional para describir el método de selección, implementación y monitoreo del ciclo de vida del software es ISO / IEC 12207 .
Un objetivo de décadas ha sido encontrar procesos repetibles y predecibles que mejoren la productividad y la calidad. Algunos intentan sistematizar o formalizar la aparentemente rebelde tarea de diseñar software. Otros aplican técnicas de gestión de proyectos para diseñar software. Un gran número de proyectos de software no cumplen con sus expectativas en términos de funcionalidad, costo o cronograma de entrega; consulte la Lista de proyectos de software personalizados con errores y sobrepresupuesto para ver 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 de línea que tienen habilidades variadas, el grupo está en el centro del esfuerzo colaborativo de todos en la organización que están involucrados con la mejora de procesos de ingeniería de software.
Un equipo de desarrollo en particular también puede aceptar los detalles del entorno de programación, como qué entorno de desarrollo integrado se utiliza 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.
Ver también
- 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 la ingeniería de software
- Abrir
- Gestión de proyectos
- Desarrollo de software
- Estimación del esfuerzo de desarrollo de software
- Ciclo de vida de la versión de software
- Diseño de arriba hacia abajo y de abajo hacia arriba # Ciencias de la computación
Referencias
- ^ a b c d e f g Oficina de servicios de información de los centros de servicios de Medicare y Medicaid (CMS) (2008). Seleccionar un enfoque de desarrollo . Webarticle. Departamento de Salud y Servicios Humanos de los Estados Unidos (HHS). Revalidado: 27 de marzo de 2008. Consultado el 27 de octubre de 2008.
- ^ a b Geoffrey Elliott (2004) Tecnología de la información empresarial global: un enfoque de sistemas integrados . Educación Pearson. p.87.
- ^ Suryanarayana, Girish (2015). "Proceso de software frente a la calidad del diseño: ¿tira y afloja?". Software IEEE . 32 (4): 7-11. doi : 10.1109 / MS.2015.87 .
- ^ "proceso de desarrollo de software" .
- ^ "Integración continua" .
- ^ Booch, Grady (1991). Diseño orientado a objetos: con aplicaciones . Benjamin Cummings . pag. 209. ISBN 9780805300918. Consultado el 18 de agosto de 2014 .
- ↑ a b Whitten, Jeffrey L .; Lonnie D. Bentley , Kevin C. Dittman . (2003). Métodos de diseño y análisis de sistemas . 6ª edición. ISBN 0-256-19906-X .
- ^ Barry Boehm (1996)., "Un modelo en espiral de mejora y desarrollo de software ". En: ACM SIGSOFT Software Engineering Notes (ACM) 11 (4): 14-24, agosto de 1986
- ^ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: gestión de proyectos de ingeniería de software . Computer Society Press del IEEE. p.130
- ^ Barry W. Boehm (2000). Estimación de costos de software con Cocomo II: Volumen 1 .
- ^ Wasserfallmodell> Entstehungskontext , Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Consultado en línea el 28 de noviembre de 2007.
- ^ Conrad Weisert, metodología Waterfall: ¡no existe tal cosa!
- ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modelado de casos de prueba en BPMN para el desarrollo impulsado por el comportamiento". Software IEEE . 33 (5): 15-21. doi : 10.1109 / MS.2016.117 . S2CID 14539297 .
enlaces externos
- Seleccionar un enfoque de desarrollo en cms.hhs.gov.
- Gerhard Fischer, "La tecnología de software del siglo XXI: de la reutilización de software al diseño de software colaborativo" , 2001
- Mapa del metro de prácticas ágiles en Agile Alliance
