ingeniería de software: tema 3. análisis de requerimientosdtorres/cursos/ingsw/tema3.pdf ·...

1

1

INGENIERIA DE SOFTWARE Tema 3: Análisis de Requerimientos

Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca Instituto de Computación Oficina 37 [email protected]

Prof. David Martínez Torres

2

Contenido

1. Técnicas de recolección de información

2. Identificación de requerimientos

3. Análisis de requisitos basados en el estándar 830-1993 IEEE

4. Introducción y aplicación de los métodos estructurados

5. Introducción del método orientado a objetos en el análisis

6. Validación de requerimientos

7. Referencias


2

Introducción

Los requisitos son pieza fundamental en un proyecto de desarrollo de software

Marcan punto de partida en la planeación (estimaciones de tiempos y costos, recursos, programa)

Son la base para verificar si se alcanzaron o no los objetivos del proyecto

Prof. David Martínez Torres 3

4

Introducción

“Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir. Ninguna otra tarea es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces. No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal. Ninguna otra tarea es tan difícil de corregir más tarde“ F. P. Brooks, 1987 [6]


3

Introducción


Introducción


4

Introducción: “1994: The Standish Group” [10]

Estudió a más de 350 empresas USA y 8,000 proyectos de desarrollo de software.

52.7% finalizaba excedido en presupuesto (sobre 189%) y con retrasos de tiempo (sobre 122%) con menores características y funcionalidad especificada.

Finalmente el 31.1% restante simplemente se cancelaba (81 billones de dolares)

16.2% de proyectos en pequeñas compañías y el 9% en grandes compañías, finalizaban dentro de los costos y de los plazos establecidos, pero el producto final tenía (aprox.) la mitad de los requisitos iniciales


Introducción

Tabla 4. Resumen del reporte de CHAOS 2015.


5

9

Introducción

Boehm, 1975: 45% de los errores tienen su orígen en los requisitos y en el diseño preliminar.

DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala Especificación de Requisitos

Chaos Report, 1995: Los factores principales que conducen al fracaso en los proyectos Sw. Son

Requisitos incompletos

Falta de comunicación con los usuarios

Cambios a los requisitos


Introducción


6

Introducción



7

Ingeniería de requisitos

El área del conocimiento de los requisitos del software se refiere al análisis, a la especificación, y a la validación de los requisitos del software [2]

Los requisitos expresan las necesidades y restricciones que debe satisfacer un producto de software para contribuir a la solución de un problema del mundo real [3]


14

Ingeniería de Requisitos

La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.


8

Que es un requisito

Un requisito es una “condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado”.

También se aplica a las condiciones que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificación.


16

Ejemplo de lo que podemos encontrar en un documento de “requisitos”

1. El sistema mantendrá la temperatura de la caldera entre 70º y 80º

2. El sistema mantendrá un registro de todos los materiales de la biblioteca, incluyendo libros, periódicos, revistas, videos y CDROM’s

3. El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN

4. El interfaz de usuario se implementará sobre un navegador Web

5. El sistema deberá soportar al menos 20 transacciones por segundo

6. El sistema permitirá que los nuevos usuario se familiaricen con su uso en menos de 15 minutos.


9

17

Requisitos funcionales y no funcionales

Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema El sistema aceptará pagos con VISA

Los requisitos no funcionales son restricciones sobre los requisitos funcionales El sistema aceptará pagos con VISA de forma segura y

con un tiempo de respuesta menor de 5 segundos

Pero esta distinción, muchas veces, resulta arbitraria. El sistema aceptará pagos con VISA a través del

protocolo SET


Proceso de Ingeniería de requerimientos [4]


10

Estudio de viabilidad

Estudio corto que evalúa si el sistema es útil para el negocio, comprende evaluación y recolección de la información, y la redacción de informes

1. ¿El sistema contribuye a los objetivos generales de la organización o empresa?

2. ¿El sistema se puede implantar utilizando tecnología actual dentro de las restricciones de tiempo y presupuesto?

