Metodología

Ágil
La metodología ÁGIL promueve un
entorno de adaptación, trabajo en
equipo, auto-organización y rápido
suministro que permita un alto nivel
de involucración del cliente desde el
principio de la planificación del
proyecto.

Metodología
ÁGIL
 Metodología Ágil
Es un tecnología de desarrollo de software que se basa en
valores, principios y prácticas básicas.
Valores:
Se
recomienda
que los
analistas
adopten estos
Comunicación Simpleza Retroalimentación Valentía valores en los
proyectos que
emprendan.
Metodología Ágil
Pueden asegurar que un proyecto se complete con éxito
mediante un ajuste en los recursos importantes:

Tiempo

Costo

Calidad

Alcance
• Cuando se incluyen estas cuatro variables de control
en forma apropiada en la planificación, hay un estado
de equilibrio entre los recursos y las actividades
necesarias para completar el proyecto.
Proceso de desarrollo para un proyecto ágil
Dos palabras que caracterizan a un proyecto realizado mediante
metodología ágil son interactivo e incremental.
Etapas:

Puesta en
Planeación
producción

Iteraciones
para la
liberación de
Exploración la primera Mantenimiento
revisión
Proceso de desarrollo de un proyecto ágil
 el entorno para evaluar su convicción de que
Exploración puede y debe lidiar con el problema

Tener la convicción de que puede y debe lidiar con el

problema mediante el desarrollo ágil.

Se ensamblará el equipo y se evaluará las habilidades de sus

miembros

Se puede requerir desde unas cuantas semanas (si conoce a

los miembros del equipo y la tecnología que va a usar) hasta
unos cuantos meses (si todo es nuevo).
 También se tendrá que examinar activamente las
tecnologías potenciales necesarias para crear el sistema.

Durante esta etapa se debe practicar con la estimación

del tiempo necesario para realizar varias tareas.

En la exploración, los clientes también experimentan

escribiendo historias de los usuarios.

El punto es hacer que el cliente refine una historia con el detalle suficiente como para
que se pueda estimar en forma competente la cantidad de tiempo necesaria para crear
la solución y convertirla en el sistema que está planeando.
Planeación
La planeación tal vez sólo requiera de unos cuantos días (Si ha habido una buena exploración).

El analista y sus clientes se ponen de acuerdo en una fecha, (dos meses hasta medio año), para
entregar soluciones a sus problemas empresariales.

Si sus actividades de exploración fueron suficientes, esta etapa debe ser muy corta.

El equipo diseña la solución más simple posible.

Pone el sistema en producción tan pronto como sea posible.

Obtiene retroalimentación del cliente empresarial sobre lo que está funcionando y adapta su diseño a
partir de ahí.
Iteraciones para la liberación de la
primera versión.
Por lo general éstas son iteraciones (ciclos de prueba,
retroalimentación y modificación) de aproximadamente tres
semanas de duración.

Se esforzará en bosquejar toda la arquitectura del sistema, aun y

cuando sólo esté en forma de bosquejo o esqueleto.

Uno de los objetivos es realizar pruebas funcionales escritas por el

cliente al final de cada iteración.
Iteraciones para la liberación de la
primera versión.
También debe preguntarse si hay que alterar el itinerario de
trabajo o si está lidiando con demasiadas historias.

Se convierte cada iteración exitosa en pequeños rituales y se

involucra en ellos tanto a los clientes como a los
desarrolladores.
Se celebra siempre su progreso aunque éste sea pequeño,
debido a que esto forma parte de la cultura de motivar a todos
a que trabajen lo más duro que puedan en el proyecto.
Puesta en Producción
Las revisiones de software se entregan en una semana

Puede instituir sesiones informativas diarias para que todos sepan lo que los demás están
haciendo.

El producto se libera durante esta fase, pero se puede mejorar si se le agregan otras
características.

Poner un sistema en producción es un suceso emocionante; se dispone de tiempo para celebrar

con compañeros de equipo la ocasión.

Uno de los lemas de la metodología ágil con el que todos estamos sinceramente de acuerdo es que:
¡desarrollar sistemas debe ser divertido!
Mantenimiento

Una vez liberado el sistema, debe seguir funcionando sin

problemas

Es posible agregar características, considerar las sugerencias

más riesgosas de los clientes y a rotar los miembros del equipo.

La actitud que se debe tomar en este punto del proceso de

