PARADIGMA DE DESARROLLO O MODELOS DE PROCESOS

Cuando los sistemas informáticos necesitaban adaptarse a las exigencias del mercado. El
programador solo utilizaba los requerimientos generales de quien necesitaba un programa
o un producto software.

1. Code & fix (codificar y corregir): Esta es una técnica antigua, por lo que quedo
terminando obsoleta. Esta técnica se basaba en requerimientos ambiguos o por
decir generales que no daba una especificación exacta de cómo se quería el
software. Se programaba, se corregía y se volvía a programar. El ciclo de vida de
este tipo de proyectos se finalizaba cuando se satisfacía las especificaciones.
2. Ciclo de vida lineal: O también conocido como “ciclo de vida básico del
software”. Es el más utilizado, siempre que es posible, precisamente por ser el
más sencillo. Consiste en descomponer la actividad global del proyecto en fases
que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada
una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil
dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de
cada fase). (Navas, 2017)
Las actividades de cada una de las etapas deben de ser independientes entre sí, la
condición principal es que no haya retroalimentación entre ellas. (Cantone, 2006)

Ilustración 1. Ciclo de vida lineal

3. Ciclo de vida en cascada puro: Es un ciclo de vida que permite iteraciones.

Después de cada etapa se realiza una o varias revisiones para comprobar si se
puede pasar a la siguiente.es un modelo rígido, poco flexible, y con muchas
restricciones. Una de sus ventajas, además de su planificación sencilla, es la de
proveer un producto con un elevado grado de calidad sin necesidad de un personal
 altamente calificado. Como inconvenientes tenemos la necesidad de contar con
todos los requerimientos al comienzo del proyecto, y si se han cometido errores y
no se detecta al principio es costoso y difícil volver atrás para realizar la
corrección.

Ilustración 2. Modelo en cascada

4. Ciclo de vida en V: El mayor inconveniente del modelo de cascada es que solo

se pasa a la siguiente fase cuando se completa la anterior, por tanto no es posible
volver atrás si se encuentra algún error en las etapas posteriores. El Modelo V
aporta opciones de evaluación del software en cada etapa de manera inversa.
(Tutoriales Point, s.f.)
Ósea que a diferencia del ciclo de vida en cascada, a este se le agregaron dos sub-
etapas de retroalimentación entre las etapas de análisis y mantenimiento, y entre
las de diseño y debugging.
Ilustración 3. Ciclo de vida en V

5. Ciclo de vida tipo Sashimi: Este ciclo de vida es parecido al ciclo de vida en
cascada puro, con la diferencia de que en el ciclo de vida en cascada no se puede
solapar las etapas, y en este sí. Esto suele, en muchos casos, aumentar su eficiencia
ya que la retroalimentación entre etapas se encuentra implícitamente en el modelo.
La ventaja es la ganancia de calidad en lo que respecta del producto final, la falta
de necesidad de una documentación detallada. Sus desventajas también se refieren
al solapamiento de las etapas: es muy difícil gestionar el comienzo y fin de cada
etapa y los problemas de comunicación.

Ilustración 4. El nombre procede del modelo del estilo japonés de presentar el pescado
crudo cortado, en que los cortes se solapan entre sí.
 6. Ciclo de vida en cascada con subproyectos: En este ciclo cada una de las
cascadas se dividen en subetapas independientes que se pueden desarrollar en
paralelo. La ventaja es que se puede tener más gente trabajando al mismo tiempo,
pero la desventaja es que puede surgir dependencias entre las distintas subetapas
que detengan el proyecto temporalmente si no es gestionado de manera correcta.

Ilustración 5. Esta es ideal cuando se cuenta con un plantel de programadores numeroso

7. Ciclo de vida iterativo: Es la iteración de varios ciclos de vida en cascada. Al

final de cada iteración se le entrega al cliente una versión mejorada o con mayores
funcionalidades del producto. El cliente es quien luego de cada iteración, evalúa
el producto y lo corrige o propone mejoras.
 Ilustración 6. Es ideal cuando el cliente necesita entregas rápidas aunque el
