El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental caracteristicas:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
- Resulta más sencilo acomodar cambios al acotar el tamaño de los incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.
Desventajas:
-El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
- Requere de mucha planeacion, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.
Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del productoSoftware denomidados “incrementos” del sistema, que son escogidos en base a prioridades predefinidas de algún modo.El modelo permite una implementación con refinacmientos sucesivos (ampliación y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.
MODELO EN ESPIRAL
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software.Las actividades de este modelo son una espiral, cada bucle es una actividad. Para cada actividad habrá cuatro tareas:
No. 1
Planificación:
Determinación de objetivos, alternativas y restricciones.
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
No. 2
Análisis de riesgo:
Análisis de alternativas e identificación/resolución de riesgos.
No. 3
Ingeniería:
Desarrollo del producto del “siguiente nivel”
Tareas de la actividad propia y se prueba.
Análisis de alternativas e identificación resolución de riesgos.
No.4
Evaluación del cliente:
Valorización de los resultados de la ingeniería.
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, etc.
- Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
Desventajas:
- Genera mucho tiempo en el desarrollo del sistema.
- Modelo costoso.
- Requiere experiencia en la identificación de riesgos.
El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.
MODELO DE DESARROLLO CONCURRENTE
El Modelo de Desarrollo Concurrente conocido además como Ingeniería Concurrente dado por Davis Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.
Provee una meta-descripción del proceso del software. El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
Provee una meta-descripción del proceso del software. El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.
Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones:
1. Dimensión de sistemas.
2. Dimensión de componentes.
Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseño, ensamblaje y uso.
En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.
1. Dimensión de sistemas.
2. Dimensión de componentes.
Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseño, ensamblaje y uso.
En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.
La concurrencia se logra de dos formas:
1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos.
2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.
Ventajas
• Excelente para proyectos en los que se conforman grupos de trabajo independientes.
• Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
• Si no se dan las condiciones señaladas no es aplicable.
• Si no existen grupos de trabajo no se puede trabajar en este método
1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos.
2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.
Ventajas
• Excelente para proyectos en los que se conforman grupos de trabajo independientes.
• Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
• Si no se dan las condiciones señaladas no es aplicable.
• Si no existen grupos de trabajo no se puede trabajar en este método
No hay comentarios:
Publicar un comentario