Análisis y Negociación de Requisitos

Transcripción

1 11/11/2013 Análisis y Negociación de Grupo de Ingeniería del Software y Bases de Datos Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla Objetivos del tema Conocer los objetivos, productos y s del de requisitos. Conocer los conceptos básicos del modelado de sistemas software. Conocer los conceptos básicos de la gestión de y negociación de requisitos. Conocer los elementos comunes de UML. 1 IR 1

2 11/11/2013 Objetivos del de requisitos Detectar en los requisitos al comienzo del proyecto, evitando que aparezcan después, cuando tiempo es mucho más caro resolverlos. La forma más habitual de es la construcción de un modelo de un que cumpla los requisitos de producto, es decir, del sistema a desarrollar. 2 Situación en el de IR Elicitación de Información elicitada Documentación de Conflictos [resueltos] [borrador] Negociación de Conflictos [pendientes] [versionados] Gestión de [validados] Defectos Análisis de [analizados] Verificación de [verificados] Validación de 3 IR 2

3 11/11/2013 Tareas del de requisitos Construir un modelo a partir de los objetivos y requisitos documentados, teniendo en cuenta también el modelo del negocio, el glosario de términos, etc. Registrar los identificados durante la construcción del modelo para su posterior resolución. Cada vez es más frecuente durante el proponer una primera arquitectura del sistema teniendo en cuenta los requisitos no funcionales. 4 Modelo de un El sistema ofrece servicios a los actores. El estado del sistema son los objetos y sus enlaces. Actor 1 e 3 e 4 o 7 Actor 4 e 2 o 1 e 1 e 9 o 6 e 5 o 2 e 7 o 4 e 6 o 3 e 8 Actor 2 Actor 3 5 IR 3

4 11/11/2013 Modelo de un Los servicios de actualización provocan cambios en el estado del sistema. Actor 1 e 3 e 4 o 7 Actor 4 e 2 o 1 e 1 e 9 o 6 e 5 o 2 e 7 o 4 e 6 o 3 e 8 Actor 2 Actor 3 6 Modelo de un Los servicios de consulta no provocan cambios en el estado del sistema. Actor 1 e 3 e 4 o 7 Actor 4 e 2 o 1 e 1 e 9 o 6 e 5 o 2 e 7 o 4 e 6 o 3 e 8 Actor 2 Actor 3 7 IR 4

5 11/11/2013 Modelo de un Con respecto a las funciones de un sistema de información Función de memoria: estado del entorno del sistema estado del sistema. El estado del sistema se mantiene sincronizado con el entorno por los servicios de actualización. Actor 1 o 1 e 3 o e 4 7 o 6 Actor 4 e 2 o 2 e e 9 1 e 4 e 6 e 7 o 3 e 8 Actor 2 Actor 3 8 Modelo de un Con respecto a las funciones de un sistema de información Función informativa: la proporciona mediante los servicios de consulta. Para que sea útil, el estado del sistema debe estar sincronizado con el estado del entorno.* Actor 1 o 1 e 3 o e 4 7 o 6 Actor 4 e 2 o 2 e e 9 1 e 4 e 6 e 7 o 3 e 8 * No necesariamente sincronizados al segundo, puede haber cierto desfase entre ambos y seguir siendo útil. Actor 2 Actor 3 9 IR 5

6 11/11/2013 Modelo de un Con respecto a las funciones de un sistema de información Función activa: la proporciona mediante la interacción con los usuarios y con otros sistemas (actores en general). La interacción con otros sistemas se realiza invocando sus servicios. Actor 1 o 1 e 3 o e 4 7 o 6 Actor 4 e 2 o 2 e e 9 1 e 4 e 6 e 7 o 3 e 8 Actor 2 Actor 3 10 Un modelo de un incluye Un modelo estático (modelo conceptual) Describe la estructura y las restricciones de la información que representa el estado del sistema. Un modelo de conducta Describe cómo interactúa el sistema con los actores y cómo evoluciona su estado al interactuar. Modelo = + Modelo estático = Estructura + Restricciones Modelo de conducta = Interacciones externas + Evolución interna 11 IR 6

