En , de de la inmediatamente anterior.

En Ingeniería de software el desarrollo en cascada, también llamado modelo en
cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de
vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización
de la inmediatamente anterior.
Un ejemplo de una metodología de desarrollo en cascada es:
1.
2.
3.
4.
5.
6.
7.
Análisis de requisitos
Diseño del Sistema
Diseño del Programa
Codificación
Pruebas
Implantación
Mantenimiento
El desarrollo en espiral es un modelo de ciclo de vida del software definido por
primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de
software. Las actividades de este modelo se conforman en una espiral, en la que cada
bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas
a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando
por el bucle interior.
El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya
que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se
diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto
y por tanto se van desarrollando simultáneamente con las diferentes versiones del
código.
Pueden distinguirse las siguientes fases:




Especificación conceptual
Análisis de requerimientos
Diseño inicial
Diseño detallado, codificación, depuración y liberación
Estas diferentes fases se van repitiendo en cada etapa del diseño.
Este modelo estipula que el software será desarrollado en sucesivas etapas:
1. Plan operativo Etapa donde se define el problema a resolver, las metas del proyecto,
las metas de calidad y se identifica cualquier restricción aplicable al proyecto.
2. Especificación de requerimientos Permite entregar una visión de alto nivel sobre el
proyecto, poniendo énfasis en la descripción del problema desde el punto de vista de los
clientes y desarrolladores. También se considera la posibilidad de una planificación de
los recursos sobre una escala de tiempos.
3. Especificación funcional Especifica la información sobre la cual el software a
desarrollar trabajará.
4. Diseño Permite describir como el sistema va a satisfacer los requerimientos. Esta
etapa a menudo tiene diferentes niveles de detalle. Los niveles más altos de detalle
generalmente describen los componentes o módulos que formarán el software a ser
producido. Los niveles más bajos, describen, con mucho detalle, cada módulo que
contendrá el sistema.
5. Implementación Aquí es donde el software a ser desarrollado se codifica.
Dependiendo del tamaño del proyecto, la programación puede ser distribuida entre
distintos programadores o grupos de programadores. Cada uno se concentrará en la
construcción y prueba de una parte del software, a menudo un subsistema. Las pruebas,
en general, tiene por objetivo asegurar que todas las funciones están correctamente
implementadas dentro del sistema.
6. Integración Es la fase donde todos los subsistemas codificados independientemente
se juntan. Cada sección es enlazada con otra y, entonces, probada. Este proceso se repite
hasta que se han agregado todos los módulos y el sistema se prueba como un todo.
7. Validación y verificación Una vez que el sistema ha sido integrado, comienza esta
etapa. Es donde es probado para verificar que el sistema es consistente con la definición
de requerimientos y la especificación funcional. Por otro lado, la verificación consiste
en una serie de actividades que aseguran que el software implementa correctamente una
función específica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente
de explotación.
8. Mantención La mantención ocurre cuando existe algún problema dentro de un
sistema existente, e involucraría la corrección de errores que no fueron descubiertos en
las fases de prueba, mejoras en la implementación de las unidades del sistema y
cambios para que responda a los nuevos requerimientos. Las mantenciones se puede
clasificar en: correctiva, adaptativa, perfectiva y prev
EL MODELO DE DESARROLLO CONCURRENTE
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo
tiempo
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.
La figura siguiente proporciona una representación esquemática de una actividad dentro del
modelo de proceso concurrente. La actividad "análisis" se puede encontrar en uno de los
estados destacados anteriormente en cualquier momento dado. De forma similar otras
actividades se pueden representar de una forma análoga. 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.
El modelo de proceso concurrente define una serie de acontecimientos que dispararan
transiciones de estado a estado para cada una de las actividades de la ingeniería del software.
Por ejemplo, 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 disparara
la actividad de análisis del estado hecho al estado cambios en espera.
El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de
aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de
componente funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso
concurrente define actividades en dos dimensiones: una división de sistemas y una división de
componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño
y realización. La concurrencia se logra de dos formas (1) las actividades del sistema y de
componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos
descrito anteriormente; (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.
En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de
software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar
actividades de ingeniería de software a una secuencia de sucesos, define una red de
actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos
generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las
transiciones entre los estados de una actividad.
MODELO V:
EL modelo v es un modelo definido depues que el modelo cascada , lo cual
implica que posee caracteristicas que el modelo cascada carece, por ejemplo en
el modelo v se tiene la facilidad de que en el momento en el cual se esta
realizando un fase es posible realizar la documentacion para las pruebas que se
realizaran mas adelante; utilizando la analogia adoptada en clase al momento
de estudiar para un examen es mucho mas sensillo acerlo si antes es
proporcionado un cuestionario en el cual se traten temas similares a los que se
trataran en en examen.
A continuacion un diagrama del modelo v: