slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
INTEGRANTE PowerPoint Presentation
play fullscreen
1 / 36
Download Presentation

INTEGRANTE - PowerPoint PPT Presentation

163 Views
Download Presentation

INTEGRANTE

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. INTEGRANTE Génesis Cañar Santana Ingeniería de Software Ing. Verònica Carrasco

  2. Introducción • En la actualidad, los negocios cambian rápidamente a nivel global, tienen que responder a nuevas oportunidades, condiciones económicas cambiantes y a la vez a nuevos productos y servicios que ingresan en un mercado tan competitivo. El software también forma parte de casi la totalidad de las operaciones de negocios, parte importante es que el software sea desarrollado rápidamente para que sean aprovechadas nuevas oportunidades y así poder responder de la mejor forma a esta constante competencia.

  3. Objetivos • El presente trabajo tiene como objetivo describir varios enfoques para el desarrollo de software pensados para la entrega rápida del software. • Otro aspecto es comprender cómo un enfoque de desarrollo de software iterativo e incremental conduce a una entrega más rápida de un software más útil. • • Entender las diferencias entre los métodos de desarrollo ágiles y los métodos de desarrollo de software que dependen mucho de la documentación de las especificaciones y diseños

  4. Objetivos • conocerá los principios, prácticas y algunos de sus limitaciones de la programación extrema. • cómo se puede utilizar el prototipado para ayudar a resolver requerimientos y diseñar incertidumbres cuando se tiene que utilizar un enfoque de desarrollo basado en la especificación.

  5. MètodosÀgiles En los años 80 y principios de los 90, existía una opinión diferente de que la mejor forma de obtener un mejor software era a través de una planificación cuidadosa del proyecto, una garantía de calidad formalizada, la utilización de métodos de análisis y diseño soportados por herramientas CASE, y procesos de desarrollo de software controlados y rigurosos. Esta opinión provenía, fundamentalmente, de la comunidad de ingenieros de software implicada en el desarrollo de grandes sistemas software de larga vida que normalmente se componía de un gran número de programas individuales.

  6. Desarrollo y Prototipado Incremental

  7. Métodos Ágiles Este software era desarrollado por grandes equipos que a veces trabajan para compañías diferentes. Trabajaban en el software durante largos periodos de tiempo. Un ejemplo de este tipo de software son los sistemas de control de un avión moderno, en los cuales pueden transcurrir hasta 10 años desde la especificación inicial hasta la utilización. Existe sobrecarga de trabajo en cuanto a la planificación, diseño y documentación del sistema. Este esfuerzo adicional se justifica cuando se tiene que coordinar el trabajo de múltiples equipos de desarrollo, cuando el sistema es un sistema crítico y cuando muchas personas diferentes estarán involucradas en el mantenimiento del software durante su vida.

  8. Limitaciones y Desventajas • Cuando este enfoque pesado que se basa en planificación se lo llevó a cabo en sistemas de negocios pequeños y tamaño medio, el esfuerzo que se invertía era muy grande. Debido a que se dedicaba mas tiempo en pensar como se debía desarrollar el sistema que en programar lo relacionado a las pruebas. • Cuando cambiaban los requerimientos, se hacía esencial rehacer el trabajo, y al menos en principio, la especificación y el diseño tenían que cambiar con el programa. • El descontento que existió con estos enfoques fue lo que llevó a los desarrolladores en los 90 a promover nuevos métodos agiles. Centrándose esta vez en el software mas que en su diseño y documentación.

  9. Característicasde los Métodos Ágiles • Dependen de un proceso iterativo para especificación, desarrollo y entrega del software. • Fueron diseñados para apoyar al desarrollo de aplicaciones de negocios. Pensados para entregar software funcional de forma rápida clientes, y son quienes pueden proponer que se agreguen en iteraciones posteriores nuevos requerimientos o cambios. • Los partidarios de los métodos àgiles han sido evangélicos en la promoción y han tendido en pasar por alto sus deficiencias. Lo que ha llevado una serie de problemas de este enfoque (Stephens y Rosenberg, 2003). Críticos más razonables como DeMarco y Boehm (DeMarco y Boehm, 2002) resaltan tanto las ventajas como las desventajas de los métodos ágiles. Proponen que un enfoque híbrido en el cual los métodos ágiles incorporen algunas técnicas del desarrollo basado en la planificación puede ser lo mejor a largo plazo.

  10. Nota Importante • Los métodos ágiles tienen que depender de contratos donde el cliente paga por el tiempo necesario para el desarrollo del sistema en vez de por el desarrollo de un conjunto de requerimientos específico. Siempre y cuando vaya todo bien,si surgen problemas puede haber disputas sobre quién es el culpable y quién debe pagar por el tiempo extra y recursos necesarios para resolver los problemas. • métodos ágiles son sólo apropiados para algunos tipos de desarrollo de sistemas. • Son los más idóneos para el desarrollo de sistemas de negocio pequeños y de tamaño medio y para el desarrollo de productos para ordenadores personales.

  11. Programación Extrema XP HISTORIA La programación extrema o extreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

  12. Programación Extrema XP • Características • En la programación extrema, todos los requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se implementan directamente como una serie de tareas. • Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el código nuevo se integre al sistema. Existe un pequeño espacio de tiempo entre las entregas del sistema. • En un proceso de la XP, los clientes están fuertemente implicados en la especificación y establecimiento de prioridades de los requerimientos del sistema.

  13. Características • Los requerimientos no se especifican como una lista funciones requeridas del sistema. Más bien el cliente forma parte del equipo y discuten los escenarios con otros • Desarrollan conjuntamente una «tarjeta de historias» (story cara) que recoge las necesidades del cliente. El equipo de desarrollo intentará entonces implementar ese escenario en una entrega futura del software.

  14. Ciclo de la programación Extrema

  15. Figura: Tarjeta Historia Descarga Documentos

  16. Diferencias de la Programación Extrema con la Tradicional La ingeniería del software tradicional es que se debe diseñar para el cambio. Esto es, hay que prever los cambios futuros en el software y diseñar éste de forma que tales cambios se puedan implementar fácilmente. Sin embargo, la programación extrema ha descartado este principio partiendo del hecho de que diseñar para el cambio es a menudo un esfuerzo inútil. Con frecuencia los cambios previstos nunca se materializan y realmente se efectúan peticiones de cambios completamente diferentes.

  17. Solución que brinda la Programación Extrema Como en la Ingeniería tradicional se diseña al cambio, estos pueden degradar estructura del software, y son mas complicados de implementarlos. La programación extrema aborda este problema .Esto significa que el equipo de programación busca posibles mejoras del software y las implementa inmediatamente. Por lo tanto, el software siempre debe ser fácil de entender y cambiar cuando se implementen nuevas historias.

  18. Pruebas en XP • Las características clave de las pruebas en XP son: • 1. Desarrollo previamente probado. • 2. Desarrollo de pruebas incremental a partir de los escenarios. • 3. Participación del usuario en el desarrollo de las pruebas y en la validación, • 4. El uso de bancos de pruebas automatizados. • los requerimientos de usuario en XP se expresan como escenarios o historias y el usuario establece las prioridades de éstos para su desarrollo. El equipo de desarrollo evalúa cada escenario y lo divide en tareas. Cada tarea representa una característica distinta del sistema y se puede diseñar entonces una prueba de unidad para esa tarea.

  19. Descripción del caso de prueba para comprobar la validez de la tarjeta crèdito

  20. Programación en Parejas Características programadores trabajan en parejas para desarrollar el software. El desarrollo no siempre implica la misma pareja de personas trabajando juntas. Más bien, la idea es que las parejas se creen de forma dinámica para que todos los miembros del equipo puedan trabajar con los otros miembros en una pareja de programación durante el proceso de desarrollo.

  21. Programación en Parejas El uso de la programación en parejas tiene varias ventajas: 1. Apoya la idea de la propiedad y responsabilidad comunes del sistema. Esto refleja la idea de Weinberg de la programación sin ego (Weinberg, 1971), en la que el equipo como un todo es dueño del software y las personas individuales no tienen la culpa de los problemas con el código. En cambio, el equipo tiene una responsabilidad colectiva para resolver estos problemas. 2. Actúa como un proceso de revisión informal ya que cada línea de código es vista por al menos dos personas. Las inspecciones y revisiones del código consiguen descubrir un alto porcentaje de errores del software. Sin embargo, requiere mucho tiempo organizarlas y, por lo general, generan retrasos en el proceso de desarrollo. A pesar de que la programación en parejas es un proceso menos formal que probablemente no encuentre tantos errores, es un proceso de inspección mucho más económico que las inspecciones formales de programas.

  22. Programación en Parejas 3. Ayuda en la refactorización, la cual es un proceso de mejora del software. Un principio de la XP es que se debe refactorizar constantemente el software. Es decir, se deben escribir nuevamente partes del código para mejorar su claridad y estructura. El problema para implementar esto en un entorno de desarrollo normal es que es un esfuerzo que se gasta para obtener un beneficio a largo plazo, y se puede juzgar a una persona que practique la refactorización como menos eficiente que otra que simplemente realice el desarrollo del código. Cuando se utiliza la programación en parejas y a propiedad colectiva, otros se benefician inmediatamente con la refactorización, por lo que probablemente apoyarán el proceso.

  23. Puntos Claves Los métodos ágiles son métodos de desarrollo iterativo que se centran en la especificación, diseño e Implementación del sistema de forma incremental. Implican directamente a todosusuarios en el proceso de desarrollo. Reducir la sobrecarga en cuanto al esfuerzo de desarrollo puede hacer posible un desarrollo del software más rápido. • La programación extrema es un m é t o d o ágil conocido que integra una variedad de buenas prácticas de programación, como tas pruebas sistemáticas, la continua mejora del software y la participación del cliente en el equipo de desarrollo. • Un punto fuerte particular de la programación extrema es el desarrollo de pruebas automatizadas antes de que se cree una funcionalidad en un programa. Se deben ejecutar de forma satisfactoria todas las pruebas cuando se integra un incremento en un sistema

  24. Preguntas La programación extrema expresa los requerimientos del usuario como historias, donde cada historia se redacta en una tarjeta. Comente las ventajas y desventajas de este enfoque para la descripción de requerimientos. 2. Explique por q u é el desarrollo previamente probado ayuda al programador a desarrollar una mejor comprensión de los requerimientos del sistema. ¿Cuáles son los problemas potenciales del desarrollo previamente probado? 3 ¿Cuándo recomendaría contra el uso de un método ágil? 4 Sugiera 1 O 2 razones por las que el índice de productividad de programadores trabajando en parejas sea aproximadamente el mismo que dos programadores trabajando de forma individual

  25. Respuestas • Ventajas • Programación organizada. • Menor taza de errores. • Satisfacción del programador. • Desventajas • Es recomendable emplearlo solo en proyectos a corto plazo. •  Altas comisiones en caso de fallar. • 2) • Al escribir primero las pruebas se define implícitamente tanto una interfaz como una especificación del funcionamiento para la funcionalidad a desarrollar. Se reducen los problemas en los requerimientos y las confusiones de la interfaz, Con el desarrollo previamente probado, siempre hay un conjunto de pruebas que se pueden ejecutar fácilmente y de forma rápida. Esto significa que siempre que se añada cualquier funcionalidad al sistema

  26. 2 Problemas Potenciales Los programadores prefieren la programación a las pruebas y algunas veces escriben pruebas incompletas que no comprueban las situaciones excepcionales. Además, puede ser difícil escribir algunas pruebas. ejemplo, en una interfaz de usuario compleja, con frecuencia es difícil escribir las pruebas de unidad para el código que implementa la «vista lógica» y el flujo de trabajo entre las pantallas. Por último, es difícil juzgar la completitud de un conjunto de pruebas. Aunque se pueda tener una gran cantidad de pruebas del sistema, ese conjunto de pruebas puede no proporcionar una cobertura completa. 3 Cuando requiera un análisis detallado en el desarrollo de software no es recomendable el uso del métodos ágiles , tampoco es recomendable en equipos desarrollo ubicados en diferentes lugares.

  27. 4 • Programación en Parejas es igual a la de dos personas que trabajen individualmente. • Las parejas discuten sobre el software antes de empezar el desarrollo, por lo probablemente tengan menos comienzos en falso.

  28. Bibliografía (SOMMERVILLE, 2005)