Xp Uniandes

DESARROLLO DE SOFTWAREAutora: Ing. Ana Luca Sandoval

EL SOFTWARE -LA INGENIERA DEL SOFTWAREQu es? Quin lo hace? Por qu es importante? Cules son los pasos? Cul es el producto final? Cmo me aseguro de que lo hice bien?

Dominios de aplicacin del software (Segn Roger Pressman)

Software de sistemasSoftware de aplicacinSoftware de ingeniera y cienciasSoftware incrustadoSoftware de lnea de productosAplicaciones web webappsSoftware de inteligencia artificial

Esta situacin resulta conocida??? Cmo me aseguro de que lo hice bien?

Plan Estratgico ITOInformation Technology Outsourcing

Contenido

Objetivos de la lneaMetas a mediano y largo plazoDefinicin de productos y serviciosEstrategias de mercado

Objetivos de la lnea

Proporcionar al mercado soluciones de aplicacin que permitan soportar adecuadamente los procesos de negocios de las empresas.

El soporte se brindar mediante la implantacin, integracin y operacin de productos de software propios o de terceros

Metas de mediano y largo plazo

Consolidar, ampliar y retener los servicios con clientes actuales.Posicionar a GMD como lder en servicios de software de aplicacin.Desarrollar e impulsar los servicios basados en la plataforma Oracle eBusiness Suite.Implantar soluciones basadas en productos Microsoft. Consolidar la relacin con los Partners EstratgicosTATAMicrosoftOracleDesarrollo de servicios conjuntos con el rea de consultora de GMD y con empresas consultoras

Definicin de productos

Integracin de productos de terceros (IPT)Implantar soluciones de software de aplicacin especializadas integrando a nuestros partners de negocio. Ej: sw para plataforma de atencin bancaria, solucin de salud para clnicas, etc.Soluciones Microsoft (SM)Utilizacin de productos Microsoft para implantacin de soluciones de aplicacin especficas:Go to Markets (GTM)Connected systemsPortalsEnterprise Project Management (EPM)Servicios de aplicacin (ASP)Utilizacin de productos de software (propio o de terceros) para brindar servicios de aplicacin (e-business suite de Oracle principalmente)Software integral (ERP)Implantacin de e-business suite de Oracle

Estrategias de Mercado

ESTRATEGIAS GENERALES

Base instalada FortalecimientoIdentificar necesidades asociadas o relacionadas a contratos actuales.Identificar necesidades no cubiertas en las que encajen los productos definidos.ProspectosIniciar labores de venta en cuentas con necesidades identificadas para concretar plan definido.MercadoIdentificar potencial de mercadoDefinir potencial a atacar (mapeo especfico de clientes potenciales)Acciones de penetracinPreparacin de material de ventaMaterial de presentacin de productos y serviciosPresentaciones de ventaCursos de entrenamiento (recursos de partners)Marketing directo a clientes potencialesPresentaciones especficas de productos y servicios a potenciales clientesDesayunos de trabajo con posibles clientes

Organizacin

Un software que realiza lo que el usuario desea, cuando lo requiera.Por ello se busca un software totalmente confiable y sin errores.Si los errores detectados en las etapas de implementacin y prueba resulta mucho ms costoso que detectarlos en las etapas tempranas de diseo, codificacin o en la etapa de anlisis. La solucin ms simple es:Una especificacin de requerimientos no ambigua, completa, verificable, consistente, modificable, trazable, utilizable.Para lograrlo existen varias metodologas como lo son:XP y Rup que ofrecen formatos para realizar una correcta especificacin.

Metodologa gil

Metodologa gilLas metodologas giles forman parte del movimiento de desarrollo gil de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de xito de un proyecto.

Contenido


Organizacin

Metodologa gilEl Manifiesto de la metodologa gil:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.Desarrollar software que funciona ms que conseguir una buena documentacin.La colaboracin con el cliente ms que la negociacin de un contrato.Responder a los cambios ms que seguir estrictamente un plan.

Es importante la derecha pero valoramos ms la izquierda

