INTRODUCCIÓN A LAINGENIERÍA DEL SOFTWARE

ACI491 – 482

Metodologías ágiles

¿Qué es una Metodología Ágil?www.agilealliance.com

Las Metodologías Ágiles (AMs) valoran: Al individuo y las interacciones en el equipo de

desarrollo más que a las actividades y las herramientas

Desarrollar software que funciona más que conseguir una buena documentación Minimalismo respecto del modelado y la documentación del sistema

La colaboración con el cliente más que la negociación de un contrato

Responder a los cambios más que seguir estrictamente una planificación

¿Por qué surgen las Metodologías Ágiles (AMs)?

Dificultad para implantar metodologías tradicionales. Sofisticadas herramientas CASE y notaciones (UML)

Una solución a medida para un segmento importante de proyectos de desarrollo de software

Pugna entre comunidades/gurús

“Aceptar el cambio” ...

Gestión del Conocimiento

Costo de los Cambios en SW

Costodel

cambio

tiempo

Tradicional

Suposición AMs

Manifiesto de las AMs agilemanifesto.org

Principios:1. La prioridad principal es satisfacer al cliente

mediante tempranas y continuas entregas de software que le reporte un valor

2. Dar la bienvenida a los cambios. Los AMs capturan los cambios para que el cliente tenga una ventaja competitiva

3. Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente

… Manifiesto de las AMs

4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto

5. Construir proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir el trabajo

6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo

7. El software que funciona es la medida principal de progreso

… Manifiesto de las AMs

8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante

9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad

10. La simplicidad es esencial

11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos

12. En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser más efectivo, y según esto ajusta su comportamiento

Comparación

Metodología Ágil Metodología No Ágil

Pocos Artefactos Más Artefactos

Pocos Roles Más Roles

No existe un contrato tradicional o al menos es bastante flexible

Existe un contrato prefijado

Cliente es parte del equipo de desarrollo (además in-situ)

El cliente interactúa con el equipo de desarrollo mediante reuniones

Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio

Grupos grandes

Menos énfasis en la arquitectura La arquitectura es esencial

Limitaciones

• Proporcionan una ayuda limitada en equipos de trabajo dispersos físicamente

• Proporcionan una ayuda limitada en equipos de trabajo grandes

• Consideran una ayuda limitada al tratamiento de subcontratos

• No privilegian la reutilización de componentes• Proporcionan una ayuda limitada para

desarrollar software de seguridad crítica• Proporcionan ayuda limitada para desarrollar

software grande y complejo• Dificultad en la utilización de herramientas que

apoyen el desarrollo

Tipos de Proyectos

Tradicionales

Grandes

Con requerimientos estables

Aplicaciones críticas

Grandes equipos de desarrollo

Equipo de desarrollo distribuídos geográficamente

Agiles

Ambientes dinámicos, con equipos de trabajo pequeños y produciendo aplicaciones no críticas

Requerimientos desconocidos o inestables, garantizando un menor riesgo ante la posibilidad de cambio en los requerimientos

Principales AMs

Crystal Methodologies, Alistarir Cockburn, www.crystalmethodologies.org

SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com

DSDM (Dynamic Systems Development Method), www.dsdm.org

Lean Programming, Mary Poppendieck, www.poppendieck.com

FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, www.nebulon.com/fdd, www.coad.com/peter/#fdd

Extreme Programming, Kent Beck www.extremeprogramming.org, www.xprogramming.com

Adaptative Software Development, Jim Highsmith www.adaptivesd.com

¿Qué resultado proveen las Metodologías Ágiles?

Hay pocos datos concretos del índice de éxito de proyectos

Está teniendo un gran auge Aumento en el número de proyectos ¿Por qué?

Tiene el apoyo de muchos gurús en ingeniería de sw

Es un proceso para gente que odia los procesos Tiene sentido ¿Política? ... Pugna entre comunidades

¿Cuándo utilizar una Metodología Ágil?

¿Existe ya un proceso? Si ¿Reacciona bien a los cambios? Si ¿Está el equipo contento con él? Si

Mejor esperar Se están recogiendo datos En un futuro se podrán hacer comparaciones

sobre lo que es más conveniente

... ¿Cuándo utilizar una Metodología Ágil?

¿Existe ya un proceso? Noo existe pero no reacciona bien a los cambioso existe pero el equipo no está contento con él

Una Metodología Ágil puede ser una buena

forma de empezar Fácil de financiar A los programadores les gusta A los clientes les gusta el mayor control

No existe una metodología universal para hacer frente con éxito a cualquier proyecto dedesarrollo de software.

Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.

Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes.

Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos que tienen estas características. Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo.

Esto ha llevado hacia un interés creciente en las metodologías ágiles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicación, tales como:

CONCLUSIONES (i)

están dirigidas a equipos pequeños o medianos (Beck sugiere que el tamaño de los equipos se limite de 3 a 20 como máximo, otros dicen no más de 10 participantes),

El entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo durante todo el tiempo

Cualquier resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio, etc.

Falta aún un cuerpo de conocimiento consensuado respecto de los aspectos teóricos y prácticos de la utilización de metodologías ágiles, así como una mayor consolidación de los resultados de aplicación.

