Julio Cesar Equilea Delgadillo 210002727Paradigmas del desarrollo de Software

1.- Ciclo de vida Clásica (Cascada):

El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de modelos de actividades de ingeniería con el fin de establecer algo de orden en el desarrollo de grandes productos de software. Consiste en diferentes etapas, las cuales son procesadas en una manera lineal. Comparado con otros modelos de desarrollo de software es más rígido y mejor administrable. El modelo cascada es un modelo muy importante y ha sido la base de muchos otros modelos, sin embargo, para muchos proyectos modernos, ha quedado un poco desactualizado.

  Descripción del modelo:

El modelo cascada es un modelo de ingeniería diseñado para ser aplicado en el desarrollo de software. La idea principal es la siguiente: existen diferentes etapas de desarrollo, la salida de la primera etapa “fluye” hacia la segunda etapa y esta salida “fluye” hacia la tercera y así sucesivamente. Existen generalmente cinco etapas en este modelo de desarrollo de software:

Análisis y definición de requerimientos: en esta etapa, se establecen los requerimientos del producto que se desea desarrollar. Éstos consisten usualmente en los servicios que debe proveer, limitaciones y metas del software. Una vez que se ha establecido esto, los requerimientos deben ser definidos en una manera apropiada para ser útiles en la siguiente etapa.

Diseño del sistema: el diseño del software es un proceso multipaso que se centra en cuatro atributos diferentes de los programas: estructura de datos, arquitectura del software, detalle del proceso y caracterización de las interfaces. Al igual que los requerimientos, el diseño es documentado y se convierte en parte del producto de software.

Implementación: esta es la etapa en la cual son creados los programas. Si el diseño posee un nivel de detalle alto, la etapa de codificación puede implementarse mecánicamente. A menudo suele incluirse un testeo unitario en esta etapa, es decir, las unidades de código producidas son evaluadas individualmente antes de pasar a la etapa de integración y testeo global.

Testeo del sistema: una vez concluida la codificación, comienza el testeo del programa. El proceso de testeo se centra en dos puntos principales: las lógicas internas del software; y las funcionalidades externas, es decir, se solucionan errores de “comportamiento” del software y se asegura que las entradas definidas producen resultados reales que coinciden con los requerimientos especificados.

Mantenimiento: esta etapa consiste en la corrección de errores que no fueron previamente detectados, mejoras funcionales y de performance, y otros tipos de soporte. La etapa de mantenimiento es parte del ciclo de vida del producto de software y no pertenece estrictamente al desarrollo. Sin embargo, mejoras y correcciones pueden ser consideradas como parte del desarrollo.

Julio Cesar Equilea Delgadillo 210002727Existen actividades que son llevadas a cabo en cada una de las etapas del desarrollo del software. Éstas son documentación, verificación y administración. La documentación es intrínseca al modelo cascada puesto que la mayoría de las salidas que arrojan las etapas son documentos.

Desventajas:El ciclo de vida clásico es el paradigma más viejo y el más ampliamente usado en la ingeniería del software. Sin embargo, su aplicabilidad en muchos campos ha sido cuestionada. Entre los problemas que aparecen cuando se aplica el modelo cascada están:

Los proyectos raramente siguen el flujo secuencial que el modelo propone. La iteración siempre es necesaria y está presente, creando problemas en la aplicación del modelo.

A menudo es difícil para el cliente poder especificar todos los requerimientos explícitamente. El modelo de vida del software clásico requiere esto y presenta problemas acomodando la incertidumbre natural que existe al principio de cualquier proyecto.

El cliente debe ser paciente. Una versión funcional del sistema no estará disponible hasta tarde en la duración del desarrollo. Cualquier error o malentendido, si no es detectado hasta que el programa funcionando es revisado, puede ser desastroso.

Ventajas:

Cada uno de estos problemas es real. Sin embargo, el modelo clásico del ciclo de vida del software tiene un lugar bien definido e importante en los trabajos de ingeniería del software. Provee un patrón dentro del cual encajan métodos para el análisis, diseño, codificación y mantenimiento.

