La respuesta real a esta pregunta es diferente . La mayor parte del software que utiliza ha sido desarrollado por equipos de personas con diferentes títulos y responsabilidades laborales, sin embargo, parte del mismo puede haber sido creado por entusiastas que no utilizaron ninguna metodología y simplemente lo hicieron. No abordaré el desarrollo ad hoc en esta respuesta.
Hay toda una disciplina que se dedica a estructurar el proceso de creación de software que es ingeniería de software de calles. Por lo general, el proceso de creación de software, también llamado ciclo de vida del software, se divide en varios pasos separados. Hay muchas metodologías con diferentes puntos de vista sobre cómo se deben llamar y ordenar estas etapas, y trataré de cubrir brevemente algunas de ellas.
Modelo de cascada : un modelo básico que postula que la creación de software es lineal y que cada etapa se produce solo una vez.
- ¿Cuál sería un proyecto inicial para la aplicación de Android?
- ¿Cuáles son algunos de los mejores estados de WhatsApp para nuestros amigos?
- ¿Por qué hay tantos chinos adictos a WeChat?
- ¿Cómo se usa el telegrama de aplicación en su país?
- ¿Cómo adquirió WhatsApp los usuarios iniciales y cómo crecieron?
La primera etapa son los requisitos, también llamados requisitos de obtención. Durante esta etapa, el cliente que desea que se desarrolle el software es frecuentemente entrevistado sobre lo que se requiere del producto final. El resultado de esta actividad es el documento de requisitos del producto que contiene todos los requisitos funcionales (qué debe hacer el software) y no funcionales (cómo debe hacerlo el software, rendimiento, seguridad, restricciones adicionales, etc.). Después de eso, se diseña la arquitectura del software: arquitectura general, estructura del paquete, contratos de interfaz, arquitectura de la base de datos, etc. Estas son algunas de las decisiones clave de diseño que se deben tomar durante el paso de Diseño. Después de eso, el software real es creado por los desarrolladores, que utilizan la arquitectura del software como un plan para ello. Cuando se escribe el software, debe verificarse, lo que significa que cumple con los requisitos del producto y validado, lo que significa que funciona según lo previsto. La última etapa es el mantenimiento, lo que significa el soporte del producto por parte de los desarrolladores, por ejemplo, parches y nuevas características.
Sin embargo, resulta que es increíblemente difícil prever el software final en las primeras etapas del ciclo de vida. El modelo de cascada es bueno en teoría, pero supone que los requisitos no cambian, que a veces es el caso, pero no tan a menudo como parece. Otro inconveniente del modelo en cascada es que el software real es funcional solo al final del ciclo de vida, alrededor del paso de verificación, mientras que en la mayoría de los escenarios de la vida real el cliente necesita software hoy, ahora mismo, en el acto, o incluso mejor, ayer . ¿Cómo deberían los desarrolladores lidiar con tal desafío?
La respuesta vino con modelos más flexibles, llamados Agile . En comparación con la cascada, estos modelos se centraron en el desarrollo rápido con lanzamientos frecuentes, cambios frecuentes en los requisitos y un entorno dinámico en general.
Aquí el desarrollo se divide en ciclos cortos llamados sprints, al final de cada uno debe haber un prototipo funcional del sistema de software. Cada sprint implementa solo una pequeña parte de los requisitos generales, por lo que se supone que la duración de un sprint es de varias semanas. Como puede ver, las etapas son algo similares a la cascada, siendo el plan las decisiones y los requisitos correspondientes, la implementación es la construcción y la verificación. Lanzamiento significa la implementación de software en un entorno en vivo, donde el cliente ya puede utilizarlo. Agile no tiene mantenimiento como etapa, ya que se ve como un proceso separado, pero también se puede administrar como parte de Agile, siendo una mención notable Kanban.
Como resultado, el software se entrega con mucha más frecuencia y en realidad se puede usar muy temprano en el desarrollo. Permite cambios frecuentes en los requisitos e incorpora la interacción del cliente como parte de cada paso del ciclo de vida del software, mientras que la cascada generalmente permite la interacción del cliente solo en las etapas de requisitos, verificación y mantenimiento.
Por supuesto, estos dos modelos no son los únicos que existen, pero espero que esto proporcione una idea de cómo los ingenieros de software resuelven la tarea de la creación consistente de un buen software.
Enlaces útiles:
- Modelos de ciclo de vida de desarrollo del sistema: descripción general de diferentes modelos con comparación de pros y contras;
- Proceso de desarrollo de software – Wikipedia – un poco largo de lectura, pero requiere una gran variedad de modelos a través del tiempo. También enlace los modelos que he mencionado como enlaces separados;
- Manifiesto para el desarrollo de software ágil
- Modelo de cascada – Wikipedia
- Scrum (desarrollo de software) – Wikipedia
- Kanban (desarrollo) – Wikipedia