CONCLUSIONES (ii)

Desarrollo individual v/s Grupal

Los proyectos de desarrollo de software de manera individual, es decir abordadospor una sola persona, son frecuentes en contextos particulares.

• Cuando se tiene poco presupuesto• Se requiere automatizar pequeñas tareas

Esta modalidad exige requisitos de calidad mínimos, por tanto, se requiere contarcon una metodología de desarrollo de software.

¿tiene experiencia en desarrollo de proyectosIndividuales?

Fuente: Universidad de Pamplona

PSP (Personal Software Process)

El PSP® es un marco de trabajo de procesos para guiar a los desarrolladores en:

•    Definir sus propios procesos

•    Planear y dar seguimiento a su propio trabajo

•    Administrar la calidad de sus propios productos de trabajo

El PSP® es un proceso personal que al estar basado en los principios de mejora,  ayuda a la gente a establecer sus metas personales, identificar qué métodos utilizarán, medir sus trabajo y analizar los resultados, para ajustar los métodos que utilizan para cumplir sus metas.

En conclusión, el PSP® es un proceso definido para ayudar a realizar mejor el trabajo, cuyo objetivo es obtener y reportar datos precisos y completos del trabajo que se realiza a nivel individual, con el fin de mejorar el proceso individual, afectando de esta manera al desempeño de todo el equipo.

Es un modelo de referencia de ingeniería de software que provee un énfasis en los procesos, los productos y el trabajo en equipo. El TSP® toma de base los principios de PSP para realizar los procesos y principios de ingeniería de software en un ambiente de trabajo en equipo. 

El TSP® enfatiza el trabajo en equipo porque:

•    Los equipos no se forman mágicamente,•    Los pasos para formar un equipo no son obvios,•    Se deben entender las fortalezas/debilidades de cada miembro del equipo y cómo estas soportan el desempeño del mismo.

Los equipos no son un accidente, se requiere una estrategia definida para trabajar juntos de manera coordinada, establecer responsabilidades y dar seguimiento al avance. Esto se logra teniendo metas comunes, acordando planes de acción y con un liderazgo apropiado.

TSP (Team Software Process) (i)

El Team Software Process no es una capacitación, usa los principios de PSP® para poner en práctica lo aprendido en el mismo y ayudar a formar y poner en marcha equipos de alto desempeño para producir productos de clase mundial, de manera cíclica, es decir al término de cada ciclo, el equipo debe entregar una versión del producto que pueda ser probada (que sea un subconjunto del producto final), de tal manera que los productos de los ciclos combinados generan el producto final.

Cada miembro del equipo, en un desarrollo TSP® planea sus actividades, da seguimiento a su trabajo y reporta su avance, controla sus propios procesos,  se involucra en la planeación y decisiones de todo el equipo y tiene roles y responsabilidades explícitas. 

TSP (Team Software Process) (ii)

Artefactos de un proceso de desarrollo

Dentro del Proceso de Desarrollo Unificado se denomina artefacto a todo producto o subproducto resultante del proceso. Dentro de esto se encuentra desde el propio código fuente hasta la documentación aportada por el cliente y la entregada al completarse cada hito dentro del proyecto. Para su mejor comprensión hemos agrupado todos los artefactos posibles del proceso en tres grandes grupos:

• Artefactos entregados por el cliente, • Artefactos internos del proceso y • Artefactos entregables al cliente

Artefactos de un proceso de desarrollo

No siempre en todo proyecto se crean los mismos artefactos, esto dependerá de las características del proyecto y los requisitos del cliente, siendo tarea de la gestión de la configuración el definir qué artefactos específicos y con qué nivel de formalidad se crearán para el proyecto en cuestión.

Artefactos de un proceso de desarrollo

• Glosario de Términos: Sólo existe uno para todo el sistema, que contiene un conjunto de definiciones concisas para favorecer la comunicación y evitar malos entendidos entre todos los involucrados. Los miembros del proyecto utilizarán el glosario inicialmente para comprender sus términos específicos. • Especificaciones de los casos de uso: Es una colección de documentos que recogen la especificación completa de cada caso de uso. Cada uno contiene los campos: nombre, descripción, actores, precondiciones, postcondiciones, flujo básico, flujos alternativos, puntos de extensión, entre otros que describen en detalle un caso de uso. • Modelo de casos de uso: Es un modelo de las funciones concebidas del sistema y su entorno. Es una entrada importante a actividades de análisis, diseño y prueba. Incluye todos los actores y casos de uso del sistema con sus descripciones. Puede ser entregado directamente en el formato que utilice la herramienta de modelación o gestión empleada, o mediante un informe de este modelo que contenga toda esta información que se complementará con las Especificaciones de los casos de uso.

Artefactos de un proceso de desarrollo

