sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Soy el cliente de la aplicación que deseo Eres el jefe de proyecto de la aplicación Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías qué y cómo preguntarme, en qué orden y hasta qué nivel de detalle y cuándo?

  • ¿Cuál sería el formato adecuado del resultado de las reuniones?

  • ¿Cómo repartirías las tareas de requisitos entre las personas del equipo de desarrollo? ¿Con cuántas personas empezarías?

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad correctiva, perfectiva o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

¿Cuándo? ¿Dónde? ¿Quién?

Grady Booch Ivar Jacobson James Rumbaugh

G.Booch

I.Jacobson

JRumbaugh

  • Dpto. Defensa USA, IBM, …​

  • Método de Desarrollo:

    • Object Oriented Analysis and Design

  • Ericsson

  • Método de Desarrollo:

    • Objectory

  • MIT,

  • Método de Desarrollo:

    • Object Modeling Technique

height32

  • Rational (IBM), 1998

logo

¿Qué?

  • Proceso de desarrollo software basado en componentes

    • lo cual significa que el sistema software es construido por

      • componentes software interconectados y

      • bien definidos vía sus interfaces

  • Dirigido por Casos de Uso

  • Centrado en la Arquitectura

  • Iterativo e incremental

Proceso Dirigido por Casos de Uso

  • Usados como un artefacto primordial para establecer el comportamiento deseado del sistema y para comunicar este comportamiento entre los implicados en el sistema.

  • Forma sistemática e intuitiva para capturar los requisitos funcionales, adecuadamente representados para los usuarios, clientes y desarrolladores

  • Primera entrada para el análisis, diseño, implementación y pruebas del sistema, incluyendo la creación, verificación y validación de la arquitectura del sistema.

  • Facilitan el mantenimiento de la aplicación gracias a la trazabilidad y ortogonalidad con las clases

  • Facilitan la planificación de actividades de los roles

height32

Proceso Centrado en la Arquitectura

  • La arquitectura del sistema es usada como un artefacto primordial para la conceptualización, construcción, gestión y evolución del sistema bajo desarrollo.

  • Esta clave incluye:

    • Disciplina de Análisis

    • Disciplina de Diseño

    • Disciplina de Implementación

    • Disciplina de Pruebas

height32

Proceso Iterativo e Incremental

  • iterativo, lo que significa que el proceso involucra un flujo de entregas ejecutables, e

  • incremental, lo que significa que el proceso involucra la integración continua de la arquitectura del sistema para producir con cada nueva entrega un incremento que aumenta a otra anterior

  • Esto incluye:

    • Disciplina de Gestión del Proyecto

    • Disciplina de Entorno

    • Disciplina de Configuración y Gestión de Cambios

    • Disciplina de Despliegue

height32

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible
Beneficios

  • Construir el sistema en el tiempo de forma incremental en lugar de todo a la vez cerca del final cuando el cambio se convierte en muy caro

  • Proporcionar un marco que maneje mejor los requisitos cambiantes e inevitables y otros cambios

  • Proporcionar un proceso de desarrollo a través del cual el personal puede trabajar más eficazmente

  • Disponer de una estructura para guiar el desarrollo de software

  • Conseguir gestión temprana del riesgo crítico
Empresas

  • Rational Software

    • Grady Booch

    • Jim Rumbaugh

    • Ivar Jacobson

  • Eclipse

  • IBM

  • Microsoft

  • Oracle Corp.

  • Hewlett-Packard

  • Digital Equipment

  • Intellicorp and James Martin & co.

    • James Odell

  • Texas Instruments

  • Unisys

  • i-Logix

    • David Harel

  • Taskon

  • MCI Systemhouse

  • ObjecTime

  • ICON Computing

    • Desmond D´Souza

  • Plantinium Technology

  • Sterling Software

¿Cómo?

Roles del Equipo

role

Fases del Proyecto

Fase: lapso de tiempo entre dos hitos principales del proceso de desarrollo
project

height32

height32