Excelente cuando se tiene un producto estable y se conoce la tecnología. Es un método muy estructurado que funciona bien con gente de poca experiencia. Provee estabilidad en los requerimientos. La planeación se puede hacer anticipadamente. Para proyectos grandes.

Aplicación:El modelo cascada se aplica bien en situaciones en las que el software es simple y en las que el dominio de requerimientos es bien conocido, la tecnología usada en el desarrollo es accesible y los recursos están disponibles.

Codificación

Diseño

Análisis

Pruebas

Mantenimiento

Ing. Requerimientos

Julio Cesar Equilea Delgadillo 2100027272.- Técnicas de cuarta Generación:

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, más tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Características:

El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas de ingeniería de software asistida por computador (CASE) y los generadores de código, T4G ofrece una solución fiable a muchos problemas del software. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio. Sin embargo, el uso de T4G para grandes trabajos de desarrollo exige el mismo o más tiempo de análisis, diseño y prueba, para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación. T4G inicia con el proceso de recolección de requerimientos. La estrategia del diseño garantiza productos de alta calidad y buena aceptación por el cliente. La implementación usando L4G facilita el desarrollo de software, los cuales se traducen automáticamente en código fuente para producir los requerimientos funcionales del cliente. La transformación de la implementación se traduce en el producto el cual va dirigido en pruebas integrales del sistema debidamente documentadas. El software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expeditiva.

Los tipos más comunes de generadores de código cubren uno o varios de los siguientes aspectos:

1.-Acceso a base de datos2.-Generación de pantallas 3.-Gestión de entornos gráficos4.-Generación de informes

Ventajas y Desventajas:

Entre las ventajas de los modelos de cuarta generación se encuentran:

Facilidad de desarrollo – Abstracción extremadamente alta – notación grafica - rápido desarrollo - Eliminación de la codificación

- Dentro de las desventajas están:

El hecho que no se recomienda para aplicaciones grandes –Requiere una estrategia para el diseño –No elimina la necesidad de identificar claramente los requerimientos –la especificación de los requerimientos puede ser ambigua –el software producido se convierte en software genérico.

Julio Cesar Equilea Delgadillo 210002727Aplicación:

Con muy pocas excepciones el dominio de aplicación actual de las T4G está limitado a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comercial, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.

3.- Prototipo:

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.

Recolección de requerimientos Estrategia

de diseño Implementación usando T4G Producto

Mantenimiento

Julio Cesar Equilea Delgadillo 210002727El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Etapas:

• Plan rápido • Modelado, diseño rápido • Construcción del Prototipo • Desarrollo, entrega y retroalimentación • ComunicaciónVentajas

• Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

• También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Desventajas:

• El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

• En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Modelado de

GestiónModelado

deDatos

Modelado de

Procesos

Generación de Aplicaciones

Pruebas yVolumen

Modelado de

GestiónModelado

deDatos

Modelado de

Procesos

Generación deAplicaciones

Pruebas y Volumen

Modelado deGestión

Modelado deDatos

Generación deAplicaciones

Modelado deProcesos

Modelado deGestión

Equipo # 1 Equipo # 2 Equipo # 3

De 60 a 90 días

Julio Cesar Equilea Delgadillo 2100027274.- Desarrollo de aplicaciones rápidas (RAD):

RAD Es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.1 2

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi,Foxpro , Anjuta, Game Maker, Velneo o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites.

Desventajas:

Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el número suficiente de equipos.

Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario.

No es adecuado cuando los riesgos técnicos son muy alto.

Julio Cesar Equilea Delgadillo 210002727Ventajas

Comprar puede ahorrar dinero en comparación con construir.

Los entregables pueden ser fácilmente trasladados a otra plataforma.

El desarrollo se realiza a un nivel de abstracción mayor.

Visibilidad temprana. Ingeniería de Software

