MODELO EN

CASCADA Y
PROGRAMACIÓN
EXTREMA (XP)

Presenta por: Andrés Felipe

Arenas Pico
Unisangil-2023
 ¿QUÉ ES?
El desarrollo en cascada (en inglés,
waterfall model) es un procedimiento
lineal que se caracteriza por dividir los
procesos de desarrollo en sucesivas
fases de proyecto. Al contrario que en
los modelos iterativos, cada una de
estas fases se ejecuta tan solo una vez.
Los resultados de cada una de las
fases sirven como hipótesis de partida
para la siguiente.
El waterfall model se utiliza,
especialmente, en el desarrollo de
software.
 HISTORIA
• El modelo de cascada es uno de los modelos de ciclo de
vida de software más antiguos y se remonta a la década
de 1970.
• Definir un enfoque estructurado y sistemático para el
desarrollo de software.
• se desarrolló a partir de los métodos de gestión de
proyectos utilizados en la industria de la construcción y la
ingeniería.
• En 1970, Winston W. Royce publicó un artículo titulado
"Managing the Development of Large Software Systems“
• Describía una metodología en la que el proceso de
desarrollo se dividía en etapas secuenciales.
• Royce utilizó el término "modelo de cascada" para
describir su enfoque.
• Royce reconoció las limitaciones del modelo de
cascada y sugirió que se necesitaba una
revisión del enfoque.
• El modelo de cascada se popularizó y se
convirtió en un enfoque comúnmente utilizado
para el desarrollo de software en la década de
1980.
• A medida que el software se volvió más
complejo y los requisitos se volvieron más
difíciles de definir con precisión,
• se hicieron evidentes las limitaciones del
modelo de cascada.
• A pesar de sus limitaciones, el modelo de
cascada sigue siendo utilizado en proyectos de
software en los que los requisitos están bien
definidos y el alcance del proyecto es limitado.
 FASES DE LA
METODOLOGÍA DE
DESARROLLO EN
CASCADA.
 1. ANÁLISIS DE REQUISITOS

Preséntanos tu proyecto. Juntos analizaremos el proyecto

y elaboraremos el documento de especificación de
requisitos. También valoraremos el tiempo y la inversión
económica.

2. Diseño

Nuestro equipo de desarrolladores definirá las

tecnologías que se emplearán en el proyecto así
como la arquitectura del sistema software. Este fase es
muy importante para que la etapa de desarrollo fluya
correctamente, minimizando los imprevistos.
 3. Programación

Una vez validado el documento de diseño,

iniciaremos el desarrollo del software, cumpliendo
con las especificaciones de diseño establecidas en la
anterior fase.

4. Prueba

Nos apoyamos en nuestro equipo de QA para

gestionar una etapa de pruebas. Esta etapa ayuda a
encontrar los defectos antes de que la plataforma
entre en producción.
 5. Despliegue

Al fin, subimos el proyecto al entorno de producción y

hacemos entrega de todo el material.

6. Mantenimiento

Si lo necesitas, te ofrecemos servicio de mantenimiento

posterior al lanzamiento… ¡Evolucionemos juntos!
PROGRAMACIÓN
EXTREMA (XP)
 ¿QUÉ ES?
La programación extrema es una
metodología de desarrollo de software
que forma parte de lo que se conoce
colectivamente como metodologías
ágiles. XP se basa en valores,
principios y prácticas, y su objetivo es
permitir que equipos pequeños y
medianos produzcan software de alta
calidad y se adapten a los requisitos
cambiantes y en evolución.
Lo que diferencia a XP de las demás
metodologías ágiles es que hace hincapié en
los aspectos técnicos del desarrollo de
software. La programación extrema es
precisa sobre cómo trabajan los ingenieros,
ya que seguir las prácticas de ingeniería
permite a los equipos entregar código de alta
calidad a un ritmo sostenible.

La programación extrema consiste, en pocas