proyecto no esté terminado.

8. Ciclo de vida por prototipos: Se maneja a base de prototipos, es decir. Es uno

de los primeros ciclos de vida que permitían que el código fuente fuera
reutilizable, sin embargo con el modelo iterativo no solo es utilizable, si no que
para muchos, estos prototipos pueden llegar a ser el producto final que siempre
quisieron, lo cual lo hace realmente relevante y destacable, por encima del resto
de los modelos de antaño que puedas encontrar.

Ilustración 7. Este modelo nos permite suavizar la transición entre los requerimientos
iniciales y finales que surgen en la creación de un proyecto de grandes innovaciones

9. Ciclo de vida evolutivo: Este modelo acepta que los requerimientos del usuario
pueden cambiar en cualquier momento.
 La práctica nos demuestra que obtener todos los requerimientos al comienzo del
proyecto es extremadamente difícil, no solo por la dificultad del usuario de
transmitir su idea, sino porque estos requerimientos evolucionan durante el
desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. El modelo
de ciclo de vida evolutivo afronta este problema mediante la iteración de ciclos
requerimientos- desarrollo- evaluación.
Tomemos como ejemplo un sistema centralizado de stock- ventas- facturación.

Ilustración 8. Luego de cada desarrollo obtenemos una nueva versión del producto.

10. Ciclo de vida incremental: Este modelo de ciclo de vida se basa en la filosofía
de construir incrementando las funcionalidades del programa.
Se realiza construyendo por módulos que cumplen las diferentes funciones del
sistema. Esto permite ir aumentando gradualmente las capacidades del software.
Ese ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del
equipo desarrollar un módulo particular en el caso de que el proyecto sea realizado
por un equipo de programadores.
 Ilustración 9. Divide & conqueror

11. Ciclo de vida en espiral: Este modelo considera el riesgo, factor que otros
modelos olvidan o no prestan atención en el proceso. El modelo empieza
determinando los objetivos y las limitaciones del software al inicio de cada
repetición. En la siguiente etapa se crean los modelos de prototipo del software.
Esto incluye el análisis de riesgos. Luego un modelo estándar de SDLC se usa
para construir el software. En la cuarta etapa es donde se prepara el plan de la
siguiente repetición.
Entre las principales ventajas de desarrollar un proyecto con el modelo espiral, es
que los riesgos se van disminuyendo conforme avanzan los ciclos o iteraciones,
de hecho no puedes avanzar a un ciclo nuevo, si no se ha dado solución a todos
los riesgos latentes. Lamentablemente el modelo es realmente costoso y para que
puedas tener un alto nivel de eficacia en la evaluación final de tu proyecto con
este ciclo de vida, necesitas que tu equipo tenga un gran nivel de conocimientos y
si es posible buena experiencia para superar cualquier riesgo al cual se puedan
enfrentar.
 Ilustración 10. El espiral se repite las veces que sea necesario

12. Ciclo de vida XP o Programación Extrema: Posiblemente la más destacada de

las metodologías ágiles para los ciclos de vida de un software, es la metodología
XP o modelo de programación extrema. A diferencia del resto de las metodología
del mundo, habidas y por haber, esta es adaptable de acuerdo a las necesidades y
requerimientos que se tengan que implementar, con la ventaja de que podemos
hacer uso de cualquier modelo anterior para el desarrollo y de inmediato salirnos
y programar otras cosas, es muy solapador y permite mucha más libertad en el
equipo de trabajo que el resto de los modelos.
No hay documentación por ningún lado, esto es porque con tanta comunicación,
en realidad no es necesaria, sin embargo dentro del código se van dejando
comentarios con las cosas que otro programador no pueda llegar a entender y se
utilizan variables o clases entendibles para que todo el mundo tenga la facilidad
de comprenderlo. Ya solamente en caso muy necesario, se procede a hacer
documentación breve para algunas partes, pero regularmente no se utiliza de
forma tradicional.