Contenido Introducción

Contenido

• Introducción

• Contexto

• Manifiesto Ágil

• Reflexiones

• FDD

• Scrum

• Open-source

• AUP

Introducción

Contexto

• Nandhakumar & Avison 1999

• Metodologías tradicionales de desarrollo de sistemas de información “son tratadas principalmente como una ficción necesaria para presentar una imagen de control o para proveer un estatus simbólico”.

• Truex et al. 2000

• Es posible que los métodos tradicionales sean “meramente ideales inalcanzables y hipotéticos straw-men que proveen una guía normativa a situaciones de desarrollo utópicas.”

• McCauley 2001

• La filosofía en la cual se basan los métodos orientados a procesos establece que los requerimientos de un proyecto de software quedan congelados antes de que el diseño y desarrollo del software comience.

Manifiesto por el Desarrollo Ágil

• Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar:

• Individuos e interacciones sobre procesos y herramientas

• Software que funciona sobre documentación exhaustiva

• Colaboración con el cliente sobre negociación de contratos

• Responder ante el cambio sobre seguimiento de un plan

• Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.

Principios

• Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor.

• Aceptamos requisitos cambiantes, incluso en etapas avanzadas.

• Entregamos software frecuentemente.

• Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto.

• Construimos proyectos con profesionales motivados.

• Conversación cara a cara.

• Software que funciona es la principal medida de progreso.

• Los procesos ágiles promueven el desarrollo sostenible.

• La atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad.

• Simplicidad es esencial.

• Las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan.

• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo.

Reflexiones

• Highsmith & Cockburn 2001

• “lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que reconozcan a las personas como primeros implicados en el éxito de un proyecto, además de un intenso foco en la efectividad y la manejabilidad. Esto genera una nueva combinación de valores y principios que definen una visión ágil del mundo.”

Reflexiones (2)

• Hawrysh & Ruprecht 2000

• Una sola metodología no puede funcionar para todo el espectro de proyectos, en vez de eso el administrador de cada proyecto debería identificar la naturaleza especifica de cada proyecto y seleccionar la mejor metodología de desarrollo aplicable.

• McCauley 2001

• Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya que no hay un modelo de desarrollo que se ajuste a todos los propósitos imaginables.

¿Cuando un método es ágil?

• El desarrollo de software es

• Incremental
• liberaciones pequeñas y ciclos rápidos.
• Cooperativo
• clientes y desarrolladores trabajando juntos.
• Simple y Directo
• el método es fácil de aprender y modificar.
• Adaptativo
• es posible realizar cambios de último momento.

Feature Driven Development

• FDD

• Es un proceso ágil diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca.

• Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar.

• Las iteraciones se deciden en base a features o funcionalidades, que son pequeñas partes del software con significado para el cliente.

Feature Driven Development

• A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción.

• No requiere un modelo específico de proceso y se complementa con otras metodologías.

• Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso.

FDD

• FDD define tres categorías de roles:

• Roles claves

• - Gerente del proyecto

• - Arquitecto jefe

• - Gerente de desarrollo

• - Programador jefe

• - Propietarios de clases

• - Experto de dominio

• Roles de soporte

• - Administrador de entrega

• - “Guru” de lenguaje

• - “Herramientista” (toolsmith)

• - Administrador del sistema

• Roles Adicionales

• - “Tester”

• - Escritores de documentos técnicos

Proceso 1

Proceso 2

• FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el sistema.

• La parte iterativa soporta desarrollo ágil con rápidas adaptaciones a cambios en requerimientos y necesidades del negocio.

• Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida.

Proceso Fases 1

• Desarrollo de un modelo general:

• Cuando comienza el desarrollo, los expertos de dominio están al tanto de la visón, el contexto y los requerimientos del sistema a construir. A esta altura se espera que existan requerimientos tales como casos de uso o especificaciones funcionales.

• Construcción de la lista de rasgos:

• Los ensayos, modelos de objeto y documentación de requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos son pequeños ítems útiles a los ojos del cliente. La lista de rasgos es revisada por los usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que requieran de más de diez días se descomponen en otros más pequeños.

Proceso Fases 2

• Planeamiento por rasgos:

• Incluye la creación de un plan de alto nivel, en el que los conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se asigna a los programadores jefes.

• Diseño por rasgos y Construcción por rasgos:

• Se selecciona un pequeño conjunto de rasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equipos dispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgos seleccionados. Una iteración puede tomar de unos pocos días un máximo de dos semanas. El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.

Experiencias en su uso

