Actividad 2 "Paradigmas"

PARADIGMA CICLO DE VIDA DEL SOFTWARE

Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento

PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS

Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.

En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:

Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.

PARADIGMA DEL MODELO ESPIRAL

Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.

CARACTERISTICAS:

• Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos.
• Incluye la etapa de análisis de riesgos, no incluida anteriormente.
• Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras.
• La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
• Este es el enfoque más realista actualmente.

El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

• experiencia para valorar el riesgo y saber cuando detener la evolución

EL MODELO DRA

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.

PARADIGMA DE TÉCNICAS DE CUARTA GENERACION

El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.

Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.

EL MODELO DE DESARROLLO CONCURRENTE

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

COMBINACIÓN DE PARADIGMAS

Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.

En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.

La siguiente figura muestra como pueden combinarse los 3 paradigmas mencionados durante un trabajo de desarrollo del software, en todos los casos el trabajo comienza con la recolección de requerimientos. El método puede seguir el ciclo de vida clásico (ingeniería de sistemas análisis de requerimiento de software) o puede ser la definición menos formal del problema usada en la construcción de un prototipo, independientemente debe producirse la comunicación cliente-realizador del software.