Julio Cesar Equilea Delgadillo 210002727 Paradigmas 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.

Cualquier error o malentendido. Éstas son documentación. Provee estabilidad en los requerimientos. El modelo de vida del software clásico requiere esto y presenta problemas acomodando la incertidumbre natural que existe al principio de cualquier proyecto. Sin embargo. La planeación se puede hacer anticipadamente. Ventajas: Cada uno de estos problemas es real. su aplicabilidad en muchos campos ha sido cuestionada. El cliente debe ser paciente. creando problemas en la aplicación del modelo. Una versión funcional del sistema no estará disponible hasta tarde en la duración del desarrollo. 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. Provee un patrón dentro del cual encajan métodos para el análisis.Julio Cesar Equilea Delgadillo 210002727 Existen actividades que son llevadas a cabo en cada una de las etapas del desarrollo del software. diseño. 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. La iteración siempre es necesaria y está presente. puede ser desastroso. Sin embargo.      Excelente cuando se tiene un producto estable y se conoce la tecnología. codificación y mantenimiento. si no es detectado hasta que el programa funcionando es revisado. verificación y administración. 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. Requerimientos Análisis Diseño Codificación Pruebas Mantenimiento . Ing. la tecnología usada en el desarrollo es accesible y los recursos están disponibles. Entre los problemas que aparecen cuando se aplica el modelo cascada están:    Los proyectos raramente siguen el flujo secuencial que el modelo propone. A menudo es difícil para el cliente poder especificar todos los requerimientos explícitamente. Es un método muy estructurado que funciona bien con gente de poca experiencia. Para proyectos grandes.

diseño y prueba. debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expeditiva. facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel. La estrategia del diseño garantiza productos de alta calidad y buena aceptación por el cliente. el uso de T4G para grandes trabajos de desarrollo exige el mismo o más tiempo de análisis. para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación. La implementación usando L4G facilita el desarrollo de software. Junto con las herramientas de ingeniería de software asistida por computador (CASE) y los generadores de código.-Acceso a base de datos 2.. Características: El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación. más tarde. los cuales se traducen automáticamente en código fuente para producir los requerimientos funcionales del cliente. El software desarrollado con T4g.-Gestión de entornos gráficos 4.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.Julio Cesar Equilea Delgadillo 210002727 2. La transformación de la implementación se traduce en el producto el cual va dirigido en pruebas integrales del sistema debidamente documentadas. 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.-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 .-Generación de pantallas 3. T4G inicia con el proceso de recolección de requerimientos.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. Los tipos más comunes de generadores de código cubren uno o varios de los siguientes aspectos: 1. la herramienta genera automáticamente el código fuente a partir de esta especificación. Sin embargo. . T4G ofrece una solución fiable a muchos problemas del software.

específicamente del análisis de información comercial. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas. en Ingeniería de software. usando los programas adecuados y no se debe utilizar muchos recursos. . específicamente del análisis de información y de la obtención de informes en las grandes bases de datos.Prototipo: El Modelo de prototipos. pertenece a los modelos de desarrollo evolutivo. Recolección de requerimientos Estrategia de diseño Implementación usando T4G Producto Mantenimiento 3..Julio Cesar Equilea Delgadillo 210002727 Aplicació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. El prototipo debe ser construido en poco tiempo.

gracias a ésta se refinan los requisitos del software que se desarrollará. lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Desventajas: • El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. se suelen desatender aspectos importantes. pero no identifica los requisitos detallados de entrada. el cual es evaluado por el cliente para una retroalimentación. Sin importar la forma en que éste se aplique. . • También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo.Julio Cesar Equilea Delgadillo 210002727 El 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. Etapas: • Plan rápido • Modelado. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. tales como la calidad y el mantenimiento a largo plazo. De esta manera. entrega y retroalimentación • Comunicación Ventajas • Este modelo es útil cuando el cliente conoce los objetivos generales para el software. con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final. se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). • En aras de desarrollar rápidamente el prototipo. el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones. procesamiento o salida. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo. Este diseño conduce a la construcción de un prototipo. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final. este ciclo de vida en particular. lo que lo convertiría en un prototipo evolutivo. Con el paso del tiempo. pero partiendo de un estado poco recomendado. A causa de la intención de crear un prototipo de forma rápida. de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. diseño rápido • Construcción del Prototipo • Desarrollo. involucra al cliente más profundamente para adquirir el producto. 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. La construcción de prototipos se puede utilizar como un modelo del proceso independiente.

