INSTITUTO POLITÉCNICO NACIONAL Prof. Paula León A.

Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y Administrativas Actividad 15. Metodologías
ágiles: XP, RAD y Metodologías
Ingeniería de Software tradicionales: SDLC, RUP.

Objetivo: Identificar las metodologías ágiles: Extreme Programming y RAD (Desarrollo Rápido de Aplicaciones) y metodologías tradicionales RUP (Rational Unified Process) y SDLC (System
Development Life Cycle).

Fecha: 20/12/2023
_______________________________
Chávez Ramírez María Fernanda 11
Nombre(s): _____________________________________________ No. Lista ___________ Grupo: 4CM50
___________
(Apellido paterno. Apellido materno. Nombre(s)

Extreme (o XP) Programming es una metodología de desarrollo que pertenece a las conocidas
como metodologías ágiles (otras son Scrum, Kanban…), cuyo objetivo es el desarrollo y gestión
de proyectos con eficacia, flexibilidad y control.
Desarrollo Rápido de Aplicaciones (RAD) en inglés Rapid Application Development. Proceso
para desarrollar sistemas en un periodo de tiempo muy corto mediante el uso de prototipos,
herramientas de cuarta generación y un trabajo estrecho en equipo entre los usuarios y los
especialistas de sistemas.
Ciclo de vida de desarrollo de los sistemas. (SDLC). Método de siete fases para el análisis y
desarrollo de sistemas cuya premisa es que los sistemas se desarrollan de una mejor manera
mediante un ciclo específico de actividades del analista y el usuario.
RUP. Proceso Unificado Racional (Rational Unified Process) Es un ejemplo de un modelo de
proceso moderno que se derivó del trabajo sobre el UML y el proceso asociado de desarrollo de
software unificado. El RUP reconoce que los modelos de proceso convencionales presentan una
sola visión del proceso. En contraste, el RUP por lo general se describe desde tres perspectivas:
Ágil. Generalmente hace referencia a la capacidad de moverse o
responder con rapidez y facilidad; ser ágil. En cualquier tipo de
disciplina de administración, Ágil es una calidad, y, por lo tanto, es
algo bueno que se debe buscar. Específicamente, la administración
ágil de proyectos implica adaptarse durante la creación de un
producto, servicio u otro resultado.
En materia de desarrollo de software, agilidad se relaciona a
los cambios que se van a construir entre los miembros del
equipo debido a cambios en las tecnologías o de otro tipo. En
cualquier actividad de software debe incluirse un soporte para
los cambios. Un equipo ágil reconoce que el software lo
desarrollan individuos que trabajan en equipo y que las
actitudes de estas personas y su capacidad para colaborar son
ingredientes para el óptimo funcionamiento de un proyecto.

1. Una perspectiva dinámica que muestra las fases del modelo a través del tiempo.
2. Una perspectiva estática que presenta las actividades del proceso que se establecen.
3. Una perspectiva práctica que sugiere buenas prácticas a usar durante el proceso.

1
▪ Políticas de desarrollo ágil: Existe un debate sobre el desarrollo y la aplicabilidad del
desarrollo ágil del software como alternativa a procesos de ingeniería de software más
convencionales.

Nadie está en contra de la agilidad. Nos preguntamos entonces:

¿Cuál es la mejor manera de lograrla?

¿Cómo se construye un software que satisfaga hoy las necesidades de los clientes y muestre
las características de calidad que le permitan extenderse y escalar para cubrir a largo plazo as
necesidades del cliente?

▪ Factores humanos: los defensores del desarrollo ágil del software resaltan la importancia de
los “factores de las personas” en un desarrollo ágil exitoso.

Si los miembros del equipo de software van a manejar las características del proceso que se
aplica para construirlo, debe existir un gran número de rasgos clave entre la gente del equipo
ágil y el equipo mismo.

▪ Competencia
▪ Enfoque común
▪ Colaboración
▪ Habilidad para la toma de decisiones
▪ Capacidad para resolución de problemas confusos
▪ Confianza y respeto mutuo
▪ Organización propia

Deja tu que no estén fritas, son tortillas frías.

Cuando se le rompieron las tortillas, morí.

2
 1. Programación extrema /Extreme Programming (XP)

La programación extrema (conocida en inglés como Extreme Programming), creada en la Chrysler Corporation, obtuvo impulso en la década de 1990. La programación
extrema, o XP, por sus siglas en inglés, evita el aumento radical del costo de software cambiante con el paso del tiempo. Las características claves del XP incluyen el
desarrollo incremental, horarios flexibles, códigos de prueba automatizados, comunicación verbal, diseño en evolución constante, así como la colaboración de cerca a corto
y largo plazo se deriva de todos los que participan.

El Extreme (o XP) Programming es una metodología de desarrollo que pertenece a las conocidas como metodologías ágiles (otras son Scrum, Kanban…), cuyo objetivo es
el desarrollo y gestión de proyectos con eficacia, flexibilidad y control.

Ambos conceptos, relacionados estrechamente, son distintos. Agile es el marco de trabajo para el desarrollo del software, se hace mediante un proceso iterativo y define
las prácticas y roles del equipo. Por su lado, el XP programming es una metodología basada en la comunicación, la reutilización del código desarrollado y la realimentación.

Si nos centramos en el ámbito empresarial, el método Extreme Programming XP, también conocido como programación extrema, es una metodología ágil y flexible utilizada
en la gestión de proyectos. Su pilar principal es potenciar las relaciones interpersonales del equipo de desarrollo como factor clave para el éxito a través del trabajo en
equipo, el aprendizaje conjunto y la buena química entre todo el equipo de trabajo, unas buenas relaciones que nos ayudarán a solventar sin problemas los cambios con
los que nos encontraremos.

3
La metodología Extreme Programming XP también hace énfasis en la retroalimentación continua entre el cliente y el equipo de desarrollo, lo que la convierte en el
método de trabajo ideal para los proyectos con requisitos imprecisos y muy cambiantes. Son precisamente estas características las que nos impiden establecer los
requisitos desde el principio, como pasa con las otras metodologías convencionales, y ahí la capacidad de adaptación y de reajustarse de esta metodología es la clave.

Características

▪ Se considera al equipo de proyecto como el principal factor de éxito del proyecto

▪ Software que funciona por encima de una buena documentación.
▪ Interacción constante entre el cliente y el equipo de desarrollo.
▪ Planificación flexible y abierta.
▪ Rápida respuesta a cambios.

Las planificaciones

Se deben planificar los plazos temporales del proyecto basándose en las exigencias del cliente. En base a las estimaciones de coste y la dificultad del proyecto se marcan
las prioridades y las fechas, no siempre de forma precisa, pero sí orientativa. Con la entrega de la planificación efectuada, se desarrolla la de la iteración en el que cada dos
semanas se marca el rumbo y se entrega el software útil después de cada uno de estos periodos bisemanales. Con esto se consigue que el nivel de precisión sea mucho
mayor, las estimaciones sobre los costes sean más exactas y la información mucho más transparente.

Pruebas

Continuamente se han de efectuar una serie de pruebas automatizadas en base a los requisitos del cliente para comprobar que todo funcione correctamente. Éstas han
de hacerse de forma periódica y automática. Con las planificaciones comentadas anteriormente se incluyen las entregas al final de cada iteración, éstas serán siempre con
el software probado y funcionando correctamente y será facilitado al cliente, que puede utilizarlo para cualquier propósito, incluso para el usuario final. Los equipos XP
también pueden hacer entregas a otros usuarios finales.

Diseño y programación

El diseño del programa suele ser simple y basado en la funcionalidad del sistema y se lleva a cabo durante todo el proyecto, tanto durante la planificación de la entrega
como en el de la iteración. La programación del software se hace siempre en pareja, lo que se llama programar a dos manos. Se asegura con este método que al menos un
programador conoce y controla la labor de otro y queda revisado. El código es de todos, con el desarrollo de las pruebas automáticas y la programación a dos manos se
incluye también la posibilidad de que cualquiera pueda añadir y retocar parte del código, aunque eso sí, deba ser un estilo común y cuyo resultado sea como si sólo lo
hubiera hecho una persona.

El Extreme Programming tiene como gran ventaja la programación organizada y planificada para que no haya errores durante todo el proceso. Los programadores suelen
estar satisfechos con esta metodología. Es muy recomendable efectuarlo en proyectos a corto plazo.

La programación extrema valora la comunicación, la retroalimentación, la simplicidad y el valor. Los distintos roles en el enfoque de XP incluyen: el cliente, desarrollador,
seguidor (tracker) y el coach. Prescribe varias prácticas de codificación, de desarrollo y empresariales, así como eventos y artefactos para lograr un desarrollo eficaz y
eficiente. El extreme programming ha sido adoptado extensamente debido a sus prácticas de ingeniería bien definidas.

La PE utiliza un enfoque orientado a objetos como su paradigma de desarrollo preferido. Abarca un conjunto de reglas y prácticas que ocurren en el contexto de cuatro
actividades de marco de trabajo: planeación, diseño, codificación y pruebas.

4
- Planeación. La actividad de planeación comienza creando historias (llamadas también historias de usuario) que describen las características y funcionalidad requeridas
para que el software que se construirá. Cada historia la escribe el cliente y se coloca en una carta índice. El cliente le asigna un valor (es decir una prioridad) a la historia
basándose en los valores generales del negocio respecto a la característica o función. Los miembros del equipo evalúan cada historia y le asigna un costo, el cual se mide
en semanas de desarrollo. Si la historia requiere más de tres semanas de desarrollo, se le pide al cliente que la divida en historias menores y se realiza de nuevo la asignación
del valor y el costo.
-
▪ Diseño
▪ Codificación
▪ Pruebas

Definición

La Programación Extrema se basa en la retroalimentación continua entre el cliente y el equipo de desarrollo, la comunicación fluida entre todos los participantes, la
simplicidad en las soluciones implementadas y el coraje para enfrentar los cambios. XP es la herramienta adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo técnico.

Objetivos de la programación extrema

▪ Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.

▪ Mejorar la productividad de los proyectos.
▪ Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

Componentes de la programación extrema

▪ Metodología liviana de desarrollo de software

▪ Conjunto de prácticas y reglas empleadas para desarrollar software
▪ Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes
▪ Originada en el proyecto C3 para Chrysler
▪ En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo

Características de la metodología XP

▪ Esta metodología está basada en la prueba y el error, con mucha iteración. Plantea 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.
▪ Se fundamenta en Valores y Prácticas
▪ 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.
▪ Se trabaja con un cliente bien definido e integrado al proyecto. 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.

5
 ▪ 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.
▪ Se presume que los requisitos pueden (y van a) cambiar
▪ Se emplea con grupos pequeños y muy integrados (máximo 12 personas)
▪ Se requiere que el equipo tenga una elevada formación y capacidad de aprender.
▪ 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.

Ventajas de la metodología XP

▪ Simplicidad: XP propone el principio de hacer el desarrollo más simple y que pueda funcionar, en relación al proceso y la codificación. Es preferible hacer algo
simple hoy en lugar de hacer algo complicado y que probablemente nunca lo usemos mañana.
▪ Comunicación: Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de
comunicación.
▪ Realimentación: Concreta y frecuente entre el cliente, el equipo y los usuarios finales. La retroalimentación da una mayor oportunidad de dirigir el esfuerzo
eficientemente.
▪ Coraje: El coraje (valor) existe en el contexto de los otros 3 valores. (Si funciona…hay que mejorarlo).

La metodología XP está orientada hacia quien produce y usa el software. Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema, y combina las mejores
prácticas probadas para desarrollar software llevándolas al extremo.

Prácticas básicas de la Programación Extrema

Para que todo esto funcione la programación extrema se basa en doce “prácticas básicas” que deben seguirse al pie de la letra.

1. Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
2. Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.
3. Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
4. Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una de ellas cada pocas semanas. Deben ser versiones
que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.
5. Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
6. Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio
diario).
7. Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más
pruebas se hagan, mejor.
8. Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse
y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe
qué es lo que falla de todo lo que hemos metido.
9. El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
10. Normas de codificación: Debe haber un estilo común de codificación (no importa cuál), de forma que parezca que ha sido realizado por una única persona.