desarrollo es más conservadora que en cualquier otro.
Análisis y Diseño de Sistemas
Orientados a Objetos
Es una metodología Utilizan el estándar de la
diseñada para facilitar el industria para modelar
desarrollo de sistemas que sistemas orientados a
deben cambiar con rapidez objetos, conocido como
en respuesta a los entornos lenguaje de modelado
empresariales dinámicos unificado (UML), para
descomponer un sistema en
un modelo de caso

Definición Se utiliza
• La programación orientada a objetos difiere de la
programación tradicional por procedimientos en cuanto a
que examina a los objetos que forman parte de un sistema.

• Cada objeto es una representación computacional de una

cosa o evento real.

• Los objetos pueden ser clientes, artículos, pedidos,

etcétera.
 Los objetos
Se representan y agrupan mediante clases, las cuales son
ideales para la reutilización y la facilidad de mantenimiento

Una clase
define el conjunto de atributos y comportamientos
compartidos que se encuentran en cada objeto de la clase.
 Las fases en el UML son similares a las del SDLC.

Como estos dos métodos comparten un modelado rígido y exigente,

se realizan a un ritmo más lento y reflexivo que las fases del
modelado ágil.
Fases
Definir el modelo de caso de uso: el analista identifica a los actores y los eventos principales
iniciados por los actores

Durante la fase de análisis de sistemas, empezar a dibujar diagramas de UML, el analista

dibujará Diagramas de actividad, los cuales ilustran todas las principales actividades en el
caso de uso

Continuar en la fase de análisis, desarrollar diagramas de clases. Los sustantivos en los casos
de uso son objetos que se pueden agrupar potencialmente en clases
Aún en la fase de análisis, dibujar diagramas de estado.

Empezar el diseño de sistemas mediante la modificación de los diagramas de

UML; después, completar las especificaciones. significa modificar el sistema
existente, para lo cual hay que modificar los diagramas que se dibujaron en la
fase anterior.

Desarrollar y documentar el sistema, Un analista podrá crear modelos

maravillosos, pero si el sistema no se desarrolla no tiene mucho sentido crearlos
Definir el modelo de caso de uso.
Identifica a los actores y los eventos principales

Diagramar con figuras hechas con líneas que representan a

los actores y flechas que muestran las relaciones entre ellos.

Representar el flujo estándar de eventos en el sistema.

Describir un escenario de caso de uso, que describe con

palabras los pasos que se llevan a cabo comúnmente.
Durante la fase de análisis de sistemas,
empezar a dibujar diagramas de UML.

Dibujar diagramas de actividad, los cuales ilustran todas las

principales actividades en el caso de uso.

Crear uno o más Diagramas de secuencia para cada caso de

uso, los cuales muestran la secuencia de actividades y su
sincronización.

Ésta es una oportunidad para regresar y revisar los casos de

uso, replantearlos y modificarlos si es necesario
Continuar en la fase de análisis,
desarrollar diagramas de clases.

Los sustantivos en los casos de uso son objetos que

se pueden agrupar potencialmente en clases.

Por ejemplo, todo automóvil es un objeto que

comparte características con otros automóviles

En conjunto conforman una clase

Aún en la fase de análisis, dibujar
diagramas de estado.
Los diagramas de clases se utilizan para dibujar
diagramas de estado, los cuales ayudan a comprender
procesos complejos que no se pueden derivar
completamente mediante los diagramas de secuencia

Los diagramas de estado son en extremo

útiles para modificar los diagramas de clases,
por lo que continúa el proceso iterativo de
modelado de UML.
 Empezar el diseño de sistemas mediante la modificación de los
diagramas de UML; después, completar las especificaciones.
Modificar el sistema existente, hay que modificar los diagramas
que se dibujaron en la fase anterior.

Es posible usar estos diagramas para derivar clases, sus atributos y

métodos

Escribir especificaciones de clase para cada una de las clases e

incluir los atributos, métodos y sus descripciones.

Desarrollar especificaciones de los métodos en las que se detallen

los requerimientos de entrada y salida para cada método, junto con
una descripción detallada del procesamiento interno del método.
Desarrollar y documentar el sistema.

Entre más completa sea la información que se proporcione al

equipo de desarrollo por medio de la documentación y los
diagramas de UML, más rápido será el desarrollo y más
sólido será el sistema de producción final.
UML
Paso 2: Establecer Relaciones
• Dependencia: Una clase depende de otra
• Generalización: herencia
• Realización: una clase implementa una interfaz que se
define
• Asociación: se establece un vínculo que las vincula
• Agregación
• Composición
 Asociación Asociación: Composición Asociación: Agregación

Generalización

Asociación

Asociación

Generalización
Dependencia
Cómo elegir qué método de desarrollo de
sistemas usar
GRACIAS POR SU ATENCIÓN