dentro de ciertos límites.. Delphi. la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario. El método comprende el desarrollo interactivo.Julio Cesar Equilea Delgadillo 210002727 4. .Desarrollo de aplicaciones rápidas (RAD): RAD Es un proceso de desarrollo de software. Anjuta. desarrollado inicialmente por James Martin en 1980. Gambas. Game Maker. el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad.Foxpro . En el área de la autoría multimedia. Lazarus. software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones. Tradicionalmente. Equipo # 1 Modelado de Gestión Modelado de Equipo # 2 Modelado de Modelado de Equipo # 3 Modelado de Gestión Modelado de Datos Modelado de Datos Modelado de Procesos Generación de Aplicaciones Pruebas y Volumen Modelado de Generación de Procesos Generación de Aplicaciones Modelado de Gestión Aplicaciones Pruebas y Volumen De 60 a 90 días Desventajas:    Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el número suficiente de equipos. 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. Algunas de las plataformas más conocidas son Visual Studio. No es adecuado cuando los riesgos técnicos son muy alto. Velneo o Clarion. o entornos de desarrollo integrado completos.

UML es una parte esencial del Proceso Unificado.  Posiblemente menor costo. De hecho. 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. El proceso unificado está basado en componentes. el Proceso Unificado es un proceso de desarrollo de software.Proceso Unificado de Desarrollo de Software: Definición y Caracteristicas: En primer lugar. para preparar todos los esquemas de un sistema software.Julio Cesar Equilea Delgadillo 210002727 Ventajas  Comprar puede ahorrar dinero en comparación con construir.  Visibilidad temprana. Sin embargo. para diferentes áreas de aplicación.  Posiblemente menos fallas. diferentes niveles de aptitud y diferentes tamaños de proyecto. esto es. el Proceso Unificado es más que un simple proceso. Los casos de uso no son sólo una herramienta para especificar los requisitos de un sistema.  El desarrollo se realiza a un nivel de abstracción mayor.  Ciclos de desarrollo más pequeños. y prueba. 5. diferentes tipos de organizaciones.  Mayor involucramiento de los usuarios. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad del sistema. El Proceso Unificado está dirigido por casos de uso Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. guían el proceso de desarrollo.  Interfaz gráfica estándar.  Los entregables pueden ser fácilmente trasladados a otra plataforma. . 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. implementación. es un marco de trabajo genérico que puede especializarse para gran variedad de sistemas de software.. Los casos de uso representan los requisitos funcionales. Ingeniería de Software  Mayor flexibilidad. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado.  Menor codificación manual. También guían su diseño.