Contenido


Organizacin

Qu es una Metodologa gil?Las Metodologas giles (MAs) valoran:Al individuo y las interacciones en el equipo de desarrollo ms que a las actividades y las herramientas

Desarrollar software que funciona ms que conseguir una buena documentacin Minimalismo respecto del modelado y la documentacin del sistema

La colaboracin con el cliente ms que la negociacin de un contrato

Responder a los cambios ms que seguir estrictamente una planificacin

Por qu surgen las Metodologas giles?Dificultades para implantar metodologas tradicionales. Procesos ceremoniosos, herramientas CASE y notaciones de modelado sofisticadas (UML)

Una solucin a medida para un segmento importante de proyectos de desarrollo de software

Pugna entre comunidades/gurs

Aceptar el cambio ...

Cundo utilizar una Metodologa gil?Tienes ya un proceso? Noexiste pero no reacciona bien a los cambiosexiste pero el equipo no est contento con l

Una Metodologa gil puede ser una buena forma de empezarNo involucra gran inversinA los programadores les (suele) gustarA los clientes les ofrece mayor visibilidad y menor riesgo en el proyecto

Comparacin gil v/s Tradicional

Metodologa gilMetodologa TradicionalPocos Artefactos. El modelado es prescindible, modelos desechables.Ms Artefactos. El modelado es esencial, mantenimiento de modelosPocos Roles, ms genricos y flexiblesMs Roles, ms especficos No existe un contrato tradicional, debe ser bastante flexibleExiste un contrato prefijadoCliente es parte del equipo de desarrollo (adems in-situ)El cliente interacta con el equipo de desarrollo mediante reunionesOrientada a proyectos pequeos. Corta duracin (o entregas frecuentes), equipos pequeos (< 10 integrantes) y trabajando en el mismo sitioAplicables a proyectos de cualquier tamao, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersosLa arquitectura se va definiendo y mejorando a lo largo del proyectoSe promueve que la arquitectura se defina tempranamente en el proyecto nfasis en los aspectos humanos: el individuo y el trabajo en equipo nfasis en la definicin del proceso: roles, actividades y artefactosSe esperan cambios durante el proyectoSe espera que no ocurran cambios de gran impacto durante el proyecto

Programacin Extrema

Antecedentes e Historia de Programacin extrema

Sin embargo, se reconoce a Kent Beck como el que articul esta propuesta y le dio nombre propio. Kent BeckEn 1989, Cunningham form un equipo que usaba los principios y muchas de las prcticas que despus adoptara XP, mientras trabajaba para la compaa Wyatt Software [Fowler 2000].Antecedentes e Historia de Programacin extrema

Posteriormente, la consolidacin de XP se logra con la publicacin del libro Extreme Programming Explained: embrace change en el ao 1999, donde Beck resume su propia experiencia y le da forma y nombre a la entonces nueva metodologa de desarrollo de software, la cual le vali el premio: Software Development Jolt Product Excellence. Antecedentes e Historia de Programacin extrema

Chrysler Corporation haca tiempo que estaba desarrollando una aplicacin de nminas, pero sin demasiado xito por parte de la gente que tena en el proyecto. El verano de 1996, Beck entr en nmina en la compaa y se le pidi de hacer esta aplicacin como trabajo. Es en esta aplicacin cuando nace la Programacin Extrema como tal.Antecedentes e Historia de Programacin extrema

Antecedentes e Historia de Programacin extremaLas ideas primordiales de su sistema las comunic en la revista C++ Magazine en una entrevista que sta le hizo el ao 1999. En sta deca que l estaba convencido que la mejor metodologa era un proceso:Que enfatizase la comunicacin del equipo.Que la implementacin fuera sencilla.Que que el usuario tena que estar muy informado e implicado.Que la toma de decisiones tena que ser muy rpida y efectiva.

Los autores de la Programacin Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que tenan y en cada pgina que, poco o mucho hablara de temas de programacin.Antecedentes e Historia de Programacin extremaPortland Pattern Repository

Qu es XP?

