Ingenier

1
Ingeniería del software II

• Metodologías ágiles
• eXtreme Programing

2
Metodologías Ágiles

• Las metodologías ágiles surgen como respuesta a
  las metodologías pesadas (PUD, Metrica, etc).
• La critica mas habitual a estas metodologías hay
  tanto que hacer para seguir la metodología que el
  ritmo entero del desarrollo se retarda.
• Las metodologías ágiles cambian algunos de los
  énfasis de las metodologías pesadas. La
  diferencia inmediata es que son menos orientados
  al documento, exigiendo una cantidad más pequeña
  de documentación para una tarea dada. En muchas
  maneras son más bien orientados al código
  siguiendo un camino que dice que la parte
  importante de la documentación es el código
  fuente.

3
Manifiesto ágil

• Estamos descubriendo mejores maneras de
  desarrollar software tanto por nuestra propia
  experiencia como ayudando a terceros. A través de
  esta experiencia hemos aprendido a valorar
•  
• Individuos e interacciones sobre procesos y
  herramientas
• Software que funciona sobre documentación
  exhaustiva
• Colaboración con el cliente sobre negociación de
  contratos
• Responder ante el cambio sobre seguimiento de un
  plan 
•  
• Esto es, aunque los elementos a la derecha tienen
  valor, nosotros valoramos por encima de ellos los
  que están a la izquierda. (http//www.agilemanifes
  to.org/)
• Esta manifiesto esta firmado por algunos de los
  mas respetados expertos en ingeniería del
  software de la actualidad Kent Beck, Alistair
  Cockburn, Ward Cunningham, Martin Fowler, Ken
  Schwaber etc

4
Ágiles vs Pesadas

• Los métodos ágiles son adaptables en lugar de
  predictivos
• Los métodos pesados tienden a intentar planear
  una parte grande del proceso del software en gran
  detalle para un plazo grande de tiempo. esto
  funciona bien hasta que las cosas cambian. Así
  que su naturaleza es resistirse al cambio.
• Para los métodos ágiles el cambio es bienvenido.
  Intentan ser procesos que se adaptan y crecen en
  el cambio, incluso al punto de cambiarse ellos
  mismos.

5
Ágiles vs Pesadas

• Los métodos ágiles son orientados a la gente y no
  orientados al proceso
• La meta de los métodos pesados es definir un
  proceso que funcionará bien con cualquiera que lo
  use.
• Los métodos ágiles afirman que ningún proceso
  podrá nunca maquillar las habilidades del equipo
  de desarrollo.
• Las metodologías ágiles afirman trabajar a favor
  de la naturaleza humana en lugar de en su contra
  y enfatizan que el desarrollo de software debe
  ser una actividad agradable.

6
Predictivo vs Adaptable diseño y construcción

• La ingeniería del software tradicionalmente se ha
  inspirado en otras ingenierías, como por ejemplo
  la ingeniería civil.
• En estas ingenierías de desarrolla un diseño y
  posteriormente este es entregado a otras personas
  que se encargan de la construcción en base a ese
  diseño.
• Hay por tanto dos fases diferenciadas
• Diseño requiere de un equipo creativo y
  altamente especializado y supone en torno al 10
  del tiempo del proyecto
• Construccion requiere de un equipo con menos
  especializacion (intelectual) y supone en torno
  al 90 del tiempo total

7
Predictivo vs Adaptable diseño y construcción

• Intentado aplicar este enfoque al desarrollo de
  software surgen muchas preguntas
• Es posible entregar un diseño de software, por
  ejemplo en UML, que especifique claramente como
  se debe desarrollar el código?
• Los diseños en UML son verificables para
  asegurarnos de su corrección antes de entregarlos
  para la fase de construcción?
• es la construcción suficientemente grande en
  costo y tiempo para hacer valer la pena este
  enfoque?

8
Predictivo vs Adaptable diseño y construcción

• Esta clase de preguntas llevaron a Jack Reeves a
  sugerir que de hecho el código fuente es un
  documento de diseño y que la fase de construcción
  está en realidad en la compilación y el ligado
• Estas idea lleva a las siguientes conclusiones
• En software la construcción es tan barata que es
  casi gratis.
• En software todo el esfuerzo está en el diseño,
  de modo que requiere de personas creativas y
  talentosas.
• Los procesos creativos no se planean fácilmente,
  de modo que la previsibilidad bien puede ser una
  meta imposible.