palabras, en las buenas prácticas llevadas al
extremo. Como programación en parejas es
buena, hagámosla siempre.
 HISTORIA DE LA PROGRAMACIÓN
EXTREMA
• El origen de XP se remonta a los años 90, cuando Kent Beck -que más
tarde se convertiría en uno de los autores del Manifiesto Ágil — lo creó
al ser contratado para dirigir el equipo del Sistema de Compensación
Integral de Chrysler.

• El proyecto había comenzado en 1993 y en 1996 no había avanzado

mucho. Como Beck era nuevo en la gestión de un equipo, decidió que lo
mejor sería enseñar a los miembros de su equipo las técnicas y
prácticas que a él le funcionaban.
• Empezaron a aplicar prácticas como la programación por parejas y el
TDD con gran éxito. Ron Jeffries un amigo de Beck y otro autor del
Manifiesto Ágil- fue contratado para entrenar al equipo de C3.

• En 1999, Kent Beck formalizó las prácticas, principios y valores de XP

en su libro Extreme Programming Explained: Embrace Change
 ¿CÓMO FUNCIONA LA PROGRAMACIÓN EXTREMA
(XP)?

Los valores proporcionan un propósito a los equipos. Actúan

como una «estrella del norte» para guiar sus decisiones en
un alto nivel. Sin embargo, los valores son abstractos y
demasiado difusos para una orientación específica.

Las prácticas son, en cierto modo, lo contrario de los valores.

Son concretas y realistas, y definen lo que hay que hacer.
Las prácticas ayudan a los equipos a responsabilizarse de los
valores. Por ejemplo, la práctica de los espacios de trabajo
informativos favorece una comunicación transparente y
sencilla.

Los principios son directrices específicas del sector que

salvan la distancia entre las prácticas y los valores.
 VALORES DE XP
comunicación, sencillez, retroalimentación, valor y respeto.

COMUNICCIÓN: La falta de comunicación impide que los

conocimientos fluyan dentro de un equipo. A menudo,
cuando hay un problema, alguien ya sabe cómo resolverlo.
Pero la falta de comunicación les impide conocer el
problema o contribuir a su solución. Así, el problema acaba
resolviéndose dos veces, generando residuos.

SIMPLICIDAD: La simplicidad dice que siempre hay que

esforzarse por hacer lo más sencillo que funcione. A
menudo se malinterpreta y se interpreta como lo más
sencillo y punto, ignorando la parte de «que funciona».

RETROALIMENTACIÓN: La retroalimentación en las

metodologías de desarrollo de software más tradicionales,
tipo cascada, a menudo es «demasiado pequeña,
demasiado tarde».
 PRINCIPIOS DE XP
Los principios proporcionan una orientación más específica que los valores. Son directrices que iluminan los
valores y los hacen más explícitos y menos ambiguos.

• Humanidad
• Economía:
• Beneficio mutuo
• Autosimilaridad
• Mejora
• Diversidad
• Fracaso
• Calidad
• Pasos de bebé
 FUNCIONES Y RESPONSABILIDADES CLAVE
Según Kent Beck, un equipo de XP maduro no debería depender de roles rígidos, pero reconoce que los roles pueden
ser útiles para los equipos principiantes, hasta que empiezan a obstaculizar la colaboración.

Cliente: lo ideal sería que hubiera un cliente real in situ para responder a las preguntas, priorizar las historias de usuario
o colaborar con las pruebas de aceptación. Cuando esto no es posible, este papel podría ser desempeñado por un
representante del cliente.

Programadores: en un equipo de XP, los programadores estiman el esfuerzo necesario para completar las tareas y las
historias, escribir las pruebas automatizadas e implementar las historias.

Entrenador: Tener un entrenador no es necesario, y muchos equipos han logrado el éxito sin uno. Sin embargo, tener a
alguien con experiencia en XP para entrenar a un equipo puede asegurar que los miembros del equipo sigan las
prácticas, las conviertan en hábitos y no vuelvan a las viejas costumbres.

