Articulo de referencia

Desarrollo de software

El desarrollo de software es el proceso de diseñar, crear, probar y mantener aplicaciones de software para satisfacer necesidades específicas del usuario u objetivos comerciales...

El desarrollo de software es el proceso de diseñar, crear, probar y mantener aplicaciones de software para satisfacer necesidades específicas del usuario u objetivos comerciales. Este proceso abarca más que la programación (escribir código) , ya que incluye la concepción del objetivo, la evaluación de la viabilidad, el análisis de requisitos , el diseño , las pruebas y el lanzamiento . El proceso forma parte de la ingeniería de software , que también incluye la gestión organizacional , la gestión de proyectos , la gestión de la configuración y otros aspectos. [ 1 ]

El desarrollo de software implica muchas habilidades y especializaciones laborales, incluyendo programación , pruebas , documentación , diseño gráfico , soporte al usuario , marketing y captación de fondos . Los tipos de herramientas más comunes son los compiladores , los entornos de desarrollo integrados (IDE) y el control de versiones .

Los detalles del proceso de desarrollo varían. Este puede ajustarse a un estándar formal y documentado , o bien, ser personalizado y adaptarse a las necesidades específicas del proyecto. Puede ser secuencial, donde cada fase principal (diseño, implementación y prueba) se completa antes de comenzar la siguiente; sin embargo, un enfoque iterativo, en el que los aspectos menores se diseñan, implementan y prueban por separado, puede reducir riesgos y costos, además de mejorar la calidad.

Metodologías

Diagrama de flujo del modelo de prototipado evolutivo , un modelo de desarrollo iterativo [ 2 ]

Cada una de las metodologías disponibles se adapta mejor a tipos específicos de proyectos, en función de diversas consideraciones técnicas, organizativas, de proyecto y de equipo. [ 3 ]

  • La metodología más sencilla es la de "codificar y corregir", utilizada normalmente por un solo programador en un proyecto pequeño. Tras considerar brevemente el propósito del programa, el programador lo codifica y lo ejecuta para comprobar su funcionamiento. Una vez finalizado, se lanza el producto. Esta metodología es útil para prototipos, pero no para programas más complejos. [ 4 ]
  • En el modelo de cascada descendente , la viabilidad, el análisis, el diseño , el desarrollo, el control de calidad y la implementación se suceden secuencialmente en ese orden. Este modelo requiere que un paso esté completo antes de que comience el siguiente, lo que provoca retrasos e imposibilita la revisión de pasos anteriores si fuera necesario. [ 5 ] [ 6 ] [ 7 ]
  • Con los procesos iterativos , estos pasos se entrelazan entre sí para mejorar la flexibilidad, la eficiencia y la programación más realista. En lugar de completar el proyecto de una sola vez, se puede recorrer la mayoría de los pasos con un componente a la vez. El desarrollo iterativo también permite a los desarrolladores priorizar las características más importantes, lo que permite descartar las de menor prioridad más adelante si es necesario. [ 6 ] [ 8 ] Agile es un método popular, originalmente pensado para proyectos pequeños o medianos, que se centra en dar a los desarrolladores más control sobre las características en las que trabajan para reducir el riesgo de sobrecostos o retrasos. [ 9 ] Los derivados de Agile incluyen la programación extrema y Scrum . [ 9 ] El desarrollo de software de código abierto normalmente utiliza la metodología Agile con diseño, codificación y pruebas concurrentes, debido a la dependencia de una red distribuida de colaboradores voluntarios. [ 10 ]
  • Más allá de la metodología ágil, algunas empresas integran las operaciones de tecnología de la información (TI) con el desarrollo de software, lo que se denomina DevOps o DevSecOps , incluyendo la seguridad informática . [ 11 ] DevOps incluye el desarrollo continuo, las pruebas , la integración del nuevo código en el sistema de control de versiones, el despliegue del nuevo código y, en ocasiones, la entrega del código a los clientes. [ 12 ] El objetivo de esta integración es ofrecer servicios de TI de forma más rápida y eficiente. [ 11 ]