3. ¿El sistema puede integrarse a otros sistemas existentes en la empresa?


Estudio de viabilidad

Preguntas que ayudan a responder el estudio

1. ¿Cómo se las arreglaría la organización o empresa si no se implantara el sistema?

2. ¿Cuáles son los problemas con los procesos actuales y como ayudaría el nuevo sistema a resolverlos?

3. ¿Cuál es la contribución directa que hará el sistema a los objetivos del negocio?

4. ¿La información se puede obtener y transferir a otros sistemas de la organización?

5. ¿El sistema requiere tecnología que no se ha utilizado previamente en la organización?

6. ¿A qué debe ayudar el sistema y a qué no?


11

Obtención y análisis de requerimientos

Fuentes de requisitos

Técnicas de captura de requisitos.


Fuente de requisitos

Métas

Conocimiento del dominio

Stakeholders

El entorno operacional

El entorno organizacional.


12

Problema en la captura de requisitos

Los usuarios no pueden/saben describir muchas de sus tareas

Mucha información importante no llega a verbalizarse

A veces hay que “inventar” los requisitos

sistemas orientados a miles de usuarios: web, comercio electrónico, etc.

La captura no debería ser un proceso pasivo, sino cooperativo


Técnicas de captura de requisitos.

Entrevistas y cuestionarios

Taller de requerimientos

Lluvia y reducción de ideas

Storyboards

Casos de uso

Juego de roles

Prototipos

Observación y análisis de tareas


13

Entrevistas y cuestionarios.

Medios tradicionales de obtener

requisitos.

Debe usarse en complemento con otras técnicas

Es fundamental:

Entrevistar a la(s) persona(s) adecuadas

Preparar las preguntas con antelación

Utilizar diagramas, modelos, etc.

El éxito depende del entrevistador y de su preparación.



Modelo para generar la máxima cantidad posible de requerimientos

Los participantes deben pertenecer a distintas disciplinas y, preferentemente con mucha experiencia.

Generar en primera instancia, muchas ideas. Luego, se eliminarán en base a criterios como: "caro", "impracticable", "imposible", etc.


14


No detenerse en pensar si la idea es o no del todo utilizable.

Otro día, en otra sesión, se evalúan las ideas

Por ejemplo, pueden puntuarse (de –1 a 1)


Storyboards

Serie de dibujos ordenados secuencialmente, que muestra cómo se usará un sistema para una tarea específica.

Para crear un storyboard, primero se identifica la tarea que se representará y luego se plantea cómo el usuario usará el sistema para conseguir su objetivo, sin detalles de la interfaz


15

Storyboard de un sistema de envío de reportes para personas que no oyen ni hablan [5] Prof. David Martínez Torres 29

Casos de uso

Se basa en escenarios, que documentan el comportamiento del sistema

Identifica a los actores involucrados en una interacción

Describen la secuencia de interacciones entre el sistema y uno o más actores, es respuesta a un estímulo inicial de un actor.

También documentan excepciones que puedan surgir.


16

Juego de roles

Aquí el desarrollador, el analista,

y cada uno de los miembros del

equipo de desarrollo toman el

lugar del interesado y ejecutan la actividad de trabajo que éste desempeña.

Experimentan problemas ligados con el sistema que se está especificando.

Intención que el analista tenga una nueva perspectiva del problema para obtener los requisitos.


Prototipos

Herramienta para clarificar requisitos confusos

Formas de prototipos:

Pantallas que describen contenido e interacción en papel o en herramientas de prototipado.

Pantallas en entornos de desarrollo.


17

Prototipos

Características

Ser construidos en poco tiempo

Ser oportunos, o sea, estar listos temprano en el proceso para que ayude a clarificar ideas

Ser fácilmente modificables

Mostrar cómo será la interacción entre usuarios y sistema

Ayudar a crear un lenguaje común entre usuarios y desarrolladores

Sugerir en vez de confirmar, para que sirvan para refinar el diseño


