Está en la página 1de 8

UNIVERSIDAD TECNICA DE BABAHOYO

F.A.F.I

TRABAJO DE INVESTIGACION

MODELOS DE DESARROLLO DE SOFTWARE

NOMBRE:
CHRISTIAN JAVIER MOSQUERA

PROFESOR:
ING. RAUL RAMOS

CURSO:
IV SEMESTRE

SECCION:
MATUTINO

PERIODO LECTIVO
ABRIL/ AGOSTO 2015
MODELOS DE DESARROLLO DE SOFTWARE (CICLO DE VIDA)

La ingeniería del software establece y se vale de una serie de modelos que establecen y
muestran las distintas etapas y estados por los que pasa un producto software, desde su
concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento,
hasta la retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del
software”. El primer modelo concebido fue el de Royce, más comúnmente conocido como
Cascada o “Lineal Secuencial”. Este modelo establece que las diversas actividades que se van
realizando al desarrollar un producto software, se suceden de forma lineal.
Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en
que se ejecutan las fases.
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el
desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de
transición asociados entre estas etapas.

Un modelo de ciclo de vida del software:


 Describe las fases principales de desarrollo de software
 Define las fases primarias esperadas de ser ejecutadas durante esas fases
 Ayuda a administrar el progreso del desarrollo
 Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo
de software
En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de
objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y
la elección de un modelo para un determinado tipo de proyecto es realmente importante; el
orden es uno de estos puntos importantes.
Existen varias alternativas de modelos de ciclo de vida. A continuación se muestran algunos de
los modelos tradicionales y más utilizados.

Modelo en cascada
Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del
software, de forma que el inicio de cada etapa debe esperar a la finalización de la
inmediatamente anterior.
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve
fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.

Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido
ampliamente en la ingeniería el software. La innovación estuvo en la primera vez que la
ingeniería del software fue dividida en fases separadas.
La primera descripción formal del modelo en cascada se cree que fue en un artículo publicado
en 1970 por Winston W. Royce, aunque Royce no usó el término cascada en este artículo.
Irónicamente, Royce estaba presentando este modelo como un ejemplo de modelo que no
funcionaba, defectuoso.
En el modelo original de Royce, existían las siguientes fases:
 Especificación de requisitos
 Diseño
 Construcción (Implementación o codificación)
 Integración
 Pruebas
 Instalación
 Mantenimiento

Modelo en V
El modelo en v se desarrolló para terminar con algunos de los problemas que se vieron
utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados
demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del
proyecto. El modelo en v dice que las pruebas necesitan empezarse lo más pronto posible en el
ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la
ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de
codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las actividades de
desarrollo, y los técnicos de pruebas necesitan trabajar con los desarrolladores y analistas de
negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de
entregables de pruebas. Los productos de trabajo generados por los desarrolladores y analistas
de negocio durante el desarrollo son las bases de las pruebas en uno o más niveles. El modelo
en v es un modelo que ilustra cómo las actividades de prueba (verificación y validación) se
pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v, las pruebas de
validación tienen lugar especialmente durante las etapas tempranas, por ejemplo, revisando
los requisitos de usuario y después por ejemplo, durante las pruebas de aceptación de usuario.
El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de
vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el
desarrollo del producto. La parte izquierda de la v representa la descomposición de los
requisitos y la creación de las especificaciones del sistema. El lado derecho de la v representa la
integración de partes y su verificación. V significa “Validación y Verificación”.
Modelo iterativo

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que
surge entre las necesidades del usuario y el producto final por malos entendidos durante la
etapa de recogida de requisitos.
Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le
entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente
es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas
iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente.

Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de
construcción de prototipos. Se basa en la filosofía de construir incrementando las
funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del
software.

Modelo en espiral

El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un modelo de


proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de
prototipos con los aspectos controlados y sistemáticos del modelo en cascada, es decir, cuando
se aplica este modelo, el software se desarrolla en una serie de entregas evolutivas (ciclos o
iteraciones), cada una de estas entregando prototipos más completas que el anterior, todo esto
en función del análisis de riesgo y las necesidades del cliente. Aunque el modelo espiral
representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy
complicado y por lo cual su uso en el ámbito real es muy escaso

Modelo de prototipos

