PDF de programación - Metodologia XP

UNIVERSIDAD NACIONAL EXPERIMENTAL DE LOS LLANOS

OCCIDENTALES EZEQUIEL ZAMORA

Ingeniería en Informática

Subproyecto: Metodología de Desarrollo del Software

Semestre VII

Bachilleres:
Bustamante Dayana C.I: 22.983.709
Rodríguez Jean C. C.I: 21.169.047



Barinas, Marzo del 2014









































INTRODUCCIÓN

las Metodologías Tradicionales,



Las metodologías de desarrollo de software son marcos o modelos de trabajos
que se utilizan para construir, planificar y controlar el proceso de desarrollo de
sistemas.

Hoy en día existen infinidades de metodologías para desarrollar software. Entre
ellas encontramos
las Metodologías
Iterativas/Evolutivas, las Metodologías basadas en Tecnología Web, y las
Metodologías Ágiles.

Mediante el siguiente trabajo nos enfocaremos en las Metodologías Ágiles, y se
profundizara en la XP (Programación Extrema), la cual pertenece a este grupo de
metodologías. A continuación, estudiaremos su origen, características, valores,
ventajas, desventajas, pasos y fases de desarrollo de la Metodología XP según su
creador Kent Beck (1999).

Además, se estudiara la normativa de calidad del software, y nos enfocaremos
en el modelo ISO 9126, el cual se enfoca en la calidad del producto que se
desarrollara.



























METODOLOGÌAS ÁGILES



Existen numerosas propuestas de metodología para desarrollar software.
Tradicionalmente estas metodologías se centran en el control del proceso,
estableciendo rigurosamente las actividades, herramientas y notaciones al
respecto, dado estas reglas estas metodologías se caracterizan por ser rígidos y
dirigidos por la documentación que se genera en cada una de las actividades
desarrolladas. Este enfoque no resulta ser el más adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se
exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta
calidad. En este escenario, las metodologías ágiles emergen como una posible
respuesta para llenar ese vacío metodológico.

Los objetivos de las metodologías ágiles, entre los cuales se destaca la
preferencia de algunos valores por sobre otros, por ejemplo: Individuos e
interacciones, sobre procesos y herramientas, Software operativo, sobre
documentación extensiva Y Colaboración con el cliente, sobre negociación de
Contratos.



METODOLOGÍA XP

Según Kent Beck 1999




ORIGEN DE LA METODOLOGÍA XP

La programación extrema o eXtreme Programming (XP) es una metodología de
desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer
libro sobre la materia, Extreme Programming Explained: Embrace Change (1999).
Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que
éstos, la programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la
marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de
proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en
cualquier punto de la vida del proyecto es una aproximación mejor y más realista
que intentar definir todos los requisitos al comienzo del proyecto e invertir
esfuerzos después en controlar los cambios en los requisitos. Se puede considerar
la programación extrema como la adopción de las mejores metodologías de
desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y
aplicarlo de manera dinámica durante el ciclo de vida del software.

Kent Beck, Creador de la Metodología XP





CARACTERÍSTICAS DE LA METODOLOGÍA XP


Se diferencia de las metodologías tradicionales principalmente en que pone

más énfasis en la adaptabilidad que en la previsibilidad.


Se aplica de manera dinámica durante el ciclo de vida del software.



Es capaz de adaptarse a los cambios de requisitos.



Los individuos e interacciones son más importantes que los procesos y

herramientas.


Al individuo y las interacciones del equipo de desarrollo sobre el proceso y

las herramientas.


La gente es el principal factor de éxito de un proyecto software. Es más
importante construir un buen equipo que construir el entorno. Muchas veces se
comete el error de construir primero el entorno y esperar que el equipo se adapte
automáticamente. Es mejor crear el equipo y que éste configure su propio entorno
de desarrollo en base a sus necesidades.


Software que funcione es más importante que documentación exhaustiva.



Desarrollar software que

funciona más que conseguir una buena

documentación.


La regla a seguir es no producir documentos a menos que sean necesarios de
forma inmediata para tomar una decisión importante. Estos documentos deben ser
cortos y centrarse en lo fundamental.


La colaboración con el cliente es más importante que la negociación de

contratos.


La colaboración con el cliente más que la negociación de un contrato.


Se propone que exista una interacción constante entre el cliente y el equipo de
desarrollo. Esta colaboración entre ambos será la que marque la marcha del
proyecto y asegure su éxito.


La respuesta ante el cambio es más importante que el seguimiento de un

plan.



VALORES DE LA METODOLOGÍA XP

Los Valores originales de
la programación extrema son: simplicidad,
comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue
añadido en la segunda edición de Extreme Programming Explained. Los cinco
valores se detallan a continuación:


SIMPLICIDAD:


La simplicidad es la base de la programación extrema. Se simplifica el diseño
para agilizar el desarrollo y facilitar el mantenimiento.

Un diseño complejo del código junto a sucesivas modificaciones por parte de
diferentes desarrolladores hace que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorización del código, ésta es la
manera de mantener el código simple a medida que crece.

También se aplica la simplicidad en la documentación, de esta manera el
código debe comentarse en su justa medida, intentando eso sí que el código esté
auto-documentado. Para ello se deben elegir adecuadamente los nombres de las
variables, métodos y clases. Los nombres largos no decrementan la eficiencia del
código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y
refactorización que existen actualmente.

Aplicando la simplicidad junto con la autoría colectiva del código y la
programación por parejas se asegura que cuanto más grande se haga el proyecto,
todo el equipo conocerá más y mejor el sistema completo.


COMUNICACIÓN:


La comunicación se realiza de diferentes formas. Para los programadores el
código comunica mejor cuanto más simple sea.


Si el código es complejo hay que esforzarse para hacerlo inteligible. El código
autodocumentado es más fiable que los comentarios ya que éstos últimos pronto
quedan desfasados con el código a medida que es modificado.

Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de
una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma
de comunicación ya que describen el diseño de las clases y los métodos al
mostrar ejemplos concretos de cómo utilizar su funcionalidad.

Los programadores se comunican constantemente gracias a la programación
por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte
del equipo de desarrollo. El cliente decide qué características tienen prioridad y
siempre debe estar disponible para solucionar dudas.


RETROALIMENTACIÓN (FEEDBACK):


Al estar el cliente integrado en el proyecto, su opinión sobre el estado del
proyecto se conoce en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se
minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a
los programador esa centrarse en lo que es más importante. Considérense los
problemas que derivan de tener ciclos muy largos.

Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios
del cliente o malentendidos por parte del equipo de desarrollo.

El código
las
herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el
estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite
descubrir fallos debidos a cambios recientes en el código.


fuente de retroalimentación gracias a

también es una

CORAJE O VALENTÍA:

todo

le permite a

lo demás del proyecto. La valentía


Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y
programar para hoy y no para mañana. Esto es un esfuerzo para evitar
empantanarse en el diseño y requerir demasiado tiempo y trabajo para
implementar
los
desarrolladores que se sientan cómodos con reconstruir su código cuando sea
necesario. Esto significa revisar el sistema existente y modificarlo si con ello los
cambios futuro