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