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 anterior | Volver al principio del trabajo | Página siguiente  |