• Debemos ser muy cautos al usar la metáfora de la
  ingeniería tradicional para construir software.
  Es un tipo diferente de actividad y por ende
  requiere un proceso diferente.
• () http//www.bleading-edge.com/Publications/CJ
  ournal/Cpjour2.htm

9
Predictivo vs Adaptablerequisitos impredecibles

• La idea detrás de la ingeniería de requisitos es
  conseguir un cuadro totalmente entendido de los
  requisitos antes de empezar a construir el
  software y conseguir la firma del cliente sobre
  estos requisitos.
• Hay que preguntarse es esto posible con el
  software?, la respuesta es NO por varios motivos
• No es fácil entender las necesidades del cliente,
  ni el sabe expresarlas en términos de software ni
  nosotros entendemos en profundidad su negocio o
  actividad.
• El valor que proporciona un software es difícil
  de cuantificar a priori, solo cuando se comienza
  a usar es posible determinar la implementación de
  que requisitos aporta mas valor.
• muchos cambios en el mundo de negocios son
  completamente imprevisibles y afectaran
  enormemente a los requisitos.

10
Predictivo vs Adaptablerequisitos impredecibles

• Aun si dispusiéramos de unos requisitos
  inamovibles, calcular el costo de implementación
  de esos requisitos puede ser complejo por varias
  razones
• Porque los materiales básicos cambian
  rápidamente. Las tecnologías evolucionan
  rápidamente y en ocasiones son complejas de
  utilizar.
• Por lo mucho que depende el software de los
  individuos involucrados, y los individuos son
  difíciles de predecir y cuantificar.

11
Predictivo vs Adaptable

• Todo esto nos lleva a la conclusión de que la
  actividad de desarrollar software es imposible o
  muy difícil de predecir o planear. Como en tantos
  problemas la parte más difícil está simplemente
  en comprender que el problema existe.
• Por tanto el uso de metodologías predictivas no
  parece lo mas adecuado, para la gran mayoría, del
  desarrollo de software.
• Las metodologías ágiles tratan de buscar
  respuesta a este problema mediante la
  Adaptabilidad

12
Adaptabilidad

• La adaptabilidad se fundamenta en dos pilares
  fundamentales
• Construcción iterativa del software
• Relación mas estrecha con el cliente

13
Orientados a la gente

• Uno de los objetivos de las metodologías
  tradicionales es desarrollar un proceso donde las
  personas involucradas sean partes reemplazables.
  Con tal proceso se puede tratar a las personas
  como recursos que están disponibles en varios
  tipos. Se tienen un analista, algunos
  programadores, algunos verificadores, un gerente.
  Los individuos no son tan importantes, sólo los
  papeles lo son.
• Pero realmente son las personas involucradas en
  el desarrollo de software partes reemplazables?
  Uno de los rasgos importantes de los métodos
  ágiles es el rechazo a esta afirmación.

14
Orientados a la gente

• La creación de software es un proceso creativo y
  que requiere talento, ni es fácil medir el
  talento de las personas ni todas las personas
  tienen el mismo talento.
• La noción de la gente como recursos esta
  profundamente inculcado en el pensamiento de
  negocios, teniendo sus raíces en el impacto del
  enfoque de La Dirección Científica de Frederick
  Taylor. En la administración de una fábrica, este
  enfoque Taylorista tiene sentido. Pero para un
  trabajo altamente creativo y profesional, como es
  el desarrollo de software, esto no se sostiene.

15
Orientados a la gente

• Una parte clave de la noción Taylorista es que la
  gente que hace el trabajo no es la mejor gente
  para entender la mejor manera de hacer el
  trabajo.
• Cuando se quiere contratar y retener a gente
  capaz, hay que reconocer que son profesionales
  competentes. Como tales son los mejores para
  decidir cómo dirigir su trabajo técnico.

16
Orientados a la gente

• Los desarrolladores deben poder tomar todas las
  decisiones técnicas. Sólo los desarrolladores
  pueden estimar cuánto tiempo se va ha emplear en
  hacer un trabajo.
• Por la naturaleza creativa del desarrollo de
  software las diferencias entre los buenos y malos
  desarrolladores son enormes, retener a los buenos
  programadores proporcionándoles un entorno de
  trabajo adecuado se hace indispensable.
