Metodos_Agiles_INGENIERIA DEL SOFTWARE

Vista previa del material en texto

CONTENIDO 
 
 TEMAS A DESARROLLAR FUENTE BIBLIOGRÁFICA 
 - Sommerville I., Cap. 3 
 - Pressman R., Cap. 3 
 
 
 
 
 
 
 
 
Curso de Auditorías 3 
Dirigidos por un 
Plan 
 Plan por Anticipado 
 Mide Avance/Planif. 
 Proceso de Desarrollo muy 
estructurado 
 
Proc. ágiles 
 Plan Incremental 
 Modif. simple del proceso 
 Proceso menos formal y flexible 
Sistemas Críticos Sistemas con requerim. 
rápidamente modificables 
(Empresariales) 
Curso de Auditorías 4 
“Se diseñan para 
producir rápidamente un 
software útil” 
 
No se desarrolla como una sola unidad, sino como una serie de 
incrementos y cada una de ellos incluye una nueva 
funcionalidad del sistema 
Curso de Auditorías 5 
 Los procesos de especificación, diseño e implementación 
están entrelazados. 
 El sistema se desarrolla en diferentes versiones. 
 Las interfaces de usuario del sistema se desarrollan 
utilizando herramientas interactivas rápidas para el diseño 
y construcción. 
Curso de Auditorías 6 
Programación extrema (Beck, 1999-2000) 
Scrum (Schwaber y Beedle, 2001) Crystal Clear (Cockburn, 2001) 
Desarrollo de software adaptable ASD (Highsmith, 2000) 
Método de desarrollo de sistemas dinámicos - DSDM (Stapleton, 1997) 
Desarrollo dirigido por características FDD (Palmer y 
Felsing, 2002) 
Modelado ágil (Ambler y Jeffries, 
2002). 
Instanciaciones ágiles del RUP 
(Larman, 2002) 
IBM Desarrollo Incremental (Mills, 1980) Leng. de 4ta. Generac.(Martin, 1981) 
 
 
 PRINCIPIO 
1- Participación del Cliente 
 
 
2- Entrega incremental 
 
 
3- Personas, no procesos 
 
 
4- Adoptar el cambio 
 
5- Mantener simplicidad 
 
 
 
 
 
 
 
 
DESCRIPCIÓN 
-Los clientes deben intervenir estrechamente durante el 
proceso de desarrollo. Su función consiste en ofrecer y 
priorizar nuevos requerimientos del sistema y evaluar las 
iteraciones del mismo 
-El software se desarrolla en incrementos y el cliente 
especifica los requerimientos que se van a incluir en cada 
incremento 
-Tienen que reconocerse y aprovecharse las habilidades del 
equipo de desarrollo. Debe permitirse a los miembros del 
equipo desarrollar sus propias formas de trabajar sin 
procesos establecidos. 
-Esperar a que cambien los requerimientos del sistema y de 
este modo diseñarlo para adaptar dichos cambios 
- Enfocarse en la simplicidad tanto en el software a 
desarrollar como en el proceso de desarrollo. Siempre que 
sea posible, trabajar de manera activa para eliminar la 
complejidad del sistema 
Curso de Auditorías 8 
 Es difícil que el cliente pueda pasar mucho tiempo con el Equipo 
de Desarrollo (ED) y que represente a todos los participantes del 
sistema. 
 Puede ser que algunos integrantes del ED no puedan interactuar 
adecuadamente con el resto del equipo. 
 Priorizar los cambios es difícil en sistemas con muchos 
participantes 
 Al trabajar con escaso tiempo para las entregas, el ED quizás no 
pueda realizar las simplificaciones deseables al sistema. 
 Para grandes Empresas resulta complicado trabajar con un 
modelo de trabajo con procesos informales y definidos por un ED. 
 
 
Curso de Auditorías 9 
 La tercerización del desarrollo , dificulta la especificación 
incremental propia de los métodos ágiles y la elaboración de 
contratos para este tipo de desarrollo. (Contratos x Tiempo de Des.) 
 Resulta difícil mantener el sistema con una escasa documentación 
formal 
 Luego de entregar el software es complicado mantener al cliente 
interviniendo en el proceso . 
 Un problema potencial es mantener la continuidad del ED. Se 
puede llegar a perder conocimiento implícito al cambiar el ED. 
 
 
 
Curso de Auditorías 10 
Dirigidos por un 
Plan 
 Identifica etapas separadas en el 
proceso del software con salidas 
asociadas a cada etapa. 
 Las salidas de una etapa se usan 