Que es XP?La programacin extrema es una metodologa de desarrollo ligera basada en una serie de valores y una docena de prcticas que propician un aumento en la productividad a la hora de generar software.XP permite controlar los problemas de riesgo en los proyectos. XP permite la participacin de pequeos grupos de programadores. XP requiere un variado equipo de desarrollo. XP permite la capacidad de hacer pruebas La meta real de XP es entregar el software requerido a tiempo.

Caractersticas de XPLas caractersticas generales de XP es deliberadamente una metodologa liviana que pasa por alto la utilizacin de elaborados casos de uso, la exhaustiva definicin de requerimientos y la produccin de una extensa documentacin. Todo lo anterior puede parecer catico segn el enfoque tradicional de la ingeniera de software, aunque no hay que olvidar que XP tiene asociado un ciclo de vida y es considerado a su vez un proceso. La tendencia de entregar software en lapsos cada vez menores de tiempo y con exigencias de costos reducidos y altos estndares de calidad, hace que XP sea una opcin a considerar.

Principios, roles y prcticas de Programacin extrema

Principios de la Programacin extremaSe busca :Realimentacin rpidaAsumir la simplicidadCambio incrementalAceptar el cambioHacer trabajo de calidad.

Principios de la Programacin extremaLas Prcticas son:1. El juego de la planificacin2. Pequeas entregas3. Metfora4. Diseo simple 5. Pruebas6. Refactorizacin

7. Programacin por parejas8. Propiedad colectiva9. Integracin continua10. 40 horas semanales 11. Cliente en casa12. Estndares de codificacin

Juego de la planificacin

El alcance de la siguiente versin esta definido por las consideraciones de negocios (prioridad de los mdulos, fechas de entrega) y estimaciones tcnicas (estimaciones de funciones, consecuencias).

Pequeas entregas

Un sistema simple se pone rpidamente en produccin. Peridicamente, se producen nuevas versiones agregando en cada iteracin aquellas funciones consideradas valiosas para el cliente.

Pruebas Continuas (Testing) Los casos de prueba se escriben antes que el cdigo. Los desarrolladores escriben pruebas unitarias y los clientes especifican pruebas funcionales.

Refactorizacin (Refactoring) Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo eliminando cdigo duplicado, simplificando funciones, Mejorando el cdigo constantemente, si el cdigo se esta volviendo complicado se debera modificar el diseo y volver a uno ms simple. Refactoring (Modificar la forma del cdigo sin cambiar su funcionamiento).

Programacin por parejas (Pair Programming) El cdigo es escrito por dos personas trabajando en el mismo computador. "Una sola mquina con un teclado y un mouse"

Objetivos de la Programacin extrema

Objetivos de XPSon:La satisfaccin del cliente.Potenciar el trabajo en grupo, todos estn involucrados en el desarrollo del software.

Interaccin entre Las cuatro variablesde Gestin de proyecto

Permite mejorar la calidad, siempre que resuelva el problema bsico del cliente. Tambien permite reducir plazo y coste. La herramienta ms potente de gestin (*)

Si poco, sufrir la calidad e inmediatamente detrs el alcance, el tiempo y el coste.

Con poco dinero ser imposible resolver los problemas del cliente.

Variable terrible de control. Se puede sacrificar para obtener ganancias a corto, pero los costes posteriores son enormes (humanos, de negocio ytcnicos).

Insistir en mayor calidad permite conseguir plazos menores o hacer ms en un tiempo dado. Efecto humano: se trabaja mejor si se siente que se hace un buen trabajo.

Ms dinero puede engrasar el sistema, pero en exceso puede crear ms problemas que los que resuelve.

Ms puede mejorar calidad y alcance, pero en exceso puede daar, pues la mejor realimentacin viene del sistema en produccin.

Si aumenta en exceso...

Si se reduce...

Variable

Alcance

Tiempo

Coste

Calidad

El coste de CambioEl coste de los cambios crece con el tiempo.

XP propone que los costes de los cambios no tienen por que aumentar con el tiempo.

