stringtranslate.com

Proceso de desarrollo de software

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 .

Historia

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
Década de 1980
Década de 1990
Década de 2000
Década de 2010

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 .

Prototipado

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]

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.

Metodologías

Desarrollo ágil

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:

Integración continua

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.

Desarrollo incremental

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.

Desarrollo rápido de aplicaciones

Modelo de desarrollo rápido de aplicaciones (RAD)

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]

Desarrollo en cascada

Las actividades del proceso de desarrollo de software se representan en el modelo de cascada . Existen otros modelos para representar este proceso.

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:

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

Desarrollo en espiral

Modelo espiral (Boehm, 1988)

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]

Ponte en forma

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]

Metodologías avanzadas

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

Metamodelos de procesos

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

En la práctica

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

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]

Véase también

Referencias

  1. ^ abcdefg "Selección de un enfoque de desarrollo" (PDF) . Centros de Servicios de Medicare y Medicaid (CMS) Oficina de Servicios de Información . Departamento de Salud y Servicios Humanos de los Estados Unidos (HHS). 27 de marzo de 2008 [Emisión original: 17 de febrero de 2005]. Archivado desde el original (PDF) el 20 de junio de 2012 . Consultado el 27 de octubre de 2008 .
  2. ^ ab Geoffrey Elliott (2004). Tecnología de la información empresarial global: un enfoque de sistemas integrados . Pearson Educación. pág. 87.
  3. ^ Suryanarayana, Girish (2015). "Proceso de software versus calidad de diseño: ¿un tira y afloja?". IEEE Software . 32 (4): 7–11. doi : 10.1109/MS.2015.87 .
  4. ^ Paul M. Duvall; Steve Matyas; Andrew Glover (2007). Integración continua: mejora de la calidad del software y reducción del riesgo . Addison-Wesley Professional . ISBN 978-0-321-33638-5.
  5. ^ Booch, Grady (1991). Diseño orientado a objetos: con aplicaciones. Benjamin Cummings . pág. 209. ISBN 9780805300918. Recuperado el 18 de agosto de 2014 .
  6. ^ ab Whitten, Jeffrey L. ; Lonnie D. Bentley , Kevin C. Dittman . (2003). Métodos de análisis y diseño de sistemas . 6.ª edición. ISBN 0-256-19906-X
  7. ^ Markus Rerych. "Wasserfallmodell > Entstehungskontext". Institut für Gestaltungs- und Wirkungsforschung, TU-Wien (en alemán) . Consultado el 28 de noviembre de 2007 .
  8. ^ Conrad Weisert. "La metodología en cascada: ¡no existe!". Archivado desde el original el 2 de agosto de 2022.
  9. ^ Barry Boehm (agosto de 1986). "Un modelo espiral de desarrollo y mejora de software". Notas de ingeniería de software de ACM SIGSOFT . 11 (4). Association for Computing Machinery : 14–24. doi :10.1145/12944.12948. S2CID  1781829.
  10. ^ Richard H. Thayer; Barry W. Boehm (1986). Tutorial: gestión de proyectos de ingeniería de software . Computer Society Press del IEEE. pág. 130.
  11. ^ Barry W. Boehm (2000). Estimación de costos de software con Cocomo II: Volumen 1 .
  12. ^ "Prólogo de Jason Fried | Shape Up". basecamp.com . Consultado el 11 de septiembre de 2022 .
  13. ^ "¿Shape Up es solo una linda teoría?". Curious Lab . Consultado el 12 de septiembre de 2022 .
  14. ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modelado de casos de prueba en BPMN para el desarrollo impulsado por el comportamiento". IEEE Software . 33 (5): 15–21. doi :10.1109/MS.2016.117. S2CID  14539297.

Enlaces externos