Melania Ponluisa: noviembre 2015

domingo, 15 de noviembre de 2015

MODELO CASCADA

MODELO EVOLUTIVO

MODELO ESPIRAL EVOLUTIVO

MODELO INCREMENTAL

MODELO BASADO EN REUTILIZACION

viernes, 13 de noviembre de 2015

MODELO BASADO EN REUTILIZACIÓN

El desarrollo basado en reutilización

ETAPAS MODELO BASADO EN REUTILIZACIÓN

Definición de requerimientos
Análisis de componentes
Modificación de requerimientos
Diseño de sistemas con reutilización
Desarrollo e integración
Validación del sistema
El desarrollo basado en reutilización con otros procesos.

La primera y la última etapa del proceso son similares pero las etapas intermedias son distintas:

Análisis de componentes: se buscan componentes para implementar la especificación de requerimientos
Modificación de requerimientos: los requerimientos se modifican para reflejar los componentes disponibles; si eso no es posible, se buscan soluciones alternativas
Diseño de sistemas con reutilización: se diseña o se reutiliza un marco de trabajo para el sistema, tomando en cuenta los componentes disponibles; si no hay componentes adecuados, se diseñan otros nuevos
Desarrollo e integración: los componentes disponibles se compran, los componentes no-disponibles se desarrollan y todos los componentes y los sistemas se integran

VENTAJAS

El modelo orientado a reutilización reduce la cantidad de software a desarrollarse, los costos y los riesgos.
El proceso es más rápido.

DESVENTAJAS

Los compromisos en los requerimientos son inevitables, existiendo el peligro de obtener un sistema que no cumple las necesidades reales de los usuarios

Link: http://es.slideshare.net/rolmary/1-presentacion1ingenieriadesoftware1

MODELO INCREMENTAL

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

Método de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:

Análisis
Diseño
Código
Prueba

Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. 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 elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo 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.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.

De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Características:

Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
El usuario se involucra mas.
Dificil de evaluar el costo total.
Dificil 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 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.
Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

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.
Requiere de mucha planeación, tanto administrativa como técnica.
Requiere de metas claras para conocer el estado del proyecto.

Link:http://procesosoftware.wikispaces.com/Modelo+Incremental

MODELO ESPIRAL EVOLUTIVO

El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. 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 más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.
LINK:http://modeloespiral.blogspot.com/

MODELO EVOLUTIVO

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:

1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.

2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.

LINK;http://tema3isoftware.blogspot.com/p/modelos-de-desarrollo-tecnicas-y.html

Modelo de Cascada

En los años 70 se impuso un nuevo enfoque de desarrollo del software, introducido por Royce en 1970, a través de un ciclo de vida en “cascada” (así denominado por la disposición de las distintas fases de desarrollo, en las que los resultados de una fase parecen caer en cascada hacia la siguiente fase, tal como se muestra en la Figura 1). El método ideado por Royce constituye uno de los primeros modelos de ciclo de vida publicados, por lo que también recibe el nombre de modelo de ciclo de vida clásico. Este método modela el ciclo convencional de la Ingeniería del Software, aplicando un enfoque sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.

Figura 1 Ciclo de vida en cascada o clásico

Como sugiere el esquema del modelo en cascada, antes de poder avanzar a la siguiente etapa, es necesario haber finalizado completamente la etapa anterior. Asociada con cada etapa del proceso existen hitos y documentos, de tal forma que se puede utilizar el modelo para comprobar los avances del proyecto y para estimar cuánto falta para su finalización.

Este modelo es muy útil pues ayuda a los desarrolladores a comprender qué es lo que tienen que hacer en cada momento. Su simplicidad hace que resulte sencillo explicárselo a los clientes que no están familiarizados el proceso software. Además, se muestran de forma explícita qué productos intermedios se tienen que obtener antes de abordar las siguientes tareas.

Una modificación sobre este modelo consiste en la introducción de una revisión y vuelta atrás, con el fin de corregir las deficiencias detectadas durante las distintas etapas, o para completar o aumentar las funcionalidades del sistema en desarrollo, resultando un diagrama de fases y etapas tal como el que se muestra en la Figura 2. De esta manera, durante cualquiera de las fases se puede retroceder momentáneamente a una fase previa para solucionar los problemas que se pudieran haber encontrado.

Figura 2 Ciclo de vida en cascada o clásico completo

Normalmente, el ciclo de vida del software se suele dividir en tres fases: una de Planificación, otra de Desarrollo y una tercera de Mantenimiento, que engloban a las seis etapas (Ingeniería del Sistema, Análisis de los Requisitos, Diseño, Codificación, Pruebas y Mantenimiento) tradicionales del ciclo de vida.
La fase de Planificación del software comprende las etapas de Ingeniería del Sistema o Análisis del Sistema (en concreto el establecimiento de los Requisitos del Software o “Plan Software”) y el Análisis de los Requisitos del Software (que se traduce en una “Especificación de Requisitos”). La fase de Desarrollo comprende las etapas de Diseño, Codificación y Pruebas. Por último, la fase de Mantenimiento incorpora solamente la etapa propia de Mantenimiento.
A pesar de su antigüedad, el ciclo de vida clásico se ha hecho con un lugar importante en el área de la Ingeniería del Software. Proporciona una guía de trabajo en la que se encuentran métodos para el análisis, diseño, codificación, pruebas y mantenimiento. El ciclo de vida en cascada sigue siendo el modelo de proceso más extensamente utilizado por los ingenieros del software, principalmente por su sencillez y facilidad de llevar a cabo. Pese a tener debilidades, es significativamente mejor que un enfoque arbitrario (como el de codificar y corregir) para el desarrollo del software. Muchos de los posteriores modelos de ciclo de vida son, en realidad, modificaciones sobre el modelo clásico, al que se le incorporan iteraciones o nuevas actividades.

Ventajas:

• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:
• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

LINK:http://spanishpmo.com/index.php/ciclos-de-vida-modelo-de-cascada/