COSTE

TIEMPO

COSTE

TIEMPO

Las cuatro valoresValores para desarrollar software:

ComunicacinSencillezRetroalimentacinValenta.

Roles de XPClienteEscribe Historias de Usuario y especifica Pruebas Funcionales. Establece prioridades, explica las HistoriasPuede ser o no un usuario finalTiene autoridad para decidir cuestiones relativas a las Historias.ProgramadorHace estimaciones sobre las HistoriasDefine Tareas a partir de las Historias y hace estimacionesImplementa las Historias y las Pruebas Unitarias

Roles de XPTutorObserva todo, identifica seales de peligro, se asegura que el proyecto se mantiene en cursoAyuda en todoDa avisos cuando se necesita.

Perseguidor (calidad)Monitoriza el progreso de los programadores, toma accin si las cosas tienden a salirse de su senda.Las acciones incluyen reuniones con el Cliente, solicitar ayuda al Tutor u otro Programador.

Roles de XP VerificadorImplementa y corre las Pruebas Funcionales (no Pruebas Unitarias)Presenta grficas de los resultados y se asegura de que la gente conoce cundo los resultados empiezan a decaer. AgoreroSe asegura que todos conocen los riesgos que existen Se asegura que las malas noticias no se ocultan, se disculpan o se reducen de proporcin.

Roles de XP GestorPlanifica las reuniones (por ej., plan de iteraciones, plan de lanzamientos releases), se asegura que el proceso de las reuniones se sigue, anota los resultados de la reunin para futuros informes y los pasa al Perseguidor.Posiblemente responsable ante el Propietario de OroAsiste a las reuniones, aporta informacin til anterior.Propietario de OroLa persona que paga el proyecto, que puede ser o no la misma que el Cliente.

Las cuatro actividades bsicasCodificarHacer pruebasEscucharDisear.

Proceso de Desarrollo

Artefactos esenciales en XPHistorias del UsuarioTareas de IngenieraPruebas de Aceptacin

Pruebas Unitarias y de IntegracinPlan de la EntregaCdigo

Historia de Usuario

Historia de Usuario Nmero: 1 Nombre: Enviar artculo Usuario: Autor Modificacin de Historia Nmero: Iteracin Asignada: 2 Prioridad en Negocio: Alta (Alta / Media / Baja) Puntos Estimados: Riesgo en Desarrollo: (Alto / Medio / Bajo) Puntos Reales: Descripcin: Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artculo.

Observaciones:

Tarea de Ingeniera

Tarea Nmero tarea: Nmero historia: Nombre tarea: Tipo de tarea : Desarrollo / Correccin / Mejora / Otra Puntos estimados: Fecha inicio: Fecha fin: Programador responsable: Descripcin:

Prueba de Aceptacin

Caso de Prueba Nmero Caso de Prueba: Nmero Historia de Usuario: Nombre Caso de Prueba: Descripcin:

Condiciones de ejecucin:

Entradas:

Resultado esperado: Evaluacin:

Escenarios en XP : ExploracinPrioridadRiesgoEsfuerzo (puntos)DefinirHistorias de UsuarioElaborarSpikesEstimar Esfuerzo y Riesgo?

Escenarios en XP: Planificacin de la EntregaHistorias de UsuarioPrimeraIteracinSegundaIteracinltimaIteracinN-simaIteracinHistoriasfuera de laentregaVelocidad de Proyecto (VP)puntos/semanaEntrega

Escenarios en XP : Comenzar IteracinHistorias de laIteracinDefinir y ordenarTareas deIngenieraTareas de la iteracin

Escenarios en XP : ProgramacinPruebas deAceptacinde Historias de la iteracinProgramacinen ParejasHistorias de laIteracinVersin delProductoDiseoRefactoringProgramacinPruebas UnitariasIntegracinPruebas de IntegracinPruebas de Aceptacin

Escenarios en XP : Pruebas de AceptacinPruebas deAceptacinDefinir Pruebasde AceptacinAplicar Pruebasde AceptacinCorregir erroresDefinir nuevas Historias

