Вы находитесь на странице: 1из 31

Nuevas

Metodologías
de desarrollo
Nombre:
Roger Mendez Roca


 1970
 Programación Estructurada
 1990
 Desarrollo Rápido de Aplicaciones
 Programación Orientada A Objetos
 Rational Unified Process (RUP)
 Nuevas Metodologías de Desarrollo
 Metodologías agiles


 Metodología para un ágil desarrollo
de software
 Programación basada en los deseos
del cliente (retroalimentación
continua cliente – desarrollador)
 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
 Cliente bien definido y en
colaboración constante.
 Los requisitos pueden y van a cambiar
(volátiles).
 Reduce los tiempos de desarrollo
manteniendo la calidad.
 Desarrollo incremental y continuo para
responder a los cambios.
 Grupo pequeño y muy integrado.
 Metodología creada a base de prueba y
error.
 Énfasis en el desarrollo del software mas
que una buena documentación.
 Empieza en pequeño y añade
funcionalidad con retroalimentación
continua.
 No introduce funcionalidades antes de
que sean necesarias.
 El cliente o el usuario se convierte en
miembro del mismo equipo.
 Comunicación: Crear software requiere de
sistemas comunicados.
 Simplicidad: Empezar con lo necesario y
requerido y trabajar desde ahí.
 Retroalimentación: Del sistema, del cliente, y
del equipo.
 Valentía: Programa para hoy y no para
mañana.
 Respeto: El equipo debe trabajar como uno, sin
hacer decisiones repentinas.
 Codificación: La parte mas importante de
XP.
 Pruebas: Nunca se puede estar seguro de
algo hasta haberlo probado.
 Escuchar: Escuchar los requisitos del
cliente acerca del sistema a crear.
 Diseño: Crear una estructura del diseño
para evitar problemas.
 Elciclo de vida ideal de XP consta de seis
fases:

 Exploración.
 Planificación de la Entrega (Release).
 Iteraciones.
 Producción.
 Mantenimiento.
 Muerte del Proyecto.
 Variación de la programación extrema clásica que consigue
cuadriplicar la eficacia de la misma

 Principios (Pipeline)
• La programación extrema en pipeline se basa en la
arquitectura Harvard de los procesadores.

 Eficiencia como:

𝑒 = 𝑥 + (𝑛 ∗ 𝑛𝑐 − 1)
 Donde:
• x es el tiempo de cada ciclo
• n el numero de escritorios remotos o participantes
• nc es el numero de iteraciones del proyecto.
 SCRUM es una metodología ágil de
gestión de proyectos cuyo objetivo
primordial es elevar al máximo la
productividad de un equipo.
 Reduce al máximo la burocracia y
actividades no orientadas a producir
software que funcione y produce
resultados en periodos muy breves de
tiempo (cada 15 o 30 días), por medio
de iteraciones o Sprints.
 Ideal para proyectos con un rápido
cambio de requerimientos.
 Sólo abarca prácticas de gestión sin
entrar en las prácticas de desarrollo
como puede hacer XP.
 Delega completamente en el equipo la
responsabilidad de decidir la mejor
manera de trabajar para ser lo más
productivos posibles y, le da gran
protagonismo a las reuniones que
realicen a lo largo del proyecto.
 Sus raíces teóricas están en las teorías
de la auto-organización.
Propietario del producto
Representa a todos los interesados en el
producto final.
Sus áreas de responsabilidad son:
 Financiación del proyecto.
 Retorno de la inversión del proyecto.
 Lanzamiento del proyecto.
Responsable de transformar el Backlog
de la iteración en un incremento de la
funcionalidad del software.
 Auto-gestionado.
 Auto-organizado.
 Multi-funcional.
Scrum Master
Responsable del proceso Scrum.
 Formación y entrenamiento del proceso.
 Incorporación de Scrum en la cultura de la
empresa.
 Garantía de cumplimiento de roles y
responsabilidad.
 Equipos de entre 6 y 10 personas revisan
los requisitos, la tecnología disponible y
evalúan los conocimientos para
colectivamente determinar como
incrementar la funcionalidad.
 Reuniones diarias, antes de empezar a
trabajar, con una duración máxima de 4
hrs.
 Se llevan a cabo hasta que el proyecto
este listo para ser puesto en producción o
ser lanzado al mercado.
 En la primera reunión se explica al equipo la forma
de trabajo, especificando que son reuniones cortas
para coordinar trabajo y no para solucionar
problemas. Se establecen los criterios para arreglar
los errores por prioridades (base del éxito del
sistema).
 Al inicio de cada iteración se revisa el trabajo