Mayor flexibilidad.

Menor codificación manual.

Mayor involucramiento de los usuarios.

Posiblemente menos fallas.

Posiblemente menor costo.

Ciclos de desarrollo más pequeños.

Interfaz gráfica estándar.

5.- Proceso Unificado de Desarrollo de Software:

Definición y Caracteristicas:

En primer lugar, el Proceso Unificado es un proceso de desarrollo de software. Sabemos que un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Sin embargo, el Proceso Unificado es más que un simple proceso; es un marco de trabajo genérico que puede especializarse para gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto.El proceso unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes de software interconectados a través de interfaces bien definidas.El Proceso Unificado utiliza el Lenguaje Unificado de Modelado, para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial del Proceso Unificado.

El Proceso Unificado está dirigido por casos de usoUn caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad del sistema.Los casos de uso no son sólo una herramienta para especificar los requisitos de un sistema. También guían su diseño, implementación, y prueba; esto es, guían el proceso de desarrollo.

Julio Cesar Equilea Delgadillo 210002727Basándose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. Los desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso. Los ingenieros de prueba prueban la implementación para garantizar que los componentes del modelo de implementación implementan correctamente los casos de uso. De este modo, los casos de uso no sólo inician el proceso de desarrollo sino que le proporcionan un hilo conductor.Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo – avanza a través de una seria de flujos de trabajo que partes de los casos de uso. Los casos de uso se especifican, se diseñan, y los casos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba.

El Proceso Unificado está centrado en la arquitectura

El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores, y se refleja los casos de uso. Sin embargo, también se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de gestión de bases de datos, protocolos para comunicaciones en red), los bloques de construcción reutilizables de que se dispones (por ejemplo, un marco de trabajo para interfaces gráficas de usuario), consideraciones de implantación, sistemas heredados, y requisitos no funcionales (por ejemplo, rendimiento, fiabilidad). La arquitectura es una vista del diseño completo con las características más importantes resaltadas dejando los detalles de lado.El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema.

El Proceso Unificado es iterativo e incremental

El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un año o más. Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento, las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto.Al ser mini proyectos, comienzan con los casos de uso y continúan a través del trabajo de desarrollo subsiguiente – análisis, diseño, implementación y prueba -, que termina convirtiendo en código ejecutable los casos de uso que se desarrollan en la iteración. En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si una iteración cumple con sus objetivos – como suele suceder - el desarrollo continúa con la siguiente iteración. Cuando una iteración no cumple sus objetivos, los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque.

Julio Cesar Equilea Delgadillo 210002727

Ventajas:Entre las ventajas podemos anotar las siguientes:

Mediante este proceso de desarrollo de software hay varias oportunidades para revisar el sistema a desarrollar hasta quesea correcto. Se pueden encontrar errores y corregirlos.

Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios. Se define una arquitectura sólida en etapas tempranas del desarrollo. La arquitectura de

un sistema se define como un conjunto de componentes y las interacciones entre ellas. De este modo este tipo de ciclo de vida debe ser ampliable, por lo que el sistema es robusto y tiene facilidad de mantenimiento.

Se reducen los riesgos de no obtener el producto deseado. En cada momento hay una versión del sistema funcionando que se modifica según las

necesidades y deseos del cliente. Progreso visible en las primeras etapas. Reducir la redundancia e incrementa la productividad, un software bien diseñado evita la

duplicidad del código con lo cual se obtiene un software robusto. Fácil ejecución del proceso de elaboración del sistema software, ya que describen como

está estructurado el sistema desde diferentes perspectivas orientadas a los diferentes involucrados en un proyecto.

El proceso es comprensible. La metodología de PU es más adaptable para proyectos de largo plazo.

Desventajas:Entre las desventajas tenemos:

El método de PU requiere costos de dedicación altos por lo que no es conveniente usarlo en procesos de un proyecto pequeño.

