Capitulo 3 - Resumen INGENIERIA DEL SOFTWARE: UN ENFOQUE PRACTICO PDF

Preview

Summary

1 CAPITULO 3 DESARROLLO AGIL Cualquier proceso del sw se caracteriza por la forma en la que aborda ciertas suposiciones claves en los proyectos Sw: predecir que requerimientos de Sw quedaran y cuales cambiaran o como cambiaran, las prioridades de los clientes a medida que avanza el proyecto. vs. Tip...

Description

1

CAPITULO Nº 3 DESARROLLO AGIL Cualquier proceso del sw ágil se caracteriza por la forma en la que aborda ciertas suposiciones claves en los proyectos Sw: 1-Es difícil predecir que requerimientos de Sw quedaran y cuales cambiaran o como cambiaran, las prioridades de los clientes a medida que avanza el proyecto. 2-En vs. Tipos de Sw el diseño y la construcción deben ejecutarse simultáneamente, pero es difícil “predecir” cuanto diseño se necesita antes de usar la construcción para diseñarlo. 3-El análisis, diseño, construcción y pruebas no son predecibles ¿cómo crear entonces un proceso que maneje lo impredecible? Un proceso ágil debe ser adaptable, pero para ello debe avanzar, incrementarse y requiere retroalimentación c/ el cliente y en esto necesita un “prototipo operativo”. Deben entregarse incrementos de Sw (prototipos ejecutables o porción de SO) en periodos cortos de tiempo así la adaptación va junto c/ el cambio (impredecible). Este enfoque interactivo permite que el cliente evalúe regularmente el incremento de Sw. FACTORES HUMANOS

El desarrollo ágil se centra en las habilidades de las personas por la cual el proceso debe adaptare a las personas y sus necesidades y no al revés. Un equipo ágil de Sw debe haber características claves que deben compartir y son: Competencia: incluye el talento innato, habilidades relacionadas c/ el Sw y el conocimiento Gral. del proceso que el equipo eligió aplicar. Enfoque común: todos los miembros del equipo ágil (aunque realicen distintas tareas o tengan distintas habilidades). Colaboración: crear información que ayude a los participantes a entender el trabajo del equipo. Habilidad para tomar decisiones: tener autoridad para decidir sobre asuntos técnica y del proyecto. Capacidad para resolver problemas difusos: el equipo debe aceptar que quizás el problema que resuelven ahora tal vez no sea el que necesite resolver. Confianza y respeto mutuo: son necesidades para crear un equipo “pegado” donde “su” tejido tan fuerte hace que el todo es más que la suma de las partes. Organización propia: el equipo ágil se organiza a si mimo para hacer el trabajo organiza el proceso que mejor se adapte a su ambiente local, programa el trabajo para lograr del mejor modo la entrega del incremento Sw. VALORES XP Beck define 5 valores fundamentales para todo trabajo realizado como parte de XP comunicación, simplicidad, retroalimentación, valentía y respeto. COMUNICACIÓN: XP enfatiza la estrecha colaboración pero informal (verbal) entre clientes y desarrolladores, metáforas para comunicar conceptos importantes, la retroalimentación continúa y evita la documentación voluminosa como medio de comunicación. SIMPLICIDAD: xp restringe a los desarrolladores para que diseñen solo para necesidades inmediatas y no para las futuras.

2

Retroalimentación: se obtiene de 3 fuentes: el software implementado, el cliente y otros miembros del equipo de software. XP usa la prueba unitaria como táctica principal de prueba. VALENTIA: un término más apropiado sería disciplina. Un equipo XP ágil debe tener disciplina (valentía) para diseñar para hoy y reconocer que los requerimientos futuros tal vez combinen mucho. RESPETO: en un equipo agil debe haber respeto entre sus miembros, entre otros participantes, etc. PROCESO XP La programación extrema usa un enfoque orientado a objetos como paradigma de desarrollo, con reglas y prácticas que ocurren en el contexto de 4 actividades estructurales: planeación, diseño, codificación y pruebas. PLANEACION: o juego de planeación, comienza escuchando, lo que lleva a crear “historias” (historias del usuario) que describen las características del software que se va a elaborar. Cada historia es escrita por el cliente y le asigna una prioridad o valor con base en el valor general de la función para el negocio. Después los miembros del equipo XP evalúan cada historia y le asignan un costo mediado en semanas de desarrollo. Si la historia requiere más de 3 semanas de desarrollo se pide al cliente que la descomponga en historias más chicas asignándole un nuevo valor y costo. Clientes y desarrolladores trabajan juntos para decidir cómo agrupar las historias en el siguiente incremento de software que desarrollara el equipo XP. Una vez que se llega a un compromiso sobre la entrega (fecha y otros aspectos del proyecto) el equipo XP ordena las historias que serán desarrolladas en una de 3 formas: 1-Todas las historias se implementaran en pocas semanas. 2-Las historias con más valor entraran a la programación de actividades y se implementaran en primer lugar. 3-Las historias con más riesgo formaran parte de la programación de actividades y se implementaran en primer lugar. Después de la primera entrega del proyecto (incremento del software) el equipo XP calcula la velocidad de este. La velocidad del proyecto es el número de historias de los clientes implementado en la primera entrega. La velocidad del proyecto se usa para: 1-Ayudar a estimar las fechas de entrega y programar las entregas posteriores. 2-Determinar si se ha hecho un gran compromiso para todas las historias durante el desarrollo del proyecto. Si esto ocurre, se modifica el contenido de las entregas o se cambian las fechas de entrega final. DISEÑO: XP sigue le principio MS (Mantenerlo sencillo). Un diseño sencillo siempre se prefiere sobre uno complejo. XP estimula el uso de la tarjeta CRC como mecanismo eficaz para pensar en el software en un contexto orientado a objetos. Las tarjetas CRC (clase-responsabilidad-colaborador) identifican y organizan las clases orientadas a objetos que son importantes para el incremento actual del software. Estas tarjetas spon el único producto del trabajo de diseño que se genera para el proceso XP.

