Unidad 2

477 views

Published on

  • Be the first to comment

  • Be the first to like this

Unidad 2

  1. 1. Modelos de la ingeniería de SoftwareUNIDAD 2
  2. 2. Unidad 22.1 MODELO DE CAPACIDAD DE MADUREZ
  3. 3. INTRODUCCIÓN El modelo de capacidad y madurez o mejor llamado CMM, CMMI o IMCM, es el modelo de evaluación de procesos de una organización. Fue creado para los procesos elativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
  4. 4. EL MODELO CMMI A partir de Noviembre de 1986 el SEI desarrollo una definición de un modelado de madures, la cual fue publicada en 1987, esto a evolucionado hasta febrero de 1993. Este modelo establece un conjunto de practicas o procesos clave agrupados en Áreas Clave del proceso (KPA-Key process Área). Para cada área de proceso define un conjunto de practicas que habrán de ser:
  5. 5. EL MODELO CMMI (CONT.) Ejecutadas de Definidas en Provistas de un modo un los medios y sistemático, Medidas Verificadas procedimiento formación universal y documentado necesarios uniforme
  6. 6. EL MODELO CMMI (CONT.) A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
  7. 7. EL MODELO CMMI (CONT.) • Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los Inicial proyectos es impredecible. • En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.Repetible • Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se Definido implementan técnicas de revisión por pares (peer reviews). • Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.Gestionado • La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.Optimizado
  8. 8. EL MODELO CMMI (CONT.) CMMI es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos eficaces. Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay dos áreas de interés cubiertas por los modelos de CMMI: Desarrollo y Adquisición. CMMI para el Desarrollo (DEV-CMMI): En él se tratan procesos de CMMI para la adquisición (ACQ- desarrollo de productos y CMMI): En él se tratan la gestión servicios. de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.
  9. 9. ÁREAS DEL PROCESO CMMI Análisis de causalidad y solución  Planificación de proyectos Configuration Management  Proceso y aseguramiento de Decisión de Análisis y Resolución calidad del producto Proyecto Integrado de Gestión  Integración de Producto Medición y Análisis  Gestión de proyectos Innovación organizacional y Cuantitativos Despliegue  Gestión de requerimientos Definición de procesos  Requerimientos de Desarrollo organizacionales  Gestión de Riesgos Enfoque en procesos  Gestión de Proveedores organizacionales  Solución Rendimiento de procesos  Validación organizacionales  Verificación Entrenamiento organizacional Vigilancia y Control de proyectos
  10. 10. REPRESENTACIONES:
  11. 11.  El modelo para ingeniería de sistemas (SE- CMM) establece 6 niveles posibles de capacidad para una de las 18 áreas de proceso implicadas en la ingeniería de sistemas. No agrupa los procesos en 5 tramos para definir el nivel de madurez de la organización, sino que directamente analiza la capacidad de cada proceso por separado. Es lo que se denomina un modelo continuo.
  12. 12. NIVELES DE CAPACIDAD DE LOS PROCESOS (REPRESENTACIÓN CONTINUA) Definido: Optimizarte: Gestionado: Además de Además de ser Además de ser un un proceso Cuantitativam ejecutarse, proceso ente cuantitativameIncompleto: nte gestionado, el proceso gestionado se gestionado: El proceso Ejecutado: de forma se planifica, ajusta a la Además de ser no se El proceso sistemática se se revisa y política de un procesorealiza, o no se ejecuta y procesos que definido se revisa y se evalúa modifica ose consiguen se logra su existe en la controla para cambia para sus objetivo. organización, utilizando comprobar adaptarlo a los objetivos. alineada con técnicas que cumple cuantitativas. objetivos del los las directivas negocio. requisitos. de la Mejora empresa. continua.
  13. 13. DIAGRAMA
  14. 14. COMPONENTES REQUERIDOSObjetivo genérico: Los objetivos genéricos asociadosa un nivel de capacidad establecen lo que unaorganización debe alcanzar en ese nivel de capacidad.Objetivo específico: Los objetivos específicos seaplican a una única área de proceso y localizan lasparticularidades que describen que se debeimplementar para satisfacer el propósito del área deproceso.
  15. 15. COMPONENTES ESPERADOS Práctica genérica: Una Práctica específica: Una práctica genérica se aplica práctica específica es unaa cualquier área de proceso actividad que se considera porque puede mejorar el importante en la realizaciónfuncionamiento y el control del objetivo específico al de cualquier proceso. cual está asociado.
  16. 16. COMPONENTES INFORMATIVOS Propósito Elaboraciones Notas de prácticas introductorias genéricas Ampliaciones Nombres de disciplina Tablas de relaciones Sub-prácticas práctica - objetivo Productos Prácticas típicos
  17. 17. Unidad 22.2 MARCO DE TRABAJO PARA EL PROCESO
  18. 18. INTRODUCCIÓN En esta sección es fácil denotar que el marco de trabajo es sobre el cual se trabajara, ya que contiene el conjunto de actividades a realizar, de la cual se desprenden tareas individuales.
  19. 19. PARTES DEL MARCO DE TRABAJO DEL PROCESO Despliegue: El Comunicación: Esta software se entrega actividad implica una al cliente, quien intensa colaboración y evalúa el producto comunicación con los recibido y clientes, abarcando la investigación de proporciona requisitos y otras información basada actividades relacionadas. en su evaluación. Planeación: Describe Construcción: las tareas técnicas Combina la que deben realizarse, generación del los riesgos probables, código y la los recursos que realización de serán requeridos, los pruebas necesarias productos del trabajo para descubrir que han de errores en el código. producirse y un Modelado: Abarca la programa de trabajo. creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que lograra satisfacerlos.
  20. 20. PARTES DEL MARCO DE TRABAJO DEL PROCESO (CONT.)Las actividades anteriores son útiles durante eldesarrollo de programas pequeños, la creación degrandes aplicaciones en la red, y en la ingeniería desistemas basados en computadoras grandes ycomplejas.Los detalles del proceso del software serán muydiferentes en cada caso, pero las actividades dentrodel marco permanecerán iguales.
  21. 21. ACTIVIDADES SOMBRILLASeguimiento y Preparación y Aseguramiento Revisiones Gestión de la control del Gestión del Gestión de la producción del de la calidad técnicas Medición configuración proyecto del riesgo reutilización producto de del software formales del software software trabajo
  22. 22. SEGUIMIENTO Y CONTROL DEL PROYECTO DEL SOFTWARE Permite que el equipo de software evalué el progreso comparándolo con el plan del proyecto y así tomar las acciones necesarias para mantener el programa.
  23. 23. GESTIÓN DEL RIESGO Evalúa los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto
  24. 24. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE Define y conduce las actividades requeridas para asegurar la calidad del software
  25. 25. REVISIONES TÉCNICAS FORMALES Evalúa los productos del trabajo de la ingeniería del software en un esfuerzo encaminado a describir y eliminar los errores antes de que estos se propaguen hacia la siguiente acción o actividad
  26. 26. MEDICIÓN Define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al equipo a entregar software que satisfaga las necesidades del cliente; se puede usar en conjunto con todas las otras actividades del marco de trabajo o actividades sombrilla
  27. 27. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE Maneja los efectos del cambio a través del proceso del software
  28. 28. GESTIÓN DE LA REUTILIZACIÓN Define los criterios para la reutilización de productos del trabajo y establece mecanismos para la creación de componentes reutilizables.
  29. 29. PREPARACIÓN Y PRODUCCIÓN DEL PRODUCTO DE TRABAJO Abarca las actividades requeridas para crear productos del trabajo como modelos, documentos, registros, formatos y listas.
  30. 30. Las actividades sombrilla se aplican en el proceso del software. La aplicación inteligente de cualquier modelo de proceso del software debe reconocer que laadaptación es esencial para el éxito de esta actividad.
  31. 31. El flujo global de actividades y tareas, y las interdependencias entre las actividades y las tareas. El grado en el cual El grado en el cual las tareas de trabajo están definidos la están definidas organización y las dentro de cada responsabilidades actividad del marco en el equipo. de trabajo. El grado de El grado en el cualautonomía otorgado se identifican y se al equipo de solicitan los proyectos de productos de software. Pero los trabajo. modelos de proceso difieren de manera fundamental en: La forma en la que El grado en el que se aplican las los clientes están actividades de comprometidos con aseguramiento de la el proyecto. calidad. La manera en la que El grado general de se aplican las detalle y el rigor con actividades de el que se describe el seguimiento y proceso. control.
  32. 32. Unidad 2 2.3 MODELOS DE LA INGENIERÍA DEL SOFTWARE: MODELO DE CASCADA, MODELO DE PROTOTIPOS,MODELO DE ESPIRAL, MODELO DE PROCESO UNIFICADO RACIONAL (RUP)
  33. 33. MODELOS DE LA INGENIERÍA DE SOFTWARE Para el caso de la ingeniería de software los modelos nos ayudan a poder realizar en orden una a una las tareas, esto se logra a través de un ciclo de vida el cual nos ayuda a poder visualizar cualquier evento de forma anticipada y así poder llegar a un fin determinado, lo cual nos dará el producto deseado.
  34. 34. MODELO DE CASCADA Mas que nada es un modelo que nos provee de lo que seria el control de las fechas de forma ordenada ya que muestra claramente la salida de una actividad y la entrada a la siguiente; también nos sirve a la gente con poca experiencia en el ramo, aunque presenta poca flexibilidad y no poder mostrar todo al cliente de forma anticipada y su impresión es lenta ante lo cual el cliente debe presentar paciencia.
  35. 35. MODELO DE CASCADA
  36. 36. MODELO DE PROTOTIPOS Versión preliminar de un sistema de información con fines de demostración o evaluación. En si es un modelo menos formal ya que en cierta manera se puede eliminar o se puede mejorar, y claro que es algo rápido pero suele crear falsas ilusiones al usuario con respecto al tiempo
  37. 37. MODELO DE PROTOTIPOS Identificación de Requerimientos Para construir los Revisar y Diseño Mejorar prototipos Rápido solo se necesita: Utilizar el Prototipo
  38. 38. MODELO EN ESPIRAL Un modelo que es cíclico en todo sentido ya que se repiten procesos de forma constante, lo cual beneficia ya que así se corrigen errores en el camino aunque tenga de defecto su dificultad y sobre todo el no saber cuando definir los limites y los objetivos.
  39. 39. MODELO EN ESPIRAL Validación del Pruebas de Prototipo Diseño Integración Análisis Prototipo de Riesgo Diseño del Requerimientos Producto Requerimientos del Software Plan de Validación de Prototipo Desarrollo Requerimientos
  40. 40. MODELO DE PROCESO UNIFICADO RACIONAL (RUP). Es un proceso de desarrollo que forma disciplinadamente la asignación de tareas y responsabilidades. Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para desarrollaran producto que sea acorde a los requisitos de los clientes y los usuarios.
  41. 41. Proveer un marco de trabajo para gestionar riesgos.Brinda una especificaciónde las herramientas quese van a necesitarencada momento, así Configuración y control decomo definir la instancia cambiosconcreta del proceso quese va a seguir. El control de cambios permite mantener la La finalidad de esta integridad de todos los actividad es dar soporte artefactos que se crean al proyecto con las en el proceso, así como adecuadas herramientas, de mantener información procesos y métodos. del proceso evolutivo que han seguido.
  42. 42. Unidad 22.4 TENDENCIAS MODERNAS DE MODELOS DE LA INGENIERÍA DEL SOFTWARE
  43. 43. XP (EXTREMA PROGRAMACIÓN) La XP empieza con Construye sobre ellos cuatro valores: una docena de comunicación, prácticas que los retroalimentación, proyectos XP deben simplicidad y coraje. seguir. Muchas de estas prácticas son técnicas Además de resucitar antiguas, tratadas y estas técnicas, la XP probadas, aunque a las teje en un todo menudo olvidadas por sinérgico dónde cada muchos, incluyendo la una refuerza a las mayoría de los demás. procesos planeados.
  44. 44. XP (EXTREMA PROGRAMACIÓN) [CONT.]En esta plataforma XP construye un proceso de diseñoevolutivo que se basa en refractora un sistema simple encada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada entre todas las metodologías adaptables.
  45. 45. XP (EXTREMA PROGRAMACIÓN) [CONT.] En el último par de Kent beck escribió años ha habido una extreme programming epidemia de libros explained, el manifiestoXP ha desarrollado un sobre xp brillantemente clave de la xp que liderazgo amplio, coloreados la mayoría Como resultado hay explica las razones muchos de ellos de los cuales son muchas fuentes para detrás de la provenientes del bastante similares en más información. metodología y bastanteproyecto fundamental que describen el explicación como para c3. proceso entero desde que la gente pueda el punto de vista de saber si se interesan varios seguidores en seguirla. tempranos.
  46. 46. LA FAMILIA DE CRISTAL DE COCKBURN Cada metodología encaja en una parte diferente de la reja, deEs una familia porque él Él mira esta variación a modo que para un cree que los tipos lo largo de dos ejes: el proyecto de 40 personasdiferentes de proyectos número de personas en que puede perder dinero requieren tipos el proyecto, y las discrecionalmente tiene diferentes de consecuencias de los una metodología metodologías. errores. diferente a la de un proyecto vital de seis personas.
  47. 47. Alistair considera que las personas encuentran difícil seguir un procesoLos cristales comparten con la disciplinado, así que más que seguir Él considera que aunque cristal XP una orientación humana, la alta disciplina de la XP, Alistair es menos productivo que la XP,pero esta centralización en la explora la metodología menos disciplinada que aun podría tener más personas serán capacesgente se hace de una manera éxito, intercambiando de seguirlo. diferente. conscientemente productividad por facilidad de ejecución.
  48. 48. Esto pone más énfasis en la gente supervisando su proceso y afinándolo conforme desarrollan. Su aserción es que el desarrolloiterativo está para encontrar los problemas temprano, y entonces permitir Alistair también corregirlos. pone mucho peso en las revisiones al final de la iteración, animando al proceso a ser automejorante.
  49. 49. CÓDIGO ABIERTO Sin embargo hay una manera En particular su definida de hacer proceso se las cosas haciendo engrana a equiposDespués de todo el en la comunidad de físicamente código abierto es código abierto, y distribuidos, lo qué un estilo de mucho de su es importantesoftware, no tanto acercamiento es porque la mayoría un proceso. tan aplicable a los de los procesos proyectos de adaptables exigen código cerrado equipos locales. como a los de código abierto.
  50. 50. La mayoría de los proyectos de código abierto tienen uno o más mantenedores.Un mantenedor es la única persona a la que se le permite integrar un cambio en el almacén de código fuente. Sin embargo otras personas pueden hacer cambios a la base del código. La diferencia importante es que estas otras personas necesitan enviar su cambio al mantenedor que entonces lo revisa y lo aplica a la base del código.Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso más fácil. El mantenedor así es responsable de coordinar los parches y mantener la cohesión en el diseño del software.
  51. 51. Proyectos diferentes manejan el papel del mantenedor de diferentesmaneras.Algunos tienen un mantenedor para el proyecto entero, algunos lodividen en módulos y tiene un mantenedor por módulo, algunos rolanel mantenedor, algunos tienen múltiples mantenedores sobre el mismocódigo, otros tienen una combinación de estas ideas.La mayor parte de la gente de código abierto son de tiempo parcial,así que hay una duda en qué tan bien se coordina un equipo así paraun proyecto de tiempo completo.
  52. 52. Un rasgo particular del desarrollo decódigo abierto Cuando También es es que la encuentran un bueno paradepuración es bug pueden gente sin mucha altamente enviar el parche destreza enparalelizable. al mantenedor. programación. Muchas Esto es un buen personas papel para los pueden no involucrarse en mantenedores el depurado. ya que la mayor parte del tiempo se gasta en encontrar bugs.
  53. 53. El proceso para el código abierto aun no se escribebien. La referencia más famosa es el artículo de EricRaymond the catedral and the bazar, que aunque esuna descripción excelente también es bastanteinformal.El libro de karl fogel sobre el almacén de código cvstambién contiene varios buenos capítulos sobre elproceso de código abierto que incluso seríaninteresantes para aquéllos que no quieren hacer unaactualización cvs.
  54. 54. EL DESARROLLO DE SOFTWARE ADAPTABLE DE HIGHSMITH Jim Highsmith ha pasado muchos años trabajando con metodologías predictivas. Él las desarrolló, instaló, enseñó, y concluyó que son profundamente defectuosas: particularmente para los negocios modernos. Su reciente libro se enfoca en la naturaleza adaptable de las nuevas metodologías, con un énfasis particular en aplicar las ideas que se originaron en el mundo de los sistemas complejos adaptables (normalmente conocida como teoría del caos.) No proporciona el tipo de prácticas detalladas como lo hace la XP, pero proporciona la basefundamental de por qué el desarrollo adaptable es importante y las consecuencias a los más profundos niveles de la organización y la gerencia.
  55. 55. En el corazón del ASD hay tres fases solapadas, no lineales: especulación, colaboración, yaprendizaje.Ve la planificación como una paradoja en un ambiente adaptable, ya que los resultados sonnaturalmente imprevisibles. En la planificación tradicional, las desviaciones del plan sonerrores que deben corregirse. En un el ambiente adaptable, sin embargo, las desviacionesnos guían hacia la solución correcta.En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se ponen deantemano y entonces se sigue ese diseño.En un ambiente adaptable, aprender desafía a todos - desarrolladores y sus clientes - aexaminar sus asunciones y usar los resultados de cada ciclo de desarrollo para adaptar elsiguiente.
  56. 56. Se enfoca directamente en fomentar las partesdifíciles del desarrollo adaptable, en particularcómo fomentar la colaboración y el aprendizajedentro del proyecto (XP, FDD y cristal).Como tal su libro ayuda a dar ideas parafomentar estas áreas "suaves" que hacen unbuen complemento a los acercamientosbasados en una práctica
  57. 57. SCRUMScrum ha estado durante algún tiempo Scrum divide un proyecto en en los círculos orientados a objetos, iteraciones (que ellos llaman carreras aunque confesaré que yo no estoy cortas) de 30 días. Antes de que muy al tanto de su historia o comience una carrera se define la desarrollo. De nuevo se enfoca en el funcionalidad requerida para esa hecho de que procesos definidos y carrera y entonces se deja al equipo repetibles sólo funcionan para atacar para que la entregue. El punto es problemas definidos y repetibles con estabilizar los requisitos durante la gente definida y repetible en carrera. ambientes definidos y repetibles.
  58. 58. La literatura de SCRUM se enfoca principalmente en la planeaciónTodos los días el equipo sostiene una iterativa y el seguimiento del proceso.junta corta (quince minutos), llamada Es muy cercana a las otrasSCRUM, dónde el equipo discurre lo metodologías agiles en muchos que hará al día siguiente. aspectos y debe funcionar bien con las prácticas de código de la xp.
  59. 59. DESARROLLO MANEJADO POR RASGOS Como las otras metodologías El desarrollo manejado por adaptables, se enfoca en rasgos (FDD por sus siglas en iteraciones cortas que entregan inglés) fue desarrollado por Jeff funcionalidad tangible. En el de Luca y el viejo gurú de la caso del FDD las iteraciones OO Peter Coad. duran dos semanas.
  60. 60. El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto. Construir Desarrollar una lista Planear Diseñar Construir un modelo de los por rasgo por rasgo por rasgo global rasgosLos últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se daun criterio de comprobación.
  61. 61. Los desarrolladores entran en dos tipos: dueños de clases y programadores jefe.Los programadores jefe son los desarrolladores más experimentados. A ellos se lesasignan rasgos a construir.Sin embargo ellos no los construyen solos.Solo identifican qué clases se involucran en la implantación de un rasgo y juntan alos dueños de dichas clases para que formen un equipo para desarrollar ese rasgo.El programador jefe actúa como el coordinador, diseñador líder y mentor mientraslos dueños de clases hacen gran parte de la codificación del rasgo.
  62. 62. DSDM (MÉTODO DE DESARROLLO DE SISTEMA DINÁMICO) El método empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si DSDM es apropiado para el proyecto.El estudio de negocio es una serie corta de talleres para entender el área de negocio dónde tiene lugar el desarrollo. También propone arquitecturas de esbozos del sistema y un plan del proyecto.
  63. 63. DSDM tiene principios El resto del proceso forma tres subyacentes que incluyen una ciclos entretejidos: el ciclo del interacción activa del usuario, modelo funcional produce entregas frecuentes, equipos documentación de análisis y autorizados, pruebas a lo largoprototipos, el ciclo de diseño del del ciclo. Como otros métodos modelo diseña el sistema para ágiles usan ciclos de plazos uso operacional, y el ciclo de cortos de entre dos y seis implantación se ocupa del semanas. Hay un énfasis en la despliegue al uso operacional. alta calidad y adaptabilidad hacia requisitos cambiantes.
  64. 64. MANIFIESTO PARA EL DESARROLLO DE SOFTWARE ÁGIL Con tanta similitud entre estos métodos, sería justo un poco de interés en alguna forma de trabajo colaborativo. Los representantes de cada una de estas metodologías fueron invitados a un taller de dos días en Snowbird, Utah en febrero de 2001.
  65. 65. Todos estábamos conscientesdel hecho de que había mucho en común, y este reconocimiento era mucho mayor que las diferencias entre los procesos. Además de un contacto útil entre los líderes de procesos,había también la idea de emitir una declaración conjunta.
  66. 66. COMPROBACIÓN DIRIGIDA POR EL CONTEXTODesde el principio han sido los desarrolladores de software quienes hanconducido a la comunidad ágil.Sin embargo muchas otras personas envueltas en el desarrollo de softwareson afectadas por este nuevo movimiento.Un grupo obvio es el de los verificadores que a menudo viven en un mundodominado por el pensamiento de cascada.Con pautas comunes que declaran que el papel de la comprobación esasegurar la conformidad del software con las especificaciones escritas deantemano, el papel de los verificadores en el mundo ágil esta lejos de serclaro.
  67. 67. En lo que se aclara eso, varias personas en lacomunidad de verificadores han estadocuestionando mucho de la corriente principal delpensamiento en comprobación por un tiempo ya. Esto ha llevado a un grupo conocido como la comprobación conducida por el contexto. La mejor descripción de esto es el libro lecciones aprendidas en comprobación de software. Esta comunidad es también muy activa en la web, eche una mirada a sitios organizados por Brian Marick (uno de los autores del manifiesto ágil), Brett Pettichord, James Bach, y Cem Kaner.

×