ParadigmaDefinicinUn 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.

ParadigmaModelo LinealModelo en CascadaModelo en Cascada ModificadoModelo de Construccin en PrototiposModelo RADModelos Evolutivos - Incremental - Modelo de la espiral de BoehmModelo de Mtodos FormalesTcnicas de 4ta. GeneracinParadigmas 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 cuandoSi 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.

Modelo incremental Combina elementos del modelo de cascadaEl 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

Modelo de la espiral de Boehm Combina los elementos controlados y sistemticos del modelo de cascada con la filosofa interactiva de construccin de prototipos. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software Comunicacin con el cliente. 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 objetosDado 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 formalesEspecifico 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: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.

Modelo de construccin de prototiposEste 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