• Save
Tema 1 Ingeniería de Requisitos
Upcoming SlideShare
Loading in...5
×
 

Tema 1 Ingeniería de Requisitos

on

  • 18,104 views

Introducción a la Ingeniería de Requisitos, Captura de requisitos, análisis de requisitos, validación y verificación de requsitos

Introducción a la Ingeniería de Requisitos, Captura de requisitos, análisis de requisitos, validación y verificación de requsitos

Statistics

Views

Total Views
18,104
Views on SlideShare
16,704
Embed Views
1,400

Actions

Likes
19
Downloads
0
Comments
5

4 Embeds 1,400

http://www.isp.fuac.edu.co 1154
http://aula7.iua.edu.ar 162
http://www.slideshare.net 77
http://www.aprehendonline.com 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tema 1 Ingeniería de Requisitos Tema 1 Ingeniería de Requisitos Presentation Transcript

  • Análisis de Requisitos
    • Curso 2008-09 Juan Carlos González Moreno
  • Introducción
    • Ingeniería de Requisitos.
    • Modelos de Ciclo de Vida.
    • Proceso de desarrollo.
    • Metodologías de desarrollo.
    • Cliente y usuario.
  • Ingeniería de Requisitos
    • Los requisitos del sistema definen lo que tiene que hacer el sistema y las circunstancias bajo las que debe operar . Tipos:
      • Generales: Indican a “grosso modo” el objetivo del sistema. Ej: El sistema registra libros, periódicos, revistas y vídeos.
      • Funcionales: Definen parte de la funcionalidad del sistema. Ej: El sistema permitirá buscar un libro por título, autor o ISBN.
      • De Implementación: Indican como se construirá el sistema. Ej: La visualización se realizará utilizando el navegador Firefox.
      • De Rendimiento: Especifica atributos de espacio y/o tiempo. Ej: El sistema soportara un mínimo de 30 transacciones/segundo.
      • De Usabilidad: Indican el uso aceptable del sistema. Ej: Las utilidades se tienen que poder demostrar en < de 15 mn.
  • Ingeniería de Requisitos
    • La ingeniería de requisitos es el conjunto de actividades implicadas en descubrir, documentar y mantener un conjunto de requisitos .
    • Un proceso de ingeniería de requisitos es un conjunto estructurado de actividades de cuya ejecución se obtiene, valida y mantiene el documento de requisitos del sistema. El proceso define las actividades a realizar, su secuencia, entradas y salidas de cada actividad, etc.
    • La gestión de requisitos es una actividad encargada de gestionar los cambios en los requisitos del sistema . La gestión implica el control de cambios y el impacto de los mismos.
  • Ingeniería de Requisitos
    • Observaciones:
      • El coste de la fase de requisitos: 10-15 % del total
      • Corregir un requisito es 100 veces más caro que un error de programación
      • Los sistemas complejos conllevan miles de requisitos, por lo que es preciso un proceso y herramientas
      • Fallar en los requisitos es fallar en todo el proceso
      • Cuando se habla de requisitos no funcionales se está hablando de atributos de calidad del producto
  • Documento de Requisitos
  • Proceso de Requisitos
  • Gestión de Requisitos
  • Captura de Requisitos
    • Es un proceso en el cual los datos son extraídos de las personas pudiendo variar, dependiendo de la persona consultada . La Ingeniería de Requisitos ha trabajado arduamente para tratar de desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y segura:
    • Introspección: Esta técnica recomienda que el ingeniero de requisitos se ponga en el lugar del cliente y trate de imaginar como desearía él el Sistema.
    • Entrevistas: Existen diferentes tipos de entrevistas recomendadas, entre las que po demos mencionar:
      • Entrevistas de Cuestionarios
      • Entrevistas de final abierto
      • Entrevistas en grupos de desarrollo
      • Discusiones
  • Captura de Requisitos
    • Entrevistas de Cuestionarios.-
    • Este tipo de entrevistas recomienda que se genere un cuestionario de preguntas , el cual será aplicado al cliente para comenzar la captura de requisitos.
    • Entrevistas de final abierto.-
    • Este tipo de entrevistas son del tipo que realizan los psicólogos. La idea es que el ingeniero de requisitos permita que el Cliente le vaya narrando su problemática y el ingeniero de Software lo guíe a través de la narración para ir determinando los requisitos del sistema.
  • Captura de Requisitos
    • Entrevistas en grupos de desarrollo.-
    • Este tipo de entrevistas recomienda formar grupos específicos con el personal del cliente . Estos grupos tendrán en común algún área de trabajo o especialidad. El objetivo es poder contar con los expertos en cierta área de la empresa para poder llegar en conjunto a la especificación de requisitos.
    • Discusiones.-
    • Este tipo de entrevistas pretende que el Ingeniero de Requisitos sostenga una discusión con el Cliente sobre su problemática para tratar de determinar en conjunto los requisitos del sistema.
  • Captura de Requisitos
    • Análisis de Protocolo: Esta técnica parte de la idea de que el cliente cuenta con un modelo mental preexistente del sistema deseado. Se enfrenta al “experto “ con un caso real y se observa como lo resuelve (establecimiento del protocolo), preguntando y anotando las dudas.
    • Casos de Uso: Es una técnica bastante utilizada que &quot; captura cada una de las funciones del sistema &quot; y en base a cada una de ellas especifica sus requisitos.
    • VORD: Esta técnica es utilizada para capturar requisitos en base a puntos de vista . Es utilizado en sistemas que van a ser desarrollados con el paradigma de programación orientados a objetos.
  • Captura de Requisitos
    • Una buena Especificación de Requisitos debe tener en cuenta las siguientes consideraciones:
      • Naturaleza de la Especificación de Requisitos de Software.- Se deben especificar los siguientes aspectos:
        • Funcionalidad
        • Interfaz Externa
        • Rendimiento
        • Atributos
        • Restricciones de diseño
      • Ambiente de la Especificación de Requisitos.- Debe de estar descrita de tal manera que no describa aspectos del área de diseño o de implementación.
  • Captura de Requisitos
    • Características de los Requisitos.- Los requisitos descritos deben ser:
      • Completos
      • Implementación Independiente
      • Consistente y no Ambiguo
      • Preciso
      • Verificable
      • Que pueda ser leído
      • Modificable
  • Captura de Requisitos
    • Aprobación del Cliente o patrocinador.- Todos los requisitos descritos deben contar con ella. Un punto importante a tener en cuenta es la &quot;evolución&quot; de los mismos y proveer mecanismos que permitan la Evolución de la Especificación de Requisitos, e incluir requisitos del Proyecto en la Especificación de Requisitos. Requisitos tales como:
      • Costo
      • Fecha de Entrega
      • Criterios de Validación y Verificación
  • Captura de Requisitos
    • En general las fases de captura y análisis de requisitos de usuario han recibido poca atención por parte de las metodologías de desarrollo de software.
    • La transición a las fases de diseño, cuando se utilizan metodologías de orientación a objetos, así como la trazabilidad de los requisitos a lo largo de éste proceso, son también aspectos poco soportados por éstas.
  • Análisis de Requisitos
    • El objetivo del análisis de requisitos es descubrir problemas en el borrador de requisitos generado durante su captura .
    • Tareas del análisis:
      • Cuestionarse la necesidad de todos los requisitos
      • Investigar su consistencia y completitud
      • Asegurar su viabilidad: técnica, costes y planificación
    • Procedimientos:
      • Checklist
      • Matrices de interacción
  • Negociación de Requisitos
    • La negociación de requisitos es el proceso de discutir los conflictos encontrados y llegar a algún compromiso que satisfaga a todos los usuarios .
    • Ej: En el desarrollo de cierta aplicación para una empresa el departamento de ventas quiere tener acceso total a los recursos almacenados y a la lista de clientes, mientras que el de seguridad quiere controlar dichos recursos y permitir sólo un acceso restringido
      • Tareas de la negociación:
        • Discutir los requisitos conflictivos
        • Establecer prioridades en los requisitos
        • Compromiso final sobre el conjunto de requisitos
  • Validación de Requisitos
    • La validación de requisitos consiste en comprobar que los requisitos son consistentes, completos y precisos .
    • Análisis vs. validación:
      • En el análisis tenemos como entrada un conjunto incompleto de requisitos, en la validación un conjunto acordado de requisitos.
      • En el análisis nos preguntamos si ¿los requisitos satisfacen las necesidades del cliente? o ¿tengo los requisitos adecuados? en la validación sin embargo las preguntas más frecuentes son ¿están bien descritos los requisitos? o ¿el documento de requisitos representa claramente el sistema?
  • Validación de Requisitos
    • El proceso puede ser visto como:
  • Validación de Requisitos
    • Aproximaciones al proceso de validación:
        • Revisión de requisitos.- Un grupo de personas lee, analiza y discute el documento de requisitos. Se sigue un procedimiento similar al de inspección de código.
        • Test de requisitos.- Es deseable diseñar pruebas sobre cada requisito individual. Dificultades a la hora de diseñar casos de test para un requisito puede implicar ambigüedad del mismo o falta de información.
  • Validación de Requisitos
    • Aproximaciones al proceso de validación:
        • Prototipos.- Sólo tiene sentido si se desarrolla uno durante la fase de captura y se continua con él en el análisis.
  • Requisitos no funcionales
  • Problemas
    • Los Problemas del proceso de análisis de requisitos
    • El primer problema que se presenta es la captura de los requisitos del usuario:
      • De una manera sistemática y organizada.
      • Usando directrices o líneas guía.
      • Hacer los requisitos manejables y analizables.
        • Una vez conseguidos los requisitos, pasamos a la fase de análisis. En ella, lo que haremos es analizar los requisitos obtenidos de los usuarios con el fin de comprenderlos, y a partir de ellos desarrollar una especificación de la aplicación, que deberá ser completa y consistente, y deberá estar expresada de una manera al menos semiformal, no simplemente textual. En este proceso, encontraremos habitualmente gran cantidad de problemas en los requisitos, areas no especificadas, requisitos contradictorios, y afirmaciones (aparentemente) vagas e irrelevantes. Eso nos llevará de vuelta a los usuarios con el fin de mejorar la calidad de los requisitos: pero debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y el por qué.
        • Después de obtener una buena lista de requisitos, comenzamos con el análisis y el diseño de la aplicación, y entonces nos surgen nuevos problemas: el primero es la trazabilidad de los requisitos: cómo seguir un requisito de usuario por el análisis, el diseño y el código, que nos permita comprobar que el requisito ha sido tenido en cuenta y cómo lo ha sido. Y esto enlaza directamente con el problema de la mantenibilidad: cuando los requisitos comienzan a evolucionar -como sin duda lo harán-, cómo podemos ir evolucionando el diseño y el código consistentemente con ello, y cómo seguir manteniendo la trazabilidad.
  • Problemas
    • Los Problemas del proceso de análisis de requisitos
    • El segundo problema es pasar a la fase de análisis, donde analizaremos los requisitos obtenidos para:
      • comprenderlos ,
      • desarrollar una especificación de la aplicación completa y consistente
      • expresarlos al menos semiformalmente .
  • Problemas
    • Los Problemas del proceso de análisis de requisitos
    • Además en este proceso, encontraremos habitualmente gran cantidad de fallos en los requisitos: áreas no especificadas, requisitos contradictorios, y afirmaciones (aparéntemente) vagas e irrelevantes .
    • Eso nos llevará de vuelta a los usuarios a los que debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y por qué .
  • Problemas
    • Los Problemas del proceso de análisis de requisitos
    • Durante el análisis y el diseño de la aplicación surgen nuevos problemas:
      • La trazabilidad de los requisitos : cómo seguir un requisito de usuario por el análisis, el diseño y el código.
      • La mantenibilidad : cuando los requisitos evolucionen cómo podemos evolucionar el diseño y el código consistentemente con ello, y manteniendo la trazabilidad.