Paradigma

Definicin
Un paradigma es una tcnica, un modelo o un
conjunto de herramientas para representar la
solucin de problemas especficos.

Un paradigma de programacin es una
coleccin de modelos conceptuales que juntos
modelan el proceso de diseo y determinan al
final la estructura de un programa.



Paradigma
Modelo Lineal
Modelo en Cascada
Modelo en Cascada Modificado
Modelo de Construccin en Prototipos
Modelo RAD
Modelos Evolutivos
- Incremental
- Modelo de la espiral de Boehm
Modelo de Mtodos Formales
Tcnicas de 4ta. Generacin
Paradigmas Orientados a Objetos

Modelo Lineal
Modelo construye y compone
Este es el primer modelo de ciclo de vida que
se us y probablemente el ms usado.
El software se desarrolla sin especificar
requerimientos y sin diseo. Luego el software
cambia tantas veces como sea necesario
hasta que satisface al cliente.

Modelo de cascada
(waterfall)
Hace el proceso de desarrollo mas
estructurado.
El modelo original es estrictamente
secuencial, esto significa que cada fase debe
terminar para que la siguiente pueda comenzar
No establece retroalimentacin entre fases ni
redefinicin de fases anteriores.

Modelo de cascada modificado

Se invent para permitir retroalimentacin entre fases
Es un modelo interactivo y no lineal.


El modelo de la cascada (y
el de la cascada
modificada) son inflexibles
en el particionamiento del
proyecto en sus distintas
fases. Sin embargo,
generalmente reflejan la
prctica de la ingeniera.
Modelo de construccin de
prototipos

Escuchar al cliente. Recoleccin de requisitos. Se encuentran y
definen los objetivos globales, se identifican los requisitos conocidos
y las reas donde es obligatorio ms definicin.
Construir y revisar la maqueta (prototipo).
El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los
requisitos del software.
Este modelo es til cuando:
El cliente no identifica los requisitos detallados.
El responsable del desarrollo no est seguro de la eficiencia de un
algoritmo, sistema operativo o de la interfase hombre-mquina.
Su principal desventaja es que una vez que el cliente ha dado su
aprobacin final al prototipo y cree que est a punto de recibir el
proyecto final, se encuentra con que es necesario reescribir buena
parte del prototipo para hacerlo funcional
Modelo de construccin de
prototipos

Modelo RAD (Diseo Rpido de
Aplicaciones)

Es un modelo de proceso de desarrollo de software de cascada que
enfatiza un ciclo de desarrollo extremadamente corto. Este modelo se
puede usar si:
Se comprenden bien los requisitos y se limita el mbito del proyecto.
Es fcil dividir al sistema en mdulos.
Se utiliza un enfoque de construccin basado en objetos reusables.

Tiene algunas desventajas:
Requiere recursos humanos suficientes como para crear el nmero
correcto de equipos.
Necesita que el cliente y el desarrollador se comprometan en las
actividades necesarias para completar un sistema en un tiempo corto.
Modelos Evolutivos

Este se utiliza cuando
Si los requisitos cambian conforme el desarrollo avanza.
Si las fechas de mercado hacen imposible tener un producto completo y hay que
introducir una versin limitada.
Si los requisitos centrales estn bien definidos pero todava hay que definir los
detalles de las extensiones del producto.

1. Modelo incremental
Combina elementos del modelo de cascada
El primer incremento es un producto esencial (ncleo).
El cliente usa el producto central y en base a la utilizacin y/o evaluacin
Este proceso se repite hasta que se elabora el producto completo.
Es interactivo, al igual que el de construccin de prototipos y otros enfoques
evolutivos.
Es til cuando la dotacin de personal no est disponible para una
implementacin completa. El primer incremento se pueden implementar con
pocas personas. Si el producto central es bien recibido, se puede aadir mas
personal.

Modelos Evolutivos

1. Modelo de la espiral de Boehm
o Combina los elementos controlados y sistemticos del modelo de
cascada con la filosofa interactiva de construccin de prototipos.
o Proporciona el potencial para el desarrollo rpido de versiones
incrementales del software
o Comunicacin con el cliente.
o Planeacin. Define recursos tiempo y otras informaciones relacionadas
con el proyecto.
Anlisis de riesgos. Evala riesgos tcnicos y de
administracin.
Ingeniera. Construye una o ms representaciones de la
aplicacin.
Construccin y adaptacin. Construye, prueba, instala y
proporciona soporte al usuario (p.e. documentacin).
Evaluacin del cliente

Modelos Evolutivos