• Algunos “agilistas” sienten que FDD es demasiado jerárquico para ser un método ágil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos.

• Otros críticos sienten que la ausencia de procedimientos detallados de prueba en FDD

• es llamativa e impropia.

• FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de 1990. Los autores sugieren su uso para proyectos nuevos o actualizaciones de sistemas existentes y recomiendan adoptarlo en forma gradual.

Open-source

• El término refiere en principio a una forma de licencia que debe tener fundamentalmente las siguientes características:

• Libre redistribución.

• Código fuente abierto.

• La redistribución de modificaciones debe estar permitida.

Proceso

• Típicamente un proyecto open-source contiene las siguientes fases:

• Descubrimiento del problema.

• Búsqueda de desarrolladores voluntarios.

• Identificación de la solución.

• Implementación y testeo.

• Revisión de cambios en el código.

• Aprobación del código y de la documentación.

• Liberación del producto.

• Estas fases se realizan en forma iterativa.

Características del Proceso

• Los siguientes factores caracterizan al proceso de desarrollo open-source.

• Muchos desarrolladores voluntarios.

• El trabajo no se asigna. Cada cual elige libremente su tarea en función de su interés personal.

• No hay plan de proyecto, ni plazos, ni lista de entregables.

• Una buena división de las tareas es esencial para el éxito del proyecto.

• Internet como herramienta de comunicación es esencial para el desarrollo open-source.

• El sistema aumenta en pequeños incrementos.

• Los programas son testeados frecuentemente.

Roles y Responsabilidades

• Una típica estructura de desarrollo open-source está compuesta por varios tipos de voluntarios.

• Líderes de Proyecto, son quienes tienen la responsabilidad general del proyecto y usualmente han escrito el código inicial.

• Desarrolladores voluntarios, crean y envían código para el proyecto.

• Personas que identifican bugs y envían reportes de problemas al usar el software.

• Personas que participan de newsgroups y foros de discusión.

Open-Source vs. Procesos Ágiles

• Diferencias

• Open-source opera generalmente en forma geográficamente distribuida. En tanto que, los métodos ágiles tradicionales recomiendan grupos de desarrollo pequeños y geográficamente cercanos.

• En open-source el cliente suele ser también desarrollador.

• En open-source cada participante elige su tarea.

Open-Source vs. Procesos Ágiles

• Similitudes

• Desarrollo incremental, entregas tempranas y frecuentes.

• El programa es frecuentemente testeado.

• Cooperación entre cliente y desarrollador.

• Open-source, no incluye ninguna norma de documentación formal predefinida.

• En un proceso de desarrollo open-source, los requerimientos son elaborados continuamente.

Conclusiones

• Se ha argumentado que open-source difiere de los procesos ágiles en aspectos filosóficos, económicos y de estructura de equipos.

• Sin embargo, el proceso de desarrollo open-source resulta bastante cercano al de los procesos ágiles.

• Organizaciones dispersas geográfica y culturalmente podrían beneficiarse de las ventajas del paradigma open-source.

AUP

• Qué es?

• Cuándo y cómo surge?

• Ciclo de vida.

• Fases e hitos.

Disciplinas

• Definen actividades que el equipo de desarrolladores debe realizar para construir, validar y entregar un software que satisfaga las necesidades de los stakeholders.

• Modelado

• Implementación

• Testeo

• Deployment

• Configuration Management

• Project Management

• Environment

Modelado

• Modelado

• El objetivo de esta disciplina es comprender el negocio de la organización, comprender el dominio del problema abordado por el proyecto, e identificar una solución al mismo que sea viable.

Recomendaciones

• No es necesario mucho detalle durante las fases de inicio y elaboración.

• Model storming se realiza en el momento para obtener los detalles necesarios.

• El objetivo es crear modelos con la profundidad necesaria para lo que se está haciendo.

• La mayor parte de los modelos se descarta.

• Siempre hay que tener en cuenta oportunidades de reuso.

• La participación activa de los stakeholders es fundamental para el éxito.

• Se recomienda la arquitectura en capas.

Agile Model Driven Development

Modelado Fase a Fase

• Inicio

• Explorar la utilización del producto escribiendo casos de uso.

• Identificar los procesos de negocio por medio de la creación de diagramas de flujo de datos.

• Identificar las principales entidades de negocio y sus relaciones.

• Identificar las principales reglas de negocio y los principales requerimientos técnicos.  

• Comenzar el desarrollo de un glosario que contenga los términos importantes técnicos y del negocio.

Modelado Fase a Fase

• Elaboración

• Identificar riesgos técnicos.

