Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Equipo 5 Metodos de Desarrllo de Software

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Modelos del software
Modelos del software
Wird geladen in …3
×

Hier ansehen

1 von 21 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (17)

Anzeige

Ähnlich wie Equipo 5 Metodos de Desarrllo de Software (20)

Aktuellste (20)

Anzeige

Equipo 5 Metodos de Desarrllo de Software

  1. 1. Modelos de Desarrollo de Software Ing. Marco Antonio Cuevas Gómez Materia: Fundamentos de Ingeniería de Software Ing. Marlene Mijangos Instituto Superior de La Venta
  2. 2. Introducción En la Ingeniería del Software, el desarrollo del mismo contempla el uso de modelos, métodos, paradigmas o filosofías que se usan para la creación de del software, cada uno con sus ventajas y desventajas, cabe destacar que ninguno de ellos se considera “perfecto” en estructura, algunos de ellos solo sirven para pequeños proyectos, y otros son complejos y extensos que abarcan hasta los detalles mas mínimos que contemplan al software.
  3. 3. Modelo construye y compone Uno de los primeros métodos existentes en el modelado de software, básicamente se desarrolla sin especificar requerimientos y sin diseño, para luego hacer tantos programas como sea posible hasta satisfacer al cliente, este método sirve para programas pequeños y desechables, ya que no contempla los costos y tiempo en que se puedan realizar los cambios que en fases terminales pueden ser excesivos. El mantenimiento también puede ser muy problemático para un sistema desarrollado bajo este escenario. Si Desarrollo del ¿Cumple con los requisitos Software Software del Cliente? Terminado Diseño No, Modificar
  4. 4. El modelo es simple, se compone de 3 partes, la primera engloba el diseño y el Desarrollo del desarrollo, pues solo se toma los datos otorgados por el cliente, y sin hacer una Software análisis muy extenso, y se comienza con el desarrollo del software. Al terminar, se Diseño presenta un software completo y terminado. Esta en vez de ser considerada una parte del modelo, es mejor vista como una evaluación integral del software que se termino en la primera etapa, aquí puede suceder dos cosas, que el cliente acepte el programa, ¿Cumple con los requisitos o que lo rechace, añadiendo o eliminado características del software del Cliente? que se termino el primera parte. Al finalizar la evaluación se procede con repetir el proceso de desarrollo y diseño; o se continua hacia la etapa final Esta es la ultima etapa del modelo, aquí solo se ven pequeños detalles Software preliminares del software que solo tienen que ver con la parte exterior del Terminado mismo. El software se considera terminado y listo para usarse.
  5. 5. Modelo de Cascada/Cascada Modificada Originalmente este modelo se basa en el conjunto de varios modelos en unificación. Hace el desarrollo mas estructurado, y además expresa la relación entre las fases subsecuentes. Originalmente era un modelo estrictamente secuencial, esto significaba que cada fase debe terminar para que la siguiente pueda comenzar. El punto crítico es que una fase no ha terminado hasta que la documentación y/o otros productos asociados con esa fase hayan sido completados. No permitía la retroalimentación o la re definición de las fases anteriores. Después se creo la cascada modificada, en este caso permitía la retroalimentación y daba mas libertades en la terminación de las tareas, “congelando” algunas desde ciertos puntos para dar paso a otras. Además se agregaron los pasos de verificación y validación, para poder checar que el sistema es el correcto y cumple con los requisitos del cliente.
  6. 6. Especificaciones Validación Diseño General Prueba Diseño en detalle Prueba Program ación Prueba de Unidad Integración Prueba de Integración Im plementación Validación Mantenimiento
  7. 7. Las ideas del cliente se plasm an aquí, el equipo de trabajo tiene Especificaciones la tarea de analizar e interpretar todos posibles requerim ientos, lim itaciones y características del software en este punto. Diseño General Ya cuando se interpretan los datos, se em pieza a visualizar un m odelo general del software, que abarca todos los puntos desde la program ación, el diseño visual, etc. Esta revisión es la m as extensa de todas, ya que abarca los Diseño en detalle elem entos m as im portantes del todo el program a, m as allá de el orden de estructuración y la m icro adm inistración, es la parte donde el program ador da soluciones a los problem as o lim itaciones expuestos por el cliente. Después de haber term inado el diseño com pleto, se com ienza con Program ación la creación de software, esta es una de las partes m as im portantes, donde se refleja la calidad del diseño y su potencial im plementación en un sistem a com plejo. Integración Sirve para garantizar que las diferentes partes de software de acoplen exitosam ente hacia el sistem a en si.
  8. 8. Después de el ensam blaje, se pone en producción el Im plementación software. Para todos los procedim ientos correctivos y las actualizaciones Mantenimiento secundarias del software (m antenimiento continuo). Con esto finaliza todo el proceso de cascada. Las validaciones son solo para verificar que tan aceptadas son los análisis que fueron realizados, y para verificar si el software esta listo para ser entregado . Las pruebas se hacen en el núcleo del proceso, ya sea para verificar el código, la programación y la implementación de software antes de entregarse al cliente y cumplir con las expectativas esperadas.
  9. 9. Modelo de construcción de prototipos Este modelo tiene 3 pasos : *Escuchar al cliente para definir detalladamente los objetivos del producto, los requisitos y las áreas donde se necesita mas información *Construir y revisar la maqueta (prototipo). *El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. Este método es útil cuando nuestros clientes no están seguros del lo que realmente quieren, además de involucrarlo en el desarrollo del mismo para conseguir los resultados que se quieren. El problema con los prototipos es que generalmente no representan actualmente el sistema que se desarrolla, algunas veces porque son creaciones que esta “forzadas” para su uso (muy grandes, mal optimizados, lentos).
  10. 10. Especificaciones Validación Diseño General Prueba Diseño en detalle Prueba Program ación Prueba de Unidad Prototipo 1 Integración Prototipo 2 Im plementación Prototipo 3 Mantenimiento Este método no diferencia mucho del de cascada modificada, solo añade prototipos al final de las fases que involucran programación.
  11. 11. Métodos de Rápido de Desarrollo de Software El desarrollo de software de "métodos rápidos" (también denominado Modelo rápido o abreviado AG) reduce el tiempo del ciclo de vida del software y por lo tanto, acelera el desarrollo de nuevo software. En primera instancia, se entrega una versión prototipo y después se integran la funcionalidades de manera iterativa para satisfacer los requisitos del cliente y controlar todo el ciclo de desarrollo. Los métodos rápidos se originaron por la inestabilidad del entorno técnico y el hecho de que el cliente a veces es incapaz de definir cada uno de los requisitos al inicio del proyecto. El término "rápido" es una referencia a la capacidad de adaptarse a los cambios de contexto y a los cambios de especificaciones que ocurren durante el proceso de desarrollo
  12. 12. Modelo RAD (Diseño Rápido de Aplicaciones) Es un modelo de proceso de desarrollo de software de cascada que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo se puede usar si y solamente si se comprenden bien los requisitos y se limita el ámbito del proyecto, si es fácil dividir al sistema en partes (o módulos) pequeños y se utiliza un enfoque de construcción basado en objetos reusables donde haya una retroalimentación en cada parte del proyecto. Particularmente este método rápido requiere recursos humanos suficientes como para crear el número correcto de equipos; además de necesitar que el cliente y el desarrollador se comprometan en las actividades necesarias para completar un sistema en un tiempo corto; un ciclo de desarrollo corto basado en tres fases (requisitos, diseño y construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.
  13. 13. Equipo 1 Modelado de gestión Modelado de datos Modelado de procesos Generación de aplicaciones Pruebas y Volum en 90 a 120 Días
  14. 14. Modelado El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién de gestión la proceso? Modelado El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones de datos entre estos objetos. Modelado Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario de para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos. procesos El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear Generación de componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la aplicaciones construcción del software. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce Pruebas y tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo. Volum en
  15. 15. Método de Desarrollo de Sistema Dinámico (DSDM) Este método se creo y desarrolló para completar lo que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo completo. En comparación del RAD, esta presenta mas fases, pero dentro del mismo ciclo temporal. •Las características principales del método DSDM son las siguientes: •Participación del usuario •Desarrollo iterativo y creciente •Frecuencia de entrega mejorada •Pruebas integradas en cada fase •La aceptación de los productos entregados depende directamente del cumplimiento de los requisitos.
  16. 16. Método de Proceso Unificado (UP) y Unificado Racional (RUP) El método proceso unificado (UP) es un proceso de desarrollo iterativo y creciente. Esto significa que el proyecto se divide en fases más cortas y que se envía una nueva versión gradual al final de cada fase; se podría considerar como un RAD con un sistema de prototipos al termino de cada fase de desarrollo. Este enfoque está basado en el modelo UML para la descripción de la arquitectura del software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo describe los requisitos y las demandas del usuario. El RUP es un método de desarrollo iterativo promovido por la compañía Rational Software, adquirida por IBM. Este método especifica, principalmente, la constitución del equipo y las escalas de tiempo, así como un número de modelos de documento, mas los métodos usados en el UP.
  17. 17. Modelo XP - Programación extrema El método XP (Programación extrema) define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente. La Programación extrema se basa en los siguientes conceptos: •Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de una o dos semanas como máximo. •La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para maximizar la interacción con el usuario. •Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código. •El código se prueba y depura a lo largo del proceso de desarrollo. •Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo.
  18. 18. Modelos evolutivos Esta familia de modelos se utilizan en las siguientes circunstancias: - Si los requisitos cambian conforme el desarrollo avanza. - Si las fechas de mercado hacen imposible tener un producto completo y hay que introducir una versión limitada. - Si los requisitos centrales están bien definidos pero todavía hay que definir los detalles de las extensiones del producto. Veremos a continuación 2 modelos de este tipo: - Incremental - Espiral de Boehm (Tradicional y Moderno)
  19. 19. Modelo incremental Combina elementos del modelo de cascada (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos. El primer incremento es un producto esencial (llamado núcleo), se afrontan requisitos básicos y muchas funciones extras (algunas conocidas o no) quedan para los siguientes incrementos. El cliente usa el producto central y en base a la utilización y/o evaluación se desarrolla un plan para el incremento siguiente. Este proceso se repite hasta que se elabora el producto completo. Es interactivo, al igual que el de construcción de prototipos y otros enfoques evolutivos. Pero a diferencia del modelo de construcción de prototipos, el modelo incremental entrega un producto operacional en cada incremento. Es útil cuando la dotación de personal no está disponible para una implementación completa. El primer incremento se pueden implementar con pocas personas. Si el producto central es bien recibido, se puede añadir mas personal.
  20. 20. Los pasos de este modelo solo están limitados por la cantidad de incrementos que se realicen el todo el proyecto, la combinación de cascada y prototipos hace de este método muy rápido y eficiente en la creación de proyectos de tamaño considerable. Modelo incremental
  21. 21. Bibliografía http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf http://eclases.tripod.com/id12.html http://ldc.usb.ve/~vtheok/cursos/ci3711/apuntes/99-01- 14/Info/Modelo%20RAD.htm http://curiosisimos.files.wordpress.com/2009/12/modelo-de- desarrollo-rapido-de-aplicaciones.pdf

×