Rastreador: Un rastreador hace un seguimiento de las métricas de progreso del equipo y habla con cada miembro del
equipo para identificar los obstáculos y encontrar soluciones. El rastreador calcula las métricas que indican lo bien que
lo está haciendo el equipo, como los gráficos de velocidad y burndown, o el equipo utiliza un tablero digital de scrum o
kanban que las calcula automáticamente.
 TARJETAS CRC
Las tarjetas CRC (Clase-Responsabilidad-Colaboración) son una herramienta de brainstorming
usada como metodología para el diseño de software orientado a objetos, creada por Kent Beck y
Ward Cunningham.
La técnica consiste en dibujar una tarjeta por
cada clase u objeto, y dividirla en tres zonas:

[Link] la parte superior, el nombre de la clase.

[Link], en la parte izquierda,
las responsabilidades de dicha clase. Son
sus objetivos, a alto nivel.
3.A la derecha de las responsabilidades,
los colaboradores, que son otras clases que
ayudan a conseguir cumplir a esta con sus
responsabilidades.
 Características
• Es una técnica para la representación de sistemas OO, para pensar en objetos.
• Son un puente de comunicación entre diferentes participantes.
• Principales desventajas: lentitud y roces.
• Se recomienda un grupo de trabajo con representantes de las distintas partes.
• Tamaño recomendable de cinco a seis personas: variedad de estilos y no demasiadas divagaciones.
• Recomendación de equipo: 1 o 2 usuarios, 2 analistas, 1 diseñador y 1 moderador.
• Permite ver las clases como algo más que repositorio de datos, sino conocer el comportamiento de cada una en un
alto nivel.
• La lluvia de ideas es una buena práctica para sugerir cómo rellenar las tarjetas CRC:
• Todas las ideas son buenas, no censura.
• Pensar rápido, la meditación después.
• Cada miembro debe tener un turno, sin presiones.
• Aligerar la situación, pausas para los roces.
 TARJETAS CRC
Tal como lo propone XP en el diseño del sistema SISGEMAP se ha utilizado la técnica de tarjetas CRC (Clase –
Responsabilidad-Colaboración), las mismas que nos han permitido realizar un inventario de las posibles clases que se van a
necesitar en la implementación del sistema y la forma en que van a interactuar. Las tarjetas CRC han permitido que el
diseño sea lo más simple posible verificando las especificaciones del sistema SISGEMAP.
Cada tarjeta CRC esta descrita por:
Nombre de la Clase Tabla 13-2: Tarjeta CRC Representante
Responsabilidades: Establece el propósito de Representante
la clase. Responsabilidades Colaboradores
Colaboradores: son las clases que permiten Realizar matrícula Matrícula
desarrollar otra. Ingresar Voucher de pago Pago
Para SISGEMAP las tarjetas CRC que se Generar reportes Cadete, Matricula, Pensión
propusieron inicialmente fueron las Realizado Por: Ericka Guanoluisa. 2016
siguientes: Tabla 12-2: Tarjeta CRC Secretaria
Secretaria Tabla 14-2: Tarjeta CRC Administrador
Responsabilidades Colaboradores Administrador
Gestionar matrículas Matrícula Responsabilidades Colaboradores
Gestionar pagos Pago Gestionar periodos Periodo
Buscar cadetes Cadete Gestionar Usuarios Usuario
Generar reportes Cadete, Matricula, Pensión Realizado Por: Ericka Guanoluisa. 2016
Aprobar pagos Pago
Tabla 15-2: Tarjeta CRC Cadete
Realizar cierre de caja Cierre de caja
Cadete Responsabilidades Colaboradores Ingresar cadete
Realizado Por: Ericka Guanoluisa. 2016
Actualizar cadete Mostrar cadete Eliminar Cadete
Realizado Por: Ericka Guanoluisa. 2016
MUCHAS GRACIAS
PO R S U AT EN C IO N