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 corrective, perfective o adaptativa?

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

  • ¿Cuánta gente incorporarías?

  • ¿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?

¿Qué?

  • Disciplina de Requisitos es el flujo de trabajo (realización de casos de uso que incluye roles, actividades y artefactos) cuyo principal propósito es dirigir el desarrollo hacia el sistema correcto describiendo los requisitos del sistema de tal forma que se alcance el acuerdo entre el cliente, usuarios y desarrolladores sobre lo que el sistema debería hacer

¿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
Objetivos

  • Establecer y mantener el acuerdo con los clientes y otros implicados sobre lo que el sistema debería hacer

  • Proveer a los desarrolladores del sistema con un mejor comprensión del los requisitos del sistema

  • Definir los límites del sistema

  • Proveer las bases para planificar los contenidos técnicos de cada iteración

  • Proveer las bases para la estimación de costes y tiempos para desarrollar el sistema

para las disciplinas técnicas: análsis, diseño, implementación y pruebas

para las disciplinas de infraestructuras: devop y gestión

¿Cómo?

Actividades

requirementDiscipline

Introduccion

Encontrar Actores y Casos de Uso

FindActorUseCases

EncontrarActoresCasosDeUso
Artefactos de Entrada

  • Modelo del Dominio

  • Requisitos Suplementarios: Requisitos no funcionales que especifican propiedades del sistema tales como restricciones de entorno e implementación, rendimiento, plataforma, mantenibilidad, extensibilidad y confiabilidad (-ilidades).
EncontrarActoresCasosDeUso3

  • Lista de Características: muchas buenas ideas que podrían convertirse en requisitos reales (contrato). Cada característica tiene un nombre corto y una breve explicación o definición, justo con la información suficiente para ser posible hablar sobre la característica durante la planificación del producto. Cada característica podría incluir:

    • Estado (p.e. propuesto, aprobado, incorporado o validado)

    • Coste estimado para la implementación (en términos de tipos de recursos y persona-hora)

    • Prioridad (p.e. crítico, importante o irrelevante)

    • Nivel de riesgo asociado en la implementación de la característica (p.e. crítico, significativo u ordinario)
EncontrarActoresCasosDeUso2
Encontrar actores Encontrar Casos de Uso

  • Un actor especifica un rol que adopta una entidad externa cuando interactúa con el sistema directamente (no en respuesta). Puede representar el rol de un usuario o el rol jugado por otro sistema que toca los límites de tu sistema. Los actores representan roles que personas o cosas juegan en relación con el sistema, no personas o cosas específicas (p.e. administrador, no Pepe).

    • ¿Quién o qué usa el sistema?

    • ¿Quién obtiene y provee información al sistema?

    • ¿Qué roles juegan en la interacción?

    • Cuando necesitas modelar cosas que suceden en tu sistema en un punto específico del tiempo pero no parecen ser lanzados por ningún actor, puedes introducir un actor Tiempo (p.e. sistema automático de backup, …)

  • Un caso de uso es una especificación de secuencias de acciones, incluyendo variaciones, que el sistema puede realizar y que dan un resultado observable de interés a un actor particular

    • El actor típicamente necesitará casos de uso para soportar su trabajo para crear, cambiar, seguir, borrar o estudiar objetos de negocio

    • Algunos de los casos de uso candidatos no llegarán a ser casos de uso en sí mismos. En vez de ello, mejor pueden ser partes de otros casos de uso

    • Recordar que intentamos crear casos de uso que son fáciles de modificar, revisar, probar y gestionar como una unidad

    • Es útil modelar la trazabilidad entre los requisitos y la lista de características