Entorno y clima de trabajo Espacio de trabajo XPEspacio abiertoMesas centralesCubculos en el espacio exteriorEspacio de trabajo del proyecto C3 de DaimlerChrysler

Reunin diaria: Stand-up Meeting Todo el equipoProblemasSoluciones

De pie en un crculo Evitar discusiones largas Sin conversaciones separadas Entorno y clima de trabajo Reunin diaria XP

Entorno y clima de trabajo Gantt de ParedObtenida de www.agiletek.comCentro del universo del proyecto

Punto de reunin para la Stand-up Meeting

Fases de la metodologa XP

Como hacemos funcionar la Metodologa XP

Contenido


Organizacin

DISEO

CODIFICACION

PRUEBA

Historias del usuario

PLANIFICACION

valores

Criterios de las pruebas de iteracin

Plan de iteracin

Diseo simple

Programacin en pareja

prototipos

Cartas CRC

Integracin continua

Prueba de unidad

Pruebas de aceptacin

Incremento de software Velocidad calculada del proyecto

Lanzamiento

recodificacin

Soluciones pico

PlanificacinXP plantea la planificacin como un permanente dialogo entre las partes la empresarial (deseable) y la tcnica (posible). deseableposible

Contenido


Organizacin

Planificacin.1 El Juego de la PlanificacinNegociombito Qu debe resolver el software?Prioridad Qu debe ser echo en primer lugar?Composicin de versiones Cunto es necesario hacer para aportar valor?Fechas de versiones Fechas para presencia del software?

Contenido


Organizacin

Planificacin.1 El Juego de la PlanificacinTcnico.Estimaciones Cunto lleva implementar una caracterstica?Consecuencias, informar sobre consecuencias de las decisiones que adopta el negocio.Procesos Cmo se organiza el trabajo en el equipo?Programacin detallada: En una versin Qu se resolver primero?

Contenido


Organizacin

Planificacin.2 Pequeas versiones.Cada versin debe de ser tan pequea como fuera posible, conteniendo los requisitos de negocios ms importantes, las versiones tiene que tener sentido como un todo..3 Metfora.Es una historia que todo el mundo puede contar a cerca de cmo funciona el sistema.

Contenido


Organizacin

Diseo.4 Diseo simple.El diseo adecuado par el software es aquel que:Funciona con todas las pruebas.No tiene lgica duplicada.Manifiesta cada intencin importante para los programadores Tiene el menor nmero de clases y mtodos.

Contenido


Organizacin

Codificacin.5 Recodificacin.Este proceso se le denomina recodificar o refactorizar (refactoring).y consiste en hacer el programa mas simple sin perder funcionalidad. No debemos de recodificar ante especulaciones si no solo cundo el sistema te lo pida.

Contenido


Organizacin

Codificacin.6 Programacin por parejas.Todo el cdigo de produccin se escribe con dos personas mirando a una mquina, con un solo teclado y un solo ratn.Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratgicamente, Va a funcionar?, Puede haber pruebas donde no funcione?, Hay forma de simplificar el sistema global para que el problema desaparezca?.

Contenido


Organizacin

Codificacin.7 Propiedad Colectiva.Cualquiera que crea que puede aportar valor al cdigo en cualquier parcela puede hacerlo, ningn miembro del equipo es propietario del cdigo.

.8 Integracin contina.El cdigo se debe integrar como mnimo una vez al da, y realizar las pruebas sobre la totalidad del sistema.

Contenido


Organizacin

Codificacin.9 Cuarenta horas.Si queremos estar frescos y motivados cada maana y cansado y satisfecho cada noche. del sistema.

.10 Cliente In Situ.Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades.

Contenido


Organizacin

Codificacin.11 Estndares de Codificacin.Se debe establecer un estndar de codificacin aceptado e implantado por todo el equipo.

Contenido


Organizacin

Pruebas.12 Hacer pruebas.Toda caracterstica en el programa debe ser probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que soporte cambios en el tiempo.

Contenido


