domingo, 8 de marzo de 2015

TÉCNICAS DE CUARTA GENERACIÓN

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, más tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Los Tipos Más Comunes De Generadores De Código Cubren Uno O Varios De Los Siguientes Aspectos:

Ø    Acceso a base de datos:
Utilizando lenguajes de consulta de alto nivel. Generadores de códigos: a partir de una especificación de los requisitos se genera automáticamente toda la aplicación

Ø    Generación de pantallas:
Permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.

Ø    Gestión de entornos gráficos.


Ø    Generación de informes:
  
Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. En el mejor de los casos el cliente debería describir los requerimientos y estos traducirse directamente a un prototipo operacional pero en general esto no es así. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla, además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo.

Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, sin embargo es necesaria una estrategia del diseño para el sistema. El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales. El último paso de la figura anterior contiene la palabra producto para transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la  productividad de la gente que construye el software. Los detractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g está abierto a discusión.
Hay algunos méritos en las razones de cada parte. Aunque es algo difícil separar los hechos de las suposiciones es posible resumir el estado actual de los métodos T4G:
Con muy pocas excepciones el dominio de aplicación actual de las T4G está limitado a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comercial, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.
La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad de análisis y diseño.

Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.

MODELO DE ENSAMBLE DE COMPONENTES


El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases). Esto se debe gracias a que, si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las inherentes aplicaciones y arquitecturas de sistemas basados en computadoras. En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en una biblioteca de clases o depósito. Acto seguido, se determina cuáles de ellas ya existen a fin de reutilizarlas. 

El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software.
No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software.

 Ventajas
El uso de este paradigma posee algunas ventajas:
Ø   Reutilización del Software
Ø   Simplifica las pruebas.
Ø   Simplifica el mantenimiento del sistema.
Ø   Posee una Mayor calidad.

Notación De Componentes
 El diagrama de componentes muestra la relación entre componentes de software, sus dependencias, su comunicación su ubicación y otras condiciones.

Interfaces
 Los componentes también pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente está ofreciendo y dejando disponibles a otros componentes de software y clases. Típicamente, un componente está compuesto por numerosas clases y paquetes de clases internos. También se puede crear a partir de una colección de componentes más pequeños.

Los Componentes Y Los Nodos
 Un diagrama de despliegue muestra el despliegue físico del sistema en un ambiente de producción (o de prueba). Muestra dónde se ubican los componentes, en qué servidores, máquinas o hardware. Puede representar los enlaces de redes.



Ventajas:
Ø  El análisis del riesgo se hace de forma explícita y clara. 
Ø  Une los mejores elementos de los restantes modelos. 
Ø  Reduce riesgos del proyecto. 
Ø  Incorpora objetivos de calidad.
Ø  Integra el desarrollo con el mantenimiento


Desventajas:
Ø  Genera mucho tiempo en el desarrollo del sistema.
Ø  Modelo costoso.
Ø  Requiere experiencia en la identificación de riesgos.
Ø  Inconvenientes.
Ø  Genera mucho trabajo adicional.
Ø  Cuando un sistema falla se pierde tiempo y coste dentro de la empresa.


MODELO DE DESARROLLO RÁPIDO DE APLICACIONES