height32
Inicio Elaboración Construcción Transición

  • donde la idea inicial se llevará hasta el punto de ser suficientemente fundada

  • donde se define la arquitectura

  • donde el software se lleva su completitud

  • donde el software se pone en manos de la comunidad de usuarios

  • Delimitar el ámbito del sistema propuesto

  • Demostrar a los potenciales usuarios y/o clientes que el sistema propuesto es capaz de solventar su problema o soportar los objetivos del negocio construyendo un prototipo como prueba de concepto

  • Describir o esbozar la arquitectura candidata

  • Identificar los riesgos críticos

  • Identifica los riesgos significativos, lo que significa riesgos que podrían alterar los planes, costos y horarios de las fases posteriores

  • Crea una línea de base arquitectónica que cubre la funcionalidad significativa del sistema y las características importantes para los implicados

  • Especifica los niveles que deben alcanzar los atributos de calidad

  • Captura casos de uso a aproximadamente 80% de los requerimientos funcionales

  • Prepara una oferta que cubre horario, personal necesario y el costo en el plazo establecido por las prácticas comerciales

  • Extiende la identificación de casos de uso, la descripción y realización a todo el cuerpo de casos de uso

  • Acaba el análisis, diseño, implementación y pruebas

  • Mantiene la integridad de la arquitectura, modificando cuando sea necesario

  • Monitoriza los riesgos críticos y significatovos heredados de las dos primeras fases y, en caso de que se materialicen, mitigarlos

  • Actividades de preparación, como el sitio web

  • Asesorar al cliente sobre la actualización del entorno en el que el software operará

  • Elaboración de manuales y otros documentos para la entrega a producción

  • Ajuste del software para operar bajo los parámetros reales del entorno del usuario

  • Corrección de los defectos encontrados después de la retroalimentación de la prueba beta

  • Modificaciones del software a la luz de los problemas imprevistos

Iteraciones en las Fases

Time

Actividades de la Iteraciones

  • Disciplina de Reqeuisitos

    • 1. Encontrar Actores y Casos de Uso

    • 2. Priorizar Casos de Uso

    • 3. Detallar Caso de Uso

    • 4. Estructurar Casos de Uso

    • 5. PrototiparInterfaz de Usuario

  • Disciplina de Análisis

    • 6. Análisis de la Arquitectura

    • 7. Análisis de Caso de Uso

    • 8. Análisis de Clase

    • 9. Análisis de Paquete

  • Disciplina de Diseño

    • 10. Diseño de la Arquitectura

    • 11. Diseño de Caso de Uso

    • 12. Diseño de Clase

    • 13. Diseño de Paquete

  • Disciplina de Implementación

    • 14. Implementar la Arquitectura

    • 15. Integración de Sistemas

    • 16. Implementar Clase

    • 17. Pruebas Unitarias

    • 18. Implementar Subsistema

  • Disciplina de Pruebas

    • 19. Planificar Pruebas

    • 20. Diseñar Pruebas

    • 21. Implementar Pruebas

    • 22. Realizar Pruebas de Integración

    • 23. Realizar Pruebas de Sistemas

    • 24. Evaluar Pruebas

height32
disciplinas

  • Iteración de Inicio

height32

  • Iteración de Elaboración

height32

  • Iteración de Construcción

height32

Artefactos del Proyecto

4+1 Vistas

  • Índice

    • Enlaces a 4+1 vistas y modelo del dominio

    • Cardinalidad: 1
viewIndex

Ejemplos

  • Mastermind

    • Modelo del dominio

    • Vista de Casos de Uso

    • Vista de Diseño

    • Vista de Implementación

    • Vista de Despliegue

    • Vista de Procesos

  • Damas

    • Modelo del dominio

    • Vista de Casos de Uso

    • Vista de Diseño

    • Vista de Implementación

    • Vista de Despliegue

    • Vista de Procesos

Itinerario

Temas Contenidos Característica
diagramaDisenyo

  • Disciplina de Gestión: Estimación del Desarrollo Software, Evaluar el Ámbito y Riesgo del Proyecto, Planificar Fases e Iteraciones, Gestionar el principio, fin y revisión de cada iteración, Cerrar fase asegurando y Seguimiento del Desarrollo Software

Iterativo e Incremental

  • Disciplina de Pruebas: Planificar Pruebas, Diseñar Pruebas, Implementar Pruebas, Realizar Pruebas de Integración, Realizar Pruebas de Sistemas y Evaluar Pruebas

  • Disciplina de Implementación: Implementar la Arquitectura, Integración de Sistemas, Implementar Clase, Pruebas Unitarias y Implementar Subsistema

  • Disciplina de Diseño: Diseño de la Arquitectura, Diseño de Caso de Uso, Diseño de Clase y Diseño de Paquete

  • Disciplina de Análisis: Análisis de la Arquitectura, Análisis de Caso de Uso, Análisis de Clase y Análisis de Paquete

Centrado en la Arquitectura

  • Disciplina de Requisitos: Encontrar Actores y Casos de Uso, Priorizar Casos de Uso, Detallar Caso de Uso, Estructurar Casos de Uso y PrototiparInterfaz de Usuario

Dirigido por Casos de Uso

Sintesis

sintesis

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Unified Software Development Process

    • Grady Booch, Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (1999)

height32

  • Rational Unified Process Made Easy, The: A Practitioner’s Guide to the RUP

    • Grady Booch, , Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (2003)

height32

  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

    • Craig Larman

    • Pearson; (2004)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Benjamin Cummings; (1995)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson; (2005)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley; (2003)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM