ANÁLISIS DE REQUERIMIENTOS

DEFINICIÓN:

Requerimientos: Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.

La captura y el análisis de los requerimientos del sistema es una de las fases más importantes para que el proyecto tenga éxito. Como regla de modo empírico, el costo de reparar un error se incrementa en un factor de diez de una fase de desarrollo a la siguiente, por lo tanto la preparación de una especificación adecuada de requerimientos reduce los costos y el riesgo general asociado con el desarrollo [Norris & Rigby, 1994].

Análisis de requerimientos: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es una tarea de ingeniería del software que permite especificar las características operacionales del software, indicar la interfaz del software con otros elementos del sistema y establecer las restricciones que debe cumplir el software.

MOLDEAMIENTO DEL NEGOCIO:

Modelo del Caso de Uso del Negocio:El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos. Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado específico para un cliente o el mercado. Debe haber un enfoque a la lógica del negocio de dicho proceso, desde la perspectiva del producto. El modelo de Casos de Uso del Negocio es un modelo que describe los procesos de un negocio (casos de uso del negocio) y su interacción con elementos externos (actores), tales como socios y clientes, es decir, describe las funciones que el negocio pretende realizar y su objetivo básico es describir cómo el negocio es utilizado por sus clientes y socios. 

Modelo de Objetos del Negocio:Un modelo de datos es una vista de datos analíticos que tiene una correspondencia de uno a uno con un modelo de objetos de negocio (MON) en IBM® Operational Decision Manager. Un MON especifica los elementos de negocio y el vocabulario utilizado para definir las reglas de negocio. El vocabulario permite a los usuarios crear reglas de negocios sin tener conocimientos de cómo se estructuran los datos a los que se refieren las reglas.

Una regla de negocio tiene el formato "si criterios entonces resultado". Por ejemplo, una decisión sobre si rechazar o no una aplicación de préstamo basándose en la capacidad de endeudamiento del aspirante corresponde a la siguiente regla de negocio:

Si la capacidad de endeudamiento del aspirante es menor

a 300 entonces rechace la aplicación.

El aspirante es la entidad de negocios en la que se basa esta regla. La capacidad de endeudamiento del aspirante es la entidad del atributo en el que se realza la decisión. El modelo de objetos de negocio debe incluir un elemento que represente al aspirante y, dicho elemento, debe incluir un atributo que corresponda a la capacidad de endeudamiento. El modelo también especifica el vocabulario utilizado para hacer referencia a los elementos del modelo en las reglas. En este caso el vocabulario incluye "capacidad de endeudamiento del aspirante".

Estructuralmente, el modelo de objetos de negocio es similar al modelo de objeto Java. Las entidades de negocios corresponden a una clase y pueden agruparse en paquetes. Las clases pueden anidarse en otras clases. Los atributos de la entidad corresponden a atributos de clase que tienen un tipo que indica el tipo de valores de datos permitidos para el atributo. Para la regla de ejemplo, el MON incluye una clase de aspirantes que tiene un atributo de capacidad de endeudamiento del tipo entero.

Los elementos del modelo de datos para una vista de datos analíticos corresponden a los elementos en el modelo de objetos de negocio. Una tabla de modelo de datos corresponde a una clase MON. Un campo en la tabla de modelo de datos corresponde a un atributo para la clase.

Figura 1. Relaciones entre un modelo de datos y el modelo de objetos de negocio

Figura 1ilustra las relaciones entre los elementos de modelos de datos y los elementos del modelo de objetos de negocio para un modelo de datos que incluye una tabla llamada Aspirante. Esa tabla corresponde a la clase MON que tiene el mismo nombre. La verbalización de la clase incluye el término aspirante para la clase. Los campos de la tabla de modelo de datos de ID, nombre y capacidad de endeudamiento corresponden a los atributos de la clase MON. Cada atributo de la clase proporciona una frase de verbalización con el formato {atributo} de {esto}. La variable {esto} se refiere al aspirante término padre en la verbalización.

Puede utilizar la correspondencia del modelo de datos y el MON para combinar los resultados desde distintos métodos analíticos. La salida de modelos predictivos que están basados en la visualización de datos analíticos pueden combinarse con reglas de negocio que se basan en un MON si los campos de modelo de datos coinciden con elementos MON. La interfaz de datos común permite que se integren indicadores desde modelos predictivos con los criterios de reglas de negocio.