En ingeniería de software, el modelo de prototipos pertenece a los modelos de desarrollo


evolutivo. Este permite que todo el sistema, o algunos de sus partes, se construyan
rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren
que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como
también la solución que se propone para dicha necesidad y de esta manera minimizar el riesgo
y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que
estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones,
es ideal para medir el alcance del producto, pero no se asegura su uso real.

Este modelo principalmente se aplica cuando un cliente define un conjunto de objetivos


generales para el software a desarrollarse sin delimitar detalladamente los requisitos de
entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de
un algoritmo, de la adaptabilidad del sistema o de la manera en que interactúa el hombre y la
máquina.

Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a


entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén
satisfechos.
Modelo estructurado

Este modelo ―como su nombre lo indica― utiliza las técnicas del diseño estructurado o de la
programación estructurada para su desarrollo, también se utiliza en la creación de los
algoritmos del programa. Este formato facilita la comprensión de la estructura de datos y su
control. Entre las principales características de este modelo se encuentran las siguientes:

 Generalmente se puede diferenciar de una manera más clara los procesos y las
estructuras de datos.

 Existen métodos que se enfocan principalmente en ciertos datos.

 La abstracción del programa es de un nivel mucho mayor.

 Los procesos y estructuras de datos son representados jerárquicamente.

Este modelo también presenta sus desventajas entre las cuales podemos mencionar algunas:

 Se podía encontrar datos repetidos en diferentes partes del programa.

 Cuando el código se hace muy extenso o grande su manejo se complica demasiado.

 En el modelo estructurado las técnicas que comúnmente se utilizan son:

 El modelo entidad-relación, esta técnica se relaciona principalmente con los datos.

 El diagrama de flujo de datos, esta es utilizada principalmente para los procesos.

Modelo orientado a objetos

Estos modelos tienen sus raíces en la programación orientada a objetos y como consecuencia
de ella gira en torno al concepto de clase, también lo hacen el análisis de requisitos y el diseño.
Esto además de introducir nuevas técnicas, también aprovecha las técnicas y conceptos del
desarrollo estructurado, como diagramas de estado y transiciones. El modelo orientado a
objetos tiene dos características principales, las cuales ha favorecido su expansión:

 Permite la reutilización de software en un grado significativo.

 Su simplicidad facilita el desarrollo de herramientas informáticas de ayuda al


desarrollo, el cual es fácilmente implementada en una notación orientada a objetos
llamado UML

Modelo RAD (rapid application development)

El RAD (rapid application development: ‘desarrollo rápido de aplicaciones’), es un modelo de


proceso de software incremental, desarrollado inicialmente por James Maslow en 1980, que
resalta principalmente un ciclo corto de desarrollo.

Esta es una metodología que posibilita la construcción de sistemas computacionales que


combinen técnicas y utilidades CASE (Computer Aided Software Engineering), la construcción
de prototipos centrados en el usuario y el seguimiento lineal y sistemático de objetivos,
incrementando la rapidez con la que se producen los sistemas mediante la utilización de un
enfoque de desarrollo basado en componentes.

Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite
que un equipo de desarrollo cree un producto completamente funcional dentro de un periodo
muy limitado de tiempo sin reducir en lo más mínimo la calidad del mismo.

Modelo de desarrollo concurrente

El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las personas
actúan simultáneamente o al mismo tiempo. Este tipo de modelo se puede representar a
manera de esquema como una serie de actividades técnicas importantes, tareas y estados
asociados a ellas.

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. Este modelo de
desarrollo se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor. 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: 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 maneras:

 Las actividades del sistema y de componente ocurren simultáneamente y pueden


modelarse con el enfoque orientado a objetos descrito anteriormente;

 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.

Bibliografía
(s.f.). Recuperado el 22 de 04 de 2015, de http://es.wikipedia.org/wiki/Ingenier
%C3%ADa_de_software#Modelos_y_Ciclos_de_Vida_del_Desarrollo_de_Software

Rubby Casalla, A. Y. (s.f.). INGENIERIA DE SOFTWARE. Recuperado el 22 de 04 de 2015, de Ciclos


de vida y Metodologia:
https://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?
media=principal:isis2603-modelosciclosdevida.pdf

También podría gustarte