Otro enfoque en muchas metodologías de programación es la idea de tratar de detectar problemas como vulnerabilidades de seguridad y errores lo antes posible ( pruebas shift-left ) para reducir el costo de rastrearlos y corregirlos. [ 13 ]

En 2009, se estimó que el 32% de los proyectos de software se entregaron a tiempo, dentro del presupuesto y con todas sus funcionalidades. Un 44% adicional se entregó, pero le faltaba al menos una de sus características. El 24% restante se canceló antes de su lanzamiento. [ 14 ]

Ciclo vital

El ciclo de vida del desarrollo de software describe las fases típicas del proceso de desarrollo de software. [ 15 ]

Factibilidad

Las fuentes de ideas para productos de software son abundantes. Estas ideas pueden provenir de la investigación de mercado , incluyendo la demografía de potenciales nuevos clientes, clientes existentes, prospectos de ventas que rechazaron el producto, otro personal interno de desarrollo de software o un tercero creativo. Las ideas para productos de software suelen ser evaluadas primero por el personal de marketing en cuanto a viabilidad económica, compatibilidad con los canales de distribución existentes, posibles efectos en las líneas de productos existentes, características requeridas y compatibilidad con los objetivos de marketing de la empresa. En la fase de evaluación de marketing, se evalúan los supuestos de costo y tiempo. [ 16 ] El análisis de viabilidad estima el retorno de la inversión del proyecto , su costo de desarrollo y su plazo. Con base en este análisis, la empresa puede tomar una decisión comercial para invertir en un mayor desarrollo. [ 17 ] Después de decidir desarrollar el software, la empresa se enfoca en entregar el producto dentro del costo y tiempo estimados o por debajo de ellos, con un alto estándar de calidad (es decir, sin errores) y la funcionalidad deseada. Sin embargo, la mayoría de los proyectos de software se retrasan y, a veces, se hacen concesiones en las características o la calidad para cumplir con un plazo. [ 18 ]

Análisis

El análisis de software comienza con un análisis de requisitos para capturar las necesidades comerciales del software. [ 19 ] Los desafíos para la identificación de necesidades radican en que los usuarios actuales o potenciales pueden tener necesidades diferentes e incompatibles, pueden no comprender sus propias necesidades y cambiarlas durante el proceso de desarrollo del software. [ 20 ] En última instancia, el resultado del análisis es una especificación detallada del producto a partir de la cual los desarrolladores pueden trabajar. Los analistas de software a menudo descomponen el proyecto en objetos más pequeños, componentes que pueden reutilizarse para aumentar la rentabilidad, la eficiencia y la confiabilidad. [ 19 ] La descomposición del proyecto puede permitir una implementación multihilo que se ejecuta significativamente más rápido en computadoras multiprocesador . [ 21 ]

Durante las fases de análisis y diseño del desarrollo de software, el análisis estructurado se utiliza a menudo para desglosar los requisitos del cliente en partes que puedan ser implementadas por los programadores de software. [ 22 ] La lógica subyacente del programa puede representarse en diagramas de flujo de datos , diccionarios de datos , pseudocódigo , diagramas de transición de estados y/o diagramas de entidad-relación . [ 23 ] Si el proyecto incorpora un software heredado que no ha sido modelado, este software puede modelarse para ayudar a garantizar que se incorpore correctamente con el software más reciente. [ 24 ]

Diseño

El diseño implica decisiones sobre la implementación del software, como qué lenguajes de programación y software de base de datos utilizar, o cómo se organizarán el hardware y las comunicaciones de red. El diseño puede ser iterativo, con la consulta a los usuarios sobre sus necesidades en un proceso de prueba y error . El diseño a menudo involucra a personas expertas en aspectos como el diseño de bases de datos , la arquitectura de pantallas y el rendimiento de servidores y otro hardware. [ 19 ] Los diseñadores a menudo intentan encontrar patrones en la funcionalidad del software para crear módulos distintos que puedan reutilizarse con la programación orientada a objetos . Un ejemplo de esto es el modelo-vista-controlador , una interfaz entre una interfaz gráfica de usuario y el backend . [ 25 ]

Programación

