ACTIVIDAD 4 (obligatorias)

¿Cual de los paradigmas de la ingeniería de software sería más útil para las aplicaciones del software?¿Porque?

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.

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

Proporcione tres ejemplos de técnicas de 4ª generación.

1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, 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.
2. 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 e análisis y diseño.
3. 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.

Describa el modelo concurrente

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo
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.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando?

Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.
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.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.

Explique los pasos tradicionales de cualquier modelo

Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.
La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
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.