Cada regin tiene tareas que se adaptan a las
caractersticas del proyecto.
El primer circuito de la espiral produce una
especificacin de productos; los pasos siguientes en
la espiral se podran usar para desarrollar un
prototipo y progresivamente versiones ms
sofisticadas del software.
Cada paso por la regin de planificacin produce
ajustes en el plan del proyecto.
El costo y la planificacin se ajustan segn la reaccin
ante la evaluacin del cliente.
A diferencia del modelo de vida clsico que termina
cuando se entrega el software, el modelo en espiral
se puede adaptar y aplicarse a lo largo de toda la
vida del software.
Su principal desventaja es que es nuevo (1988) y no se ha
utilizado tanto como otros modelos de ciclo de vida. Adems
puede resultar difcil convencer a algunos clientes que el
proceso es controlable.
Diagrama de modelo espiral
Modelo de mtodos formales

Permiten especificar, desarrollar y verificar un sistema aplicando una notacin
rigurosa y matemtica.
Eliminan muchos de los problemas que son difciles de superar con otros
paradigmas. La ambigedad, la incompetez y la inconsistencia se pueden descubrir
y corregir, no mediante una revisin, sino mediante la aplicacin del anlisis
matemtico.
Su principal desventaja es que requiere que el desarrollador y el cliente tengan
conocimientos formales para poderlos aplicar y comunicarse entre s.

Tcnicas de cuarta generacin (4GT)

Permite especificar el software usando lenguajes especializados o
notaciones grficas que describan el problema.
Requiere usar alguna herramienta CASE (Computer-aided Software
Engineering) con herramientas tales como: SQL (Structured Query
Language), generador de reportes, base de datos, definidores de
pantallas, generadores de cdigo, generador de grficas, hoja de
clculo, etc.
Idealmente el cliente describe los requisitos, que son traducidos
inmediatamente a un prototipo operativo.
En aplicaciones pequeas, se puede ir directamente a la
implementacin usando un lenguaje de cuarta generacin (4GL).
Paradigma orientado a
objetos
La POO, es un paradigma que define los
programas en clases de objetos, objetos que se
combinan en datos, mtodos e identidad
De esta forma el objeto tiene toda la
informacin (atributos) que lo diferencian de
otros objetos
Dado el conjunto clases de objetos el
programador no debe separar ni dar mayor
importancia a atributos a favor de mtodos
La programacin estructurada esta
pensada en procedimientos y funciones y
en segundo lugar los datos que se van a
marcar
La POO define objetos y cada clase es
una solucin de un caso de la vida real
Modelo de mtodos formales
Especifico desarrollo y venfico un
sistema aplicando una notacin rigurosa
Matemtico
Elimina problemas de ambigedad,
inconsistencia y se puede regir por un
anlisis matemtico.
La desventaja es que el desarrollador y
el cliente deben tener conocimientos
formales para comunicarse entre si.
Modelo de construccin de
prototipos
Tiene tres pasos:
1. Escuchar al cliente. Recoleccin de
requisitos. Se encuentran y definen los
objetivos globales, se identifican los
requisitos conocidos y las reas donde es
obligatorio ms definicin.
2. Construir y revisar la maqueta (prototipo).
3. El cliente prueba la maqueta (prototipo) y lo
utiliza para refinar los requisitos del software.

Modelo de construccin de
prototipos
Este modelo es til cuando:
El cliente no identifica los requisitos detallados.
El responsable del desarrollo no est seguro de la eficiencia de un
algoritmo, sistema operativo o de la interface hombre-mquina.

Su principal desventaja :
es que una vez que el cliente ha dado su
aprobacin final al prototipo y cree que est a
punto de recibir el proyecto final, se encuentra
con que es necesario reescribir buena parte del
prototipo para hacerlo funcional, porque lo ms
seguro es que el desarrollador haya hecho
compromisos de implementacin para hacer
que el prototipo funcione rpidamente. Es
posible que el prototipo sea muy lento, muy
grande, no muy amigable en su uso, o incluso,
que est escrito en un lenguaje de
programacin inadecuado.
Modelo RAD (Diseo Rpido de
Aplicaciones)

Es un modelo de proceso de desarrollo
de software de cascada que enfatiza un
ciclo de desarrollo extremadamente
corto. Este modelo se puede usar si:
Se comprenden bien los requisitos y se
limita el mbito del proyecto.
Es fcil dividir al sistema en mdulos.
Se utiliza un enfoque de construccin
basado en objetos reusables.

Tiene algunas desventajas:
Requiere recursos humanos suficientes
como para crear el nmero correcto de
equipos.
Necesita que el cliente y el desarrollador
se comprometan en las actividades
necesarias para completar un sistema
en un tiempo corto