Si el proceso no se aplica bien desde el inicio el PU se puede volver muy grande y difícil, tanto para aprender como para administrar.

Una cantidad sustancial de tiempo se gasta en tratar de adecuar el PU a cada proyecto. Aquí, también, se corre el riesgo de volverse un esclavo del proceso y perder de vista la razón del proceso.

Es un proceso pesado. Se basa mucho en la documentación.

Diseño Grafico

Julio Cesar Equilea Delgadillo 210002727

Aplicaciones:El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.No es recomendable para proyectos muy pequeños

6.- Win Win:

Definición y Características:Es una variante del Modelo Espiral. El modelo espiral sugiere una actividad del marco de trabajo que aborda la comunicación con el cliente. El objetivo de esta actividad es mostrar los requisitos de cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar. Desgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o características del sistema frente al coste y al tiempo de comercialización.Las mejores negociaciones se esfuerzan en obtener “victoria-victoria”. Esto es, el cliente gana obteniendo el producto o sisma que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.El modelo en espiral WINWIN de Boehm define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente, se definen las siguientes actividades:

1. Identificación del sistema o subsistemas clave de los directivos.2. Determinación de la condiciones de victoria de los directivos.

Julio Cesar Equilea Delgadillo 2100027273. Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto

de condiciones victoria-victoria para todos los afectados (incluyendo el equipo de proyecto de software).

Conseguidos completamente estos pasos iniciales se logra un resultado victoria-victoria, que será el criterio clave para continuar con la definición del sistema y del software.Además del énfasis realizado en la negociación inicial, el modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación, que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.En esencia, los puntos de fijación representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral. El primer punto de fijación llamado objetivos del ciclo de vida (OCV), defina un conjunto de objetivos para cada actividad principal de ingeniería del software. Como ejemplo, de un parte de OCV, un conjunto de objetivos asociados a la definición de los requisitos del producto/sistema del nivel más alto. El segundo punto de fijación llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software debe demostrar que ha evaluado la funcionalidad de los componentes del software reutilizables y que ha considerado su impacto en las decisiones de arquitectura. La capacidad operativa inicial (COI) es el tercer punto de fijación y representa un conjunto de objetivos asociados a la preparación del software para la instalación/distribución, preparación del lugar previamente a la instalación, y la asistencia precisada de todas las partes que utilizará o mantendrá el software.

Ventajas:

El cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.

Reduce riesgos del proyecto. Constituye un enfoque realista del desarrollo de sistemas de software. Se evalúan en una etapa independiente la resolución de riesgos.

Desventajas:

Requiere una gran habilidad de negociación. Incorpora sólo los objetivos de más importantes y necesarios del proyecto. No es un modelo ampliamente usado.

Julio Cesar Equilea Delgadillo 210002727Diseño gráfico:

AplicacionesPuede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos. Pero se requiere que se tenga cierta experiencia en el desarrollo de proyectos.

7.- Recursivo Paralelo:

Realizar los análisis suficientes para aislar las clases del problema y las conexiones más importantes Realizar un pequeño diseño para determinar si las clases y conexiones pueden ser implementadas de manera practica Extraer objetos reutilizables de una biblioteca para construir un prototipo previo Conducir algunas pruebas para descubrir errores en el prototipoObtener realimentación del cliente sobre el prototipo Modificar el modelo de análisis basándose en lo que se ha aprendido del prototipo, de la realización del diseño y de la realimentación obtenida del cliente Refinar el diseño para acomodar sus cambios Construir objetos especiales (no disponibles en la biblioteca)Realizar pruebas para descubrir errores en el prototipo Este enfoque continua hasta que el prototipo evoluciona hacia una aplicación en producción. El progreso se produce iterativamente.

Lo que hace diferente al modelo recursivo/paralelo es el reconocimiento de que:

1.-El modelo de análisis y diseño para sistemas orientado a objetos no puede realizarse a un nivel uniforme de abstracción.

