Paradigmas en el desarrollo de software

Definición de Paradigma:
Para la Ingeniería de Software el paradigma es una agrupación de métodos,
herramientas y procedimientos con el fin de describir un modelo.

Paradigmas de la Ingeniería de Software:

Cada metodología de desarrollo de software tiene más o menos su propio enfoque
para el desarrollo de software.

La ingeniería del Software define paradigmas de desarrollo estructurado como base

a seguir en un proyecto de Software. Si ninguno de estos paradigmas se adecua al
problema por resolver, entonces el desarrollador se verá obligado a combinar los
paradigmas o definir uno nuevo.
Para resolver los problemas reales, el ingeniero del software debe incorporar una
estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas.

La estrategia a menudo se llama modelo de proceso o paradigma de ingeniería del

software. Se selecciona un modelo de proceso para la ingeniería del software según
la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a
utilizarse y los controles y entregas que se requieren.

Los paradigmas o modelos de desarrollo de software más utilizados son: el método

de cascada, el método de prototipos y el de Espiral.

Modelo Lineal Secuencial o de Cascada (Waterfall):

Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos
hacia abajo (como en una cascada de agua) a través de las fases de análisis de las
necesidades, el diseño, implantación, pruebas (validación), la integración, y
mantenimiento.

La primera descripción formal del modelo de cascada se cita a menudo a un artículo

publicado por Winston Royce en 1970, aunque Royce no utilizó el término "cascada"
en este artículo.

Es el paradigma más antiguo y fue el más utilizado durante la hegemonía del método
estructurado. El número de etapas propuestas varía de acuerdo al proyecto a
desarrollar, aunque existen etapas comunes para este paradigma.

Este paradigma concibe las fases de desarrollo como proceso independientes en el

tiempo, es decir, no se pueden realizar de manera simultánea; cada fase empieza
cuando se ha terminado la fase anterior y para poder pasar a otra fase es necesario
haber conseguido todos los objetivos de la etapa previa.

Las etapas de este paradigma se desarrollan en forma secuencial y cuando se detecta

algún error en alguna etapa, lo más probable será abandonar todo lo avanzado y
regresar a la etapa primera de análisis de requisitos del sistema; pues, aunque la
vuelta atrás por etapas es posible, ésta demanda mucho esfuerzo y puede terminar
en el colapso.

Definición de los requisitos. En este proceso se identifican las necesidades y

requerimientos del cliente con respecto al software.

Análisis y Diseño. En el análisis se establece la viabiliad del software desde el punto

de vista técnico y económico, se planifican las actividades y el presupuesto. En el
diseño del software se centra en cuatro atributos de un programa: estructura de
datos, arquitectura del software, representaciones de interfaz y detalle procedimental
(algoritmo).

Codificación: Se traducir en forma legible por la máquina el modelo previamente

diseñado. El paso de generación de código lleva a cabo esta tarea. Si lleva a cabo el
diseño de una forma detallada, la generación de código se realiza mecánicamente.
Pruebas. El proceso de pruebas se centra en los procesos lógico internos del
software, y en los procesos externos funcionales. Se deben realizar las pruebas para
detección de errores y asegurarse que las entradas definidas produzcan resultados
reales que concuerden con los resultados requeridos.

Mantenimiento. El software indudablemente sufrirá cambios después de ser

entregado al cliente. El mantenimiento vuelve a aplicar cada una de las fases
precedentes a un programa ya existente y no a uno nuevo.

Modelos de Prototipos:

El modelo de prototipos permite desarrollar modelos de aplicaciones de software que

permiten ver la funcionalidad básica de la misma, sin necesariamente incluir toda la
lógica o características del modelo terminado.

El prototipo permite al cliente evaluar en forma temprana el producto, e interactuar

con los diseñadores y desarrolladores para saber si se está cumpliendo con las
expectativas y las funcionalidades acordadas.

Los Prototipos no poseen la funcionalidad total del sistema pero si condensa la idea
principal del mismo, Paso a Paso crece su funcionalidad, y maneja un alto grado de
participación del usuario.

Los modelos previos pueden ser en papel o computadora para mostrar la interacción
hombre-máquina; un modelo que muestra algunas funciones del software; o, algún
software anterior (parte o todo) parecido al que se desea, que luego será modificado
y adaptado según los requerimientos del usuario.
El paradigma de construcción de prototipos comienza con la recolección de requisitos.
El desarrollador y el cliente encuentran y definen los objetivos globales para el
software, identifican los requisitos conocidos, y las áreas del esquema en donde es
obligatoria más definición. Entonces aparece un “diseño rápido”.

El diseño rápido se centra en una representación de esos aspectos del software que
serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un
prototipo.
El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del
software a desarrollar.

La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la

vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.

Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los
requisitos del software. Si se construye un prototipo de trabajo, el desarrollador
intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas
que permiten generar rápidamente programas de trabajo.

El paradigma de la elaboración por prototipos resulta una alternativa para el

desarrollo rápido de aplicaciones de software; pues el analista acorta en tiempo entre
la determinación de los requerimientos de información y la entrega de un sistema
funcional, además que el usuario podrá modificar y depurar sus requerimientos
conforme avance el desarrollo del proyecto.

Modelo en Espiral:

Propuesto por Boehm en 1988 con la finalidad de paliar los inconvenientes del modelo
en cascada y adecuar el desarrollo por prototipos a problemas complejos.

Este paradigma combina el paradigma de cascada y el de construcción por prototipos,