• La productividad en el desarrollo de software
  depende en gran medida del estado de animo del
  desarrollador, un equipo de desarrollo satisfecho
  con el trabajo que realiza será un equipo de
  trabajo mucho mas productivo.

17
Metodologías Ágiles

• Basándose en estos principios existen diversas
  metodologías
• eXtreme Programming
• Cristal
• SCRUM
• FDD (Feature Driven Development)

18
eXtreme Programming

• eXtreme programming es un metodologia creada por
  Kent Beck, Ward Cunningham y Ron Jeffries durante
  su trabajo en el proyecto C3 de Chrysler.
• Actualmente es la metodología ágil mas extendida

19
eXtreme Programming

• XP es una metodología pensada para equipos de
  desarrollo de tamaño pequeño o medio que trabajan
  en proyectos donde los requisitos varían con
  mucha frecuencia.
• El extreme en el nombre de la metodología viene
  dado por que según los autores tratan de llevar
  al extremo practicas que consideran de sentido
  común en el desarrollo de software.

20
eXtreme Programming

• Revisar el código es bueno, XP propone revisarlo
  constantemente (programación en parejas).
• Testear el código es bueno, XP propone testear
  constantemente (desarrollo dirigido a test)
• Diseñar es bueno, XP propone que el diseño forme
  parte del trabajo diario (refactorizacion)
• La simplicidad es buena, XP propone hacer siempre
  lo mas sencillo The simplest thing that could
  possibly work
• Integrar los test en el desarrollo es importante,
  XP propone integrarlos incluso varias veces al
  dia (integracion continua)

21
Promesas de XP

• A los programadores
• Promete trabajar en cuestiones importantes todos
  los días.
• No tener que afrontar problemas o situaciones
  difíciles solos.
• Tomaran las decisiones los mejores cualificados
  para hacerlo.

22
Promesas de XP

• A clientes y jefes de proyecto
• Se conseguirá el mayor valor posible por cada
  semana de trabajo.
• Cada pocas semanas se podrán ver resultados
  concretos del trabajo.
• Se podrá cambiar la dirección del proyecto
  durante el desarrollo sin tener que asumir un
  coste exorbitante.

23
Valores de XP

• Comunicación
• Muchos proyectos fracasan por errores en la
  comunicación.
• Las técnicas de XP están orientadas a fomentar la
  comunicación entre los distintos integrantes del
  proyecto.
• XP pretende que todos los programadores tengan un
  visión global proyecto, que el cliente este
  presente en el desarrollo y otras técnicas que
  sirven para fomentar esta comunicación.

24
Valores de XP

• Simplicidad
• XP toma la simplicidad como uno de sus valores
  fundamentales, los diseños y codificaciones deben
  ser lo mas simples posibles y mejorarlas a traves
  de la refactorizacion cuando sea necesario.
• Es Preferible hacer un diseño lo mas simple
  posible hoy y mejorarlo por futuras peticiones
  mañana que hacer un diseño muy complejo hoy y que
  luego no sea nunca necesario.

25
Valores de XP

• Retroalimentación (feedback)
• Retroalimentación del sistema Escribiendo test
  unitarios que proporcionen información constante
  acerca del estado del sistema
• Retroalimentación del cliente El cliente escribe
  los test funcionales y prueba el sistema
  proporcionando información sobre su
  funcionamiento.

26
Valores de XP

• Coraje
• Los desarrolladores tienen que tener coraje para
  afrontar ciertas circunstancias del desarrollo,
  ejemplos
• Coraje para refactorizar el código
  constantemente.
• Coraje para tirar a la basura partes del codigo
  que se han convertido en demasiado complejas y
  que son un lastre en el desarrollo.
• Coraje para afrontar cambios profundos en el
  sistema que puedan proporcionar una mejora
  significativa del mismo.

27
Practicas XP

• Para seguir la metodología XP se deben seguir una
  serie de practicas. Estas practicas en su mayoría
  no son nada nuevo, son practicas que se llevan
  usando en programación durante años. La novedad
  en XP es incluirlas todas juntas dentro del
  contexto de una metodología.

28
Practicas XP el juego de la planificación

• El desarrollo de software es a menudo un dialogo
  entre lo posible y lo deseable.
• Dentro de la planificación tendrán que intervenir
  tanto gente conocedora del negocio y del problema
  a resolver por a aplicación como la gente técnica
  encargada de hacer la aplicación.
