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 y/o la gestión del producto . La metodología puede incluir la predefinició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 pueden describirse 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 una instancia particular adoptada por una organización específica. [ cita necesaria ] 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 de la metodología de desarrollo de software (también conocida 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 como el marco metodológico formalizado más antiguo para la construcción de sistemas de información . La idea principal del SDLC ha sido "buscar 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– llevarse a cabo de forma 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 comerciales funcionales a gran escala en una era de conglomerados comerciales a gran escala. Las actividades de sistemas de información giraban en torno al procesamiento pesado de datos y rutinas de cálculo 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 discusiones exhaustivas y realizar entrevistas con las partes interesadas para identificar las características, funcionalidades y el alcance general deseados 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 cronogramas, la asignación de recursos y los resultados. Durante esta fase también se establecen la arquitectura y el diseño del software. Se consideran elementos de diseño de la interfaz de usuario (UI) y de la experiencia del usuario (UX) para garantizar la usabilidad, la intuición y el atractivo visual del software.

Desarrollo: con la planificación y el diseño implementados, el equipo de desarrollo comienza el proceso de codificación. Esta fase implica escribir , probar y depurar el código del software. A menudo se emplean metodologías ágiles, como scrum o kanban, 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 comentarios y ajustes rápidos.

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

Despliegue e implementación: una vez que el software pasa la fase de prueba, está listo para su despliegue e implementación. 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 a los usuarios maximizar el potencial del software.

Mantenimiento y soporte: una vez implementado el software, el mantenimiento y el soporte continuos se vuelven cruciales para abordar cualquier problema, mejorar el rendimiento e incorporar mejoras futuras. Se publican 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 atender sus consultas o inquietudes. Las metodologías, procesos y marcos varían desde pasos prescriptivos específicos que una organización puede utilizar directamente en el trabajo diario, hasta marcos flexibles que una organización utiliza para generar un conjunto personalizado de pasos adaptados a 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:

década de 1970
década de 1980
década de 1990
2000
década de 2010

Desde 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, todavía utilizan procesos preágiles (a menudo en cascada o similares). El proceso del software y la calidad del software están estrechamente relacionados; 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 conocidas y de procesos 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]

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

Metodologías

Desarrollo ágil

El "desarrollo ágil de software" se refiere a un grupo de marcos de desarrollo de software basados ​​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 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 IC en su método de 1991 , [5] aunque no recomendó la integración varias veces al día. La programación extrema (XP) adoptó el concepto de CI y abogó por la integración más de una vez al día, tal vez 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 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]

  1. Se realiza una serie de minicascadas, 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 en minicascada de incrementos individuales de un sistema, o
  3. El concepto de software inicial, el análisis de requisitos y el diseño de la arquitectura y el núcleo del sistema se definen mediante una cascada, seguido de una implementación incremental, que culmina con la instalación de la versión final, un sistema en funcionamiento.

Desarrollo rápido de aplicaciones

Modelo de desarrollo rápido de aplicaciones (RAD)

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 utilizando RAD se entrelaza con la escritura del software en sí. 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 de negocios utilizando técnicas estructuradas . En la siguiente etapa, los requisitos se verifican mediante la creación de prototipos, para eventualmente refinar los datos y los modelos de proceso. 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". [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 la ingeniería de tecnologías 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 de cascada

Las actividades del proceso de desarrollo de software representadas en el modelo en cascada . Hay varios otros modelos para representar este proceso.

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:

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 utilizó el término "cascada" en este artículo. Royce presentó este modelo como un ejemplo de modelo defectuoso 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 estricto en cascada desalienta la revisión de cualquier fase anterior una vez completada. [¿ según quién? ] Esta "inflexibilidad" en un modelo puro en cascada ha sido motivo de críticas por parte de los partidarios de otros modelos más "flexibles". Se le ha culpado ampliamente de que varios proyectos gubernamentales a gran escala se excedan en el presupuesto, se prolonguen en el tiempo y, en ocasiones, no cumplan con los requisitos debido al gran enfoque de diseño inicial . [¿ según quién? ] Excepto cuando sea requerido 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íticas al modelo de 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 otras metodologías habían descuidado: el análisis de riesgo iterativo deliberado, particularmente adecuado para sistemas complejos a gran escala.

Los principios básicos son: [1]

Ponerse 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 velocidad, trabajos pendientes o sprints, a diferencia de Waterfall , Agile o Scrum . En cambio, esos conceptos son reemplazados 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 procesos " 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 ha desarrollado una variedad de marcos de este tipo, cada uno con sus propias fortalezas y debilidades reconocidas. Un marco metodológico de desarrollo de software no es necesariamente adecuado para su uso en 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. [1]

Las organizaciones de desarrollo de software implementan metodologías de procesos para facilitar el proceso de desarrollo. En ocasiones, los contratistas pueden requerir las metodologías empleadas, un ejemplo es la industria de defensa estadounidense , 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 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 difícil tarea 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 cumplen con sus expectativas en términos de funcionalidad, costo o cronograma de entrega; consulte la Lista de proyectos de software personalizados fallidos y con exceso de presupuesto 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 diversas habilidades, el grupo está en el centro del esfuerzo colaborativo de todos los miembros de la organización que participan en la mejora de procesos de ingeniería de software.

Un equipo de desarrollo en particular también puede acordar los detalles del entorno del programa, como qué entorno de desarrollo integrado se utiliza, 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.

En el mundo digital actual, es fundamental priorizar la seguridad durante todo el ciclo de vida del desarrollo de software (SDLC). Los actores maliciosos buscan continuamente agujeros que explotar; por lo tanto, los peligros para la seguridad cibernética van en aumento. Las organizaciones pueden proteger datos confidenciales, prevenir infracciones y mantener la confianza de los usuarios incorporando medidas de seguridad en cada etapa de desarrollo. Esta estrategia proactiva no solo reduce los riesgos sino que también garantiza el cumplimiento normativo, lo que da como resultado un ecosistema digital más resiliente y seguro.

Ver también

Referencias

  1. ^ abcdefg "Selección de un enfoque de desarrollo" (PDF) . Oficina de Servicio de Información de los Centros de Servicios de Medicare y Medicaid (CMS) . Departamento de Salud y Servicios Humanos de los Estados Unidos (HHS). 27 de marzo de 2008 [Edició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 . Educación Pearson. pag. 87.
  3. ^ Suryanarayana, Girish (2015). "Proceso de software versus calidad del diseño: ¿tira y afloja?". Software IEEE . 32 (4): 7–11. doi : 10.1109/MS.2015.87 .
  4. ^ "Integración continua".
  5. ^ Booch, Grady (1991). Diseño orientado a objetos: con aplicaciones. Benjamín Cummings . pag. 209.ISBN 9780805300918. Consultado 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 . 6ta 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. "Metodología en cascada: ¡no existe tal cosa!". Archivado desde el original el 2 de agosto de 2022.
  9. ^ Barry Boehm (agosto de 1986). "Un modelo en espiral de desarrollo y mejora de software". Notas de ingeniería de software de ACM SIGSOFT . 11 (4). Asociación de Maquinaria de Computación : 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 . Prensa de la Sociedad de Computación del IEEE. pag. 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 buena teoría?". Laboratorio curioso . 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 basado en el comportamiento". Software IEEE . 33 (5): 15-21. doi :10.1109/MS.2016.117. S2CID  14539297.

enlaces externos