EncontrarActoresCasosDeUso4
EncontrarActoresCasosDeUso5
Describir brevemente cada caso de uso Describir el modelo de casos de uso como un todo

  • A veces garabatear unas pocas palabras para explicar cada caso de uso y a veces simplemente escribir los nombres, que a menudo comienza con un verbo

  • Explicar el modelo de casos de uso en su conjunto, particularmente la forma en el que los casos de uso se relacionan entre sí con diagramas de estado y de los actores con los diagramas de casos de uso

    • Este paso incluye preparar un glosario de términos

    • Es muy útil permitir a las personas que no son parte del equipo de desarrollo aprobar el modelo de casos de uso conducido con una entrevista informal

height32

  • Diagrama de estados con transiciones de casos de uso asociados a los actores

  • Se entiende que la transición se realiza en caso satisfactorio

Priorizar Casos de Uso

prioritizeUseCases

PriorizarCasosDeUso
Priorizar Casos de Uso

  • Determinar cuáles de ellos serán desarrollados (es decir, analizados, diseñados, implementados, y probados) en las primeras iteraciones, y cuáles se puede desarrollar en posteriores iteraciones tomando en consideración:

    • Aspectos técnicos

    • Aspectos de redundancia

    • Aspectos económicos

    • Aspectos de negocio

    • Aspectos obscuros de requisitos

    • …​ cualquier riesgo
PriorizarCasosDeUso2

Especificar Casos de Uso

detailUseCases

