ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

PROGRAMACION EXTREMA XP


Enviado por   •  9 de Septiembre de 2015  •  Trabajo  •  4.097 Palabras (17 Páginas)  •  156 Visitas

Página 1 de 17

Tutor :

Eddie Morris

Integrantes :

José Vicente Hernández

Luis Carrasco

David Cruz Roncal

David Velazco Infante

Fecha:

Lima,14 de junio del 2003

[pic 1][pic 2][pic 3]


INDICE

BREVE RESEÑA HISTORICA        

INTRODUCCION        

LOS CUATRO PRINCIPIOS        

Comunicación        

Retroalimentación        

Simplicidad        

Osadía        

LAS DOCE PRACTICAS        

Juego de Planeamiento (Planning Game)        

Lanzamientos de corto alcance (Small Release)        

Metáfora (Metaphor)        

Diseño Simple (Simple Design)        

Pruebas (Testing)        

Refabricación (Refactoring)        

Programación en Pares (Pair Programming)        

Propiedad Colectiva (Collective Ownership)        

Integración Continua (Continuous Integration)        

Semana de 40 horas (40-Hours Week)        

Cliente en el Lugar (On-site Customer)        

Standard de Código (Coding Standard)        

Flujo de un Proyecto a través de las 12 prácticas        

CICLO DE DESARROLLO        

Especificación de Usuario (User Stories)        

Plan de Lanzamiento (Release Plan)        

Secuencia de Desarrollo o Iteración (Iteration)        

Plan de Secuencia de Desarrollo o Iteración (Iteration Plan)        

Desarrollo (Development)        

Reunión de Inicio del desarrollo (StandUp Meeting)        

Propiedad colectiva del código (Collective Code Ownership)        

Pruebas de Aceptación (Acceptance Test)        

Pruebas Unitarias        

Pruebas Funcionales        

FINALIDADES DE LOS FACTORES DE ÉXITO EN LA GP DEL PMI:        

FACTORES CRÍTICOS DE ÉXITO EN GP        

REFERENCIAS        

SOBRE PROGRAMACION EXTREMA        

SOBRE FACTORES CRITICOS DE EXITO        

ANEXO        


PROGRAMACION EXTREMA XP

BREVE RESEÑA HISTORICA

Entre los años 1986 y 1996 Kent Beck y Ward Cunningham investigaron acerca de las mejores formas de desarrollar software en Tektronix. [pic 4]

Juntos, Ward y Kent, habían experimentado con un método de desarrollo que hacia que todo pareciera simple y más eficiente.

Kent se concentro en separar las cosas que hacían simple el desarrollo del software y las cosas que lo hacían más difícil. Entre ellas encontró una serie de buenas prácticas como son la refactorización, programación por parejas, cambios rápidos, feedback constante del cliente, integración continua, desarrollo iterativo, prueba constante, etc. que son todos elementos de su cultura que adquirió en el desarrollo sobre Smalltalk.

En marzo de 1996 Kent empezó un proyecto en usando nuevos conceptos en el desarrollo de software. El resultado fue la “Metodología de la Programación Extrema”.

        

INTRODUCCION

La programación extrema es una metodología ágil de desarrollo de software. Sigue la filosofía de las metodologías “Lightweight”, es decir su objetivo es simplificar al máximo las tareas de ingeniería. Como posee sólo unas pocas reglas y técnicas todas ellas fáciles de seguir y entender, no necesita mucha práctica para seguirla correctamente.

Esta metodología se basa en una serie de principios y una docena de prácticas que propician un aumento en la productividad a la hora de desarrollar software, es decir son aquellas en la que dan prioridad a las tareas que dan resultados directos y que reducen la burocracia que hay alrededor tanto como sea posible.

Debido a que XP esta basada en la programación  iterativa y a otras practicas como la “propiedad colectiva” y la “integración continua” el costo del cambio  no varía a través del tiempo como lo demuestra la figura que se muestra a continuación.

[pic 5]


LOS CUATRO PRINCIPIOS

La programación extrema es una disciplina ligera para el desarrollo de software basada en  los principios de simplicidad (simplicity), comunicación (communication), retroalimentación (feedback), osadía (courage), principios que pasamos a desarrollar:

Comunicación

XP involucra comunicación extrema. El cliente tiene que hacerse parte del equipo de trabajo, haciendo la definición de los requerimientos, permitiendo producir versiones cada 2 a 4 semanas. Esto permite también que, si el programador necesita aclarar algo en los requerimientos, se reúne con el equipo de trabajo y se resuelven sus dudas.

...

Descargar como (para miembros actualizados) txt (27 Kb) pdf (505 Kb) docx (1 Mb)
Leer 16 páginas más »
Disponible sólo en Clubensayos.com