La característica central del desarrollo de software es la creación y comprensión del software que implementa la funcionalidad deseada. [ 26 ] Existen diversas estrategias para escribir el código. El software cohesivo tiene varios componentes que son independientes entre sí. [ 19 ] El acoplamiento es la interrelación de diferentes componentes de software, lo cual se considera indeseable porque aumenta la dificultad del mantenimiento . [ 27 ] A menudo, los programadores de software no siguen las mejores prácticas de la industria, lo que resulta en un código ineficiente, difícil de entender o que carece de documentación sobre su funcionalidad. [ 28 ] Es especialmente probable que estos estándares fallen en presencia de plazos de entrega. [ 29 ] Como resultado, probar, depurar y revisar el código se vuelve mucho más difícil. La refactorización de código es una técnica para reestructurar el código existente sin cambiar su comportamiento externo, a menudo para mejorar su diseño, legibilidad o mantenibilidad. [ 30 ]

Desde la popularización de los grandes modelos de lenguaje , el desarrollo de software asistido por IA se ha utilizado para aumentar la programación humana al permitir que una IA maneje la sintaxis y escriba el código. [ 31 ]

Pruebas

Informe de cobertura de pruebas en Clover

Las pruebas son el proceso de asegurar que el código se ejecute correctamente y sin errores. La depuración la realiza cada desarrollador de software en su propio código para confirmar que el código hace lo que se espera. En particular, es crucial que el software se ejecute con todas las entradas, incluso si el resultado es incorrecto. [ 32 ] Las revisiones de código por parte de otros desarrolladores se utilizan a menudo para examinar el nuevo código añadido al proyecto y, según algunas estimaciones, reducen drásticamente el número de errores que persisten después de que se completan las pruebas. [ 33 ] Una vez que se ha enviado el código, el control de calidad —un departamento independiente de no programadores en la mayoría de las grandes empresas— prueba la precisión de todo el producto de software. Las actividades de prueba también pueden ocurrir a lo largo del ciclo de vida del desarrollo de software, dependiendo de la metodología utilizada. [ 34 ] Las pruebas de aceptación derivadas de los requisitos de software originales son una herramienta popular para esto. [ 32 ] Las pruebas de calidad también suelen incluir pruebas de estrés y carga (para comprobar si el software es robusto ante altos niveles de entrada o uso), pruebas de integración (para asegurar que el software se integra adecuadamente con otro software) y pruebas de compatibilidad (para medir el rendimiento del software en diferentes sistemas operativos o navegadores). [ 32 ] Cuando las pruebas se escriben antes que el código, esto se denomina desarrollo guiado por pruebas . [ 35 ]

Producción

La producción es la fase en la que el software se implementa para el usuario final. [ 36 ] Durante la producción, el desarrollador puede crear recursos de soporte técnico para los usuarios [ 37 ] [ 36 ] o un proceso para corregir errores y fallos que no se detectaron anteriormente.También podría haber un retorno a fases de desarrollo anteriores si las necesidades de los usuarios cambiaron o fueron malinterpretadas. [ 36 ]

Trabajadores

Programador en el trabajo

El desarrollo de software lo llevan a cabo desarrolladores de software , que suelen trabajar en equipo. La comunicación eficiente entre los miembros del equipo es esencial para el éxito. Esto se logra más fácilmente si el equipo es pequeño, está acostumbrado a trabajar junto y se encuentra cerca. [ 38 ] La comunicación también ayuda a identificar problemas en una etapa temprana del desarrollo y a evitar la duplicación de esfuerzos. Muchos proyectos de desarrollo evitan el riesgo de perder conocimientos esenciales que posee un solo empleado, asegurándose de que varios trabajadores estén familiarizados con cada componente. [ 39 ] El desarrollo de software involucra a profesionales de diversos campos, no solo programadores de software , sino también gerentes de producto que establecen la estrategia y la hoja de ruta del producto, [ 40 ] personas especializadas en pruebas, redacción de documentación, diseño gráfico , soporte al usuario, marketing y recaudación de fondos. Aunque los trabajadores de software propietario reciben un salario, la mayoría de los colaboradores de software de código abierto son voluntarios. [ 41 ] Alternativamente, pueden recibir un salario de empresas cuyo modelo de negocio no implica la venta del software, sino algo más, como servicios y modificaciones al software de código abierto. [ 42 ]

Modelos y herramientas

Ingeniería de software asistida por ordenador

La ingeniería de software asistida por computadora (CASE) son herramientas para la automatización parcial del desarrollo de software. [ 43 ] CASE permite a los diseñadores esbozar la lógica de un programa, ya sea uno que se va a escribir o uno ya existente, para ayudar a integrarlo con código nuevo o realizar ingeniería inversa (por ejemplo, para cambiar el lenguaje de programación ). [ 44 ]

Documentación

La documentación se presenta en dos formas que generalmente se mantienen separadas: una destinada a los desarrolladores de software y otra disponible para el usuario final para ayudarlo a usar el software. [ 45 ] [ 46 ] La mayor parte de la documentación para desarrolladores se presenta en forma de comentarios de código para cada archivo, clase y método que cubren la interfaz de programación de aplicaciones (API) —cómo se puede acceder a la pieza de software desde otra— y, a menudo, detalles de implementación. [ 47 ] Esta documentación es útil para que los nuevos desarrolladores comprendan el proyecto cuando comienzan a trabajar en él. [ 48 ] En el desarrollo ágil, la documentación a menudo se escribe al mismo tiempo que el código. [ 49 ] La documentación para el usuario es escrita con mayor frecuencia por redactores técnicos . [ 50 ]

Estimación del esfuerzo

Una estimación precisa es crucial en la etapa de viabilidad y para entregar el producto a tiempo y dentro del presupuesto. El proceso de generación de estimaciones suele ser delegado por el director del proyecto . [ 51 ] Dado que la estimación del esfuerzo está directamente relacionada con el tamaño de la aplicación completa, se ve fuertemente influenciada por la adición de funcionalidades en los requisitos: cuantos más requisitos, mayor es el costo de desarrollo. Los aspectos no relacionados con la funcionalidad, como la experiencia de los desarrolladores de software y la reutilización del código, también son esenciales para considerar en la estimación. [ 52 ] A partir de 2019La mayoría de las herramientas para estimar la cantidad de tiempo y recursos para el desarrollo de software fueron diseñadas para aplicaciones convencionales y no son aplicables a aplicaciones web o aplicaciones móviles . [ 53 ]

entorno de desarrollo integrado

Anjuta , un IDE de C y C++ para el entorno GNOME.

Un entorno de desarrollo integrado (IDE) admite el desarrollo de software con características mejoradas en comparación con un editor de texto simple . [ 54 ] Los IDE suelen incluir compilación automatizada , resaltado de sintaxis de errores, [ 55 ] asistencia para la depuración, [ 56 ] integración con control de versiones y semiautomatización de pruebas. [ 54 ]

Control de versiones

El control de versiones es una forma popular de gestionar los cambios realizados en el software. Cada vez que se registra una nueva versión, el software guarda una copia de seguridad de todos los archivos modificados. Si varios programadores trabajan simultáneamente en el software, este gestiona la fusión de sus cambios de código. El software resalta los casos en los que existe un conflicto entre dos conjuntos de cambios y permite a los programadores resolverlo. [ 57 ]

Ver modelo

La matriz de puntos de vista y perspectivas de TEAF

Un modelo de vista es un marco que proporciona los puntos de vista sobre el sistema y su entorno , para ser utilizado en el proceso de desarrollo de software . Es una representación gráfica de la semántica subyacente de una vista.

El propósito de los puntos de vista y las perspectivas es permitir a los ingenieros comprender sistemas muy complejos y organizar los elementos del problema en torno a dominios de especialización . En la ingeniería de sistemas físicamente exigentes, los puntos de vista suelen corresponder a capacidades y responsabilidades dentro de la organización de ingeniería. [ 58 ]

Funciones de aptitud física

Las funciones de aptitud son pruebas automatizadas y objetivas para garantizar que los nuevos desarrollos no se desvíen de las restricciones, verificaciones y controles de cumplimiento establecidos. [ 59 ]

Propiedad intelectual