6
 11. Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda
uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el “recolector de basura” de java. Ayuda a que todos los programadores
(y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
12. Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué
hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir
el objetivo cercano de terminar una historia de usuario o mini-versión.

Ventajas y desventajas de la Programación Extrema

Ventajas:

- Programación organizada.
- Menor taza de errores.
- Satisfacción del programador.

Desventajas:

- Es recomendable emplearlo solo en proyectos a corto plazo.

- Altas comisiones en caso de fallar.

En resumen, la metodología XP mejor reúne las metodologías más exitosas por separado en un mismo sistema. Se funda en el aporte de la experiencia práctica a los
modelos teóricos y brinda un enfoque conjunto de prácticas a modo de rompecabezas. Además, cuenta con la tecnología en expansión y destaca la importancia de revisar
las metodologías desde la experiencia práctica.

Los roles en la programación extrema

Programador Serán los que se encargarán de desarrollar el Extreme Programming.

Escribe las pruebas unitarias y produce el código del sistema.
Cliente Establecen las prioridades y marca el proyecto. Suelen ser los usuarios finales del producto y quiénes marcan las necesidades.
Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.
Tester se encargan de ayudar al cliente sobre los requisitos del producto.

Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para
Tracker Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
Entrenador Asesoran al resto de componentes del equipo y marcan el rumbo del proyecto.
(coach) Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.
Consultor o Ofrece recursos, es el responsable de la comunicación externa y quien coordina las actividades.
Manager Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo
a resolver un problema específico.
Gestor (Big boss) Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.
Roles en XP
7
 2. Desarrollo Rápido de Aplicaciones (RAD)

Introducción.

Para solucionar problemas reales de la industria utilizando software, los desarrolladores de aplicaciones deben incorporar en la planeación del producto una estrategia de
modelado de software. Esto se conoce en la ingeniería de software como el modelo del proceso o el paradigma de la ingeniería de software; existen varios modelos para
el proceso de desarrollo de software, dentro de estos se destacan el modelo lineal secuencial, el modelo de construcción de prototipos, el modelo para el Desarrollo rápido
de aplicaciones, el modelo incremental, el modelo en espiral y el desarrollo basado en componentes. En el momento de desarrollar software, se recomienda seleccionar
un modelo o paradigma teniendo en cuenta la naturaleza del proyecto y de la aplicación.

El desarrollo rápido de aplicaciones también conocido como RAD (en inglés Rapid Application Development) es uno de los modelos para el proceso de desarrollo de
software, diseñado por James Martin en 1980. Este método comprende el desarrollo iterativo, la construcción de prototipos y el uso de herramientas CASE (Computer
Aided Software Engineering) y herramientas de rápido desarrollo. Hoy en día los desarrolladores de software suelen utilizar aplicaciones que permiten realizar de forma
rápida y sencilla el diseño y codificación de interfaces gráficas de usuario. Algunas de las plataformas más conocidas son Visual Studio Net, Delphi, NetBeans, entre otros.

Los lenguajes de programación utilizados para desarrollar software basado en la web son de tipo intérprete; es decir, son lenguajes que analizan el programa fuente y lo
ejecutan directamente utilizando otro programa que normalmente es un explorador de Internet. Los intérpretes no generan código equivalente al lenguaje de máquina;
dentro de los lenguajes de programación utilizados para la web se encuentran, el HTML, el javascript, el PHP, el ASP, el PERL, el ASP.NET, entre otros.

Modelo para el desarrollo rápido de aplicaciones (RAD).

Es un modelo de proceso de desarrollo de software relativamente corto (dura entre 60 y 90 días), este modelo es una adaptación a alta velocidad del modelo lineal
secuencial, para lograr un desarrollo rápido se utiliza la construcción de software basada en componentes, utilizando herramientas de software que permitan de forma ágil
y efectiva realizar una aplicación con altos estándares de calidad.

8
El Modelo RAD comprende las siguientes etapas:

Modelado de gestión. Este modelo se basa en dar respuesta a las siguientes preguntas:

- ¿Qué información conduce el proceso de gestión?

- ¿Qué información genera?
- ¿A dónde va la información?
- ¿Quién la procesa?

Modelado de datos. En este modelo se definen los almacenes de datos y cómo se relacionan los almacenes entre sí.
Modelado del proceso. Se utiliza para añadir, modificar, suprimir o recuperar un objeto de datos.
Generación de aplicaciones. Para esto se utiliza una herramienta de cuarta generación que permite crear el software y facilitar la construcción del programa.
Pruebas y entrega. El proceso de desarrollo finaliza realizando pruebas de calidad del software diseñado con la herramienta RAD, posteriormente se realiza la
implementación de la aplicación.

Modelo RAD

3. SDLC. Systems Development Life Cycle

Systems Development Life Cycle. El SDLC es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor
utilizando un ciclo especifico de actividades del analista y el usuario.

Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el ciclo d del desarrollo de sistemas, pero en general alaban su enfoque organizado. En la imagen
siguiente se presenta un ciclo dividido en siete fases.

9
 Ciclo de vida de desarrollo de sistemas

En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito
del resto del proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un problema que no era el que se tenía que resolver. La primera fase requiere que el
analista observe objetivamente lo que sucede en un negocio. A continuación, en conjunto con otros miembros de la organización, el analista de sum mina con precisión
cuáles son los problemas. Con frecuencia los problemas son detecta de por alguien más, y ésta es la razón de la llamada inicial al analista. Las oportunidades son situaciones
que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados. El aprovechamiento de las oportunidades podría permitir a la
empresa obtener una ventaja competitiva o establecer un estándar para la industria.

La identificación de objetivos también es una parte importante de la primera fase. En primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A
continuación se podrá determinar si algunas funciones de las aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos
aplicándolas a problemas u oportunidades específicos.

Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase consisten en
entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar alcance del proyecto y documentar los resultados. El resultado de
esta fase es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos A continuación, la administración debe decidir si se sigue
adelante con el proyecto propuesto. Si el grupo de usuarios no cuenta con fondos suficientes, si se desea atacar problemas distintos, o si la solución a estos problemas no
amerita un sistema de cómputo, se podría sugerir una solución diferente y el proyecto de sistemas de cancelaría.

4. RUP. Proceso Unificado Racional

El Proceso Unificado Racional (RUP, por las siglas de Rational Unified Process) (Krutchen, 2003) es un ejemplo de un modelo de proceso moderno que se derivó del trabajo
sobre el UML y el proceso asociado de desarrollo de software unificado (Rumbaugh et al., 1999; Arlow y Neustadt, 2005).

10
El RUP reconoce que los modelos de proceso convencionales presentan una sola visión del proceso. En contraste, el RUP por lo general se describe desde tres perspectivas:

1. Una perspectiva dinámica que muestra las fases del modelo a través del tiempo.
2. Una perspectiva estática que presenta las actividades del proceso que se establecen.
3. Una perspectiva práctica que sugiere buenas prácticas a usar durante el proceso.

La mayoría de las descripciones del RUP buscan combinar las perspectivas estática y dinámica en un solo diagrama (Krutchen, 2003). Esto hace que el proceso resulte más
difícil de entender, por lo que en este texto se usan descripciones separadas de cada una de estas perspectivas.
El RUP es un modelo en fases que identifica cuatro fases discretas en el proceso de software. Sin embargo, a diferencia del modelo en cascada, donde las fases se igualan
con actividades del proceso, las fases en el RUP están más estrechamente vinculadas con la empresa que con las preocupaciones técnicas. La figura siguiente ilustra las
fases del RUP. Éstas son:

Fases en el Proceso Unificado Racional

1. Concepción. La meta de la fase de concepción es establecer un caso empresarial para el sistema. Deben identificarse todas las entidades externas (personas y
sistemas) que interactuarán con el sistema y definirán dichas interacciones. Luego se usa esta información para valorar la aportación del sistema hacia la empresa.
Si esta aportación es menor, entonces el proyecto puede cancelarse después de esta fase.
2. Elaboración. Las metas de la fase de elaboración consisten en desarrollar la comprensión del problema de dominio, establecer un marco conceptual
arquitectónico para el sistema, diseñar el plan del proyecto e identificar los riesgos clave del proyecto. Al completar esta fase, debe tenerse un modelo de
requerimientos para el sistema, que podría ser una serie de casos de uso del UML, una descripción arquitectónica y un plan de desarrollo para el software.
3. Construcción. La fase de construcción incluye diseño, programación y pruebas del sistema. Partes del sistema se desarrollan en paralelo y se integran durante
esta fase. Al completar ésta, debe tenerse un sistema de software funcionando y la documentación relacionada y lista para entregarse al usuario.
4. Transición. La fase final del RUP se interesa por el cambio del sistema desde la comunidad de desarrollo hacia la comunidad de usuarios, y por ponerlo a funcionar
en un ambiente real. Esto es algo ignorado en la mayoría de los modelos de proceso de software aunque, en efecto, es una actividad costosa y en ocasiones
problemática. En el complemento de esta fase se debe tener un sistema de software documentado que funcione correctamente en su entorno operacional.

La iteración con el RUP se apoya en dos formas. Cada fase puede presentarse en una forma iterativa, con los resultados desarrollados incrementalmente. Además, todo el
conjunto de fases puede expresarse de manera incremental.

La visión estática del RUP se enfoca en las actividades que tienen lugar durante el proceso de desarrollo. Se les llama flujos de trabajo en la descripción RUP. En el proceso
se identifican seis flujos de trabajo de proceso centrales y tres flujos de trabajo de apoyo centrales. El RUP se diseñó en conjunto con el UML, de manera que la descripción
del flujo de trabajo se orienta sobre modelos UML asociados, como modelos de secuencia, modelos de objeto, etc.

La ventaja en la presentación de las visiones dinámica y estática radica en que las fases del proceso de desarrollo no están asociadas con flujos de trabajo específicos. En
principio, al menos, todos los flujos de trabajo RUP pueden estar activos en la totalidad de las etapas del proceso. En las fases iniciales del proceso, es probable que se use
mayor esfuerzo en los flujos de trabajo como modelado del negocio y requerimientos y, en fases posteriores, en las pruebas y el despliegue.

11
El enfoque práctico del RUP describe las buenas prácticas de ingeniería de software que se recomiendan para su uso en el desarrollo de sistemas. Las seis mejores prácticas
fundamentales que se recomiendan son:

1. Desarrollo de software de manera iterativa. Incrementar el plan del sistema con base en las prioridades del cliente, y desarrollar oportunamente las características
del sistema de mayor prioridad en el proceso de desarrollo.
2. Gestión de requerimientos. Documentar de manera explícita los requerimientos del cliente y seguir la huella de los cambios a dichos requerimientos. Analizar el
efecto de los cambios sobre el sistema antes de aceptarlos.
3. Usar arquitecturas basadas en componentes. Estructurar la arquitectura del sistema en componentes.
4. Software modelado visualmente. Usar modelos UML gráficos para elaborar representaciones de software estáticas y dinámicas.
5. Verificar la calidad del software. Garantizar que el software cumpla con los estándares de calidad de la organización.
6. Controlar los cambios al software. Gestionar los cambios al software con un sistema de administración del cambio, así como con procedimientos y herramientas
de administración de la configuración.

El RUP no es un proceso adecuado para todos los tipos de desarrollo, por ejemplo, para desarrollo de software embebido. Las innovaciones más importantes en el RUP son
la separación de fases y flujos de trabajo, y el reconocimiento de que el despliegue del software en un entorno del usuario forma parte del proceso. Las fases son dinámicas
y tienen metas. Los flujos de trabajo son estáticos y son actividades técnicas que no se asocian con una sola fase, sino que pueden usarse a lo largo del desarrollo para
lograr las metas de cada fase.

12
 INSTITUTO POLITÉCNICO NACIONAL Prof. Paula León A.
Unidad Profesional Interdisciplinaria de Ingeniería y Ciencias Sociales y Administrativas Actividad 15. Metodologías
ágiles: XP, RAD y Metodologías
Ingeniería de Software tradicionales: SDLC, RUP.
Fecha:
20/12/23
_______________________________
Chávez Ramírez María Fernanda
Nombre(s): _____________________________________________ No. Lista 11
___________ Grupo: 4CM50
___________
(Apellido paterno. Apellido materno. Nombre(s)

1. Mencione el nombre de dos metodologías ágiles.

a XP: Extreme Programming

b RAD:Desarrollo Rapido de Aplicaciones

2. Mencione el nombre de dos metodologías tradicionales.

a SDLC: Ciclo de vida de desarrollo se los sistemas

b RUP: Proceso Unificado Racional

3. Marque la casilla indicada al texto de referencia en función de las características de la Metodología conducida tradicional o ágil según corresponda:

Metodologías conducidas Metodologías ágiles

por planes
- Debe haber un plan para validar cada actividad importante del sistema. (Plan de validación)  
- Planificación predictiva  
- Cambios validados, es decir los cambios deben ser aprobados por los involucrados en el sistema  
- Orientada a los procesos  
- Contratos de por medio con tiempo exacto  
- Ejemplos: SDLC, RUP  
- Ejemplos: RAD. Extreme Programming (XP)  
- Orientadas al código (dado que la parte importante de la documentación es el código)  
- Planificación adaptable, es decir hay flexibilidad al cambio  
- Cambios aceptados  
- Orientados más hacia las personas  

4. Elabore un mapa conceptual de las cuatro metodologías abordadas en la presente actividad.

a. Puede emplear el contenido de este material y/o agregar información de otras fuentes.
b. Cite las referencias/fuentes de consulta

13
Mapa conceptual

14