• Los primeros hablaran de lo deseable y lo
  segundos de lo posible, intentando acercar los
  dos puntos lo máximo posible.

29
Practicas XP el juego de la planificación

• La gente de negocios debe decidir
• El alcance de la aplicación hasta donde tiene
  que llegar la aplicación para poder resolver un
  problema real en producción.
• Prioridades que tareas son más prioritarias de
  realizar.
• Composición de las entregas que debe contener
  cada entrega de la aplicación para que aporte
  valor respecto a la anterior.
• Fechas de las entregas Que fechas, desde el
  punto de vista del negocio, son importantes y
  seria deseable tener el software terminado.

30
Practicas XP el juego de la planificación

• La gente técnica debe decidir
• Estimaciones Cuanto puede llevar implementar una
  característica determinada.
• Consecuencias Se debe informar de las
  consecuencias técnicas de las decisiones de
  negocios. Como por ejemplo confiar en un
  determinado proveedor de BD para la aplicación.
• Planificación detallada Dentro de cada iteración
  los programadores tienen la libertad de
  planificar que características se implementaran
  primero.

31
Practicas XP Entregas pequeñas

• Las entregas deben ser lo mas pequeñas posibles,
  pero deben contener características que aporten
  valor al producto final.
• Una entrega debe tener sentido como conjunto, es
  decir, no se puede hacer una entrega que
  implemente características sólo a medias a fin de
  reducir el tiempo de entrega.
• Es preferible planear una entrega con un plazo de
  un mes a planear entregas con un año de duración.

32
Practicas XP Diseño Simple

• Un código bien diseñado debe cumplir lo
  siguiente
• Pasar todos los test.
• No tener lógica duplicada.
• Tener el menor número posible de clases y
  métodos.
• Esto es justo lo contrario a una recomendación
  clásica del desarrollo de software programa
  para hoy, diseña para mañana.
• No diseñes pensando en cual será el futuro,
  diseña sólo pensando en la forma más sencilla de
  poner el sistema en funcionamiento. Si en el
  futuro aparecen nuevos requerimientos modifica
  el diseño.

33
Practicas XP Test

• En XP se debe utilizar el desarrollo dirigido a
  Test. Dentro del desarrollo dirigido a test para
  cada funcionalidad nueva a implementar se siguen
  los pasos
• Primero se escribe un test unitario.
• Se ejecuta el test, que obviamente fallara.
• Se escribe el código que implementa la
  funcionalidad.
• Cuando se consigue pasar el test el trabajo ha
  terminado.

34
Practicas XP Test

• Test funcionales los test funcionales o de
  aceptación deben ser escritos por el cliente, que
  es quien sabe lo que quiere de la aplicación.
• Si una característica de la aplicación no tiene
  su correspondiente test y ha sido pasado,
  sencillamente esa característica no existe.

35
Practicas XP Refactorización

• Después de añadir una nueva característica el
  programador se debe preguntar si existe una forma
  más simple de diseñar su programa.
• Si existe un forma más simple se debe modificar
  el diseño y verificar que siguen pasando los
  test, a esto se le llama refactorización.
• De este modo no se modifica el diseño por
  especulación o por lo que me puedan pedir
  mañana, se modifica el código en el preciso
  instante en que aparece la necesidad de hacerlo.

36
Practicas XP Programación en parejas

• Todo el código de producción es escrito por dos
  personas en una maquina, con un teclado y un
  ratón.
• En cada pareja hay dos roles
• El primero, el que maneja el teclado y el ratón,
  piensa y en la mejor forma de implementar.
• El segundo piensa de una forma más estratégica
• esto va ha funcionar?
• qué nuevos test se pueden introducir?
• hay alguna manera de simplificar el diseño?

37
Practicas XP Propiedad colectiva del código

• Nadie es dueño de ninguna porción del código,
  cualquiera puede ver y modificar cualquier parte
  del código si lo considera necesario.
• Todos los programadores toman la responsabilidad
  del sistema completo y no solo de su parte del
  código.
• Los programadores se mueven y cambian de tarea
  frecuentemente, esto implica que todo el mundo
  conoce todo el código y esta capacitado para
  cambiar cualquier parte del sistema.

38
Practicas XP Integración Continua

• El código se integra y testea varias al veces al
  día, o al menos una vez al día.
• Se suele dedicar una maquina exclusivamente al
  proceso de integración. Existen programas que
  permiten automatizar y programar esta tarea.