como base para planear la siguiente 
actividad del proceso. 
 La iteración ocurre dentro de las 
actividades con documentos formales 
que se utilizan para comunicarse 
entre etapas del proceso. 
 Los Req. generan una especificación 
que son entradas para el proceso de 
Diseño. 
 
 
 
 
Proc. ágiles 
 Consideran al Diseño (D) y la 
Implementación (I) como 
actividades centrales 
 Incorporan en el D+I , otras 
actividades como la adquisición 
de requerimientos(RQ) y pruebas 
 La iteración ocurre a través de 
las actividades. 
 Los RQ y el D se desarrollan en 
conjunto, no por separado. 
Curso de Auditorías 11 
Curso de Auditorías 12 
- Para decidir sobre el equilibrio entre un enfoque basado en un plan y uno ágil se deben 
responder algunas preguntas técnicas, humanas y organizacionales 
Curso de Auditorías 13 
Curso de Auditorías 14 
“Irrelevante para el 
cliente que compra un 
sistema de software” 
 
Lo importante para los clientes es si cuentan con un sistema de 
software ejecutable que cubra sus necesidades y realice 
funciones útiles 
Curso de Auditorías 15 
Curso de Auditorías 16 
Curso de Auditorías 17 
Curso de Auditorías 18 
Tarjetas de historia: son las entradas principales al 
proceso de planeación de XP 
Tarjetas de Tareas 
 Estimación del esfuerzo 
 Recursos requeridos para 
implementar la tarea 
 Discusión con el cliente para refinar 
los requerimientos 
* 
 El cliente prioriza las 
historias 
 Elige las historias que 
pueden utilizarse 
inmediatamente para 
entregar apoyo 
empresarial 
 Se intentará identificar funcionalidades útiles que puedan 
implementarse en aproximadamente 2 semanas 
Curso de Auditorías 19 
Curso de Auditorías 20 
Curso de Auditorías 21 
1. Desarrollo de primera prueba ( se desarrolla mientras se escribe 
el código) 
2. Desarrollo de pruebas incrementales a partir de escenarios 
(cada tarea genera una o más pruebas de unidad que verifican la 
implementación descripta en dicha tarea) 
3. Involucramiento del usuario en el desarrollo y la validación de 
pruebas ( el cliente ayuda a desarrollar pruebas de aceptación 
para las historias, que deban implementarse en la siguiente 
liberación) 
4. Utilización de marcos de pruebas automatizadas ( Las pruebas 
se escriben como componentes ejecutables antes de 
implementar la tarea. Deben ser independientes , simular el 
envío de la entrada a probar y verificar que el resultado cumple 
con la especificación de la salida) 
 
 
Curso de Auditorías 22 
Curso de Auditorías 23 
 Los programadores prefieren programar que probar y escriben 
pruebas incompletas que no comprueban todas las posibles 
excepciones 
 Algunas pruebas llegan a ser muy difíciles de escribir de manera 
incremental. En una interfaz de usuario compleja, las pruebas de 
unidad entre la “lógica de despliegue” y el “flujo de trabajo” es 
muy difícil de implementar. 
 Es difícil juzgar la totalidad de un conjunto de pruebas. Aunque 
tenga muchas pruebas de sistema, partes críticas del sistema 
pueden no ejecutarse y no ser probadas. 
 Si las pruebas no se revisan y se escriben más pruebas después 
del desarrollo, entonces pueden entregarse errores en el 
programa durante la liberación del sistema. 
 
 
 
Curso de Auditorías 24 
“Dirigir el proyecto -> el SW 
sea entregado a tiempo con 
el presupuesto paneado ” 
 
Supervisan el trabajo de los ingenieros de software 
y monitorean el avance del desarrollo 
Curso de Auditorías 25 
Dirigidos por un 
Plan 
 Los administradores se 
apoyan en el Plan para 
administrar el proyecto. 
 El plan muestra lo que se 
debe entregar y cuándo. 
 El plan establece quién 
trabajará en el desarrollo 
de las entregas del 
proyecto. 
 
 
 
 
 
Proc. ágiles 
 No se puede utilizar el “Enfoque 
estándar”, debido a que: 
- Los requerimientosse desarrollan 
incrementalmente 
- El software se entrega en rápidos 
incrementos cortos 
- Los cambios a los requerimientos y 
al software son permanentes 
Enfoque estándar 
Curso de Auditorías 26 
“Se focaliza en la 
administración iterativa 
del desarrollo” 
 