agregando una etapa de "análisis de riesgo".
El paradigma de espiral es un modelo de ciclo de vida orientado a riesgos que divide
un proyecto software en miniproyectos y donde cada miniproyecto se centra en uno
o más riesgos importantes hasta que todos estos estén controlados.

Este modelo se realiza en varias iteraciones; se parte de una escala pequeña la cual
comienza con la identificación de objetivos, alternativas y restricciones; en medio de
la espiral, se localizan riesgos, se genera un plan para manejarlos, y a continuación
se establece una aproximación a la siguiente iteración.

Se proporciona el potencial para el desarrollo rápido de versiones increméntales del

software. En el modelo espiral, el software se desarrolla en una serie de versiones
increméntales. Durante las primeras iteraciones, la versión incrementar podría ser
un modelo en papel prototipo.

Durante las últimas iteraciones, se producen versiones cada vez más completas de
ingeniería del sistema. El modelo en espiral se divide en un número de actividades
estructurales también llamadas guiones de tareas. Estas inclusive pueden variar de
3 a 6 tareas.

Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira
alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el
centro. El primer circuito de la espiral produce el desarrollo de una especificación de
productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un
prototipo y progresivamente versiones más sofisticadas del software. Cada paso de
la región de planificación produce ajustes en el plan del proyecto.

El costo y la planificación se ajustan según la reacción ante la evaluación del cliente.

Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas
para completar el software.

En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativo

hasta que el software se retira. Hay veces en que el proceso está inactivo, pero
siempre que se inicie un cambio, el proceso arranca en el punto de entrada adecuado
(p. Ej.: mejora el producto).

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software

a gran escala. Como el software evoluciona, a medida que progresa el proceso, el
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno
de los niveles evolutivos.

El modelo en espiral utiliza la construcción de prototipos como mecanismos de

reducción de riesgos, pero lo que es más importante, permite a quien lo desarrolla
aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del
producto.

Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico,
pero lo incorpora al marco de trabajo interactivo que refleja de forma más realista el
mundo real. El modelo en espiral demanda una consideración directa de los riesgos
técnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir
los riesgos antes de que se conviertan en problemáticos.

El paradigma espiral, al igual que los demás modelos, se puede combinar con otros
paradigmas.

Módelo “Rapid Application Development” (RAD)

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de

software, que implica el desarrollo iterativo y la construcción de prototipos.

El desarrollo rápido de aplicaciones es un término originalmente utilizado para

describir un proceso de desarrollo de software introducido por James Martin en 1991.
El objetivo clave de este modelo es un rápido desarrollo y entrega de una alta calidad
en un sistema de relativamente bajo coste de inversión.
Intenta reducir el riesgos inherente del proyecto partiendolo en segmentos más
pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.

Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente

mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo),
promueve la participación de los usuarios y el uso de herramientas de desarrollo
computarizadas.

Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI),

Computer Aided Software Engineering (CASE) las herramientas, los sistemas de
gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación,
generadores de código, y técnicas orientada a objetos.

Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que

la ingeniería tecnológica o excelencia es de menor importancia.

El control de proyecto implica el desarrollo de prioridades y la definición de los plazos

de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de
requisitos para el ajuste, no en el aumento de la fecha límite.
En general incluye “Joint application development” (JAD), donde los usuarios están
intensamente participando en el diseño del sistema, ya sea a través de la creación
de consenso estructurado en talleres, o por vía electrónica.

La participación activa de los usuarios es imprescindible.

Iterativamente realiza la producción de software, en lugar de enfocarse en un

prototipo.
Produce la documentación necesaria para facilitar el futuro desarrollo y
mantenimiento.

Criterios Generales para Seleccionar un Paradigma:

El ingeniero de sistemas debe estar en capacidad de seleccionar de manera correcta
la utilización de alguno de los paradigmas anteriormente mencionados o una
combinación de ellos, evaluando las principales características del problema al cual
se enfrentará.

Estas características se deben captar en la fase de análisis general del sistema y

deberán reforzarse en la etapa de análisis detallado del sistema. Como puntos de
evaluación para la selección del paradigma adecuado tenemos:

 La naturaleza del proyecto, donde se agrupan criterios como la complejidad

del producto final, el conocimiento de la aplicación por parte del grupo, la utilización
final del software, etc.
 El control del proyecto y la importancia de los avances, directamente
relacionado con las características del cliente, sus perspectivas y deseos respecto al
software, la importancia de su inclusión en el grupo de desarrollo del producto, etc..
 Los métodos y las herramientas disponibles para el desarrollo de cada una de
las fases a realizar.
 Metodología Scrum
¿Qué es?

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en
construir primero la funcionalidad de mayor valor para el cliente y en los principios de
inspección continua, adaptación, auto-gestión e innovación.

¿Cuándo se utiliza?

Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado

que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear
el software con los objetivos de negocio de su empresa, ya que puede introducir cambios
funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que
forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para
desarrollar sus capacidades.

Beneficios

 Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que

le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información
el Product Owner establece su prioridad. De manera regular, en las demos de Sprint
el Product Owner comprueba que efectivamente los requisitos se han cumplido y
transmite se feedback al equipo.
 Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología está
diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.
 Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por completo.
 Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión
funcional después de cada iteración, ayuda a la obtención de un software de calidad
superior.
 Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos
para organizarse.
 Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de
inversión.
 Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del
equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible
estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que
todavía está en el Backlog.
 Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.

Si desea conocer más acerca de Scrum,