El desarrollo rápido de aplicaciones o DRA (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE.
Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.
El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

Modelado de gestión:
El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas:
¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

Modelado de datos:
El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso:
Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

Generación de aplicaciones:
El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas de entrega:
Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
Obviamente la limitación de tiempo impuesto en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un solo conjunto.

Ø    Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.

Ø    DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.

 Has Click aquí para seguir el enlace de esta imagen


No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modular adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione.
DRA no es adecuado cuando Ingeniería de Software los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes. DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.


Características De Rad
Entre las principales características del RAD tenemos:

1. Equipos Híbridos
Ø    Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.
Ø    Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

2. Herramientas Especializadas
Ø   Desarrollo "visual"
Ø   Creación de prototipos falsos (simulación pura)
Ø   Creación de prototipos funcionales
Ø   Múltiples lenguajes
Ø   Calendario grupal
Ø   Herramientas colaborativas y de trabajo en equipo
Ø   Componentes reusables
Ø   Interfaces estándares (API)
Ø   Control de versiones

3. "Timeboxing"
Ø   Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

 Prototipos Iterativos y Evolucionarios

Ø   Reunión JAD (Joint Application Development):
Ø  Se reúnen los usuarios finales y los desarrolladores.
Ø  Lluvia de ideas para obtener un borrador inicial de los requisitos.

 Iterar hasta acabar:

Ø    Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
Ø    Los diseñadores revisan el prototipo.
Ø    Los clientes prueban el prototipo, depuran los requisitos.
Ø    Los clientes y desarrolladores se reúnen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios.

Ø    Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.
Ventajas de DRA
Ø     Puede ahorrar dinero en comparación con construir.
Ø     Los entregables pueden ser fácilmente trasladados a otra   plataforma.
Ø     El desarrollo se realiza a un nivel de abstracción mayor.
Ø     Visibilidad temprana.
Ø     Mayor flexibilidad.
Ø     Menor codificación manual.
Ø     Mayor involucramiento de los usuarios.
Ø     Posiblemente menos fallas.
Ø    Ciclos de desarrollo más pequeños.
Ø     Interfaz gráfica estándar.

Desventajas de DRA
Ø     Comprar puede ser más caro que construir.
Ø     Costo de herramientas integradas y equipo necesario.
Ø     Progreso más difícil de medir.
Ø     Menos eficiente.
Ø     Menor precisión científica.
Ø    Es difícil para los clientes proporcionar todos los requisitos de una sola vez, siendo esto necesario para este modelo.
Ø    Más fallas (por síndrome de "codificar a la ligera").
Ø    Los Prototipos pueden no escalar, un problema mayúsculo.
Ø    Se requiere más desarrolladores, ya que múltiples equipos    trabajan concurrentemente

MODELO DE MÉTODOS  FORMALES

La denominación métodos formales se usa para referirse a cualquier actividad relacionada con representaciones matemáticas del software, incluyendo la especificación formal de sistemas, análisis y demostración de la especificación, el desarrollo transformacional y la verificación de programas. Todas estas actividades dependen de una especificación formal del software.
Una especificación formal del software es una especificación expresada en un lenguaje cuyo vocabulario, sintaxis y semántica están formalmente definidos. Esta necesidad de una definición formal significa que los lenguajes de especificación deben basarse en conceptos matemáticos cuyas propiedades se comprendan bien. La rama de las matemáticas usada es la de matemática discreta, y los conceptos matemáticos provienen de la teoría de conjuntos, la lógica y el álgebra.
En la década de los 80, muchos investigadores de ingeniería del software propusieron que el uso de métodos formales de desarrollo era la mejor forma de mejorar la calidad del software. Argumentaban que el rigor y el análisis detallado, que son una parte esencial de los métodos formales, podrían dar lugar a programas con menos errores y más adecuados a las necesidades de los usuarios. Predijeron que, en el siglo XXI, una gran proporción del software estaría desarrollado usando métodos formales.
Claramente, esta predicción no se ha hecho realidad. Existen cuatro razones principales para esto:


1. Una ingeniería del software exitosa.
El uso de otros métodos de ingeniería del software como los métodos estructurados, gestión de configuraciones y ocultación de la información en el diseño del software y procesos de desarrollo ha conducido a mejoras en la calidad del software. La gente que sugirió que la única forma de mejorar la calidad del software era usando métodos formales estaba claramente equivocada.

2. Cambios en el mercado.
En la década de los 80, la calidad del software fue vista como un problema clave de la ingeniería del software. Sin embargo, desde entonces, la cuestión crítica para muchas clases de desarrollo del software no es la calidad, sino la oportunidad de mercado. El software debe desarrollarse rápidamente, y los clientes están dispuestos a aceptar software con algunos defectos si se les entrega rápidamente. Las técnicas para el desarrollo rápido del software no funcionan de forma efectiva con las especificaciones formales. Por supuesto, la calidad todavía es un factor importante, pero debe lograrse en el contexto de entrega rápida.
3. Ámbito limitado de los métodos formales.
Los métodos formales no son muy apropiados para la especificación de interfaces de usuario e interacciones del usuario. El componente de interfaz de usuario se ha convertido en una parte cada vez mayor de la mayoría de los sistemas, de manera que realmente s6lo pueden usarse métodos formales cuando se desarrollan las otras partes del sistema.

4. Escalabilidad limitada de los métodos formales.
Los métodos formales todavía no son muy escalables. La mayoría de los proyectos con éxito que han usado estas técnicas han estado relacionados con núcleos de sistemas críticos relativamente pequeños. A medida que los sistemas incrementan su tamaño, el tiempo y esfuerzo requerido para desarrollar una especificación formal crece de forma desproporcionada.

Ventajas
Ø  Se comprende mejor el sistema.
Ø  La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.
Ø  El sistema se describe de manera más precisa.
Ø  El sistema se asegura matemáticamente que es correcto según las  especificaciones.
Ø  Mayor calidad software respecto al cumplimiento de las especificaciones.

 Desventajas
Ø  El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.
Ø   Los investigadores por lo general no conocen la realidad industrial.
Ø   Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.
Ø  Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

El uso de métodos formales está creciendo en el área del desarrollo de sistemas críticos, en donde las propiedades emergentes del sistema tales como seguridad, fiabilidad y protección son muy importantes. El alto coste de los fallos de funcionamiento en estos sistemas implica que las compañías están dispuestas a aceptar los costes elevados iniciales de los métodos formales para asegurar que su software es tan confiable como sea posible.

Los sistemas críticos en los que los métodos formales se han aplicado con éxito incluyen un sistema de información de control de tráfico aéreo, sistemas de señalización de redes ferroviarias, sistemas de naves espaciales y sistemas de control médico.
MODELO EVOLUTIVO
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo

1.           Desarrollo exploratorio: donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2.           Prototipos desechables: Donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos.
     



 Desventajas:

Ø    El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.

Ø    A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.

MODELO INCREMENTAL.
El modelo incremental es una evolución del modelo de cascada; viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no secuencial.
El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc. del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias.

El modelo incremental por otra parte es una unión de las mejores funcionalidades del modelo de cascada y del modelo de prototipos. A medida que se presenta un prototipo se produce un “incremento”, que es una interacción del proceso anterior pero aplicando las experiencias aprendidas del proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están orientados a ser operacionales en cada incremento y no ser solo una “previa” de cómo sería el sistema en su versión final.

MODELO ESPIRAL

Es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza prototipos como apoyo. La forma de espiral representa una interacción (repetición) de procesos que, a medida que se van entregando prototipos y éstos son revisados por los clientes o usuarios finales, el tiempo empleado para desarrollar la próxima versión es cada vez mayor. Cada división recibe el nombre de región de tareas.
Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y no es tan usado en la realidad.
Modelo Espiral WINWIN

Una variante interesante del Modelo Espiral es el Modelo espiral Win-Win. El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar, sin embargo, esta es una situación que rara vez ocurre. Normalmente el cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
Las mejores negociaciones se fuerzan en obtener <<Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.