Post on 10-Aug-2020
MODULO II
Gabinete de Auditoría de Sistemas CPA - 506
Resumen preparado por Miguel Cotaña
DESARROLLO AGIL
1
Los métodos ágiles se desarrollaron en
un intento por superar las debilidades
advertidas y reales en IS convencional.
El desarrollo ágil proporciona
beneficios importantes, pero es
imposible aplicarlo en todos los
proyectos, productos, personas y
situaciones. 2
La IS ágil combina una filosofía y un
conjunto de directrices de desarrollo. La
filosofía busca la satisfacción del cliente y
la entrega temprana del software
incremental; equipos de proyectos
pequeños y con alta motivación; métodos
informales; un mínimo de productos de
trabajo de la IS; y una simplicidad
general de desarrollo. Las directrices
hacen referencia al Análisis y Diseño. 3
El desarrollo ágil puede llamarse con
mayor precisión “ingeniería de
software ligera”. Las actividades
básicas del marco de trabajo se
conservan, pero éstas se conforman
como un conjunto mínimo de tareas que
empujan al equipo de proyecto hacia la
construcción y la entrega.
4
Qué es la agilidad?
Un equipo ágil es un equipo rápido que responde de manera apropiada a los “cambios”:
Cambios en el software que se va a construir; Cambios entre los miembros del equipo; Cambios debidos a las NTIC.
5
Un equipo ágil reconoce que el Sw lo
desarrollan individuos y que las aptitudes
y su capacidad para colaborar, son
esenciales para el éxito del proyecto.
Para quienes quieren alcanzar la agilidad,
se define 12 principios:
1) La mayor prioridad es satisfacer al
cliente mediante la entrega temprana
del Software;
2) Bienvenidos los requisitos cambiantes,
incluso en fases tardías del desarrollo; 6
3) Entregar Sw en funcionamiento, con
escala de tiempo lo más corta posible;
4) La gente de negocios y los
desarrolladores deben trabajar juntos a
diario;
5) Construir proyectos alrededor de
individuos motivados;
6) Incentivar la conversación cara a cara;
7) El Sw en funcionamiento es la medida
primaria de progreso; 7
8) Los procesos ágiles promueven el
desarrollo sustentable;
9) La atención continúa a la excelencia
técnica y al buen diseño mejora la
agilidad;
10) La simplicidad es esencial
11) Las mejores arquitecturas, requisitos
y diseños emergen de equipos
autoorganizados;
12) Los equipos se vuelven más efectivos
a intervalos regulares. 8
Según Fowler. Cualquier proceso ágil de
software, se caracteriza por 3
suposiciones:
1. Resulta difícil predecir cuáles
requisitos del software persistirán y
cuáles cambiarán. También es difícil
presagiar cómo cambiarán las
prioridades del cliente mientras se
ejecuta un proyecto.
Qué es un proceso ágil ?
9
2. El diseño y la construcción se deben
realizar de manera conjunta, de
modo que los modelos de diseño
sean probados conforme se crean.
Difícil predecir cuanto diseño se
necesita antes de que la
construcción se utilice para probar el
diseño.
3. El análisis, diseño y la construcción
no son predecibles. 10
Un proceso ágil de software debe ser
adaptable en forma incremental.
Para la adaptación incremental, un
equipo ágil requiere de retroalimentación
con el cliente. Un catalizador efectivo
para la retroalimentación del cliente es
un prototipo operacional o una
porción de un sistema operacional. Por lo
tanto, debe instituirse una estrategia
incremental de desarrollo. 11
El desarrollo ágil, según Cockburn, se
centra en los talentos y las habilidades de
los individuos, puesto que el proceso se
ajusta a personas y equipos específicos.
Si los miembros del equipo de software
van a manejar las características del
proceso que se aplica para construirlo,
debe existir rasgos clave entre los “ágiles”
y los demás miembros del equipo
Factores humanos
12
Los rasgos son los siguientes:
Competencia;
Enfoque común;
Colaboración;
Habilidad para la toma de decisiones;
Capacidad de resolución de problemas
confusos;
Confianza y respeto mutuo;
Organización propia.
13
Modelos ágiles de proceso
La historia de la IS está llena de decenas
de descripciones y metodologías, métodos
de modelado y notaciones, herramientas y
tecnologías obsoletas. Cada elemento
surgió con notoriedad y después lo eclipsó
algo nuevo y mejor.
Los modelos ágiles se ajustan al manifiesto
para el desarrollo de software y a los 12
principios detallados con anterioridad.
14
La XP, es una metodología para el desarrollo de proyectos software que trata de dar solución a los problemas de la IS desde un enfoque distinto al tradicional.
15
La XP, recibe este calificativo porque defiende un enfoque radical. Reconoce las bondades de las prácticas de las metodologías tradicionales y propone llevarlas hasta su extremo:
“Si diseñar es bueno, diseñemos todo el tiempo”
“Si las pruebas son buenas, probemos todo el tiempo”
16
La XP utiliza un enfoque OO, como su
paradigma de desarrollo preferido. La
XP abarca un conjunto de reglas y
prácticas que ocurren en el contexto
de 4 actividades del marco de trabajo:
Planeación;
Diseño;
Codificación;
Prueba.
17
Planeación
diseño
codificación
prueba
Incremento de software
velocidad calculada
del proyecto
Lanzamiento
Historias del usuario
valores
criterios de las pruebas de iteración
Plan de iteración
Diseño simple
cartas CRC
Soluciones pico
prototipos
Programación
en pareja
Integración continua
Prueba de unidad
Pruebas de aceptación
refabricación
Proceso de desarrollo extremo
18
Comunicación. Para ser efectiva, debe involucrar a todos los participantes en el proyecto, y debe ser libre y sincera; Simplicidad. Nunca debe perderse de vista que el objetivo de un proyecto es proporcionar valor al cliente; no es demostrar la pericia técnica del equipo ni construir una aplicación que resuelva más problemas que los del cliente;
Valores
19
Refabricación. No se puede dirigir adecuadamente un proceso si no se dispone de realimentación permanente sobre su progreso. La realimentación puede provenir del cliente, de los programadores, de herramientas automáticas, etc. Coraje. A veces, hacer lo que es correcto requiere valor. Por ejemplo, hay que tener coraje para reescribir código que funciona.
20
Los valores mencionados dan origen a cinco principios básicos:
1.- Conseguir realimentación rápida; 2.- No complicar las cosas con
suposiciones (asumir que las cosas son simples);
3.- Realizar cambios incrementales; 4.- Abrazar el cambio; 5.- Generar productos de calidad.
Principios
21
Prácticas
Los principios se manifiestan a través de las prácticas de XP. Son actividades que el equipo de un proyecto lleva a cabo cada día. Las 12 prácticas de la XP tienen su origen en prácticas conocidas en la IS y en el sentido común. Sin embargo, lo que caracteriza a este conjunto es la cohesión de todos los elementos, y que cada práctica ha sido llevada al extremo:
22
1. El juego de la planificación. Esta práctica busca dividir la funcionalidad de un proyecto en pequeños fragmentos autocontenidos, c/u de los cuales se denomina historia de usuario. 2. Entregas frecuentes. Se trata de publicar una nueva versión en cuanto sea posible aportar algún nuevo valor al cliente.
23
3. Diseño simple. El sistema debe ser el más simple posible que cumpla especificaciones (pruebas de aceptación). En un entorno donde los requisitos del cliente y sus prioridades cambian continuamente, no tiene sentido realizar un diseño sofisticado. La mejor forma de obtener una idea de los futuros requisitos de un sistema es proporcionar cuanto antes un prototipo;
24
4. Pruebas automáticas. ¿Cómo puede saber un programador que el código que ha escrito funciona realmente? ¿Cómo puede saber que seguirá funcionando siempre, incluso aunque lo refactorice? La única manera de asegurarlo con cierta confianza es escribiendo pruebas automáticas con las que pueda comprobar el código en cualquier momento y sin esfuerzo.
25
5. Integración continua. Nuevamente se lleva al extremo una práctica convencional de la IS. Si la integración es una fase crucial, en la que pueden aparecer errores, ¿por qué dejarla para el final, cuando el riesgo es mayor? Resulta más conveniente realizar integración continua (cada hora, cada día). Es imprescindible que el proceso de integración esté automatizado.
26
6. Refactorización. La refactorización es un proceso disciplinado por el cual se modifica el diseño de un módulo sin afectar a su comportamiento externo. Gracias a la refactorización, es posible compatibilizar el diseño simple con la flexibilidad. El coraje para refactorizar proviene de la disponibilidad de pruebas automáticas.
27
7. Programación por parejas. Llevar al extremo una práctica habitual: las revisiones formales de código. Si revisar el código es bueno, ¿por qué no revisarlo continuamente, incluso desde el mismo momento en el que se escribe por primera vez? En la programación por parejas, dos programadores comparten un único ordenador y colaboran para escribir el código o las pruebas
28
8. Propiedad colectiva del código. En el transcurso de una refactorización, o mientras se corrige un defecto, algún programador va a tener que modificar líneas de código escritas por otro programador. XP invita a llevar a cabo esa modificación con coraje, y el coraje procede de las pruebas automáticas.
29
9. Semana de 40 horas. Los programadores cansados se equivocan más. Si las semanas de más de 40 horas son la norma, algo no funciona bien en el proyecto; 10. Metáfora. El objetivo de esta práctica es encontrar una metáfora que ayude al equipo del proyecto y al cliente a hablar en los mismos términos, compartiendo una visión común del sistema;
30
11. Cliente en el equipo. Para lograr una realimentación ágil, el cliente no puede estar muy lejos del equipo; en una situación ideal, el cliente debe estar dentro del equipo. 12. Estándares de codificación. Es una necesidad cuando se trata de escribir código que otros programadores puedan entender y modificar..
31
Lo propuso Highsmith, como una técnica
para construir software y sistemas
complejos. Los apoyos filosóficos del DAS
se enfocan en la colaboración humana y la
organización propia del equipo.
Argumenta que un enfoque de desarrollo
ágil y adaptativo basado en la colaboración
es “tanto como una fuente de orden en las
complejas interacciones entre disciplina e
ingeniería”.
Desarrollo adaptativo de software (DAS)
32
especulación
colaboración
aprendizaje
Incremento de software
ajuste para ciclos subsecuentes
Lanzamiento
Planeación del ciclo adaptativo
enunciado de la misión
restricciones del proyecto
requisitos básicos
Plan de lanzamiento en el tiempo
Recopilación de requisitos
JAD
especificaciones mínimas
Componentes implementados/probados
grupos de enfoque para retroalimentación
revisiones técnicas formales
Post morten
Desarrollo Adaptativo de Software
33
Es un enfoque de desarrollo de
software ágil que “proporciona un
marco de trabajo para construir y
mantener sistemas con restricciones
de tiempo muy estrechas mediante el
empleo de la construcción de
prototipos incrementales en un
ambiente de proyecto controlado”
Método de desarrollo de sistemas dinámicos (MDSD)
34
Al igual que la PE y el DAS, el MDSD
sugiere un proceso iterativo de software.
En la red mundial hay una organización
(DSDM Consortium, www.dsdm.org) que
de manera colectiva asume el papel de
“conservador” del método. Esta
organización ha defindo un modelo ágil de
proceso, llamado el ciclo de vida del MDSD.
Este método define 3 ciclos iterativos
diferentes, a los cuales preceden 2
actividades del ciclo de vida adicionales: 35
Estudio de factibilidad. Establece los
requisitos básicos de negocio y las
restricciones asociadas con la aplicación del
método y para evaluar si la aplicación es
una candidata viable para el proceso del
MDSD.
Estudio de negocios. Establece los
requisitos funcionales y de información que
permitirán que la aplicación proporcione un
valor al negocio.
36
Iteración del modelo funcional. Produce
una serie de prototipos incrementales que
demuestran la funcionalidad para el cliente.
El propósito durante éste ciclo iterativo es
recopilar requisitos adicionales mediante la
retroalimentación de lo que obtiene el
usuario, mientras éste trabaja con el
prototipo.
Iteración de construcción y diseño.
Revisa la construcción de prototipos
durante la iteración del modelo funcional 37
Implementación. Coloca el incremento más
reciente (un prototipo “operacionalizado”) en
el ambiente operativo. Se debe destacar que:
1.El incremento puede no estar 100%
completo, o
2.Se pueden requerir cambios cuando el
incremento se coloca en el sitio.
En cualquier caso, el trabajo de desarrollo del
MDSD continúa al regresar a la actividad de
iteración del modelo de función.
38
El MDSD se puede combinar con la PE
para obtener un enfoque conjunto que
define un modelo sólido de proceso (el
ciclo de vida del MDSD) con los aspectos
prácticos (PE) necesarios para construir
incrementos de software. Además los
conceptos del DAS de colaboración y
equipos autoorganizados se pueden
adaptar a un modelo de proceso
combinado
39
Es un modelo (propuesto por Schwaber y
Beedle) ágil de proceso. Los principios de
la melé son consistentes con el manifiesto
ágil:
Los equipos de trabajo pequeños
están organizados para “maximizar la
comunicación, minimizar los gastos
generales y maximizar el hecho de
compartir conocimiento tácito e
informal”.
Melé
40
El proceso debe adaptarse a los
cambios técnicos y de negocios “para
asegurar que se produzca el mejor
producto posible”.
El proceso produce incrementos
frecuentes de software “los cuales se
pueden inspeccionar, ajustar, probar,
documentar y construir”.
El trabajo de desarrollo y la gente que
lo realiza están divididos en “particiones
o paquetes de bajo acoplamiento”. 41
Conforme se construye el producto se
realizan pruebas y documentación
constantes.
Los procesos de melé proporcionan la
“capacidad de declarar un producto como
´realizado´ siempre que esto se requiera
(porque la competencia acaba de hacer
un lanzamiento, porque la compania
necesita dinero, porque el usuario/cliente
necesita las funciones, porque ya se está
en el momento en que se prometió……. 42
Con los principios de la melé se guían
las actividades dentro de un proceso
que incorpora las siguientes
actividades del marco de trabajo:
requisitos, análisis, diseño, evolución y
entrega. En cada actividad del marco
de trabajo las tareas de trabajo
suceden dentro del patrón de proceso
llamado sprint
43
La melé subraya el uso de un conjunto
de “patrones de software” que ha
probado su efectividad en proyectos
con tiempos de entrega muy
reducidos, requisitos cambiantes y
condiciones críticas en los negocios.
Cada uno de estos patrones de proceso
define un conjunto de actividades de
desarrollo:
44
Retrasos: son una lista que considera la
prioridad de los requisitos o características
de proyecto que proporcionan un valor
comercial para el cliente. En cualquier
momento se pueden agregar elementos a
los retrasos (así se introducen los
cambios). El gerente de producto evalúa
los retrasos y actualiza las prioridades de
acuerdo con lo requerido.
45
Sprint: consiste en unidades de trabajo que
se requieren para satisfacer un requisito
definido en los retrasos en un periodo
predefinido (el lapso usual es de 30 días). En
esta etapa los elementos de los retrasos a los
que se dirigen las unidades de trabajo del
sprint están congelados (es decir, durante el
sprint no se introducen cambios). Por lo
tanto, el sprint permite a los miembros del
equipo trabajar en un ambiente enfocado al
corto plazo, pero estable. 46
Reuniones de melé: son reuniones cortas
(por lo general de 15 minutos) y las realiza a
diario el equipo de melé. Existen 3 preguntas
que plantean y responden todos los
miembros del equipo:
¿ Qué hiciste desde la última reunión?
¿ Cuáles obstáculos encontraste?
¿ Qué esperas lograr para la siguiente
reunión del equipo?
47
Un líder del equipo, llamado “maestro de
la melé”, preside la reunión y evalúa las
respuestas de cada persona. Cada reunión
de melé ayuda al equipo a descubrir
problemas potenciales tan pronto como
sea posible. Estas reuniones diarias
también conducen a la “socialización del
conocimiento”, y por ende, a promover
una estructura de equipo con organización
propia.
48
Demostración: se entrega el
incremento del software al cliente de
forma que éste demuestre y evalúe la
funcionalidad implementada. Es
importante señalar que la demostración
quizá no contenga toda la funcionalidad
planteada, sino aquellas funciones
susceptibles de entregarse dentro del
periodo establecido.
49
Flujo del proceso melé
Melé: reunión diaria de 15 minutos
Los miembros del equipo responden
a las preguntas básicas:
1.- ¿Qué hiciste desde la última reunión?
2.- ¿Tienes algún obstáculo?
3.- ¿Qué harás antes de la próxima reunión?
La nueva funcionalidad
se demuestra
al final del sprint
Retraso del producto:
Características del producto deseadas por
el cliente que han recibido prioridad
Elementos de
retraso expandidos
por el equipo
Retraso de Sprint:
Características
Asignadas al Sprint
30 días
Cada 24
horas
50
Beedle y sus colegas presentan un
análisis completo de estos patrones y
establecen:
“La melé supone la existencia
del caos…..”
El patrón de proceso de la melé permite
que un equipo de desarrollo de software
trabaje de manera exitosa en un mundo
donde la eliminación de la incertidumbre
es imposible.
51
Historia de usuario
Número: 1 Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia Número:
Iteración asignada: 2
Prioridad en negocio: Alta (Alta/Media/Baja)
Puntos estimados:
Riesgo en desarrollo (Alta/Media/Baja)
Puntos reales
Descripción:
Se introducen los datos del artículo (título, fichero adjunto, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con su login y password para que el autor pueda posteriormente acceder al artículo
Observaciones:
Historias de usuario
52
Nombre de la clase: PEDIDO
Responsabilidades Colaboradores
Revisar si existen elementos en existencia
Línea de pedidos
Determinar el precio Línea de pedidos
Revisa si el pago es válido
Cliente
Despacha a la dirección de entrega
Cartas CRC
53
Trabajo de investigación
Investigar por lo menos 5 métodos y/o
metodologías (OMT, Cristal Clear, Desarrollo
conducido por Características (DCC), Agile
Unified Process (AUP), Essential Unified Process
(EssUP), Feature Driven Development (LSD),
Open Unified Process (OpenUP), Ariadne
Development Method(ADM),etc.) de desarrollo:
1. Características;
2. Marco de trabajo;
3. Acciones y tareas por actividad;
4. Ventajas y Desventajas.
FECHA DE ENTREGA: 06-09-12 (enviar por correo y
presentar impreso)
54
Número: 1 Nombre: Gestión de Biblioteca
Usuario: Autor-de-historia-de-ususario
Modific. de Historia Número: Iteración asignada: 2
Prioridad en negocio: Alta (Alta/Media/Baja)
Puntos estimados:
Riesgo en desarrollo (A/M/B) Puntos reales
Descripción:
Se requiere un sistema de control de préstamos en una biblioteca. El sistema debe admitir altas, bajas de usuarios y de libros. Los usuarios pueden pedir libros en préstamo, pero no pueden tener más de dos libros en préstamo en un momento determinado. Los libros se han de devolver a las 48 horas de la fecha de préstamo. Cada vez que un usuario devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. Cuando llega a cero el socio se da de baja automáticamente. 55