ACTIVIDAD 2 "PARADIGMAS"

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.

CARACTERISTICAS:

• Este paradigma ayuda al cliente a brindar requisitos paso a paso.
• También facilita al programador ir probando algoritmos no explotados con anterioridad, de los que no tiene seguridad de su eficiencia.
• Consiste en la creación de prototipos

DESVENTAJAS:

La construcción de prototipos como paradigma para la ingeniería de software puede ser problemático por las siguientes razones:
1. El cliente ve funcionando lo que parece ser una versión del software ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas hacer que funcione no han considerado los aspectos de calidad y mantenimiento a largo plazo del software. Cuando se informa al cliente que el producto debe ser reconstruido, este grita horrible y solicita que el producto se le aplique en cuantas mejoras se han necesarias para hacer del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo del software sede.
2. El técnico del desarrollo realiza frecuentemente ciertos compromisos de implementación en orden a obtener un prototipo que funcione rápidamente. Puede utilizarse un S.O. o lenguaje de programación inapropiado simplemente porque esta disponible y es conocido. Un algoritmo ineficiente puede implementarse de forma sencilla para demostrar su capacidad; después de pasar un tiempo en el que el técnico esta familiarizado con estas selecciones, olvida las razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.

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.

VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.

PROBLEMAS:
• Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable.
• Requiere gran habilidad y 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.

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero 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.

Obviamente la limitación de tiempo impuestas 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 pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.

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.

Para resumir las técnicas de cuarta generación se convertirán en una parte importante en el desarrollo del software durante la siguiente década. Como muestra la siguiente figura la demanda del software continuara creciendo durante el resto del siglo, pero los métodos y paradigmas convencionales contribuirán cada vez menos al desarrollo del mismo.

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.