• Modelado de la arquitectura.

• Realizar un prototipo de la interfaz de usuario.

Modelado Fase a Fase

• Construcción

• Participación activa del stakeholder y modelado inclusivo.

• Mostrar los detalles de los casos de uso.

• Explorar reglas de negocios y requerimientos técnicos con la misma profundidad.

• Aplicar model storming para el diseño.

• Puede resultar útil realizar diagramas de secuencia UML, modelo de deployment, diagramas de clase UML, modelo de seguridad frente a amenazas, modelos de datos físicos.

• Documentar las decisiones de diseño críticas.

Modelado Fase a Fase

• Transición

• Aplicar model storming para intentar comprender la causa de defectos detectados.

• Finalizar la documentación general del sistema.

Deployment

• Objetivo

• Planificar la liberación del sistema.

• Sugerencias:

• Desarrollar los scripts de instalación/desinstalación

• durante la fase de construcción.

• Tener un área de pre-producción donde poder validar el sistema antes de la liberación.

Deployment

• Tener en mente los periodos de pausa en la organización, ya que en estos periodos no se podrá realizar la liberación.

• Definir puntos de decisión (seguir/no seguir) .

• Ser capas de desinstalar el sistema si surgen problemas.

• Realizar testeo de scripts instalación/desinstalación.

Deployment

Deployment Fases

• Inicial:

• - Identificar la liberación potencial.

• - Comienzo de la planificación de la

• liberación.

• Elaboración:

• - Actualizar el plan de liberación.

Deployment Fases

• Construcción:

• - Desarrollo de los scripts.

• - Desarrollo de las notas de liberación.

• - Desarrollo inicial de la documentación.

• - Actualización del plan.

• - Liberación pre-producción.

Deployment Fases

• Transición:

• - Finalización del empaquetado del

• sistema.

• - Finalización de la documentación.

• - Anuncio de la liberación.

• - Entrenamiento del personal.

Roles y Responsabilidades 1

• AUP define los siguientes:

• DBA, administrador de bases de datos

• Agile Modeler, responsable de crear y desarrollar modelos.

• Configuration Manager, responsable de proveer toda la infraestructura necesaria para el equipo de desarrollo.

• Deployer, responsable de la liberación del sistema.

Roles y Responsabilidades 2

• Developer, escribe, realiza pruebas unitarias

• y construye el software.

• Process Engineer, desarrolla, adapta y mantiene el proceso de software de la organización.

• Project Manager

• Reviewer, evalua los artefactos generados por el proyecto.

Roles y Responsabilidades 3

• Stakeholder

• Technical Writer, responsable de producir la documentación para los stakeholders, documentación operacional, de soporte y para usuarios.

• Test Manager, responsable de la planificación del testeo del sistema.

• Tester, responsable de escribir y ejecutar las pruebas.

Roles y Responsabilidades 4

• Tool Specialist, responsable de seleccionar, adquirir, configurar las herramientas a utilizar.

• Un mismo rol puede ser asumido por varias personas.

• Una persona puede asumir varios roles.

Entregables

• Consejos

• Mantener los entregables tan simples y concisos como se pueda.
• Se necesita mucha menos documentación de la que se piensa.
• Trabajar conjuntamente con la gente que crea los entregables, para producir sólo lo necesario.
• Documentos ágiles son justo lo suficientemente buenos.
• Producir documentos es la peor manera de comunicar la información.
• Utilizar pizarrones, papel y Wikis para modelar y capturar la documentación.

Entegables Minimos

• Sistema

• Código Fuente

• Casos de Testeo

• Scripts de Instalación

• Documentación del Sistema

• Release Notes

• Modelo de Requerimientos

• Test de Aceptación, Procesos de Negocio, Dominio, Casos de Uso, Interfaz de Usuario

• Modelo de Diseño

• El mejor lugar para documentar el diseño es en los test unitarios y en el código fuente

Otros…

• Oportunidades de Automatización

• Una lista

• Reportes de Defectos

• Un mail o una planilla Excel

• Modelo de Interfaz de Usuario

• Un papel o una pizarra

Filosofía

• Los integrantes saben lo que hacen.

• Simple

• Todo es Conciso

• Ágil

• Mantener el foco en las actividades de alto valor.

• Independiente de la Herramienta

• Brinda soporte a herramientas CASE

• Customizable

Y Entonces…

• Casos de Éxito ?

• “AUP no es para todos, ningún proceso lo es. AUP es adecuado si se busca una versión ágil y racionalizada del Unified Process.”

¿ Preguntas ?