los bloques de construcción reutilizables de que se dispones (por ejemplo. consideraciones de implantación. diseño. y los casos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba. un marco de trabajo para interfaces gráficas de usuario). comienzan con los casos de uso y continúan a través del trabajo de desarrollo subsiguiente – análisis. fiabilidad). los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. sistema operativo. se diseñan. Los ingenieros de prueba prueban la implementación para garantizar que los componentes del modelo de implementación implementan correctamente los casos de uso. que termina convirtiendo en código ejecutable los casos de uso que se desarrollan en la iteración. y los incrementos. rendimiento. los casos de uso no sólo inician el proceso de desarrollo sino que le proporcionan un hilo conductor. al crecimiento del producto. los desarrolladores identifican y especifican los casos de uso relevantes. Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. sistema de gestión de bases de datos. protocolos para comunicaciones en red). como las perciben los usuarios y los inversores. los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque. Los desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso. . 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. En cada iteración. Cuando una iteración no cumple sus objetivos. 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. las iteraciones hacen referencia a pasos en el flujo de trabajo. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. implementan el diseño mediante componentes. Al ser mini proyectos. El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Cada mini proyecto es una iteración que resulta en un incremento. Si una iteración cumple con sus objetivos – como suele suceder . Sin embargo. y verifican que los componentes satisfacen los casos de uso. como la plataforma en la que tiene que funcionar el software (arquitectura hardware. también se ve influida por muchos otros factores. y se refleja los casos de uso. crean un diseño utilizando la arquitectura seleccionada como guía. 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. La arquitectura es una vista del diseño completo con las características más importantes resaltadas dejando los detalles de lado. Los casos de uso se especifican. y requisitos no funcionales (por ejemplo. implementación y prueba -.Julio Cesar Equilea Delgadillo 210002727 Basándose en el modelo de casos de uso.el desarrollo continúa con la siguiente iteración. La arquitectura surge de las necesidades de la empresa. De este modo. sistemas heredados.

 Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios.  Fácil ejecución del proceso de elaboración del sistema software.  Reducir la redundancia e incrementa la productividad. Aquí.  Se define una arquitectura sólida en etapas tempranas del desarrollo. también. De este modo este tipo de ciclo de vida debe ser ampliable. un software bien diseñado evita la duplicidad del código con lo cual se obtiene un software robusto. La arquitectura de un sistema se define como un conjunto de componentes y las interacciones entre ellas. por lo que el sistema es robusto y tiene facilidad de mantenimiento.  Progreso visible en las primeras etapas.  Es un proceso pesado.  Se basa mucho en la documentación. tanto para aprender como para administrar. Diseño Grafico .  La metodología de PU es más adaptable para proyectos de largo plazo.  En cada momento hay una versión del sistema funcionando que se modifica según las necesidades y deseos del cliente.  Se reducen los riesgos de no obtener el producto deseado. 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.  El proceso es comprensible. ya que describen como está estructurado el sistema desde diferentes perspectivas orientadas a los diferentes involucrados en un proyecto.  Una cantidad sustancial de tiempo se gasta en tratar de adecuar el PU a cada proyecto. Se pueden encontrar errores y corregirlos. se corre el riesgo de volverse un esclavo del proceso y perder de vista la razón del proceso.  Si el proceso no se aplica bien desde el inicio el PU se puede volver muy grande y difícil.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.

rendimiento.. No es recomendable para proyectos muy pequeños 6. para diferentes áreas de aplicación. Desgraciadamente. Esto es. y otros productos o características del sistema frente al coste y al tiempo de comercialización. El objetivo de esta actividad es mostrar los requisitos de cliente. El modelo espiral sugiere una actividad del marco de trabajo que aborda la comunicación con el cliente. esto raramente ocurre. 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. donde el cliente puede ser preguntado para sopesar la funcionalidad. 2. . diferentes niveles de competencia y diferentes tamaños de proyectos. Identificación del sistema o subsistemas clave de los directivos. Las mejores negociaciones se esfuerzan en obtener “victoria-victoria”. En un contexto ideal. El modelo en espiral WINWIN de Boehm define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral.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. se definen las siguientes actividades: 1. En realidad el cliente y el desarrollador entran en un proceso de negociación. el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar. Determinación de la condiciones de victoria de los directivos. diferentes tipos de organizaciones.Win Win: Definición y Características: Es una variante del Modelo Espiral. Más que una simple actividad de comunicación con el cliente.

Como ejemplo. defina un conjunto de objetivos para cada actividad principal de ingeniería del software. los puntos de fijación representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral.Julio Cesar Equilea Delgadillo 210002727 3. 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. El segundo punto de fijación llamado arquitectura del ciclo de vida (ACV). Incorpora sólo los objetivos de más importantes y necesarios del proyecto. Constituye un enfoque realista del desarrollo de sistemas de software. El primer punto de fijación llamado objetivos del ciclo de vida (OCV). Se evalúan en una etapa independiente la resolución de riesgos. En esencia. que será el criterio clave para continuar con la definición del sistema y del software. . de un parte de OCV. el modelo en espiral WINWIN introduce tres hitos en el proceso. Reduce riesgos del proyecto.    Desventajas:    Requiere una gran habilidad de negociación. 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). un conjunto de objetivos asociados a la definición de los requisitos del producto/sistema del nivel más alto. Conseguidos completamente estos pasos iniciales se logra un resultado victoria-victoria. No es un modelo ampliamente usado. preparación del lugar previamente a la instalació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. llamados puntos de fijación. 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. 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. y la asistencia precisada de todas las partes que utilizará o mantendrá el software. Además del énfasis realizado en la negociación inicial.

Pero se requiere que se tenga cierta experiencia en el desarrollo de proyectos.Julio Cesar Equilea Delgadillo 210002727 Diseño gráfico: Aplicaciones Puede ser utilizado para una gran cantidad de tipos de sistemas de software. .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 prototipo Obtener realimentación del cliente sobre el prototipo Modificar el modelo de análisis basándose en lo que se ha aprendido del prototipo. El progreso se produce iterativamente. 7. para diferentes áreas de aplicación. Lo que hace diferente al modelo recursivo/paralelo es el reconocimiento de que: 1. 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 modelo de análisis y diseño para sistemas orientado a objetos no puede realizarse a un nivel uniforme de abstracción. diferentes tipos de organizaciones y diferentes tamaños de proyectos.

-El análisis y diseño pueden aplicarse a componentes independientes del sistema de manera concurrente. El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. En general cada incremento se construye sobre aquel que ya fue entregado. Desarrollo y Validación) sintetizan el desarrollo pormenorizado de los incrementos. que se hará posteriormente. 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. Bajo este modelo se entrega software “por partes funcionales más pequeñas”. pero reutilizables. .. Las actividades concurrentes (Especificación. llamadas incrementos.Julio Cesar Equilea Delgadillo 210002727 2. Planificación Análisis Diseño Revisión y refinamiento Análisis Diseño … Análisis Diseño Revisión y refinamiento Planificación Análisis Diseño Extraer clases reutilizables Prototipo Probar Primer Prototipo Evaluación del cliente Revisión y refinamiento Planificación Análisis Diseño Extraer clases reutilizables Prototipo Probar Evaluación del cliente Siguiente incremento … Revisión y refinamiento Planificación Análisis Diseño Extraer clases reutilizables Prototipo Probar N-ésimo incremento Evaluación del cliente 8. Aplica secuencias líneas de manera escalonada conforme avanza el tiempo.Incremental: Concepto.

Julio Cesar Equilea Delgadillo 210002727 El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejora).Secuencial: 11. pruebas y mantenimiento.  Diseño: . codificación. Desventajas.  No es recomendable para casos de sistemas de tiempo real. los primeros incrementos proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. 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.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. de alto nivel de seguridad.. 9.    Se enfoca en la entrega de un producto operacional con cada incremento. diseño.. y/o de alto índice de riesgos. Es útil sobre todo cuando el personal necesario para una implementación completa no está disponible. aunque omite los muchos bucles de este último. Ventajas. 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. Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos. de procesamiento distribuido.