DetallarCasosDeUso
Estructurar la descripción de los Casos de Uso

  • Tenemos que describir la secuencia de acciones de los casos de uso, cómo estas acciones son invocadas por los actores y cómo es el resultado de su ejecución a petición del actor

  • Debería definir el estado de arranque como pre-condiciones y las posibles estados finales como post-condiciones

  • Elegir un camino básico completo desde el estado de arranque al estado final, en una sección, lo que dé el valor más obvio al actor

  • Describir el resto de caminos como alternativas o desviaciones del camino básico, cada una en secciones separadas o si son suficientemente pequeñas pueden se explicadas “en línea”

  • Estas variaciones pueden ocurrir por muchas razones:

    • Actor lo cancela

    • Sistema puede detectar errores de entrada

    • Sistema puede estar mal funcionando por el sistema de recursos

    • …​

  • Especificar los requisitos no funcionales (p.e. velocidad, disponibilidad, precisión, tiempo de respuesta, tiempo de recuperación, …​ con la que el sistema debe realizar un caso de uso dado
Formalizarlas descripciones de los casos de uso con diagramas de estados, actividad o secuencia

  • Pero usar estas clases de diagramas con cuidado y suelen ser suficientes descripciones textuales puras

  • Contraindicaciones:

    • No incluir términos referentes al “pensamiento o intenciones” del actor (p.e. el jugador mira …, decide …, …) porque no atañe a nuestro sistema, no se van a “programar”

    • No incluir términos referentes a la ejecución del software (p.e. se graba en la base de datos …, validar …, …) porque no atañe a los requisitos sino al análisis/diseño del software y serían decisiones prematuras

    • No incluir términos referentes al diseño de la interfaz de usuario (p.e. botón …, arrastra el ratón …, ventana de …, …_) porque no atañe a esta actividad, será en la última actividad de requisitos

  • Indicaciones:

    • El actor introduce …, selecciona …y solicita …

    • El sistema: permite introducir, permite seleccionar, permite solicitar … y presenta/muestra/visualiza …

height32

height32

height32

Estructurar Casos de Uso

structuringUseCases

EstructurarCasosDeUso
Identificar descripciones de funcionalidad compartida Identificar descripciones opcionales y adicionales de funcionalidad

  • Para reducir la redundancia, deberíamos mirar por las acciones o partes de acciones que son comunes o compartidas por varios casos de uso

    • Una generalización de un caso de uso A aun caso de uso B indica que una instancia del caso de uso A también incluiría el comportamiento especificado por B

    • Los casos de uso concretos son iniciados por un actor y sus instancias constituyen una secuencia completa de acciones realizadas por el sistema

    • Los casos de uso abstractos no serán instanciados por sí mismos, existen solo por otros casos de uso para su reusabilidad

  • Una inclusión/extensión se comporta como si fuera algo que se añade en la descripción original de un caso de uso

    • Una relación de extensión desde un caso de uso A aun caso de uso B indica que una instancia del caso de uso B puede incluir el comportamiento especificado por A. Incluye una condición para la extensión

    • Una relación de inclusión puede pensarse simplemente como la inversa de la relación de extensión que provee una explícita e incondicional extensión a un caso de uso

    • En ambos casos, incluye una referencia al punto de extensión en el caso de uso destino, esto es, una posición (sujeto a las condiciones establecidas en la extensión) en el caso de uso donde la extensión puede ser hecha
EstructurarCasosDeUso2

Prototipar Interfaz de Usuario

prototypeUserInterface

PrototiparInterfazDeUsuario
Crear un diseño lógico de la Interfaz de Usuario Crear un diseño físico de la Interfaz de usuario

  • ¿Qué necesita la interfaz de usuario para permitir los casos de uso para cada actor?

  • ¿Qué elementos de la interfaz de usuario son necesarios para permitir la realización del casos de uso (p.e. iconos, lista de ítems, carpetas u objetos sobre un mapas en 2D)

  • ¿Cómo deberían ser relacionado con otros?

  • ¿Cómo se usarán en distintos casos?

  • ¿Qué aspecto tienen?

  • ¿Cómo deberían ser manipulados?

  • Preparar bocetos de la constelación de elementos de interfaz de usuario que forman la interfaz de usuario útil para los actores

  • Esbozar elementos adicionales que se necesitan para combinar los distinto elementos de la interfaz de usuario para completarla (p.e. carpetas, ventanas, barras de herramientas y controles)
Preparar un prototipo ejecutable Diseño de Ventanas y flujo con Mockups

  • Herramientas de prototipado rápido para cada actor

  • Validar la interfaz de usuario a través de entrevistas con los prototipos y bocetos en un punto inicial puede prevenir errores que serán más caros de corregir más tarde
height32
Si una imagen vale más que mil palabras, un prototipo vale más que mil reuniones
— Tom and David Kelley
IDEO
height32
Trazabilidad Casos de Uso x Pantalla Trazabilidad Estados del Contexto x Pantalla
height32
height32

Artefactos

4+1 Vistas

  • Índice

    • Enlaces a 4+1 vistas y modelo del dominio

    • Cardinalidad: 1
viewIndex

Vista de Casos de Uso

  • Índice

    • Enlaces a actores, casos de uso, …​

    • Cardinalidad: 1
caseViewIndex

  • Actores

    • Diagrama de Casos de Uso

    • Cardinalidad: 0..<paquetesActores>
actors

  • Casos de Uso

    • Diagrama de Casos de Uso

    • Cardinalidad: 1..<paquetesCasosUso>
useCases

  • Contexto

    • Diagrama de Estados, transición con casos de uso

    • Cardinalidad: 1..<subestados>
context

  • Especificación de Casos de Uso

    • Diagrama de Estados, transición con acciones entre actor y sistema (caja negra)

    • Cardinalidad: 1..<casosUso>
specification

  • Prototipo

    • Diagrama de Casos de Uso

    • Cardinalidad: 1..<ventanas>

prototipo

Síntesis

sintesis

Soy un cliente con dinero para pagar a tu empresa si tu equipo desarrolla la aplicación que deseo:

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

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

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

  • Modelo del Dominio,

  • Actores,

  • Casos de Uso,

  • Detalle de Casos de Uso,

  • Prototipo de Interfaz,

  • Diagramas de Clases, Objetos, Actividad, Estados, …​ para el Modelo de Dominio,

  • Diagramas de Casos de Uso para Actores y Casos de Uso,

  • Diagramas de Estados o Actividad o Secuencia o textos para el detalle de Casos de Uso

  • Estimando cada actividad, entre 2 y 20 horas, y

  • Repartiendo cohesivamente entre el equipo de desarrollo

  • …​ con trazabilidad de todo!

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