pendiente en el proyecto y se selecciona la parte a
la cual se le incrementara funcionalidad, para al
final de la iteración incorporarla al SW y
presentársela a las partes involucradas.
 En cada reunión las preguntas claves a contestar
son:
 ¿Qué es lo que se hizo desde la última reunión?
 ¿Qué es lo que se va a hacer hasta la siguiente reunión?
 ¿Cómo se va a llevar a cabo?
Sprint
 Es la base del desarrollo Scrum.
 Su duración máxima es de 30 días.
 Se llevan a cabo las tareas pre-
establecidas y no se puede modificar el
trabajo acordado en el backlog.
 Sólo el ScrumMaster puede abortar un
sprint si lo considera no viable por alguna
de las sgtes. razones:
 Las circunstancias del negocio han cambiado.
 La tecnología acordada no funciona.
 El equipo ha tenido interferencias.
Product Backlog
 Crea un listado con los requisitos de los
usuarios o propietarios del sistema para
planificar el proyecto.
 No es una lista completa y definitiva. Es sólo
una estimación inicial de los requisitos.
 Es un documento dinámico que incorpora
las constantes necesidades del sistema y se
mantiene durante todo el ciclo de vida
(hasta la retirada del Sist.).
Sprint Backlog
 Especifica la serie de tareas que se van a
desarrollar según los requisitos señalados.
 Estas tareas tienen una duración de entre 4
y 16 hrs. de trabajo.
 Las de mayor duración intentar
descomponerlas en Sub-Tareas dentro de
ese rango de tiempo.
 Al final del sprint se busca un incremento
en la funcionalidad.
 Es un proceso ágil para el desarrollo
de sistemas.
 No hace énfasis en la obtención de
los requerimientos sino en como se
realizan las fases de diseño y
construcción.
 Se preocupa por la calidad, por lo
que incluye un monitoreo constante
del proyecto.
 Se basa en un proceso iterativo con
iteraciones cortas que producen un
software funcional que el cliente y la
dirección de la empresa pueden ver y
monitorear.
 Define claramente entregas tangibles y
formas de evaluación del progreso del
proyecto.
 El proceso consiste de cinco pasos
secuénciales durante los cuales se diseña
y se construye el sistema:
 Desarrollode un modelo global.
 Construcción de una lista de funcionalidades.
 Planeación por funcionalidad.
 Diseño por funcionalidad.
 Construcción por funcionalidad.
 Puesto que todos los procesos se
centran en la producción de software
es deseable una comparación, no en
su conjunto, sino según los medios que
emplean y sus resultados.
 Realizamos una comparación entre
FDD, RUP y XP.
 Tamaño de los equipos: RUP esta pensado para
proyectos y equipos grandes, en cuanto a tamaño
y duración. FDD y XP se implementan mejor para
proyectos cortos y equipos más pequeños, siendo
quizás FDD más escalable que XP.
 Obtención de requisitos: RUP y XP crean como base
UseCases y UserStories, por lo contrario FDD no
define explícitamente esa parte del proyecto sobre
la adquisición de requisitos.
 Evaluación del estado del proyecto: FDD es
posiblemente el proceso más adecuado para
definir métricas que definan el estado del proyecto,
puesto que al dividirlos en unidades pequeñas es
bastante sencillo hacer un seguimiento de las
mismas.
XP también define esos componentes pequeños.
RUP por su parte, es tan grande y complejo en este
sentido como en el resto, por lo que manejar el
volumen de información que puede generar
requiere mucho tiempo.
 Carga de trabajo: XP es un proceso ligero, esto
es, que los creadores del proceso han tenido
cuidado de no poner demasiadas tareas
organizativas sobre los desarrolladores. RUP es un
proceso pesado, basado mucho en la
documentación, en la que no son deseables todos
esos cambios volátiles. FDD es por su parte un
proceso intermedio, en el sentido de que genera
más documentación que XP pero menos que RUP.
 Relación con el cliente:Con RUP se presentarán al
cliente los artefactos del final de una fase, en
contrapartida, la aseguración de la calidad en XP y
FDD no se basa en formalismos en la
documentación, si no en controles propios y una
comunicación fluida con el cliente.
 Conocimiento sobre la arquitectura: En RUP se
intentará reducir la complejidad del software a
producir a través de una planificación intensiva. En
XP se conseguirá a través de la programación a
pares que ya en la creación del código se puedan
evitar errores y malos diseños. En FDD sin embargo
se usan las sesiones de trabajo conjuntas en fase
de diseño para conseguir una arquitectura sencilla
y sin errores