• Especificaciones suplementarias: Este artefacto captura los requerimientos del sistema que no fueron recogidos en el Modelo de casos de uso. Generalmente contiene los requerimientos no funcionales del sistema. • Especificación de requisitos del software: En los casos en que la empresa cliente no desee utilizar el enfoque de casos de uso para la gestión de requisitos, podrá entregar en lugar de los 3 artefactos descritos anteriormente un solo documento que recoja las características, requisitos funcionales y no funcionales del sistema, así como otra información útil como por ejemplo: restricciones en el diseño e implementación, componentes comprados a terceros, interfases de hardware o software, etc. • Documento de arquitectura del software: Este documento brinda un resumen de la arquitectura utilizando varias vistas diferentes que muestran distintos aspectos del sistema. Es un medio de comunicación entre el arquitecto de software y otros miembros del equipo del proyecto, acerca de las decisiones significativas que han sido tomadas para la arquitectura.

Artefactos de un proceso de desarrollo

• Modelo de diseño: Es una abstracción de la implementación del sistema que normalmente se utiliza para concebir y documentar su diseño. Es un artefacto compuesto que contiene todas las clases, subsistemas, paquetes, colaboraciones y las relaciones entre ellas. También contiene las realizaciones de los casos de uso. • Modelo de datos: Describe la representación física y lógica de los datos persistentes utilizados por la aplicación. Se utilizará siempre que se necesiten manejar datos persistentes. Usualmente describirá los diferentes elementos componentes de la estructura de una base de datos relacional. • Mapa de navegación: Expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los caminos de navegación principales. Existirá solamente uno de estos artefactos en el sistema y por lo general será empleado para aplicaciones Web.

Artefactos de un proceso de desarrollo• Prototipo de la interfaz de usuario: Es un ejemplo de la interfaz de usuario que se construye para validar y/o explorar su diseño. El grado de formalidad y herramientas utilizadas para generarlo puede variar mucho de proyecto en proyecto, pudiendo ir desde solo unas cuantas imágenes de pantallas hasta un esqueleto de interfaz de usuario ejecutable producido en un ambiente de Desarrollo rápido de aplicaciones (RAD : Rapid Application Development) o un conjunto de páginas HTML interactivas. En aplicaciones Web pueden ser las imágenes de las diferentes pantallas creadas por el diseñador gráfico.

Artefactos internos del proceso

• Plan de gestión de requisitos: Describe los artefactos de la disciplina, tipos de requisitos y sus respectivos atributos. Especifica la información que deberá ser obtenida y los mecanismos de control que deberán ser utilizados para reportar, medir, y controlar los cambios a los requisitos del producto. • Plan de pruebas: Contiene la definición de los objetivos de las pruebas, los elementos que deberán ser probados, los métodos que deberán utilizarse, los recursos necesarios y documentos a entregar. Usualmente se tiene uno de estos documentos con alcance global para todo el proyecto y uno por cada iteración del ciclo de vida del producto. • Guión de pruebas: Son las instrucciones paso a paso que indican como llevar a cabo una prueba. Pueden ser documentos con información textual que describa cómo realizar la prueba manualmente o archivos de instrucciones legibles por las máquinas que posibiliten la ejecución automatizada de la prueba.

Artefactos internos del proceso

• Informe resumen de las pruebas: Organiza y muestra un análisis resumido de los resultados de las pruebas que será entregado a los miembros del equipo de calidad para su revisión y evaluación. Adicionalmente puede contener un enunciado general de la calidad relativa y ofrecer recomendaciones para futuros esfuerzos de prueba. • Plan de gestión de configuración: Describe todas las actividades de Gestión de configuración y cambios que serán realizadas durante todo el ciclo de vida del proyecto. Brinda planificaciones detalladas de las actividades, responsabilidades asignadas, recursos necesarios que incluyen personal, herramientas y equipamiento. • Solicitud de cambio: Los cambios a los artefactos del proyecto se proponen mediante Solicitudes de cambio (Change Requests CR). Estos se utilizan para documentar y controlar defectos, solicitudes de mejoras o cualquier otra solicitud de cambios al proyecto. El beneficio de utilizarlos es que proporcionan un registro de las decisiones y, debido a su proceso evaluativo, se asegura que los impactos de los cambios sean entendidos por todos los miembros del equipo del proyecto.

Artefactos internos del proceso

• Plan de desarrollo de software: Es un artefacto compuesto que recoge toda la información necesaria para llevar a cabo la dirección del proyecto. Contiene otros planes no menos importantes que, al igual que éste son desarrollados desde la fase de inicio y mantenidos durante todo el ciclo de vida (Aseguramiento de la calidad, Gestión de riesgos, Métricas, Aceptación del producto y Resolución de problemas). • Plan de la iteración: Es un plan más refinado que contiene un conjunto secuencial de actividades, tareas y recursos asignados a una iteración, por lo que existirá un artefacto de este tipo por cada iteración del ciclo de vida del producto. Incluye los objetivos de la iteración, que son utilizados como criterio de evaluación y miden diferentes aspectos deseables a su final, como grado de terminación de la funcionalidad planificada, niveles de calidad, rendimiento, etc. • Evaluación de la iteración: Se realiza al final de la iteración y captura el grado en que se cumplió el criterio de evaluación, las lecciones aprendidas y los cambios a realizar en la planificación de las subsiguientes iteraciones en función del nuevo conocimiento adquirido. Es un artefacto esencial del enfoque iterativo de desarrollo de software.