7 11/11/2013 Gestión de en los requisitos Los pequeños como faltas de información o necesidades de aclaración se pueden resolver consultando con el cliente de una manera más o menos informal (p.e. una llamada de teléfono o un correo electrónico). 12 Gestión de en los requisitos En el caso de que se detecten conflictos que requieran soluciones no triviales, es necesaria la Negociación de. Gestión de Elicitación [versionados] de Conflictos Negociación [resueltos] de Información Documentación Conflictos [pendientes] [validados] elicitada de [borrador] Análisis de Verificación Validación de de Defectos [analizados] [verificados] 13 IR 7

8 11/11/2013 Proceso de negociación de requisitos El habitual suele ser: 1. Registrar el conflicto (normalmente con una herramienta). 2. Identificar los requisitos afectados. 3. Analizar el impacto del conflicto (analizando la trazabilidad de los requisitos). 4. Identificar las fuentes (participantes) relevantes. 5. Convocar y realizar la reunión de negociación. 6. Asimilar la solución del conflicto. 14 Unified Modeling (UML) Estándar de la OMG (Object Management Group) para el modelado de sistemas software. Ago 2007 Nov 2007 Feb 2009 May 2010 Mar 2010 Ago UML 2.0 UML UML UML 2.2 UML 2.3 UML 2.4 UML Sep 1997 Jun 1998 Mar 2000 Sep 2001 Mar 2003 Ene 1997 UML 1.0 UML 1.1 UML 1.2 UML 1.3 UML 1.4 UML 1.5 Jun 1996 UML 0.9 Oct 1995 Unified Method 0.8 OOSE Booch'93 OMT-2 Booch'91 Otros métodos OMT-1 15 IR 8

9 11/11/2013 Unified Modeling (UML) Es ampliamente usando en la industria del software y existen muchas herramientas. Define hasta 14 tipos de diagramas para modelar sistemas software (versión 2.4.1, agosto 2011) Nosotros usaremos Diagrama de casos de uso Diagrama de clases Diagramas de objetos Diagrama de estados Diagrama de secuencia 16 Organización de modelos en UML En UML los modelos se organizan en paquetes, que pueden incluir otros paquetes. Los paquetes deben agrupan elementos cercanos semánticamente y que suelen cambiar juntos. Existen algunos paquetes especiales «system»: corresponde al sistema que se modela. «subsystem»: representa una parte del sistema que se modela. Permite diferenciar subsistemas en el sistema. Nombre <<subsystem>> Nombre <<system>> Nombre 17 IR 9

10 11/11/2013 Elementos comunes de UML Notas Se representan mediante rectángulos con la esquina doblada y se pueden asociar a cualquier símbolo. Pueden contener comentarios (cualquier combinación de texto y gráficos) o restricciones. Comentarios Se presentan dentro de notas que deben asociarse al elemento al que se refiere el comentario. Alumno Este actor representa a cualquier alumno, incluidos los de doctorado. 18 Elementos comunes de UML Restricciones Representan condiciones que deben cumplir los elementos a los que se le asocia. Se representan mediante texto entre llaves y pueden aparecer dentro de los elementos o dentro de notas. class Ejemplo de restricción Fac tura número {único} fechaemisión * emitidaa 1 Cliente {f ac turas sin duplic ados: un mismo producto no debe aparecer dos veces en la misma factura.} 1..* {ordered} L ínead efac tura cantidad precio * c ontiene 1 Produc to 19 IR 10

11 11/11/2013 Elementos comunes de UML Estereotipos Permiten ampliar UML al definir nuevos elementos de modelado a partir de otros ya existentes, pudiendo tener sus propios valores etiquetados, sus propias restricciones y su propio icono. Se pueden representar mediante el nombre entre comillas francesas () o mediante un icono. «tablabd» Alumnos Alumnos «tablabd» Alumnos Alumnos 20 Elementos comunes de UML Valores etiquetados (tagged values) Son parejas {etiqueta=valor} que permiten añadir información a un elemento. Si no es ambiguo, se puede especificar sólo el valor. RetiradaEfectivo {estado=borrador, fecharevisión=15/10/2004} importe : Moneda {importe debe ser múltiplo de 10 } 21 IR 11

12 11/11/2013 Bibliografía C. Larman, UML y Patrones. Ed. Prentice-Hall, Capítulos 9 al 12 C. Larman, UML y Patrones (2ª edición). Ed. Prentice-Hall, Capítulos 10 al 12 M. Fowler, UML Distilled (3 rd edition). Ed. Addison-Wesley, Capítulo 3 22 IR 12