Observación y análisis de tareas

Ingenieros del software

observan a los usuarios en

el desarrollo de sus tareas

Técnicas relativamente

costosas

Ilustran que muchas tareas del usuario y proceso de negocio son demasiado sutiles y complejo


18


Se aplican cuando los requisitos

tienen implicaciones cruzadas

desconocidas para las

personas individuales implicadas

Normalmente no se descubren en las entrevistas o quedaron incompletamente definidas.



Facilitados por un

analista del negocio,

las personas implicadas

participan en discusiones para descubrir requisitos

Analizan sus detalles y las implicaciones cruzadas. Es Útil la selección de un secretario para liberar al analista de negocios que se centre en la definición de requisitos.


19

37

Análisis de Requisitos

Consiste en detectar y resolver conflictos entre requisitos

Se precisan los límites del sistema y la interacción con su entorno

Se trasladan los requisitos de usuario a requisitos del software (implementables).

Se realizan tres tareas fundamentales: Clasificación, Modelización y Negociación


38

Clasificación de los requisitos

En el análisis de requisitos, éstos se clasifican

En funcionales vs. No funcionales (Capacidades vs. Restricciones)

Por prioridades

Por costo de implementación

Según su volatilidad/estabilidad

Si son requisitos sobre el proceso o sobre el producto


20

39

Modelización conceptual

Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interacción, de objetos, etc.

La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente)

El tipo de modelo elegido depende de

La naturaleza del problema

La experiencia del modelizador

La disponibilidad de herramientas

Por decreto. El cliente impone una notación


40

Negociación de requisitos

En todo proceso de IR intervienen distintos individuos con distintos y, a veces, enfrentados intereses

Estos conflictos entre requisitos se descubren durante el análisis. Todo conflicto descubierto debería disparar un proceso de (re)negociación.

Los conflictos NUNCA se deben resolver “por decreto”


21

41

El Documento de Requisitos

Es la forma habitual de guardar y comunicar requisitos.

Es buena práctica utilizar al menos, dos documentos, a distinto nivel de detalle

DRU = Documento de Requisitos de Usuario (en inglés, URD)

ERS = Especificación de Requisitos Software (en inglés, SRS)

Documento electrónico de almacenamiento y distribución:

Procesador de textos

Base de Datos

Herramienta de Gestión de Requisitos


42

Características de una buena ERS IEEE 830

Correcta

Si todo requisito que figura en ella refleja alguna

necesidad real.

Implica que el sistema implementado será el

sistema deseado.

No ambigua

Si cada requisito descrito tiene una única

interpretación.

Incluso puede incluir un glosario


22


Completa.

Incluye todos los requisitos significativos del software (funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).

Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas

Cumple con el estándar utilizado.

Aparecen etiquetadas todas las figuras, tablas, diagramas.



Consistente

Si ningún conjunto de requisitos son contradictorios o entran en conflicto. Casos:

Las características especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules.

Conflicto lógico o temporal entre dos acciones determinadas. Un requerimiento puede especificar que sumará dos entradas y otro que multiplicará las dos entradas.

Requisitos que describen el mismo objeto real utilizando distintos términos.


23


Clasificada por importancia y/o estabilidad

No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por

Importancia: Pueden ser esenciales, condicionales u opcionales.

Estabilidad: Cambios que pueden afectar al requisito.



Verificable

Si existe algún proceso no tan costoso que constate que el software satisface dicho requerimiento. Ejemplo

No verificables:

El producto debería funcionar bien

El producto debería tener una buena interfaz de usuario

Verificable:

La salida del programa se produce dentro de los 20 seg del evento por el 60% del tiempo, y en los 30 segundos por el 100% del tiempo.


24


Modificable

Si su estructura y estilo permiten un cambio fácil, completo y consistente.

Tener una organización coherente y fácil de usar con una tabla de contenido, índice y referencia cruzada.

No redundante



Trazable

Si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito).


25

49

La calidad como ideal

