Fase de concepción Objetivo: definir la razón de ser y el alcance del proyecto. Estudio de oportunidad. Visión = QUÉ + PARA QUÉ + CUÁNTO Actividades Especificación de los criterios de éxito del proyecto Definición de los requerimientos Estimación de los recursos necesarios Cronograma inicial de fases Artefactos Documento de definición del proyecto
Fase de elaboración Objetivo: establecer un plan de proyecto y una arquitectura correcta del sistema Actividades Análisis del dominio del problema Definición de la arquitectura básica Análisis de riesgos Planificación del proyecto Artefactos Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura básica
Fase de construcción Objetivo: desarrollar el sistema a lo largo de una serie de iteraciones Actividades Análisis Diseño Codificación Pruebas (individuales, de integración)
XP: eXtreme Programming
eXtreme Programming Es una metodología ágil Diseñada para entornos dinámicos Pensada para equipos pequeños (hasta 10 programadores) Orientada fuertemente hacia la codificación Énfasis en la comunicación informal, verbal
Valores que fomenta XP Comunicación
Simplicidad
Retroalimentación
Coraje
Roles Programador (Programmer) Responsable de decisiones técnicas Responsable de construir el sistema Sin distinción entre analistas, diseñadores o codificadores En XP, los programadores diseñan, programan y realizan las pruebas Jefe de Proyecto (Manager) Organiza y guía las reuniones Asegura condiciones adecuadas para el proyecto
Cliente (Customer) Es parte del equipo Determina qué construir y cuándo Establece las pruebas funcionales
Roles Entrenador (Coach) Responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura Encargado de Pruebas (Tester) Ayuda al cliente con las pruebas funcionales Se asegura de que las pruebas funcionales se superan Rastreador (Tracker) Metric Man Observa sin molestar Conserva datos históricos
Captura de requisitos Historias del Usuario (User-Stories) Establecen los requisitos del cliente Trozos de funcionalidad que aportan valor Se les asignan tareas de programación con un nº de horas de desarrollo Las establece el cliente Son la base para las pruebas funcionales
Planificación Planificación por entregas (releases) Se priorizan aquellas user-stories que el cliente selecciona porque son más importantes para el negocio Entregas: Son lo más pequeñas posibles Se dividen en iteraciones (iteración = 2 o 3 semanas) Están compuestas por historias A cada programador se le asigna una tarea de la user-story
Programación La programación de tareas se realiza por parejas
La pareja diseña, prueba, implementa e integra el código de la tarea
Código dirigido por las pruebas
Código modular, intentando refactorizar siempre que se pueda
Modelo de un proyecto
Prácticas
El juego de la planificación Entregas pequeñas Metáfora Diseño simple Pruebas Refactoring
Programación en parejas Propiedad colectiva Integración contínua Semana de 40 horas Cliente in situ Estándares de programación
El juego de la planificación Decisiones de negocio (cliente): Alcance ? ¿Cuándo debe estar listo el producto para que sea valioso en producción? Prioridad ? Prioriza la incorporación de las user-stories Composición de entregas ? ¿Qué se necesita para que el negocio sea mejor antes de tener el sw? Fechas de entrega ? Fechas cuando el software funcionando causaría una gran diferencia
El juego de la planificación Decisiones técnicas (programadores y otros): Estimaciones ? ¿Cuánto tiempo tardará en implementarse una user-story? Consecuencias ? Tener en cuenta las consecuencias técnicas de determinadas decisiones de negocio Proceso ? Organización del proceso y el equipo Planificación detallada ? Dentro de una entrega, qué user-stories se realizan primero. Intentar trasladar los segmentos de desarrollo más arriesgados al principio, intentando respetar las prioridades del negocio
Cada entrega es lo más corta posible: Contenga requisitos más valiosos del sistema (básicos) Reducen el riesgo ? mayor retroalimentación desde el cliente, y más frecuente Minimizar el nº de user-stories que componen una entrega ? No realizar user-stories a medias
Entregas pequeñas
Se diseña "la cosa más simple que pueda funcionar" Uso de tarjetas CRC Diseño de software correcto, es aquel que: Supera todas las pruebas No tiene lógica duplicada Pone de manifiesto las intenciones importantes de los programadores Tiene el mínimo número de clases y métodos
Diseño simple
Las pruebas unitarias se escriben ANTES que el código Pruebas automatizadas Permiten el desarrollo de proyectos de forma rápida y segura Pruebas unitarias ? programadores Pruebas funcionales ? cliente Resultado ? Un programa cada vez más seguro Pruebas
NUnit Framework para pruebas unitarias Escritura de pruebas Ejecución de pruebas Hacer un Assert de los resultados Mostrar los fallos o éxitos Mantener un código que pase los tests http://nunit.org/
Ejemplo de un test en NUnit
Fallo en ejecución de los tests
Éxito en ejecución de los tests
Refactorización = Mejora del código
Intentar eliminar complejidad
Código duplicado ? Refactorización
Se plantea su aplicación después de implementar cada user-story
Refactoring
C# Refactoring Herramientas integradas con Visual Studio Simplifican la refactorización del código Métricas para el análisis del código http://www.xtreme-simplicity.net/
Integración con Visual Studio
Métricas de análisis del código
Refactoring con C# Refactory
Toda el código se escribe en parejas Se produce código de mayor calidad
Extiende el conocimiento
"Se realiza el trabajo de 1 persona en casi la mitad del tiempo y mejor" (cuestionable)
Programación en parejas
Cualquiera puede modificar el código en cualquier momento ? Se evitan cuellos de botella en la codificación
Todos asume las responsabilidades sobre el conjunto del sistema
Todos conocen algo sobre todas las partes y conocen muy bien aquéllas en las que trabajan Propiedad colectiva
El código se integra y se prueba después de pocas horas
Existe una ordenador dedicado para la integración
Cada pareja integra su código en dicho ordenador
Integración contínua
Cliente real = Aquel que usará el sistema cuando esté en producción
El cliente real debe estar con el equipo de trabajo: Responder preguntas Resolver disputas Establecer prioridades Discutir mejoras Cliente in situ
Son fundamentales cuando los programadores cambian de pareja o hacen refactoring del código de otros
Se consigue un código con el mismo estilo, homogéneo, legible Estándares de programación
Patrones de diseño software
Definición "Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esa solución un millón de veces más, sin hacer jamás la misma cosa dos veces" (Christopher Alexander) "Son soluciones reutilizables a problemas recurrentes que encontramos durante el desarrollo de software"
Ventajas que ofrece el uso de patrones "Diseñar código orientado a objetos es costoso, y diseñar código orientado objetos reutilizable aún lo es más" "Los patrones permiten a los programadores reconocer un problema e inmediatamente determinar la solución sin tener que pararse a analizar el problema primero" Permiten trabajar a un nivel de abstracción mayor Aumentan la productividad, la reutilización del código y su consistencia
Ventajas que ofrece el uso de patrones Capturan la experiencia en diseño. Los patrones se crean a partir de ejemplos prácticos de diseño Utilizar patrones de diseño es reutilizar la experiencia adquirida diseñando Estudiar los patrones existentes es una manera de aprender cómo los "expertos" diseñan sistemas Los patrones definen un conjunto de términos que forman un vocabulario con el que poder hablar de diseño de software
Componentes que constituyen un patrón Nombre Resumen o esencia de la solución Contexto al que se aplica Razones para utlizar o no el patrón Consideraciones de implementación Consecuencias e implicaciones de su uso Ejemplo de uso (Test Case) Patrones relacionados
Proceso de aplicación de patrones Problema Contexto Solución Beneficios Patrones relacionados Consecuencias Fuerza
Clasificación de los patrones Fundamentales De creación De partición Estructurales De comportamiento De concurrencia
Fundamentales Son los patrones más básicos y fundamentales: Muchos del resto de patrones utiliza al menos uno de ellos Son tan básicos que muchas veces no se mencionan dándolos por supuestos
Delegate Interface Abstract superclass Interface + abstract class Immutable Proxy Fundamentales
Provee de una guía de cómo crear objetos cuando su creación precisa de la toma de decisiones: "Las decisiones normalmente involucran la determinación de forma dinámica de qué clase instanciar o a qué objeto delegar la responsabilidad" Estos patrones nos ayudan a estructurar y encapsular las decisiones De creación
De creación Factory Builder Prototype Singleton Object pool
De partición Siguen el paradigma de "divide y vencerás" "Nos proporcionan la guía de cómo particionar las clases e interfaces para llegar a un buen diseño"
De partición Filter Composite Read-only interface
Estructurales "Describen las formas más comunes en las que diferentes tipos de objetos pueden organizarse para trabajar conjuntamente"
Estructurales Adapter Iterator Bridge Façade Flyweight Dynamic linkage Virtual proxy Decorator Cache management
De comportamiento "Patrones utilizados para organizar, gestionar y combinar comportamiento"
De comportamiento Chain of responsibility Command Little language Mediator Snapshot Observer State Null object Strategy Template method Visitor
De concurrencia Patrones para la coordinación de operaciones concurrentes y que permiten solucionar dos problemas principalmente: Recursos compartidos Secuenciación de operaciones
De concurrencia Single threaded execution Lock object Guarded suspension Balking Scheduler Read/Write lock Producer-consumer Two-phase termination Double buffering Asynchronous processing Future
Arquitecturas dirigidas por modelos (MDA)
Nueva orientación de las actividades del OMG La base de todo son los modelos (ni su implementación, ni la plataforma) Basado en el desarrollo de modelos independientes de la plataforma (PIM) Define un segundo nivel en el que diseñamos para una plataforma concreta pero de forma abstracta (PSM) Definición de transformaciones de PIM a PSM Aunque la plataforma cambie, siempre mantenemos el PIM Introducción
PIM, PSM y transformaciones en MDA Reglas de transformación (Gp:) Modelo específico (PSM)
(Gp:) Modelo independiente de la plataforma (PIM)
(Gp:) Modelo específico (PSM)
Ejemplos con MOF/XMI (Gp:) UML Model (PIM) (Gp:) < Auto> < Color> Red < /Color> < Door> 4 < /Door> < Engine> 2 < /Engine> < /Auto> (Gp:) XMI Document (PSM) (Gp:) XMI (Gp:) < !Element Auto (Color*, Door*, Engine*)> (Gp:) XMI DTD, Schema (PSM) (Gp:) X M I (Gp:) M O F (Gp:) interface Auto { };
(Gp:) IDL, Java. (PSM) (Gp:) Class Auto {public String color; public int Door; public int Engine; }
Herramientas de apoyo al modelado
Herramientas comerciales generales: Borland Together IBM Rational Suite Herramientas libres o con versiones básicas gratuitas: Argo UML Poseidon Umbrello Eclipse UML2 Eclipse Omondo Integración con los IDEs existentes Herramientas de apoyo al modelado
Herramientas con soporte de ingeniería inversa Herramientas de generación en un solo sentido Herramientas de soporte MDA: Together AndroMDA Ayuda a la generación de código
Formato XMI Importación y exportación a este formato por parte de las herramientas Base para las transformaciones en MDA Intercambio de metadatos
| Página siguiente |