Modelo de Dominio:

Un modelo de dominio en la resolución de problemas e ingeniería de software, es un modelo conceptual de todos los temas relacionados con un problema específico. En él se describen las distintas entidades, sus atributos, papeles y relaciones, además de las restricciones que rigen el dominio del problema.

El modelo de dominio se crea con el fin de representar el vocabulario y los conceptos clave del dominio del problema. El modelo de dominio también identifica las relaciones entre todas las entidades comprendidas en el ámbito del dominio del problema, y comúnmente identifica sus atributos. Un modelo de dominio que encapsula los métodos dentro de las entidades se asocia más bien con modelos orientados a objetos. El modelo de dominio proporciona una visión estructural del dominio que puede ser complementado con otros puntos de vista dinámicos, como el modelo de casos de uso.

EJEMPLO:

La empresa interactúa con distintos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empresa), el proveedor (persona o entidad que reabastece de productos a la empresa) y por último la empresa de transportes, que es una subcontrata encargada de servir los pedidos desde los distintos almacenes regionales a los clientes de la empresa.

Modelo de Casos de Uso del Negocio

Modelo de Objetos de Vender Productos

Modelo de Objetos de Seguimiento y Consulta de Productos

Modelo de Objetos de Reponer Stock

Modelo de Objetos de Modificar Catálogo

Modelo de Objetos de Realizar Entrega

Modelo del Dominio

RESUMEN:

La captura de los requerimientos tiene como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a implantar. En otras palabras, los requerimientos identifican el qué del sistema, mientras que el diseño establece el cómo del sistema.
El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos. Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado específico para un cliente o el mercado.

SUMMARY:

Capturing requirements main objective understanding of what customers and users expect the system to do . A requirement expresses the purpose of the system regardless of how you will implement . In other words, identify the requirements which the system, while designing the system sets the how .
The business model describes the business in terms of business use cases , which corresponds to what is generally called processes. A business process is structured activities that are designed to produce a specific result for a client or the market as a whole.

RECOMENDACIONES:
Diseñar modelos de negocios transparente (fáciles de comprender). 
CONCLUSIONES:
Las CASE han sido creadas para la automatización de procesos de análisis, diseño e implementación,
brindándonos un sin número de componentes que hacen que los proyectos sean cada día más eficientes para los
usuarios finales.
APRECIACIÓN DEL EQUIPO:
La aplicación de las herramientas CASE corresponde el mejor método para el análisis y solución de situaciones empresariales complejas, ya que han venido a mejorar los aspectos claves en el desarrollo de los sistemas de negocios.

GLOSARIOS DE TÉRMINOS:
Requerimiento: petición de una cosa que se considera necesaria.
Esencial: que es lo mas importante y necesario.

LINKOGRAFIA:

http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html
http://modeladodelsistema3.blogspot.pe/2012/03/republica-bolivariana-de-venezuela.html
https://es.wikipedia.org/wiki/Modelo_de_dominio

Presentación de diapositivas: SlideSha

Juan Julca Landacay.

METODOLOGÍAS RUP

DEFINICIÓN:

El Proceso Racional Unificado (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM.1 Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

CARACTERÍSTICAS:

• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software
• Pretende implementar las mejores prácticas en Ingeniería de Software, de forma que se adapte a cualquier proyecto

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

CICLO DE VIDA:

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado

ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

ARTEFACTOS:

RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio:

Documento Visión

Diagramas de caso de uso

Especificación de Requisitos

Diagrama de Requisitos

Elaboración:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica

Diagrama de clases

Modelo E-R (Si el sistema así lo requiere)

Vista de Implementación

Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboración

Vista Conceptual

Modelo de dominio

Vista física

Mapa de comportamiento a nivel de hardware.

Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos

Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construcción:

Especificación de requisitos faltantes

Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa

Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el caso

Transición:

Pruebas finales de aceptación

Puesta en producción

Estabilización

EJEMPLO:

Desarrollo de  un Sistema para la Gestión de Artículos Deportivos    

La aplicación se desarrolló bajo el lenguaje de programación Visual Basic 6.0, teniendo que soportar tanto acceso a una base de datos Oracle como a una base de datos Access, dependiendo de la selección del usuario en el arranque del programa. Cabe citar que el equipo de desarrollo estaba limitado a unos conocimientos medios del lenguaje de programación, por lo que las soluciones adoptadas pueden no ser completamente eficientes.

En el partado de Gestión del Proyecto se muestran las planificaciones temporales de desarrollo del proyecto en su fase de inicio y de elaboración, así como el diario de ejecución del proyecto, junto con el diario de construcción de la aplicación y cumplimiento de los plazos estimados.

En el apartado de Modelado del Negocio se encuentran los artefactos utilizados de la metodología RUP para definir un modelo del negocio, modelos de objetos del negocio y el modelo del dominio.

En el apartado Requisitos se muestran todos los enlaces a los documentos en formato word y pdf consultables desde el navegador. Dicha documentación consta de los artefactos definidos según la metodología RUP, es decir, el documento plan de desarrollo software, el documento visión, el documento glosario y las especificaciones tanto de los casos de uso como de los casos de pruebas relacionados con estos. También se recoge la gestión del proyecto con la herramienta de Rational, el Requisite Pro, con la que además de llevar el control de toda la documentación, se puede seguir la trazabilidad entre requerimientos de todo el proyecto. En este apartado se muestran las matrices de atributos de todos los requerimientos así como la navegabilidad entre ellos. Por añadidura también se muestran los casos de uso de cada subsistema generados con la herramienta Rational Rose, y desde los cuales también se puede consultar la especificación del caso de uso.

En el apartado Análisis/Diseño se muestran tanto el modelo de análisis/diseño (diagrama de clases) como el modelo de datos (modelo entidad - relación), desde los cuales se puede consultar la especificación de los métodos de clase más relevantes o las especificaciones de atributos.

En el apartado Implementación se muestran los prototipos de interfaces de usuario de la aplicación, tanto para el sistema de gestión de ventas como para el sistema de gestión de almacén. También en este apartado se muestran los diagramas de componentes y diagrama de despliegue que modela las aplicaciones incorporadas en el proyecto hasta la segunda iteración de la fase de construcción (según la definición de fases e iteraciones de la metodología RUP) y desde los cuales, a través de los componentes se puede consultar el código fuente de cada uno.

Por último, en el apartado Pruebas se encuentran los enlaces a los documentos word de especificación de casos de pruebas funcionales consultables mediante el navegador o bien descargables mediante un enlace en formato zip. Se muestran únicamente los casos de pruebas generados para los casos de uso incorporados hasta la segunda iteración de la fase de construcción.

RESUMEN:

 El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

SUMMARY:

The RUP is not a system with well-established steps , but a set of adaptable to the context and needs of each organization methodologies. It is also known by the name software , also developed by Rational , which includes information interlaced various artifacts and descriptions of the various activities. It is included in the Rational Method Composer (RMC ), which allows customization according to the needs .

The RUP is a product of Rational (IBM ) . It is characterized by iterative and incremental , be focused on architecture and guided by use cases . Includes artifacts (which are the tangible products of the process such as the use case model , source code, etc. ) and roles ( role of a person at a given time , a person can play different roles throughout the process).

 

RECOMENDACIONES:

 Es importante seguir metodologías y estándares que nos lleven a estar en competitividad en todo momento, para mantener el control y el orden del proyecto.

CONCLUSIONES:

El RUP, como herramienta colaboradora en el desarrollo de software, aumenta la visión de desarrollo del mismo, es decir, el RUP es una herramienta que permite prever los cambios que un software pueda tener de acuerdo a los requerimientos y avance social que se tenga, brindando objetivos mas amplios y visión de requerimientos global.

APRECIACIÓN DEL EQUIPO:

El RUP es aquel método que da cabida al cambio en las etapas del desarrollo de software, no siguiendo al pie de la letra los requerimientos, sino, por el contrario, mostrando otros campos que mejoren y optimicen el desarrollo del mismo.

GLOSARIO DE TÉRMINOS:
Iterativo:Que se repite o se ha repetido muchas veces.

LINKGRAFÍA:

https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/

Presentación en Diapositivas  : SlideSahre

Elaborado por Juan Elezaér Julca Landacay

 

METODOLOGÍA XP

DEFINICIÓN:

La programación extrema o eXtreme Programming (de ahora en adelante, 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 la 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.

CARACTERÍSTICAS:
las características fundamentales del método son:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

• Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.
• Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
• Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
• Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
• Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
• Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
• Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
• Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
• La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

CICLO DE DESARROLLO:

Exploración:

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

Planificación de la Entrega (Release):

En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días. Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.

Iteraciones:

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.

Producción

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación (por ejemplo, durante la fase de mantenimiento).

Mantenimiento:

Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.

Muerte del Proyecto:

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

EJEMPLO:

Un ejemplo en la que se puede aplicar la metodología xp  según el equema:

RESUMEN:

La programación extrema o eXtreme Programming (de ahora en adelante, 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). Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. 

las características fundamentales del método son:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Hacer entregas frecuentes.

Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. La simplicidad y la comunicación son extraordinariamente complementarias. 

Exploración:

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.

Iteraciones:

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.

Producción

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.

Muerte del Proyecto:

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. 

SUMMARY:

Extreme or eXtreme Programming (hereinafter, XP) is a programming development methodology software engineering made by Kent Beck, author of the first book on the subject, Extreme Programming Explained: Embrace Change (1999). Proponents of XP consider changing requirements on the fly is a natural, inevitable and even desirable aspect of project development.

the fundamental characteristics of the method are:

Iterative and incremental development: small improvements, one after another.

Continuous unit testing, frequently repeated and automated, including regression testing. Frequent programming team integration with the client or user. It is recommended that a customer representative works with the development team.

Make frequent deliveries.

Code refactoring, ie, rewrite certain parts of the code to increase readability and maintainability without changing their behavior. The simplicity and communication are extremely complementary.

Exploration:

In this phase, customers raise roughly user stories that are of interest to the first delivery. Test technology and the possibilities of the system architecture are explored building a prototype. One point equals programming is ideally week. The stories generally worth of 1-3 points. Moreover, the development team keeps track of the "speed" of development, established in points per iteration, based primarily on the amount of points corresponding to the user stories that were completed in the last iteration. The speed of the project is used to establish how many stories can be implemented before a certain date or how long it will implement a set of stories. By planning time, the number of iterations is multiplied by the speed of the project, determining how many points can be completed. When planning system range as the sum of points of the user stories selected from the speed of the project, obtaining the number of iterations required for its implementation is divided.

Iterations:

This phase includes several iterations of the system before delivery. In the first iteration you can try to establish a system architecture that can be used during the rest of the project. At the end of the last iteration the system is ready to go into production. The factors to be taken into account during the preparation of the Iteration Plan are not addressed user stories, project speed, unsurpassed acceptance tests in the previous iteration and unfinished tasks in the previous iteration. All work iteration is expressed in programming tasks, each of which is assigned to a scheduler responsible, but carried out by pairs of programmers.

Production

The production phase requires additional testing and review of performance before the system is transferred to the customer environment. The maintenance phase may require new staff within the team and changes in its structure.

Project death:

It is when the customer has no more stories to be included in the system. The final system documentation is generated and no further changes are made to the architecture.

RECOMENDACIONES:

• Cualquier metodología tiene sus ventajas y desventajas , solo hay que analizarlas para que se lo mas adecuado posible al realizar un proyecto.(Sandra Jimenez Berrú)
• Tener en cuenta  los plazos establecidos en cualquier metodología , a fin de no frustrar el proyecto.(Juan Julca Landacay)

CONCLUSIONES:

• Es una metodología compleja pero muy adaptable(Sandra Jimenez Berrú)
• El Costo puede ser elevado  al no cumplirse ciertos  objetivos.(Juan Julca Landacay)

APRECIACIÓN DE EQUIPO:

• Es una de las mejores metodologías ya que el  Ciclo de vida del software es muy dinámico.

GLOSARIO DE TÉRMINOS:

• Programación:es el proceso de diseñar, codificar, depurar y mantener el código fuente de programas computacionales. El código fuente es escrito en un lenguaje de programación.
• Refactorización: Se usa a menudo para describir la modificación del código fuente sin cambiar su comportamiento, lo que se conoce informalmente por limpiar el código.

LINKOGRAFÍA:

• http://oness.sourceforge.net/proyecto/html/ch05s02.html#xpproyecto
• https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

Elaborado por el Equipo : "Desarrolladores de Sistemas"

                                                       Integrantes:

                                                       >Sandra Jimenez Berrú.

                                                       >Juan Julca Landacay.

Presentacion de Diapositivas: SlideShare