3

CODIFICACION: Después que las historias han sido desarrolladas y se hizo el diseño preliminar, el equipo no inicia la codificación sino que desarrolla pruebas unitarias a cada uno de las historias que se incluirán en la entrega en curso. Luego de creada la prueba unitaria el desarrollador esta mejor capacitado para centrarse en lo que debe implementarse para pasar la prueba. Una vez que el código está terminado se le aplica una prueba unitaria con lo que se obtiene retroalimentación instantánea para los desarrolladores. Un concepto clave en la codificación y del que más se habla en la XP es la “programación por parejas”. XP recomienda que 2 personas trabajen juntos en una estación de trabajo con el objeto de crear código para una historia. Esto da un mecanismo para la solución de problemas en tiempo real. A medida que las parejas de programadores terminan su trabajo, el código que desarrollan se integra con el trabajo de los demás. PRUEBAS: la creación de pruebas unitarias antes de que comience la codificación es un elemento cave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el uso de una estructura que permita automatizarlos. Las pruebas de aceptación XP o “pruebas del cliente”, son especificadas por el cliente. Estas pruebas se derivan de las historias de los usuarios que se han implementado como parte de la liberación del SW. XP INDUSTRIAL La programación externa industrial (IXP) incorpora 6 prácticas diseñadas para garantizar que un proyecto funcione c/ éxito para proyectos significativos dentro de una organización grande: 1) Evaluación de la factibilidad: antes de iniciar un proyecto IXP la organización debe hacer una “evaluación de factibilidad” para averiguar si: a) existe una ambiente apropiado de desarrollo que acepte IXP: b) el equipo estará formado por los participante adecuados. c) La organización tiene un programa de calidad que apoya la mejora continua. d) La cultura organizacional apoyara los nuevos valores de un equipo ágil 2) Comunidad el Proyecto: en IXP los miembros de la comunidad y sus papeles debe definirse de modo explícito, así como establecer los mecanismos para la comunicación y coordinación entre los integrantes de la comunidad. 3) Calificación del proyecto: la calificación también analiza el contexto de proyecto para determinar como complementa, extiende o remplaza sistemas o procesos existentes. 4) Adm. Orientada a pruebas: establecen destinos medibles y luego define los mecanismos para determinar si se han alcanzado o no. 5) Retrospectivas: después de entregar un incremento el sw el equipo XP, realiza una revisión técnica llamada “retrospectiva” que examinan temas eventos, etc. cuyo objetivo es mejorar e proceso IXP 6) Aprendizaje continuo: los miembros del equipo Xp son invitados e incentivados a aprender nuevos métodos y técnicas que conduzcan a una calidad más alta de producto. IXP modifica algunas de las existentes en XP. El desarrollo impulsado por la historia DIH insiste en que las historias de las pruebas de aceptación se escriban antes de generar una sola línea de código. El diseño implementado por el dominio DID es una mejora sobre el concepto de la “metáfora del sistema”

4

usado en XP: el DID sugiere la creación evolutiva de un modelo de dominio que represente con exactitud como piensan los expertos del dominio en su materia. DEBATE XP Volatilidad de los requerimientos Necesidades conflictivas del cliente Requerimientos se expresan informalmente Falta de un diseño formal SCRUM Los principios SCRUM se usan para guiar actividades de desarrollo dentro de un proceso de análisis que incorpora las sgtes. Actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad estructural las tareas de trabajo ocurren c/ un patrón del proceso llamado sprint. Scrum acentúa el uso de un conjunto de patrones del proceso del Sw que han demostrado ser eficaces en proyectos c/ plazos de entrega muy apretados, requerimientos cambiantes y negocios críticos. c/u de estos patrones de proceso define un grupo de acciones de desarrollo que son 4: 1. Retraso: lista de prioridades de requerimientos o característica del proyecto que dan al cliente un valor del negocio 2. Sprints: unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el retraso que debe ajustarse en una caja de tiempo “predefinida”. 3. Reuniones Scrum: reuniones breves (aprox.15mtos.) que el equipo Scrum efectúa a diario. Hay 3 ptas. claves que deben responder todos los miembros del equipo: * ¿Qué hiciste desde la última reunión del equipo? * ¿Qué obstáculos están encontrando? ¿Qué planeas hacer mientras llega la sgte reunión del equipo? Maestro srum: líder del equipo, dirige la junta, evalúa las respuestas de cada persona: esta junta ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible. 4- Demostraciones preliminares: entregar el incremento de Sw al cliente de modo que las funcionalidad que se hay implementado pueda demostrase al cliente y este pueda evaluarlo....