Julio Cesar Equilea Delgadillo 2100027272.-El análisis y diseño pueden aplicarse a componentes independientes del sistema de manera concurrente.

8.- Incremental:

Concepto.

El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Aplica secuencias líneas de manera escalonada conforme avanza el tiempo, Cada secuencia lineal produce “incrementos” del software.

La descripción del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificación, Desarrollo y Validación) sintetizan el desarrollo pormenorizado de los incrementos, que se hará posteriormente.

Bajo este modelo se entrega software “por partes funcionales más pequeñas”, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.

Evaluación del cliente

ProbarAnálisis Extraer clases reutilizables

PrototipoDiseñoPlanificación

…

Revisión y refinamiento

Revisión y refinamiento

Evaluación del cliente

ProbarAnálisis Extraer clases reutilizables

PrototipoDiseñoPlanificación

Evaluación del cliente

ProbarAnálisis Extraer clases reutilizables

PrototipoDiseñoPlanificación

…

Revisión y refinamiento

DiseñoAnálisisPlanificación

Análisis Diseño Análisis Diseño

Revisión y refinamiento

Primer Prototipo

Siguiente incremento

N-ésimo incremento

Julio Cesar Equilea Delgadillo 210002727El modelo permite una implementación con refinamientos 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.

Ventajas.

Se enfoca en la entrega de un producto operacional con cada incremento. los primeros incrementos proporcionan al usuario la funcionalidad que necesita y una plataforma

para evaluarlo. Es útil sobre todo cuando el personal necesario para una implementación completa no está

disponible.

Desventajas.

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.

9.- Secuencial: 11.- Modelo en V o de cuatro niveles:

También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen en el “Modelo de cascada" ingeniado por Winston Royce, aunque omite los muchos bucles de este último. El Modelo Lineal Secuencial sugiere un enfoque sistemático o más bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. El Modelo Lineal Secuencial acompaña las siguientes actividades:

Análisis de los requerimientos del software:

Es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos.

Diseño:

Julio Cesar Equilea Delgadillo 210002727Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta haciéndose parte del software.

Generación del código:Es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina. Esta etapa va a depender estrechamente de lo detallado del diseño.

Pruebas:Esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en la detección de errores.

Mantenimiento:Debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios. El Modelo Lineal Secuencial es el paradigma de desarrollo de software más antiguo que existe, sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de él basada en los siguientes errores reales:

Los proyectos raramente siguen el paradigma secuencial que propone el proyecto. A menudo es difícil que el cliente exponga exactamente todos los requisitos. El cliente debe tener paciencia. Los responsables del desarrollo de software siempre se retrasan innecesariamente. Todo lo anteriormente expuesto es cierto pero este paradigma tiene un lugar bien definido e importante en el trabajo de la Ingeniería de Software aparte de proporcionar una plantilla en la que se

Julio Cesar Equilea Delgadillo 210002727encuentran métodos para análisis, diseño, codificación, pruebas y mantenimiento. Con todo y sus errores, sigue siendo el paradigma más utilizado en el desarrollo del software, siendo mucho mejor que un enfoque al azar.

Características del modelo:

Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico y modelo lineal secuencial. Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre al modelo. Cada fase genera documentación para la siguiente. Esta documentación debe ser aprobada. Una fase no comienza hasta que la anterior ha terminado. Requiere disponer de unos requisitos completos y precisos al principio del desarrollo. Se disponga de unos requisitos completos y consistentes al principio del desarrollo. Sea un proyecto pequeño, en el que el período de congelación de los requisitos es corto, o un proyecto con unos requisitos bastante estables. Ventajas:

Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno.

Facilita la gestión del desarrollo. Desventajas

Desventajas:En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable, Los usuarios no pueden imaginarse lo que quieren hasta que no ven un sistema funcionando.

Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo cambia.

El usuario debe esperar mucho tiempo hasta ver los resultados Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases

siguientes con un efecto conocido como bola de nieve. Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y

éste recae, en su mayor parte