Paradigmas de desarrollo del software

Vamos a comenzar explicando que es un 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.

Defincion: Es una agrupación de métodos, herramientas y procedimientos con el fin de

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

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 PROTOTIPO

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.
VENTAJAS:
• Permite la retroalimentación por parte del usuario.
• Desarrollo rápido.
• El cliente se siente parte de grupo.
Desventajas:
• El desarrollador debe dar forma prematuramente a un sistema, incluso antes de
comprender de manera básica el problema y su funcionamiento.
• El usuario puede creer que es un prototipo final.

MODELO DE DESARROLLO RAPIDO DE APLICACIÓN (CONSULTAR)

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.
FASES
• PLANIFIACION DE NECESIDADES:
En esta primera fase, lo que habrá que hacer será sentar las bases de las necesidades
del proyecto, tanto de necesidades de la aplicación como de alcance del proyecto y de
esta manera comenzar a trabajar en la creación de prototipos.
• DISEÑO CON EL USUARIO:
Los usuarios aportarán comentarios que serán determinantes a la hora de diseñar la
arquitectura del sistema. Con el feedback del usuario crearemos modelos y prototipos
iniciales. Y este paso se podrá repetir tantas veces como se considere necesario según
avance el proyecto.
• CONSTRUCCION:
Ahora que tenemos el diseño básico, tendremos que realizar el grueso del proyecto:
Codificación, pruebas e integración reales de la aplicación. Al igual que en la fase
anterior, esta se podrá repetir tantas veces como necesitemos, según haya nuevos
componentes o modificaciones en el proyecto.
• TRANSICION:
La última fase, también conocida como “cutover”, permitirá al equipo de desarrollo
pasar los componentes a un entorno de producción en vivo, para realizar todas las
pruebas que sean necesarias.
VENTAJAS:
• Aumenta la versatilidad y la adaptabilidad, dado que los desarrolladores pueden
hacer los ajustes necesarios de forma inmediata durante el proceso de
desarrollo.
• Las iteraciones rápidas reducen el periodo de desarrollo y agilizan la entrega.
• Se fomenta la reutilización del código, por lo que se reduce la programación
manual y, en consecuencia, disminuyen tanto la posibilidad de cometer errores
como los periodos de prueba.
• Se incrementa la satisfacción del cliente gracias al alto nivel de colaboración y
de coordinación entre las partes implicadas, como los desarrolladores, los
clientes y los usuarios finales.
• Existe una mejor gestión de riesgos, dado que las personas implicadas cuentan
con la capacidad de debatir y abordar las diferentes vulnerabilidades sin
necesidad de que se detengan los procesos de desarrollo.
 • Se reduce el factor sorpresa, ya que, a diferencia de la metodología de cascada,
en el desarrollo rápido de aplicaciones existen integraciones en las fases más
tempranas de los procesos de desarrollo de software.
DESVENTAJAS:
• Requiere sistemas modulares: dado que cada componente dentro del
sistema debe ser iterable y verificable por sí mismo, el diseño general del
sistema cuando se usa RAD requiere que cada componente sea modular, lo que
permite que los elementos sean intercambiados o alterados por una variedad de
miembros del equipo. .
• Dificultad dentro de proyectos a gran escala: si bien los métodos de
desarrollo rápido de aplicaciones llevan a una flexibilidad mucho mayor durante
el proceso de diseño y desarrollo, también tenderá a reducir el control y las
restricciones. Si bien esto no es intrínsecamente negativo, la administración
adecuada de esta flexibilidad y volatilidad adicionales dentro del alcance de
todo el proyecto puede ser difícil para aplicaciones más grandes.
• Exige mucha interactividad del usuario: obtener información y opiniones de
los usuarios temprano y con frecuencia es sin duda un beneficio desde la
perspectiva del diseño, pero esta espada de doble filo requiere que el equipo
esté dispuesto y sea capaz de comunicarse con los usuarios de forma mucho
más frecuente, en comparación a un método típico de desarrollo de cascada.

OTROS MODELOS

METODO SCRUM
La primera fase se encarga de estudiar y analizar el proyecto
identificando las necesidades básicas del sprint.
En el contexto de las metodologías ágiles, un sprint es un mini-
proyecto con una duración no mayor a un mes que se interconecta
con otros mini-proyectos para dirigirnos a los objetivos generales y
específicos del proyecto general.
INICIO
Las preguntas a hacer en la fase de inicio son:

 ¿Qué quiero?
 ¿Cómo lo quiero?
 ¿Cuándo lo quiero?

En este método solo se necesitan como máximo 5 personas para

realizarlo.

Planificación y estimación
La clave para llevar una buena administración de los proyectos es
hacer una planificación y estimación del sprint, lo que te ayudará a
establecer metas fijas y a cumplir con los plazos.
MODELO BASADO EN COMPONENTES

El desarrollo de software basado en componentes permite reutilizar

piezas de código preelaborado que permite realizar diversas tareas,
conllevando a diversos beneficios como: La mejora a la calidad, la
reducción del ciclo de desarrollo y mayor retorno sobre la inversión.

MODELO XP, PEROGRAMACION EXTREMA

PLANEACION: ESTA VA POR ESTAPAS Y MUCHA COMUNICACIÓN,

COMO LO PODEMOS VER EN LA IMAGEN

DISEÑO: El diseño es la guía para la implementación del sistema,

por lo tanto debe ser claro, y para poder ser claro necesita de
simplicidad, ya que no sólo será entendido por el programador sino
que también en muchas ocasiones, por el usuario.

CODIFICACION Para poder empezar en la codificación, antes se debieron

hacer pruebas unitarias de avances en diseño a los clientes, para así, poder
establecer los requerimientos primordiales

Uno de los mejores mecanismos para hacer que la codificación funcione de

manera correcta es la unión de dos personas del equipo, es decir, la
programación en parejas, cada una de estas personas, con características
distintas y especializadas en distintas áreas puede encargarse de tareas
distintas dentro de un mismo código.

PRUEBA Las pruebas unitarias son la medida de comprobación de

la funcionabilidad de cada uno de los módulos o componentes del
sistema, estas pueden ser ejecutadas a diario y brindan una
información del avance que tiene el proyecto.