gabinete de auditoria de sistemascotana.informatica.edu.bo/downloads/2.3 desarrollo agil.pdf ·...
TRANSCRIPT
MODULO II
Resumen preparado por Miguel Cotaña24/03/2020
2.3 DESARROLLO AGIL
1
GABINETE DE AUDITORIA DE SISTEMAS
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
Alistair Cockburn, argumenta que los
modelos prescriptivos de proceso
tienen una falla importante: olvidan las
fragilidades de las personas que
construyen el software de ordenador.
Asimismo, establece “como la consistencia
en la acción es una debilidad humana, las
metodologías que exigen un alto grado de
disciplina son frágiles”.5
Qué es la agilidad?
Un equipo ágil es un equiporápido que responde demanera apropiada a los“cambios”:
Cambios en el softwareque se va a construir;Cambios entre losmiembros del equipo;Cambios debidos a lasNTIC.
6
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;7
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;8
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.9
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 ?
10
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.11
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.12
Los incrementos de software (prototipos)
deben entregarse en cortos periodos para
que la adaptación mantenga un buen ritmo
con el cambio. Este enfoque iterativo le
permite al cliente evaluar el incremento del
software de manera regular, proporcionar
la retroalimentación necesaria al equipo de
software, e influir sobre las adaptaciones
del proceso que se realizan para adecuar la
retroalimentación.
13
Existe un debate en la actualidad sobre los
beneficios y la aplicabilidad del desarrollo
ágil del software como alternativa a
procesos de IS más convencionales.
Los tradicionalistas, prefieren producir
documentación nada fluida. Y los ágiles
dan sorpresas agradables en el negocio,
en base a un conjunto de ideas (tareas de
trabajo).
Políticas del desarrollo ágil:
14
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
15
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.
16
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.
17
La XP, es unametodología para eldesarrollo deproyectos softwareque trata de darsolución a losproblemas de la ISdesde un enfoquedistinto altradicional.
18
La XP, recibe este calificativo porquedefiende un enfoque radical.Reconoce las bondades de lasprácticas de las metodologíastradicionales y propone llevarlashasta su extremo:
“Si diseñar es bueno, diseñemos todo el tiempo”
“Si las pruebas son buenas, probemos todo el tiempo”
19
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.
20
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
21
Comunicación. Para ser efectiva,debe involucrar a todos losparticipantes en el proyecto, y debeser libre y sincera;Simplicidad. Nunca debe perdersede vista que el objetivo de unproyecto es proporcionar valor alcliente; no es demostrar la periciatécnica del equipo ni construir unaaplicación que resuelva másproblemas que los del cliente;
Valores
22
Refabricación. No se puede dirigiradecuadamente un proceso si no sedispone de realimentaciónpermanente sobre su progreso. Larealimentación puede provenir delcliente, de los programadores, deherramientas automáticas, etc.Coraje. A veces, hacer lo que escorrecto requiere valor. Por ejemplo,hay que tener coraje para reescribircódigo que funciona.
23
Los valores mencionados dan origen acinco principios básicos:
1.- Conseguir realimentación rápida;2.- No complicar las cosas con
suposiciones (asumir que lascosas son simples);
3.- Realizar cambios incrementales;4.- Abrazar el cambio;5.- Generar productos de calidad.
Principios
24
Prácticas
Los principios se manifiestan a travésde las prácticas de XP.Son actividades que el equipo de unproyecto lleva a cabo cada día. Las12 prácticas de la XP tienen suorigen en prácticas conocidas en laIS y en el sentido común. Sinembargo, lo que caracteriza a esteconjunto es la cohesión de todos loselementos, y que cada práctica hasido llevada al extremo:
25
1. El juego de la planificación.Esta práctica busca dividir lafuncionalidad de un proyecto enpequeños fragmentosautocontenidos, c/u de los cuales sedenomina historia de usuario.2. Entregas frecuentes. Se tratade publicar una nueva versión encuanto sea posible aportar algúnnuevo valor al cliente.
26
3. Diseño simple. El sistema debeser el más simple posible que cumplaespecificaciones (pruebas deaceptación). En un entorno donde losrequisitos del cliente y sus prioridadescambian continuamente, no tienesentido realizar un diseño sofisticado.La mejor forma de obtener una ideade los futuros requisitos de un sistemaes proporcionar cuanto antes unprototipo;
27
4. Pruebas automáticas. ¿Cómopuede saber un programador que elcódigo que ha escrito funcionarealmente? ¿Cómo puede saber queseguirá funcionando siempre, inclusoaunque lo refactorice?La única manera de asegurarlo concierta confianza es escribiendopruebas automáticas con las quepueda comprobar el código encualquier momento y sin esfuerzo.
28
5. Integración continua.Nuevamente se lleva al extremo unaprá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? Resultamás conveniente realizar integracióncontinua (cada hora, cada día). Esimprescindible que el proceso deintegración esté automatizado.
29
6. Refactorización. Larefactorización es un procesodisciplinado por el cual se modifica eldiseño de un módulo sin afectar a sucomportamiento externo.Gracias a la refactorización, esposible compatibilizar el diseñosimple con la flexibilidad.El coraje para refactorizar provienede la disponibilidad de pruebasautomáticas.
30
7. Programación por parejas.Llevar al extremo una prácticahabitual: las revisiones formales decódigo. Si revisar el código es bueno,¿por qué no revisarlo continuamente,incluso desde el mismo momento enel que se escribe por primera vez? Enla programación por parejas, dosprogramadores comparten un únicoordenador y colaboran para escribir elcódigo o las pruebas
31
8. Propiedad colectiva del código.En el transcurso de unarefactorización, o mientras se corrigeun defecto, algún programador va atener que modificar líneas de códigoescritas por otro programador.XP invita a llevar a cabo esamodificación con coraje, y el corajeprocede de las pruebas automáticas.
32
9. Semana de 40 horas. Losprogramadores cansados seequivocan más. Si las semanas demás de 40 horas son la norma, algono funciona bien en el proyecto;10. Metáfora. El objetivo de estapráctica es encontrar una metáforaque ayude al equipo del proyecto y alcliente a hablar en los mismostérminos, compartiendo una visióncomún del sistema;
33
11. Cliente en el equipo. Paralograr una realimentación ágil, elcliente no puede estar muy lejos delequipo; en una situación ideal, elcliente debe estar dentro del equipo.12. Estándares de codificación. Esuna necesidad cuando se trata deescribir código que otrosprogramadores puedan entender ymodificar..
34
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)
35
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
36
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)
37
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:38
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.
39
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 funcional40
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.
41
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
42
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é
43
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”.44
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ó…….45
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
46
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:
47
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.
48
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.49
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?
50
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.
51
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.
52
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
53
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.
54
Cristal
Cockburn y Highsmith crearon la familia
cristal de los métodos ágiles, en base a
la “manejabilidad”, que caracterizan
como “un juego cooperativo de inventiva
y comunicación con recursos limitados,
con una meta primaria: consistente en
la entrega de software útil y en
funcionamiento, y una meta
secundaria: de prepararse para el
juego siguiente”
55
Para alcanzar la menejabilidad, definieron
un conjunto de metodologías, cada una de
ellas con elementos esenciales comunes a
todas, y funciones, patrones de proceso,
productos de trabajo y prácticas únicas en
cada una de ellas. La familia cristal es un
conjunto de procesos ágiles.
El objetivo es permitir que los equipos
ágiles seleccionen el miembro de la familia
cristal más apropiado para su proyecto y
ambiente.56
Desarrollo conducido por características (DCC)
Peter Coad, lo concibió como un modelo
de proceso práctico para la IS OO. S.
Palmer y J. Felsing, mejoraron, al
describir un proceso adaptativo y ágil
que puede aplicarse en proyectos de
software de tamaño moderado y grande.
Una característica “es una función
valuada por el cliente que puede
implementarse en 2 semanas o
menos”
57
Esta característica proporciona los
siguientes beneficios:
Como las características son bloques
pequeños de funcionalidad entregable,
los usuarios las describen con mayor
facilidad, pueden entender cómo éstas se
relacionan con otras con mayor rapidez,
y pueden revisarlas de mejor manera en
búsqueda de ambigüedades, errores u
omisiones.
58
Las características se pueden
organizar en un agrupamiento
jerárquico relacionado con el negocio.
Como una característica es el
incremento de software entregable, el
equipo desarrolla características
operativas cada dos semanas.
59
Debido a que las características son
pequeñas, sus diseños y
representaciones de código son más
fáciles de inspeccionar de manera
efectiva.
La planeación del proyecto, la
elaboración de su programa y su rastreo
los guía la jerarquía de la característica,
en lugar de hacerlo un conjunto de
tareas de IS adaptado en forma
arbitraria.60
Coad, sugiere la siguiente plantilla para
definir una característica:
<acción> el <resultado> <por|para|de|a> un <objeto>
Donde un <objeto> es “una
persona, sitio o cosa (incluyendo
papeles, momentos en el tiempo o
intervalos de itiempo, o descripciones
del tipo de catálogo de entrada)”.
61
Los ejemplos de las características para
una aplicación de comercio electrónico
podrían ser:
Agregar el producto a un carrito
de supermercado
Desplegar las especificaciones
técnicas de un producto
Almacenar la información de
navegación para un cliente
62
Un conjunto de aspectos relevantes
agrupa características relacionadas en
categorías relacionadas con el negocio:
<acción> <-ar, -er, -ir> un <objeto>
Por ejemplo, hacer la venta del
producto es un conjunto de
características que podría abarcar las
características relacionadas con
anterioridad y otras
63
El enfoque del DCC define 5 actividades de
“colaboración” dentro del marco de
trabajo (en el DCC éstas se llaman
procesos):
Desarrollar
un modelo
general
Elaborar una
lista de
características
Plan
por
característica
diseño
por
característica
construcción
por
característica
Más forma
que contenido
Una lista de
Características
Agrupadas en
Conjuntos y
Áreas de
contenido
Un plan de desarrollo
Propietarios de clase
Propietarios del conjunto
de características
Un paquete
de diseño
(secuencias)
Función
Cliente-volar
completada
64
El DCC define 6 puntos de fijación
durante el diseño y la implementación
de una característica:
Ensayo del diseño
Diseño
Inspección de diseño
Código
Inspección del código
Promoción de la construcción
65
Modelado ágil (MA)
En muchas situaciones los IS deben
construir sistemas grandes y críticos para
los negocios. El ámbito y la complejidad de
dichos sistemas se deben modelar de
forma que:
1) Todas las circunscripciones entiendan mejor
lo que se debe lograr.
2) El problema se divida de manera efectiva
entre la gente que lo debe resolver.
3) La calidad se evalúe en cada paso conforme
el sistema se desarrolla y construye.
66
El modelado ágil es una colección de
valores, principios y prácticas para el
modelado de software que puede
aplicarse en un proyecto de desarrollo de
software de una manera efectiva y
ligera.
Ambler, sugiere valor y humildad. Un
equipo ágil debe tener el valor para
tomar decisiones que ocasionarán el
rechazo y la refabricación de un diseño
67
Debe tener humildad de reconocer que
quienes manejan la tecnología no tienen
todas las respuestas, y que los expertos
en negocios y otros participantes de la
empresa son dignos de respeto y
consideración.
A pesar de que el MA sugiere un arreglo
amplio de principios de modelado
“esenciales” y “suplementarios”.
68
Los responsables de que el MA sea único
son los siguientes:
Modelar con un propósito. Un
desarrollador que use el MA debe tener una
meta específica en mente antes de crear el
modelo.
Usar múltiples modelos. Cada modelo
debe presentar un aspecto diferente del
sistema, y sólo aquellos modelos que
proporcionan un valor para la audiencia a la
que están dirigidos deben usarse.69
Viajar ligero. Cada vez que se decide conservar
un modelo se intercambia la agilidad por la
conveniencia de tener la información disponible
para el equipo de una forma abstracta.
El contenido es más importante que la
representación. El modelado debe comunicar
información a la audiencia.
Conocer modelos y herramientas. Entender
fortalezas y debilidades.
Adaptarse en forma local. A las necesidades
del equipo ágil.
70
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 delos autores debe indicarse como autor de contacto. El sistemaconfirma la correcta recepción del artículo enviando un e-mailal autor de contacto con su login y password para que elautor pueda posteriormente acceder al artículo
Observaciones:
Historias de usuario
71
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
72
Trabajo de investigación
Investigar por lo menos 5 métodos,
metodologías (OMT, SCRUM, OOHDM,
etc.) de desarrollo de productos
software, detallando:
1. Características;
2. Marco de trabajo;
3. Acciones y tareas por actividad;
4. Ventajas y Desventajas.
FECHA DE ENTREGA: 17-09-09 (enviar
por correo y presentar impreso)
73