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
Prof. David Martínez Torres
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]
Prof. David Martínez Torres
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
Prof. David Martínez Torres 7
Introducción
Tabla 4. Resumen del reporte de CHAOS 2015.
Prof. David Martínez Torres 8
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
Prof. David Martínez Torres
Introducción
Prof. David Martínez Torres 10
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]
Prof. David Martínez Torres 13
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.
Prof. David Martínez Torres
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.
Prof. David Martínez Torres 15
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.
Prof. David Martínez Torres
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
Prof. David Martínez Torres
Proceso de Ingeniería de requerimientos [4]
Prof. David Martínez Torres 18
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?
Prof. David Martínez Torres 19
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?
Prof. David Martínez Torres 20
11
Obtención y análisis de requerimientos
Fuentes de requisitos
Técnicas de captura de requisitos.
Prof. David Martínez Torres 21
Fuente de requisitos
Métas
Conocimiento del dominio
Stakeholders
El entorno operacional
El entorno organizacional.
Prof. David Martínez Torres 22
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
Prof. David Martínez Torres 23
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
Prof. David Martínez Torres 24
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.
Prof. David Martínez Torres 25
Lluvia y reducción de ideas
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.
Prof. David Martínez Torres 26
14
Lluvia y reducción de ideas
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)
Prof. David Martínez Torres 27
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
Prof. David Martínez Torres 28
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.
Prof. David Martínez Torres 30
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.
Prof. David Martínez Torres 31
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.
Prof. David Martínez Torres 32
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
Prof. David Martínez Torres 33
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
Prof. David Martínez Torres 34
18
Taller de requerimientos
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.
Prof. David Martínez Torres 35
Taller de requerimientos
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.
Prof. David Martínez Torres 36
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
Prof. David Martínez Torres
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
Prof. David Martínez Torres
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
Prof. David Martínez Torres
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”
Prof. David Martínez Torres
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
Prof. David Martínez Torres
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
Prof. David Martínez Torres
22
Características de una buena ERS IEEE 830
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.
Prof. David Martínez Torres 43
Características de una buena ERS IEEE 830
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.
Prof. David Martínez Torres 44
23
Características de una buena ERS IEEE 830
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.
Prof. David Martínez Torres 45
Características de una buena ERS IEEE 830
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.
Prof. David Martínez Torres 46
24
Características de una buena ERS IEEE 830
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
Prof. David Martínez Torres 47
Características de una buena ERS IEEE 830
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).
Prof. David Martínez Torres 48
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.
Prof. David Martínez Torres
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
Prof. David Martínez Torres
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
Prof. David Martínez Torres
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.
Prof. David Martínez Torres
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.
Prof. David Martínez Torres
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.
Prof. David Martínez Torres
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.
Prof. David Martínez Torres
56
¿Preguntas?
Gracias!
Prof. David Martínez Torres