Organizacin

El juego de la planificacinEntregas pequeasMetforaDiseo simple RecodificacinProgramacin en parejasPropiedad colectivaIntegracin continuaSemana de 40 horasCliente in situEstndares de programacinPruebasPrcticas XPDISEOCODIFICACIONPLANIFICACIONPRUEBAS

Prcticas XPInteraccin entre PrcticasXP: Kent BeckCliente in situMetforaPropiedad ColectivaIntegracin ContinuaEl juego de la planificacinSemana de 40 horasProgramacin en parejasRecodificacinEstndares deprogramacinPruebasDiseo simplePequeas versiones

Aspectos sobre Programacin Extrema

Aspectos Positivos De Xp Pruebas unitarias en el cdigo factor clave para obtener un software de alta calidad.

La integracin continua es aceptada y recomendada para evitar catstrofes ocasionadas por defectos no detectados a tiempo.

la simplicidad y la refabricacin es encontrado como un factor saludable en la prctica de programacin.

El enfoque extremadamente humano, siendo este un aspecto que el resto del campo del software debera tratar de emular.

Cliente tambin se percibe el enfoque humano, ya que tenemos su presencia constante en las instalaciones del desarrollador.

Aspectos Controversiales de Xp La XP se ha afirmado que no es la metodologa que va a resolver todos los problemas en IS y se han resaltado sus limitaciones. No es aconsejable XP si no es posible disminuir la curva costo/tiempo.Tampoco si la tecnologa o el entorno no permiten realizar integraciones frecuentes o realizar pruebas continuamente. No se recomienda intentar XP si la distribucin fsica impide la programacin en pares o si no todos los programadores se encuentran en el mismo sitio.

Desalienta el diseo, que es dbil en la documentacin, que el modelo no aplica para proyectos donde la seguridad es crtica.Exceso de pruebas retrasa el desarrollo, el diseo simple solo aplica a proyectos simples, que la programacin en pares consume mayor tiempo y recursos.XP asume implcitamente que siempre se utiliza el enfoque de programacin orientada a objetos.Aspectos Controversiales de Xp

La refabricacin, como sinnimo de rediseo constante y que se puede tomar como una excusa para relegar hasta el ltimo minuto el diseo.La planeacin, segn algunos crticos, no debera hacerse sobre la marcha como parece recomendar XP.La programacin en pares. Se argumenta que no cualquier clase de programador desea trabajar de esta manera.Beneficios, tales como: producir menos defectos, aumentar la productividad, elevar la moral del equipo, mejorar la confianza y el trabajo en equipo, naturalidad en la transferencia del conocimiento y favorecer el aprendizaje.

Aspectos Controversiales de Xp

Posturas A Favor Y En Contra

0

10

20

30

40

50

60

Lo he probado y no me gusta nada

Es una mala idea, no puede funcionar nunca

Es una buena idea, pero no funcionar

Lo he probado y me gusta mucho

Extrapolacin De Las Prcticas De Xp XP adecuada para proyectos de software pequeos o cuando mucho medianos.

Diseo al inicio: Aqu se recomienda un buen diseo inicial (up-front) que respalde al proyecto.

Se producen funcionalidades completas en cada iteracin (entrega) durante el ciclo del software. El tiempo entre cada entrega es corto.

Extrapolacin De Las Prcticas De Xp (Cont..I)Se simula al cliente en las instalaciones, en lugar de ser un cliente real como dice XP, este rol lo asume alguien con experiencia.

Programacin en pares flexible. Se modifica la prctica de XP y en lugar de ser obligatoria para todo el cdigo que se escribe.

Seleccin y administracin del equipo de desarrollo. Se buscan diferentes habilidades y experiencias en los programadores.

BENEFICIOSSatisfaccin del cliente.Cumplimiento de plazos.El cliente tiene el control sobre las prioridades.Se hacen pruebas continuas durante el proyecto.Calidad en el trabajo.La XP es mejor utilizada en la implementacin de nuevas tecnologas donde los requerimientos cambian rpidamente.