La propiedad intelectual puede ser un problema cuando los desarrolladores integran código o bibliotecas de código abierto en un producto propietario, ya que la mayoría de las licencias de código abierto utilizadas para el software exigen que las modificaciones se publiquen bajo la misma licencia. Como alternativa, los desarrolladores pueden optar por una alternativa propietaria o escribir su propio módulo de software. [ 60 ]

Véase también

Referencias

  1. Dooley 2017 , pág. 1.
  2. Dooley 2017 , pág. 12.
  3. Metodologías de desarrollo de sistemas para comercio electrónico habilitado para la web: un marco de personalización Linda V. Knight (Universidad DePaul, EE. UU.), Theresa A. Steinbach (Universidad DePaul, EE. UU.) y Vince Kellen (Blue Wolf, EE. UU.)
  4. Dooley 2017 , págs. 8–9.
  5. Dooley 2017 , pág. 9.
  6. ^ Langer 2016 , págs. 2–3, 5–6.
  7. ^ Tucker, Morelli y de Silva 2011 , p. 8.
  8. Dooley 2017 , pág. 11.
  9. 1 2 Dooley 2017 , pág. 13.
  10. ^ Tucker, Morelli y de Silva 2011 , págs .
  11. 1 2 Vishnu 2019 , págs. 1–2.
  12. Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper (2017). "Problemas, causas y soluciones al adoptar la entrega continua: una revisión sistemática de la literatura" . Information and Software Technology . 82 : 55–79 . doi : 10.1016/j.infsof.2016.10.001 .
  13. Winters, Manshreck y Wright 2020 , pág. 17.
  14. ^ Tucker, Morelli y de Silva 2011 , p. 6.
  15. Saif 2019 , págs. 46–47.
  16. Morris 2001 , pág. 1.10.
  17. Langer 2016 , pág. 7.
  18. Dooley 2017 , págs. 3, 8.
  19. 1 2 3 4 Langer 2016 , pág. 8.
  20. Langer 2016 , págs. 2–3.
  21. Dooley 2017 , págs. 193–194.
  22. ^ Langer 2016 , págs. 103-104.
  23. Langer 2016 , págs. 117, 127, 131, 137, 141.
  24. Langer 2016 , pág. 106.
  25. Dooley 2017 , pág. 142.
  26. ^ Tucker, Morelli y de Silva 2011 , p. 31.
  27. Langer 2016 , págs. 8–9.
  28. ^ Tucker, Morelli y de Silva 2011 , págs .
  29. ^ Tucker, Morelli y de Silva 2011 , págs .
  30. "Página principal de refactorización" . refactoring.com . Consultado el 11 de mayo de 2026 .
  31. Cass, Stephen (23 de septiembre de 2025). "Los mejores lenguajes de programación de 2025" . IEEE Spectrum . Consultado el 6 de mayo de 2026 .
  32. 1 2 3 Langer 2016 , pág. 9.
  33. Dooley 2017 , pág. 272.
  34. "Asociación de Estándares IEEE" . Asociación de Estándares IEEE . Consultado el 11 de mayo de 2026 .
  35. ^ Tucker, Morelli y de Silva 2011 , p. 9.
  36. 1 2 3 Langer 2016 , pág. 10.
  37. ^ Tucker, Morelli y de Silva 2011 , p. 37.
  38. Dooley 2017 , pág. 2.
  39. Winters, Manshreck y Wright 2020 , págs. 30–31.
  40. "¿Qué hace un gerente de producto? Y cómo convertirse en uno" . Coursera . 21 de enero de 2025. Consultado el 5 de mayo de 2025 .
  41. ^ Tucker, Morelli y de Silva 2011 , p. 7.
  42. ^ Tucker, Morelli y de Silva 2011 , págs. 14-15.
  43. Langer 2016 , pág. 22.
  44. ^ Langer 2016 , págs. 108-110, 206.
  45. ^ Tucker, Morelli y de Silva 2011 , p. 243.
  46. Winters, Manshreck y Wright 2020 , pág. 192.
  47. Winters, Manshreck y Wright 2020 , págs. 193–195.
  48. ^ Tucker, Morelli y de Silva 2011 , p. 143.
  49. ^ Tucker, Morelli y de Silva 2011 , p. 144.
  50. Winters, Manshreck y Wright 2020 , pág. 204.
  51. Saif 2019 , págs. 50–51.
  52. Saif 2019 , págs. 52–53.
  53. Saif 2019 , pág. 45.
  54. ^ Tucker , Morelli y de Silva 2011 , pág. 68.
  55. Dooley 2017 , pág. 236.
  56. Dooley 2017 , pág. 239.
  57. Dooley 2017 , págs. 246–247.
  58. Edward J. Barkmeyer (febrero de 2003). "INSTIR 6928 - Conceptos para la automatización de la integración de sistemas" (PDF) . NIST. Archivado del original (PDF) el 25 de enero de 2017. Consultado el 21 de mayo de 2026 .
  59. Fundamentos de la arquitectura de software: Un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  60. ^ Langer 2016 , págs .