• Este proceso ayuda enormemente a detectar lo más
  pronto posible posibles errores colaterales.

39
Practicas XP 40 horas semanales

• No es necesario que sean exactamente 40 horas,
  diferentes personas tienen diferentes tolerancias
  al trabajo.
• Pero es importante que sean unas horas razonables
  que permitan a los integrantes del proyecto
  acudir cada mañana con la cabeza despejada y
  dispuesta para trabajar a pleno rendimiento.
• La regla en XP es no trabajar por encima de las
  horas estipuladas dos semanas consecutivas. Si en
  algún momento aparece la necesidad de trabajar
  mas horas durante varias semanas consecutivas eso
  significa que el proyecto tiene un problema que
  no se va ha resolver simplemente trabajando mas
  horas.

40
Practicas XP Cliente como parte del equipo

• Un cliente real se tiene que sentar junto al
  equipo de desarrollo.
• Un cliente real significa alguien que realmente
  vaya a usar el sistema, no confundir con el que
  paga.
• Una objeción a esta regla suele ser que el
  cliente es importante en su puesto actual de
  trabajo. Los gestores del proyecto deben
  preguntarse si merece la pena perder el trabajo
  de esta persona para tener un mejor sistema en
  menos tiempo.
• Si consideran que la perdida de una persona
  durante un determinado tiempo es de mayor
  importancia que el sistema quizás no merezca la
  pena construirlo.

41
Practicas XP Estándares de codificación

• Si asumimos que todos los programadores deben ver
  el código de todos y todos pueden modificarlo no
  puede usar cada uno sus propios estándares de
  codificación.
• Tiene que llegar un momento en el que sea
  imposible saber que miembro del equipo ha escrito
  que líneas de código.
• El estándar debe ser adoptado voluntariamente por
  todo el equipo, es decir, se debe llegar a un
  acuerdo con el que todo el mundo este satisfecho.
• Una buena practica es incluir comprobaciones de
  que se cumple el estándar como un test más.

42
El proceso XP Proyecto
43
El proceso XP Iteracion
44
El proceso XP Desarrollo
45
El proceso XP Propiedad Colectiva del código
46
Roles en XP Programador

• Programadores los programadores son el corazón
  de XP. Los programadores tienen la
  responsabilidad de tomar todas las decisiones
  técnicas sobre el proyecto. No hay ningún otro
  rol técnico en XP además de los programadores.
• Un programador XP tiene que desarrollar ciertas
  habilidades
• Aprender a trabajar en parejas
• Convertir la simplicidad en un habito
• Conocer las técnicas del desarrollo orientado a
  test
• Conocer las técnicas de refactorizacion.

47
Roles en XP Cliente

• Es la otra parte de la dualidad fundamental en XP
  (programador/cliente), el cliente sabe lo que hay
  que hacer y el programador sabe como hacerlo.
• Un cliente XP debe aprender también ciertas
  habilidades
• Escribir buenas historias de usuario.
• Escribir buenos test funcionales.

48
Roles en XP Test

• El papel de tester dentro de un proceso XP esta
  asignado al cliente, el deberá ser el encargado
  de ejecutar los test y verificar que el sistema
  funciona. quién mejor que el usuario final del
  sistema para probarlo?.
• El testeador en XP no es por tanto una persona
  sólo dedicada a tratar de romper el sistema y
  humillar a los programadores.

49
Roles en XP Entrenador (Coach)

• Es el encargado del conjunto del proceso. Tiene
  que responsabilizarse de que todos los
  participantes del proceso cumplen con su parte y
  realizan adecuadamente las diferentes practicas
  de XP.
• Es el encargado también de proporcionar
  información y asesoramiento a los participantes
  en el proyecto de cómo ejecutar de forma más
  conveniente las practicas XP.

50
Roles en XP Consultor

• En un equipo XP no hay especialistas en áreas de
  conocimiento determinadas.
• Es posible que en ocasiones y ante problemas
  concretos en equipo de XP necesite la ayuda de un
  experto en un área determinado que pueda aportar
  un conocimiento técnico más profundo sobre alguno
  cuestión.
• Una vez que el consultor ha terminado su trabajo
  los programadores XP deben tirar a la basura el
  código del consultor y hacerlo por ellos mismos
  gracias a los conocimientos adquiridos junto al
  consultor.