CONCLUSIONES La programacin extrema es una forma ligera, eficiente, flexible, predecible, cientfica y divertida de generar software.

La programacin extrema se beneficia de la existencia de un gran nmero de herramientas de software libre que permiten aplicarla con gran productividad.

El software libre se inspira en algunas de las prcticas de la XP .

CONCLUSIONES Cont.. (II)Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado, evitando que se desmoralice por no sabe como preparar pruebas de aceptacin.

El proceso de desarrollo de las pruebas ayuda al cliente a clarificar y concretar la funcionalidad de la historia de uso y favorece la comunicacin entre el cliente y el equipo de desarrollo.

El desarrollo de pruebas ayuda identificar y corregir fallos u omisiones en las historias de uso.

CONCLUSIONES Cont.. (III)Permite corregir errores en las ideas del cliente, por ejemplo encontrando resultados que el cliente espera encontrar en la implementacin.

Permite identificar historias adicionales que no fueran obvias para el cliente o en las que cliente no hubiese pensado de no enfrentarse a dicha situacin.

Garantiza la cobertura de la funcionalidad de las pruebas de aceptacin, garantizando que no se deja ningn punto importante de la funcionalidad de una historia de uso sin probar.

RECOMENDACIONES Algunas prcticas podrn ser controversiales y hasta contraproducentes fuera de un dominio especfico. Las metodologas giles se recomiendan. Para proyectos y equipos pequeos.Requerimientos cambiantes (enfoque evolutivo).Equipo de desarrollo competente.Cliente dispuesto a participar con el equipo. El proceso como una manera de agilizar el Proceso Unificado, combinndolo con la XP.

BIBLIOGRAFAUna explicacin de la Programacin extrema: aceptar el cambio Autor: Kent Beck. Publicado: Addison-Wesley Iberoamericana Espanya, S.A. 2002.La Programacin Extrema en la prctica Autor: James Newkirk, Robert C. Martin. Publicado: Addison-Wesley Iberoamericana Espanya, S.A. 2002.Extreme Programming Installed. Autor: Ron Jeffries, Ann Anderson, Chet Hendrickson, Ronald E. Jeffries. Publicado: Addison-Wesley Pub Co; 1 edicin (13 Octubre 2000).Extreme Programming Explained: Embrace Change. Autor: Kent Beck.Publicado: Addison-Wesley Pub Co; 1 edicin (5 Octubre 1999).

BIBLIOGRAFA Extreme Programming Pocket Guide. Autor: chromatic. Publicado: O'Reilly & Associates; 1 edicin (Junio 2003).Extreme Programming Refactored: The Case Against XP. Autor: Matt Stephens, Doug Rosenberg. Publicado: APress; (1 Enero 1970).Planning Extreme Programming. Autor: Kent Beck, Martin Fowler. Publicado: Addison-Wesley Pub Co; 2000

Referencias WebSitio Extreme Programming: A Gentle Introduction. www.extremeprogramming.org Secciones Artculos y Roadmap del sitio de la Agile Alliance. www.agilealliance.orgSitio Xprogramming, mantenido por Ron Jeffries. www.xprogramming.comWikiWiki de Extreme Programming http://c2.com/cgi/wiki?ExtremeProgrammingRoadmapRevista electrnica Software Development. www.sdmagazine.comNmero monogrfico de revista CrossTalk: Agile Software Development. www.stsc.hill.af.mil/crosstalk/2002/10/Una extensiones de XP, Agile+. www.agiletek.comSitios de modelado gil, mantenidos por Scott W. Ambler. www.agilemodeling.com y www.agiledata.orgRefactoring, mantenido por Martin Fowler. www.refactoring.comPruebas en contexto gil, www.junit.org International Conference on eXtreme Programming and Agile Methods in Software Development (XP200x) http://www.xp2004.orgXP Agile Universe http://www.agileuniverse.com

GRACIAS

**************************CN*CS*CN Y CE*CS CN*CN Y CS*

Xp Uniandes

Documents

Transcript of Xp Uniandes