Análisis de Requisitos - us

Análisis y Negociación de Requisitos 11/11/2013

IR 1

1. Objetivos del análisis

2. Situación en el proceso

3. Tareas del análisis

4. Modelo de un sistema software

5. Gestión de problemas

6. Unified Modeling Language

© D

iseño d

e A

mador

Durá

n T

oro

, 2011

© D

iseño d

e A

mador

Durá

n T

oro

, 2011

Análisis y Negociación de Requisitos

Grupo de Ingeniería del Software y Bases de Datos

Departamento de Lenguajes y Sistemas Informáticos

Universidad de Sevilla

noviembre 2013







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


Ingeniería de Requisitos noviembre 2013

• Objetivos del tema

– Conocer los objetivos, productos y procesos del

análisis de requisitos.

– Conocer los conceptos básicos del modelado de

sistemas software.

– Conocer los conceptos básicos de la gestión de

problemas y negociación de requisitos.

– Conocer los elementos comunes de UML.

1


IR 2







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Objetivos del análisis de requisitos

– Detectar problemas en los

requisitos al comienzo del

proyecto, evitando que

aparezcan después, cuando

es mucho más caro resolverlos.

– La forma más habitual de análisis es la

construcción de un modelo de un sistema software

que cumpla los requisitos de producto, es decir,

del sistema a desarrollar.

tiempo

€

2







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


Ingeniería de Requisitos 3 noviembre 2013

• Situación en el proceso de IR

Elicitación de Requisitos

Información elicitada

Documentación de Requisitos

Requisitos [borrador]

Análisis de Requisitos

Verificación de Requisitos

Validación de Requisitos

Requisitos [analizados]

Requisitos [verificados]

Requisitos [validados]

Gestión de Requisitos

Requisitos [versionados]

Defectos

Conflictos [pendientes]

Negociación de Requisitos

Conflictos [resueltos]


IR 3







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Tareas del análisis 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 problemas identificados durante la

construcción del modelo para su posterior

resolución.

– Cada vez es más frecuente durante el análisis

proponer una primera arquitectura del sistema

teniendo en cuenta los requisitos

no funcionales.

4







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Modelo de un sistema software

• El sistema ofrece servicios a los actores.

• El estado del sistema son los objetos y sus

enlaces.

noviembre 2013 Ingeniería de Requisitos 5

o7

o6

o5

o4

o3

o2

o1

e1 e2

e3 e4

e5

e6

e8

e7

e9

Actor1

Actor2

Actor3

Actor4


IR 4







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Los servicios de actualización provocan

cambios en el estado del sistema.


o7

o6

o5

o4

o3

o2

o1

e1 e2

e3 e4

e5

e6

e8

e7

e9

Actor1

Actor2

Actor3

Actor4







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Los servicios de consulta no provocan

cambios en el estado del sistema.


o7

o6

o5

o4

o3

o2

o1

e1 e2

e3 e4

e5

e6

e8

e7

e9

Actor1

Actor2

Actor3

Actor4


IR 5







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• 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.


o7

o6

o5

o4

o3

o2

o1

e1 e2

e3 e4

e5

e6

e8

e7

e9

Actor1

Actor2

Actor3

Actor4







© D

iseño d

e A

mador

Durá

n T

oro

, 2011




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.*


o7

o6

o5

o4

o3

o2

o1

e1 e2

e3 e4

e5

e6

e8

e7

e9

Actor1

Actor2

Actor3

Actor4

* No necesariamente sincronizados al segundo, puede haber cierto desfase entre ambos y seguir siendo útil.


IR 6







© D

iseño d

e A

mador

Durá

n T

oro

, 2011




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.


o7

o6

o5

o4

o3

o2

o1

e1 e2

e3 e4

e5

e6

e8

e7

e9

Actor1

Actor2

Actor3

Actor4







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Un modelo de un sistema software 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 de conducta = Interacciones externas

+

Evolución interna

Modelo estático = Estructura

+

Restricciones

11


IR 7







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Gestión de problemas en los requisitos

– Los problemas 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







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Gestión de problemas en los requisitos

– En el caso de que se detecten conflictos que

requieran soluciones no triviales, es necesaria la

Negociación de Requisitos.

Elicitación de Requisitos

Información elicitada

Documentación de Requisitos

Requisitos [borrador]

Análisis de Requisitos

Verificación de Requisitos

Validación de Requisitos

Requisitos [analizados]

Requisitos [verificados]

Requisitos [validados]

Gestión de Requisitos

Requisitos [versionados]

Defectos

Conflictos [pendientes]

Negociación de Requisitos

Conflictos [resueltos]

13


IR 8







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



• Proceso de negociación de requisitos

– El proceso 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







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Unified Modeling Language (UML)

– Estándar de la OMG (Object Management Group)

para el modelado de sistemas software.

noviembre 2013 Ingeniería de Requisitos

Oct 1995

Jun 1996

Booch'91 OMT-1 Otros métodos

Booch'93

Unified Method 0.8

UML 0.9

Ene 1997 UML 1.0

Sep 1997

UML 1.1

Jun 1998

UML 1.2

Mar 2000

UML 1.3

Sep 2001

UML 1.4

Mar 2003

UML 1.5

2005 UML 2.0 UML 2.1.1

Ago 2007

UML 2.1.2

Nov 2007

UML 2.2

Feb 2009

UML 2.3

May 2010

UML 2.4.1

Ago 2011

UML 2.4

Mar 2010

OOSE

OMT-2

15


IR 9







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Unified Modeling Language (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








© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• 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.


<<system>>

Nombre <<subsystem>>

Nombre Nombre

17


IR 10







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• 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







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



– 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.


c lass Ejemplo de restricc ión

Fac tura

número {único}fechaEmisión

L íneaDeFac tura

cantidadprecio

Cl iente Produc to

{fac turas sin dupl icados:un mismo producto no debe aparecer dos veces en la misma factura.}

*

contiene

1

*

emitidaA

1

1..*{ordered}

19


IR 11







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



– 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







© D

iseño d

e A

mador

Durá

n T

oro

, 2011



– 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.


importe : Moneda {importe debe ser múltiplo de 10€}

RetiradaEfectivo {estado=borrador, fechaRevisión=15/10/2004}

21


IR 12







© D

iseño d

e A

mador

Durá

n T

oro

, 2011


• Bibliografía

– C. Larman, UML y Patrones.

Ed. Prentice-Hall, 1999.

• Capítulos 9 al 12

– C. Larman, UML y Patrones (2ª

edición). Ed. Prentice-Hall, 2003.

• Capítulos 10 al 12

– M. Fowler, UML Distilled (3rd

edition). Ed. Addison-Wesley, 2004.

• Capítulo 3


Análisis de Requisitos - us

Documents

Transcript of Análisis de Requisitos - us