PARADIGMA CICLO DE VIDA DEL SOFTWARE
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
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa.
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,
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
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
PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS
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?
PARADIGMA DEL MODELO ESPIRAL
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.
EL MODELO DRA
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
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
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 existenteso a crear componentes reutilizables
Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas
PARADIGMA DE TÉCNICAS DE CUARTA GENERACION
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.
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.
EL MODELO DE DESARROLLO CONCURRENTE
Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto, la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.
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.
- 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
No hay comentarios:
Publicar un comentario