la arquitectura del software. 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. puede no ser del completo agrado del cliente o puede necesitar. Esto quiere decir que no se rehace el programa. En forma general se hace un esbozo de lo solicitado y se documenta haciéndose parte del software. El cliente debe tener paciencia.Julio Cesar Equilea Delgadillo 210002727 Es una etapa dirigida hacia la estructura de datos. 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 .  Mantenimiento: Debido a que el programa puede tener errores. las representaciones de la interfaz y el detalle procedimental (algoritmo). asegurando que todas las sentencias se han comprobado. y en la detección de errores. sino que sobre la base de uno ya existente se realizan algunos cambios.  Pruebas: Esta etapa se centra en los procesos lógicos internos del software. A menudo es difícil que el cliente exponga exactamente todos los requisitos. Los responsables del desarrollo de software siempre se retrasan innecesariamente. eventualmente acoplarse a los cambios en su entorno.  Generación del código: Es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina. El Modelo Lineal Secuencial es el paradigma de desarrollo de software más antiguo que existe. Esta etapa va a depender estrechamente de lo detallado del diseño.

en su mayor parte 10.Framework: En el desarrollo de software. es una estructura conceptual y tecnológica de soporte definido. normalmente con artefactos o módulos de software concretos. Sea un proyecto pequeño. Ventajas:  Se debe tener en cuenta que fue el primer modelo empleado. o un proyecto con unos requisitos bastante estables. también denominado ciclo de vida clásico y modelo lineal secuencial. establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable.    El usuario debe esperar mucho tiempo hasta ver los resultados Los errores de análisis y diseño son costosos de eliminar. diseño. Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y éste recae. Cada fase genera documentación para la siguiente. codificación. pruebas y mantenimiento. y se propagan a las fases siguientes con un efecto conocido como bola de nieve. sigue siendo el paradigma más utilizado en el desarrollo del software. lo que da nombre al modelo.  Desventajas Desventajas: En general.Julio Cesar Equilea Delgadillo 210002727 encuentran métodos para análisis. Consiste en la ejecución secuencial de una serie de fases que se suceden. Requiere disponer de unos requisitos completos y precisos al principio del desarrollo. un framework o infraestructura digital. 1970). Esta documentación debe ser aprobada. Se disponga de unos requisitos completos y consistentes al principio del desarrollo.  Los requisitos no se pueden congelar mientras dura el desarrollo. Los usuarios no pueden imaginarse lo que quieren hasta que no ven un sistema funcionando. Características del modelo: Primer modelo empleado (Royce. en el que el período de congelación de los requisitos es corto.  Facilita la gestión del desarrollo. siendo mucho mejor que un enfoque al azar. El mercado cambia. Una fase no comienza hasta que la anterior ha terminado. Con todo y sus errores.. . todo cambia. y por lo tanto es mejor que ninguno.

Sin embargo. puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. puede incluir soporte de programas. puede ser considerado como el conjunto de procesos y tecnologías usados para resolver un problema complejo. Tenemos que contemplar estos aspectos básicos en cuanto a la implementación de nuestro sistema: Los Frameworks se basan en el Modelo Vista Controlador (MVC).Julio Cesar Equilea Delgadillo 210002727 con base a la cual otro proyecto de software puede ser más fácilmente organizado y desarrollado. Típicamente. hay quejas comunes acerca de que el uso de framework añade código innecesario y que la preponderancia de framework competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar los framework. y provee una estructura y una especial metodología de trabajo. Controlador: es la capa intermedia. para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Es el esqueleto sobre el cual varios objetos son integrados para facilitar una solución dada. Arquitectura: Dentro de este aspecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. bibliotecas. interactuando con la capa de modelo. presenta el modelo en un formato elegido. un equipo que usa Apache Struts para desarrollar un sitio web de un banco. Se encarga de gestionar las peticiones recibidas desde la vista. permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. la cual extiende o utiliza las aplicaciones del dominio. podemos basarnos en el modelo MVC (Controlador => Modelo => Vista). un patrón de diseño que separa las aplicaciones en tres componentes:    Modelo: son los datos o la información que se manejan en la aplicación. entre otras herramientas. Vista: normalmente representada por una interfaz de usuario. Por ejemplo. Fuera de las aplicaciones en la informática. . y un lenguaje interpretado. Introducción: Son diseñados con la intención de facilitar el desarrollo de software. ya que debemos fragmentar nuestra programación.

Es un método de gestión de proyectos comparable a PRINCE2 y describe tanto métodos para la gestión como para el desarrollo de sistemas. evitando así en el futuro la repetición de errores. simplificando el proceso de desarrollo. Algunos de los Frameworks más conocidos son Spring o Struts para aplicaciones en Java.Julio Cesar Equilea Delgadillo 210002727 Existen Frameworks para la gran mayoría de lenguajes utilizados en el desarrollo de aplicaciones. Desventajas: Posibilidad de generación de código innecesario para nuestra aplicación. Si una librería falla.Modelo en V o de cuatro niveles: El Método-V define un procedimiento uniforme para el desarrollo de productos para las TIC. Favorecen la reutilización de código. dd 11. El tiempo que se gana en dejar de programar puede perderse en aprender el Frameworks si no se va a utilizar para otros proyectos.    Aprendizaje costoso. . provocando una demanda de recursos computacionales innecesaria. Como está disponible públicamente muchas compañías lo usan. ya que los Frameworks tienden a generalizar la funcionalidad de los componentes. cada Frameworks tiene su propia convención de código.NET para C# o Zend para PHP. Existe una alta dependencia del código fuente de la aplicación con respecto al Framework. ASP.. Algunos de los Frameworks más conocidos son Spring o Struts para aplicaciones en Java. Aplicación  Existen Frameworks para la gran mayoría de lenguajes utilizados en el desarrollo de aplicaciones. la depuración es más complicada al no conocer el programador el código.    Facilitan servicios genéricos necesarios en la mayoría de proyectos. Aumenta la facilidad de depuración del código gracias al MVC. Ello provoca una amplia ganancia de tiempo en cuanto a la programación y el diseño. Es el estándar utilizado para los proyectos de la Administración Federal Alemán y de defensa. De esta forma. Además. Por eso es importante utilizar Frameworks y módulos en versiones avanzadas. Ventajas: Los Frameworks utilizan patrones de diseño. también se utiliza código ya testeado. por lo que no resulta sencillo cambiar de Frameworks. Entre ellos destaca el Modelo Vista Controlador que comentamos anteriormente. lo cual permite que el código resultante sea limpio y extensible para futuras ampliaciones. ASP.NET para C# o Zend para PHP.

Describe las actividades y los resultados que se producen durante el desarrollo del software. . También es ideal. Resume los pasos principales que hay que tomar en conjunción con las correspondientes entregas de los sistemas de validación. La parte de abajo.El Método-V es una representación gráfica del ciclo de vida del desarrollo del sistema.El Método-V fue desarrollado para regular el proceso de desarrollo de software por la Administración Federal Alemana. para toda esa gente que nunca ha programado siguiendo una metodología.Julio Cesar Equilea Delgadillo 210002727 La versión actual del Método-V es el Método-V XT que se terminó en Febrero del 2005. por su robustez. No es comparable con CMMI. • Es un modelo sencillo y de fácil aprendizaje • Hace explícito parte de la iteración y trabajo que hay que revisar • Especifica bien los roles de los distintos tipos de pruebas a realizar • Involucra al usuario en las pruebas Desventajas: • Es difícil que el cliente exponga explícitamente todos los requisitos • El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida • Las pruebas pueden ser caras y. el Método-V describe el "cómo" y el "cuándo" y "quién" es el responsable de haberlo hecho. La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema. donde se encuentran ambas partes. no lo suficienteme nte efectivas • El producto final obtenido puede que no refleje todos los requisitos del usuario Aplicación: Se trata de un proceso ideal. La parte derecha de la V representa la corriente donde se comprueba el sistema (contra las especificaciones definidas en la parte izquierda). para proyectos pequeños. con equipos de una a cinco personas. por su claridad. representa la corriente de desarrollo. Mientras que CMMI solo describe "qué" se ha hecho. a veces. Ventajas: • La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.

Sign up to vote on this title
UsefulNot useful