Una ERS perfecta es imposible.

La calidad de la ERS es muy difícil de cuantificar.

En general, una ERS de calidad NO garantiza la ausencia de problemas, pero una ERS pésima garantiza su presencia.


50

Validación de Requisitos

Objetivo: Descubrir problemas en el Documento de Requisitos antes de comprometer recursos a su implementación.

El documento debe revisarse para

descubrir omisiones

conflictos

Ambigüedades

Comprobar la calidad del documento y su grado de adhesión a estándares


26

51

Revisiones (Reviews)

Es la fórmula más empleada para validación

Un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de requisitos.

Tres fases: Busqueda de problemas, reunión y acuerdos.

Uso de listas de comprobación (“checklists”).

Hay “checklists” adaptadas a distintos tipos de sistemas


52

Otros métodos de validación

Prototipado: Permite descubrir con rápidez si el usuario se encuentra satisfecho, o no, con los requisitos

Uso de escenarios/casos de uso

Validación de modelos: Cuando los requisitos se expresan por medio de modelos (de objetos, DFDs, etc.)

Validación de su “testeabilidad”. El equipo de pruebas debe revisar los requisitos.


27

53

6. Conclusiones

En esta presentación se ha visto que los errores en la fase temprana (análisis del sistema), son los más graves, debido a que se van acumulando, ocasionando muchas veces productos totalmente opuestos a lo que necesita el cliente

De ahí la importancia que ha cobrado la ingeniería de requisitos, la cual ha apoyado en gran medida la definición correcta de los requerimientos tanto del software como del sistema

Se ha visto el proceso de requisitos y las técnicas que ayudan a la captura de tales requisitos.


54

7. Referencias

1. Pressman, S Roger (1998) “Ingeniería del Software: Un enfoque práctico”, 4a edición McGraw-Hill.

2. Kotonya, G., Sommerville, I. (1998) “Requirements Engineering. Processes and Techniques”. Wiley.

3. Kovitz, B.L. (1999) “Practical Software Requirements: A Manual of Content and Style”, Manning.

4. Sommerville, I., Sawyer P. (1998) “Requirements Engineering. A Good Practice Guide”, Wiley.

5. Davis, A. (1993) “Software Requirements: Objects, Functions and States” Prentice-Hall, 1993.

6. Somerville, Ian (2002) “Ingeniería de software”. 6a edición. Addison Wesley.

7. Braude Eric J. (2003) “Ingeniería de Software Una perspectiva orientada a objetos”, Alfaomega

8. Gause, D. C., Weinberg, G. M. (1989) “Exploring Requirements: Quality Before Design”, Dorset House.

9. Jackson, M. (1995) “Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices” Addison-Wesley.


28

55

8. Referencias

10. Robertson, S., Robertson, J. (1999) “Mastering the Requirements Process”, Addison-Wesley.

11. Wiegers, K. (1999) “Software Requirements”, Microsoft Press.

12. http://www.paper-review.com/tools/rms/read.php

13. Weitzenfeld, Alfredo (2004) Ingeniería de Software Orientada a Objetos con UML, Java e Internet. THOMSON EDITORES

14. Hadad, Graciela D. S. (2011), Notas de clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances. Universidad Belgrano, Buenos Aires, Argentina

15. Gacitúa Bustos Ricardo A. (2003) Métodos de desarrollo de software: El desafío pendiente de la estandarización. Theoria, Vol 12: 2003 Universidad del Bío-Bío. Chile.


56

¿Preguntas?

Gracias!


http://www.paper-review.com/tools/rms/read.php



http://www.cengage.com.mx/he/book_detail.php?isbn13=9789706861900&type=4

http://www.cengage.com.mx/he/book_detail.php?isbn13=9789706861900&type=4

http://www.laislalibros.com/busqueda/listaLibros.php?codEditorial=B35

ingeniería de software: tema 3. análisis de requerimientosdtorres/cursos/ingsw/tema3.pdf ·...

Documents