# data[].attributes.body
La metodología Scrum es un proceso para llevar a cabo un conjunto de tareas de forma regular con el objetivo principal de trabajar de manera colaborativa, es decir, para fomentar el trabajo en equipo.

Con este método de trabajo lo que se pretende es alcanzar el mejor resultado de un proyecto determinado. Las prácticas que se aplican con la metodología Scrum se retroalimentan unas con otras y la integración de las mismas tiene su origen en un estudio de cómo hay que coordinar a los equipos para ser potencialmente competitivos. En Scrum se van realizando entregas regulares y parciales del trabajo final, de manera prioritaria y en función del beneficio que aportan dichas entregas a los receptores del proyecto. Por este motivo, es una metodología especialmente indicada para proyectos complejos, con requisitos cambiantes y en los que la innovación y la flexibilidad son protagonistas.

# data[].attributes.body
Metodología en cascada Este modelo fue propuesto por Winston Royce en el año 1970. Es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencial como el lineal. Después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente, los resultados de cada una de las fases sirven como hipótesis de partida para la siguiente. Es un modelo rígido, poco flexible, y con muchas restricciones, aunque fue uno de los primeros pioneros, y sirvió de base para el resto de los modelos de ciclo de vida.

# data[].attributes.body
Llamado algunas veces “ciclo de vida básico” o “modelo en cascada”, el modelo lineal secuencial sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. Es un ciclo de vida en sentido amplio, que incluye no sólo las etapas de ingeniería sino toda la vida del producto: las pruebas, el uso (la vida útil del software) y el mantenimiento.

Es el más sencillo de dos los modelos. consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa).

# data[].attributes.body
Una variante de la representación del modelo de la cascada se denomina modelo en V. En donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución.

Una vez que se ha generado el código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de pruebas (acciones para asegurar la calidad) que validan cada uno de los modelos creados cuando el equipo fue hacia abajo por el lado izquierdo. En realidad, no hay diferencias fundamentales entre el ciclo de vida clásico y el modelo en V.

# data[].attributes.body
Metodología orientada a Objetos Esta técnica fue presentada en la década del 90, tal vez como una de las mejores metodologías a seguir para la creación de producto de software. Puede considerarse como un modelo pleno a seguir, así también como una alternativa dentro de los modelos anteriores.

La metodología orientada a objetos son técnicas de abordar la complejidad del problema que utilizan como procedimiento de modularización la identificación de los objetos del dominio del problema. Cada módulo que se define corresponde a la abstracción de un objeto existente en el dominio del problema y en él se incluyen todos los aspectos (funcionalidad, estados, datos, etc.) que son propios del objeto. La descomposición del problema se realiza utilizando los criterios propios del dominio del problema, y no en función de criterios de representación informática.

# data[].attributes.body
Modelo espiral, propuesto en primer lugar por Barry Boehm, es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de versiones cada vez más completas. Boehm describe el modelo del modo siguiente:

El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en software. Tiene dos características distintivas principales. La primera es el enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su implementación, mientras que disminuye su grado de riesgo.  completas del sistema cuya ingeniería se está haciendo.

# data[].attributes.body
El modelo incremental combina aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo.

Por ejemplo, un software para procesar textos que se elabore con el paradigma incremental quizá entregue en el primer incremento las funciones básicas de administración de archivos, edición y producción del documento; en el segundo dará herramientas más sofisticadas de edición y producción de documentos; en el tercero habrá separación de palabras y revisión de la ortografía; y en el cuarto se proporcionará la capacidad para dar formato avanzado a las páginas