-No se centra en enfoques técnicos específicos 
-No prescribe el uso de prácticas de programación, como la prog. en pares. 
- Puede usarse complementado enfoques ágiles más técnicos como XP 
 
Curso de Auditorías 27 
- Se establecen los 
objetivos generales 
del proyecto y el 
diseño de la 
arquitectura 
 
-Cada ciclo desarrolla un 
incremento del sistema. 
- Completa la Doc. requerida 
(marcos de ayuda del sistema, 
manuales del usuario,etc.) 
- Valora las lecciones aprendidas 
en el proyecto. (Restrospectiva) 
 
Curso de Auditorías 28 
- Al final de un sprint, la 
funcionalidad completa 
se entrega a los 
participantes 
(Entregable) 
 
dsdsdsdsdsdsdsdsdsdsd
sdsdsdsdsdsdsdsdsdsds
dsdsdsdsdsdsdsdsdsdsd
sdsdsdsdsds 
- Se valora el trabajo 
que se va a realizar. 
 
- Se seleccionan las 
particularidades por desarrollar. 
- Se implementa el software. 
 
- Un Sprint de Scrum es una “Unidad de planeación” 
“Un Sprint puede durar 
entre 2 y 4 semanas” 
 
“Un Sprint suele incluir varios 
requerimientos del cliente, 
comenzando por los más prioritarios” 
 
“No se pueden incluir cambios durante un 
sprint, hay que esperar que termine e 
introducirlos en el ´próximo” 
 
Curso de Auditorías 29 
incremento de 
software 
potencialmente 
entregable 
ScrumMaster; mantiene los 
procesos y trabaja de forma 
similar al director de proyecto 
Product Owner: 
representa los intereses 
del cliente. Escribe las 
historias de usuario, las 
prioriza, y las coloca en 
el Product Backlog 
Team: tiene la responsabilidad de 
entregar el producto. Un pequeño 
equipo de 3 a 9 personas que realizan el 
trabajo de análisis, diseño, desarrollo, 
pruebas, documentación, etc. 
Los elementos del 
Product Backlog 
(PB) que forman 
parte del sprint se 
determinan durante 
la reunión de Sprint 
Planning. Allí el 
Product Owner 
identifica los 
elementos del PB a 
ser completados y 
comunicados al 
equipo 
Cada día de un sprint, se realiza la reunión 
sobre el estado de un proyecto. Esto se llama 
daily standup o Stand-up meeting. 
Curso de Auditorías 30 
Pila del producto (product backlog): lista 
de requisitos de usuario que a partir de la 
visión inicial del producto crece y 
evoluciona durante el desarrollo 
Pila del sprint (sprint backlog) : lista de 
los trabajos que debe realizar el equipo 
durante el sprint para generar el 
incremento previsto. 
Incremento: Resultado de cada 
sprint. Cada Sprint incluye 
planificación, desarrollo, testing, 
integración, y un entregable al final. 
(Generalmente todo se realiza entre 
dos y cuatro semanas) 
Los requerimientos se sacan 
del product backlog y se 
pasan al sprint backlog 
Curso de Auditorías 31 
Curso de Auditorías 32 
 El Equipo (Team) debe ser polifuncional, compuesto por siete 
miembros (más/menos dos). Su labor consiste en seleccionar el 
objetivo final de cada sprint, especificar los resultados del trabajo y 
llevarlo a cabo. 
 El Equipo (Team), posee el derecho de realizar lo que sea dentro de los 
límites que impongan los lineamientos del proyecto, para alcanzar el 
objetivo final de un sprint. Debido a que opera como una “caja negra”, 
debe organizarse a sí mismo y a su trabajo, y debe preparar una demo 
de los resultados para exhibir ante el Dueño del producto (Product 
Owner). 
 Es el encargado de cubrir todas las necesidades que se presentan para 
generar el producto final, es un equipo multidisciplinar, normalmente 
consta de un analista, un diseñador , un codificador, de una persona 
que documenta, de una persona de QA(Aseguramiento de la Calidad). 
 
 
 
 
Curso de Auditorías 33 
 El propietario del producto o “product owner” es la persona que toma 
las decisiones por parte del cliente. Es la persona designada por el 
cliente para que se encargue del proyecto. 
 Es la única persona que conoce lo que el cliente quiere y todo el entorno 
de negocio; como tal es la persona que esta más interesada en tener un 
producto final, también es la persona encargada del Product Backlog. 
 Es la persona encargada que el producto final este de acorde con lo que 
el cliente quiere. 
 Las responsabilidades del Dueño del producto incluyen: 