Lecturas adicionales

  • Conde, Dan (2002). Gestión de productos de software: Gestión del desarrollo de software desde la idea hasta el producto, el marketing y las ventas . Aspatore Books. ISBN 1587622025.
  • Davis, AM (2005). Just enough requirements management: Where software development meets marketing . Dorset House Publishing Company, Incorporated. ISBN 0932633641.
  • Dooley, John F. (2017). Desarrollo, diseño y codificación de software: con patrones, depuración, pruebas unitarias y refactorización . Apress. ISBN 978-1-4842-3153-1.
  • Kit, Edward (1992). Pruebas de software en el mundo real . Addison-Wesley Professional. ISBN 0201877562.
  • Hasted, Edward (2005). Software que vende: Una guía práctica para desarrollar y comercializar su proyecto de software . Wiley Publishing. ISBN 0764597833.
  • Hohmann, Luke (2003). Más allá de la arquitectura de software: Creación y mantenimiento de soluciones exitosas . Addison-Wesley Professional. ISBN 0201775948.
  • Horch, John W. (marzo de 1995). "Dos orientaciones sobre cómo trabajar con objetos". IEEE Software . 12 (2): 117– 118. ProQuest 215832531 . 
  • Langer, Arthur M. (2016). Guía para el desarrollo de software: diseño y gestión del ciclo de vida . Springer. ISBN 978-1-4471-6799-0.
  • McCarthy, Jim (1995). Dinámica del desarrollo de software . Microsoft Press. ISBN 1556158238.
  • Morris, Joseph M. (2001). Contabilidad de la industria del software (2.ª  ed.). John Wiley & Sons . OCLC 53863959 . 
  • Rittinghouse, John (2003). Managing Software Deliverables: A Software Development Management Methodology . Digital Press. ISBN 155558313X.
  • Saif, Syed Mohsin (2019). «Estimación del esfuerzo de software para el desarrollo exitoso de aplicaciones de software». En Vishnu, Pendyala (ed.). Herramientas y técnicas para el desarrollo de software en grandes organizaciones: investigación y oportunidades emergentes . IGI Global . pp. 45–97 . ISBN  978-1-7998-1865-6.
  • Tucker, Allen; Morelli, Ralph; de Silva, Chamindra (2011). Desarrollo de software: Un enfoque de código abierto . CRC Press. ISBN 978-1-4398-8460-7.
  • Vishnu, Pendyala (2019). «Evolución de la ingeniería de integración, compilación, pruebas y lanzamiento hacia DevOps y DevSecOps». En Vishnu, Pendyala (ed.). Herramientas y técnicas para el desarrollo de software en grandes organizaciones: investigación y oportunidades emergentes . IGI Global. pp. 1–20 . ISBN  978-1-7998-1865-6.
  • Wiegers, Karl E. (2005). Más sobre los requisitos de software: cuestiones complejas y consejos prácticos . Microsoft Press. ISBN 0735622671.
  • Winters, Titus; Manshreck, Tom; Wright, Hyrum (2020). Ingeniería de software en Google: Lecciones aprendidas de la programación a lo largo del tiempo . O'Reilly Media, Inc. ISBN 978-1-4920-8276-7.
  • Wysocki, Robert K. (2006). Gestión eficaz de proyectos de software . Wiley. ISBN 0764596365.
  • Logotipo de Wikimedia CommonsContenido multimedia relacionado con el desarrollo de software en Wikimedia Commons.