- Definir las características del producto 
- Determinar la fecha de lanzamiento y el contenido 
- Ajustar las características y las prioridades cada treinta días (según sea 
necesario) 
- Aceptar o rechazar resultados del trabajo. 
 
 
 
 
 
 
Curso de Auditorías 34 
 El Scrum Master es un facilitador, que trabaja en contacto estrecho 
con el Dueño del producto. 
 Sus responsabilidades abarcan: 
 - Asegurar que el equipo se mantenga plenamente funcional y productivo 
- Permitir la cooperación estrecha entre todos los roles y funciones 
- Eliminar las barreras que obstaculicen el desarrollo del proyecto 
- Proteger al equipo de las interferencias externas 
- Asegurar que el proceso (SCRUM) se lleve a cabo correctamente, asegurando 
la concurrencia de los involucrados a las reuniones diarias de Scrum, a las 
revisiones de sprint y a las planificaciones de sprint. 
 
 
Curso de Auditorías 35 
 Los sprints tienen longitud fija de 2 a 4 semanas. 
 El punto de partida para la Planeación es la lista de trabajos por 
realizar en el proyecto. 
 Durante la fase de Valoración del sprint este se revisa y se 
asignan prioridades y riesgos. 
 El cliente interviene estrechamente en el proceso de valoración, 
y al comienzo de cada sprint puede introducir nuevos 
requerimientos o tareas. 
 La fase de Selección incluye a todo el equipo del proyecto que 
trabaja con el cliente, con el objeto de seleccionar las 
características y la funcionalidad a desarrollar durante el sprint. 
 Una vez acordadas las características y la funcionalidad, el 
equipo se organiza para desarrollar el software. 
 
 
 
 
 
Curso de Auditorías 36 
 Con el objetivo de revisar el progreso y si es necesario volver a asignar 
prioridades al trabajo, se realizan reuniones diarias breves con todos 
los miembros del equipo. (Daily Scrum Meeting) 
 Durante el desarrollo , el equipo se aísla del cliente y de la organización 
y todas las comunicaciones se canalizan a través el “Scrum Master” 
(SM) o “Scrum Manager” 
 El SM tiene como función principal proteger al equipo de desarrollo de 
distracciones externas . 
 A diferencia de XP, Scrum no hace sugerencias específicas sobre como 
escribir requerimientos, desarrollar la primera prueba, etc. Sin 
embargo esas prácticas de XP se pueden utilizar cuando el equipo las 
considere adecuadas. 
 Al final del Sprint en curso, el trabajo realizado se revisa y se presenta a 
los participantes. Luego comienza el siguiente ciclo de sprint. 
 
 
 
 
Curso de Auditorías 37 
 En Scrum, todo el equipo está autorizado a para tomar decisiones de 
modo que se evita deliberadamente el término “Administrador del 
proyecto”. 
 El SM es el facilitador que ordena las reuniones diarias rastrea el atraso 
del trabajo a realizar, registra las decisiones, mide el progreso del atraso 
y se comunica con los clientes y administradores fuera del equipo. 
 Todo el equipo asiste a las reuniones diarias, que en ocasiones los 
participantes ni siquiera se sientan para hacerlas breves y enfocadas. 
 Durante la reunión todos los miembros del equipo comparten 
información , describen sus avances desde la última reunión, los 
problemas que han surgido y los planes del día siguiente. 
 Todos en el equipo conocen lo que acontece y si surgen problemas, 
replantean el trabajo en el corto plazo para enfrentarlo. 
 Todos participan de la planeación, no hay dirección descendente desde 
el SM. 
Curso de Auditorías 38 
t 
Curso de Auditorías 39 El producto se desglosa en un conjunto de piezas manejables y 
comprensibles. 
 Los requerimientos inestables no retrasan el progreso . 
 Todo el equipo tiene conocimiento de todo y en consecuencia se mejora 
la comunicación entre los miembros del mismo. 
 Los clientes observan la entrega a tiempo de los incrementos y obtienen 
retroalimentación sobre cómo funciona el producto. 
 Se establece la confianza entre clientes y desarrolladores, a la vez que se 
crea una cultura positiva donde todos esperan el triunfo del proyecto. 
 BIBLIOGRAFÍA 
 
- Sommerville, Ian, Ingeniería del Software,Pearson-Addison Wesley, 9na. Ed.,2011. 
- Pressman, Roger S. ,Ingeniería de Software, Un enfoque práctico, Mc. Graw Hill, 
7ma.Ed.,2010.