Sesion6 Procesos de Ingeniería de Requisitos
Upcoming SlideShare
Loading in...5
×
 

Sesion6 Procesos de Ingeniería de Requisitos

on

  • 737 views

Describe las principales relaciones de la ingeniería de requisitos. Introduce las técnicas de obtención y análisis de requisitos, así como la validación y revisión de requisitos, y la gestión ...

Describe las principales relaciones de la ingeniería de requisitos. Introduce las técnicas de obtención y análisis de requisitos, así como la validación y revisión de requisitos, y la gestión de requisitos en apoyo de otros procesos de la ingeniería de requisitos.

Statistics

Views

Total Views
737
Views on SlideShare
737
Embed Views
0

Actions

Likes
0
Downloads
44
Comments
0

0 Embeds 0

No embeds

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

Sesion6 Procesos de Ingeniería de Requisitos Sesion6 Procesos de Ingeniería de Requisitos Presentation Transcript

  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 1 Procesos de Ingeniería de Requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 2 Objetivos Describir las principales relaciones de la ingeniería de requerimientos Introducir a las técnicas de obtención y análisis de requerimientos Describir la validación de requerimientos y la función de la revisión de requerimientos Discutir la función de la gestión de requerimientos en apoyo de otros procesos de la ingeniería de requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 3 Tópicos Expuestos Estudios de viabilidad Obtención y análisis de requerimientos Validación de requerimientos Gestión de requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 4 Procesos de la ingeniería de requerimientos Los procesos utilizados para la ingeniería de requerimientos varían ampliamente dependiendo en el dominio de la aplicación, las personas implicadas y la organización que desarrolla los requerimientos. Sin embargo, hay una serie de actividades genéricas comunes a todos los procesos • Obtención de requerimientos; • Análisis de requerimientos; • Validación de requerimientos; • Gestión de requerimientos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 5 El proceso de ingeniería de requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 6 Ingeniería de requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 7 Estudios de viabilidad Un estudio de viabilidad decide si el sistema propuesto es meritorio o no. Es un estudio breve orientado a resolver varias cuestiones • Si el sistema contribuye a los objetivos organizacionales; • Si el sistema puede ser diseñado utilizando la tecnología actual y dentro del presupuesto; • Si el sistema puede integrarse con otros sistemas existentes.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 8 Implementación del estudio de viabilidad Sobre la base de evaluación de la información (lo que se requiere), la recopilación de información y redacción de informes. Preguntas para las personas en la organización • Qué pasa si el sistema no fue implementado? • Cuáles son los problemas con los procesos actuales? • Cómo ayudará el sistema propuesto? • Cuáles serán los problemas de integración? • Nueva tecnología es requerida por el sistema? • A qué debe ayudar el sistema?
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 9 Obtención y análisis A veces llamado obtención o descubrimiento de requerimientos. Implica personal técnico que trabaja con los clientes para conocer el dominio de aplicación, los servicios que debe proporcionar el sistema y las restricciones operacionales del sistema. Puede implicar a los usuarios finales, administradores, ingenieros involucrados en el mantenimiento, expertos de dominio, los sindicatos, etc. Estos se llaman stakeholders (afectados por el sistema).
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 10 Problemas de análisis de requerimientos Los afectados (stakeholders) no saben lo que realmente quieren. Los afectados por el sistema expresan los requerimientos en sus propios términos. Las diferentes partes interesadas (stakeholders) pueden tener requerimientos conflictivos. Factores organizacionales y políticos pueden influir en los requerimientos del sistema. Las requerimientos cambian durante el proceso de análisis. Pueden surgir nuevos stakeholders y el entorno empresarial cambia.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 11 Proceso de obtención y análisis de requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 12 Actividades del proceso Descubrimiento de requerimientos • Interactuar con las partes interesadas para conocer sus necesidades. Los requerimientos del dominio son también descubiertos en esta etapa. Clasificación y organización de requerimientos • Agrupa los requerimientos relacionados y los organiza de un modo coherente. Ordenación por prioridades y negociación • Priorizar requerimientos y resolver los conflictos entre los mismos. Documentación de requerimientos • Los requerimientos son documentados e ingresados en la siguiente iteración.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 13 Descubrimiento de requerimientos Proceso de recopilación de información sobre los sistemas propuestos y existentes y la destilación de los requerimientos de usuario y del sistema a partir de esta información. Fuentes de información que incluyen la documentación, afectados por el sistema (stakeholders) y las especificaciones de sistemas similares.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 14 Stakeholders de un sistema de cajero automático Los clientes del banco Representantes de otros bancos Directores de banco Contadores Administradores de base de datos Los administradores de seguridad Departamento de marketing Ingenieros de mantenimiento de hardware y software Reguladores bancarios
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 15 Puntos de vista Son una forma de estructuración de los requerimientos para representar las perspectivas de diferentes stakeholders. Los stakeholders pueden ser clasificados por diferentes puntos de vista. Este análisis de perspectiva múltiple es importante ya que no existe una única forma correcta de analizar los requerimientos del sistema.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 16 Tipos genéricos de punto de vista Puntos de vista de los interactuadores • Personas u otros sistemas que interactúan directamente con el sistema. En un cajero automático, el cliente y la base de datos de la cuenta son puntos de vista de los interactuadores. Puntos de vista indirectos • Stakeholders que no utilizan el sistema en sí, pero influyen en los requerimientos. En un cajero automático, la gerencia del banco y el personal de seguridad son puntos de vista indirectos. Puntos de vista del dominio • Representan las características y restricciones del dominio que influyen en los requerimientos del sistema. En un cajero automático, un ejemplo serían los estándares para las comunicaciones inter-bancarias.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 17 Identificación de los puntos de vista Identificar los puntos de vista utilizando • Proveedores y receptores de los servicios del sistema; • Sistemas que interactúan directamente con el sistema a especificar; • Regulaciones y estándares que se aplican al sistema; • Fuentes de los negocios y los requerimientos no funcionales. • Ingenieros que han de desarrollar y mantener el sistema; • Marketing y otros puntos de vista.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 18 Jerarquía de los puntos de vista en el LIBSYS
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 19 Entrevistas En el sector formal o informal de entrevistas, el equipo de ingeniería de requerimientos formula preguntas a los interesados sobre el sistema que utilizan y el sistema a desarrollar. Hay dos tipos de entrevista • Entrevistas cerradas donde los stakeholders responden a un conjunto de preguntas. • Entrevistas abiertas, donde no hay una agenda pre-definida y una gama de cuestiones se estudian con los stakeholders del sistema.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 20 Entrevistas en la práctica Normalmente una mezcla de entrevistas abiertas y cerradas. Las entrevistas son buenas para obtener una comprensión global de lo que hacen los stakeholders y cómo pueden interactuar con el sistema. Las entrevistas no son buenas para la comprensión de los requerimientos de dominio • Los ingenieros de requerimientos no pueden entender el la terminología específica del dominio; • Algún conocimiento del dominio es tan familiar que las personas tienen dificultades para articular o pensar que no vale la pena articular.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 21 Entrevistadores eficaces Los entrevistadores deben ser de mentalidad abierta, dispuestos a escuchar a los stakeholders y no deben tener ideas pre- concebidas acerca de los requerimientos. Deben impulsar al entrevistado con una pregunta o una propuesta y no simplemente esperar que responda a una pregunta como qué quieres o esperas?.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 22 Escenarios Los escenarios son ejemplos de la vida real de cómo un sistema puede ser utilizado. Deben incluir • Una descripción de la situación inicial; • Una descripción del flujo normal de los acontecimientos; • Una descripción de lo que puede salir mal y cómo manejarlo; • Información acerca de otras actividades; • Una descripción del estado del sistema cuando finalice el escenario.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 23 LIBSYS escenario (1) Asunción inicial: El usuario ha abierto una sesión al sistema de LIBSYS y ha localizado el diario que contenía la copia del artículo. Normal: El usuario selecciona el artículo para ser copiado. El sistema entonces proporciona la información del suscriptor para el diario e indica cómo se pagará el artículo. Los métodos alternativos del pago están por la tarjeta de crédito o cotizando un número de cuenta bancaria. Entonces piden al usuario rellenar un impreso de los derechos reservados que mantenga los detalles de la transacción y someten esto al sistema de LIBSYS. Se comprueba la forma de los derechos reservados y, si es ACEPTABLE, la versión del pdf del artículo se transfiere a la zona de trabajo de LIBSYS en la computadora del usuario y el usuario es informado de que está disponible. Pide al usuario seleccionar una impresora y una copia del artículo se imprime. Si el artículo se ha señalado por medio de una bandera como `solo imprimir' se suprime del sistema una vez que el usuario ha confirmado la impresión completa.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 24 LIBSYS escenario (2) Qué puede salir mal: El usuario puede no poder rellenar el impreso de los derechos reservados correctamente. En este caso, la forma se debe presentar al usuario para la corrección. Si la forma sometida es todavía incorrecta, entonces el pedido de usuario del artículo se rechaza. El pago se puede rechazar por el sistema. El pedido de usuario el artículo se rechaza. La transferencia directa del artículo puede fallar. Revise hasta acertado o el usuario termina la sesión. Puede no ser posible imprimir el artículo. Si el artículo no se señala por medio de una bandera como `imprímalo-only' entonces se sostiene en el espacio de trabajo de LIBSYS. Si no, se suprime el artículo y la cuenta de usuario se acredita con el coste del artículo. Otras actividades: Transferencias directas simultáneas de otros artículos. Estado de sistema en la terminación: Abren una sesión al usuario. El artículo transferido se ha suprimido de espacio de trabajo de LIBSYS si se ha señalado por medio de una bandera como imprime-solamente.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 25 Casos de uso Son un escenario basado en la técnica de UML que permite identificar a los actores interactuantes y que describen la interacción propiamente dicha. Un conjunto de casos de uso deben describir todas las posibles interacciones con el sistema. Diagramas de secuencia se puede utilizar para añadir detalles a casos de uso, mostrando la secuencia de transformación de eventos en el sistema.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 26 Caso de Uso - Imprimiendo
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 27 LIBSYS - Casos de Uso
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 28 Imprimir artículo
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 29 Diagrama de Secuencia
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 30 Factores sociales y organizacionales Sistemas de software se utilizan en un contexto social y organizativo. Esto puede influir o incluso dominar los requisitos del sistema. Factores organizativos y sociales no son un único punto de vista, pero son factores que influyen en todos los puntos de vista. Buenos analistas deben ser sensibles a estos factores, pero actualmente no de forma sistemática para hacer frente a su análisis.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 31 Etnografía Los analistas pasan un considerable tiempo observando y analizando cómo la gente trabaja realmente. La gente no tiene que explicar o articular su trabajo. Se pueden observar factores sociales y organizacionales de importancia. Estudios etnográficos han mostrado que el trabajo es generalmente más rico y más complejo que la que sugieren los modelos de sistemas simples.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 32 Etnografía enfocada Desarrollado en un proyecto de estudio de un proceso de control de tráfico aéreo Combina la etnografía con prototipado Desarrollo de prototipos resulta en preguntas sin respuesta que enfocan el análisis etnográfico. El problema de la etnografía es que estudia prácticas existentes que pueden tener cierta base histórica, que ya no es relevante.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 33 Etnografía y prototipado
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 34 Alcance de la etnografía Los requerimientos se derivan de la forma en que las personas trabajan realmente, no de la manera en que las definiciones del proceso sugieren que deberían trabajar. Los requerimientos se derivan de la cooperación y el conocimiento de las actividades de otras personas.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 35 Validación de requerimientos Preocupado por demostrar que los requerimientos definen el sistema que el cliente realmente quiere. Los costes de error en los requerimientos son muy altos, por lo que la validación es muy importante • Reparar un error en los requerimientos después de la entrega puede costar hasta 100 veces más que la reparación de un error de implementación.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 36 Verificación de los requerimientos Verificaciones de validez. El sistema proporciona los servicios que mejor responden a las necesidades del cliente? Verificaciones de consistencia. Hay conflictos entre los requerimientos? Verificaciones de completitud. Son todas las funciones requeridas por el cliente? Verificaciones de realismo. pueden implementarse los requerimientos dada la disponibilidad de presupuesto y tecnología? Verificabilidad. Pueden ser verificados los requisitos?
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 37 Técnicas de validación de requerimientos Revisiones de requerimientos • Análisis sistemático manual de los requerimientos. Construcción de prototipos • Usando un modelo ejecutable del sistema para verificar los requerimientos. Contempladas en el Capítulo 17. Generación de casos de prueba • Desarrollar pruebas para los requerimientos del usuario y comprobar que éstos deben poder probarse.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 38 Evaluación de requerimientos Evaluaciones periódicas deberían realizarse mientres la definición de los requerimientos se está formulando. Tanto el cliente como el personal contratista deben participar en las evaluaciones. Las evaluaciones pueden ser formales (con documentos completos) o informales. Una buena comunicación entre desarrolladores, clientes y usuarios pueden resolver los problemas en una etapa inicial o temprana.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 39 Revisiones de los requerimientos Verificabilidad. Puede probarse el requerimiento de modo realista? Comprensibilidad. Es el requisito comprensible? Rastreabilidad. Está claramente definido el origen del requerimiento? Adaptabilidad. Puede modificarse el requerimiento sin causar un gran impacto en otros requerimientos?
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 40 Gestión de requerimientos Es el proceso de gestionar la evolución de los requerimientos durante el proceso de ingeniería de requerimientos y el desarrollo del sistema. Los requerimientos son inevitablemente incompletos e inconsistentes • Nuevos requerimientos emergen durante el proceso de cambio de requerimientos de la empresa y una mejor comprensión del sistema es desarrollada; • Puntos de vista diferentes, tienen diferentes requerimientos y éstos son a menudo contradictorios.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 41 Cambio en los requerimientos La prioridad de los requerimientos de los diferentes puntos de vista cambia durante el proceso de desarrollo. Los clientes del sistema pueden especificar los requerimientos desde una perspectiva empresarial que entra en conflicto con los requerimientos de los usuarios finales. El entorno empresarial y técnico del sistema cambia durante su desarrollo.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 42 Evolución de requerimientos
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 43 Requerimientos duraderos y volátiles Requerimientos duraderos. Derivados de la actividad principal de la organización. Por ejemplo, un hospital tendrá siempre médicos, enfermeras, etc. Pueden derivarse de modelos del dominio Requerimientos volátiles. Requerimientos que cambian durante el desarrollo o cuando el sistema está en uso. En un hospital, requerimientos derivados de la política de atención a la salud
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 44 Clasificación de los requerimientos Tipo de requerimiento Descripcion Requerimientos cambiantes Requerimientos que cambian debido a los cambios en el entorno en el que opera la organización. Por ejemplo, en los sistemas hospitalarios, el pago del cuidado del paciente puede cambiar y así requerir un tratamiento diferente la información a tratar Requerimientos emergentes Requerimientos que emergen a medida que la comprensión del sistema por parte del cliente aumenta durante el desarrollo del sistema. El proceso de diseño puede revelr nuevos requerimientos emergentes. Requerimientos consecuentes Requerimientos que resultan de la introducción de un sistema informático o computacional. Al introducir dicho sistema pueden cambiar los procesos empresariales y abrir nuevas formas de trabajo que generan nuevos requerimientos del sistema Requerimientos de compatibilidad Requerimientos que dependen en sistemas particulares o procesos empresariales dentro de las organizaciones. A medida que esos cambian, los requerimientos de compatibilidad en el sistema entregado puede que también tengan que evolucionar.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 45 Planificación de la gestión de requerimientos Durante el proceso de ingeniería de requerimientos, usted tiene que planificar: • La identificación de requerimientos • Cómo los requerimientos son identificados individualmente; • Un proceso de gestión del cambio • El proceso seguido en el análisis de requerimientos de un cambio; • Las políticas de rastreo • La cantidad de información acerca de las relaciones de los requerimientos que se mantienen; • Herramientas CASE de apoyo • La herramienta de apoyo requerida para ayudar a gestionar los cambios en los requerimientos;
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 46 Rastreabilidad La rastreabilidad se refiere a las relaciones entre los requerimientos, sus fuentes y el diseño del sistema Información de rastreo de la fuente • Enlaces de los requerimientos a los stakeholders que propusieron estos requerimientos; Información de rastreo de los requerimientos • Vínculos entre los requerimientos dependientes; Información de rastreo del diseño • Enlaces de los requerimientos hacia el diseño;
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 47 Una matriz de rastreo
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 48 Herramienta CASE de apoyo Almacenamiento de requerimientos • Los requerimientos deben ser administrados de forma segura, desde un almacén de datos. Gestión del cambio • El proceso de gestión del cambio es un proceso de flujo de trabajo cuyas etapas pueden ser definidas y el flujo de información entre estas etapas parcialmente automatizado. Gestión de rastreo • Recuperación automatizada de los vínculos entre los requisitos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 49 Gestión del cambio de requerimientos Debería aplicarse a todos los cambios propuestos a los requerimientos. Principales etapas • Análisis de problemas. Discutir las necesidades y proponer cambios; • Análisis del cambio y cálculo de costos. Evaluar los efectos del cambio en los demás requerimientos; • Implementación del cambio. Modificar el documento de requerimientos y otros documentos a fin de reflejar el cambio.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 50 Gestión del cambio
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 51 Puntos clave El proceso de ingeniería de requerimientos incluye un estudio de viabilidad, obtención y análisis de requerimientos, especificación de los requerimientos y gestión de requerimientos. Obtención y análisis de requerimientos es iterativa, puesto que implica la comprensión de dominio, clasificación, estructuración, priorización y validación. Los sistemas tienen múltiples stakeholders con diferentes requerimientos.
  • ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 52 Puntos clave Factores sociales y organizacionales influyen en los requerimientos del sistema. La validación de requerimientos se refiere a verificaciones de validez, consistencia, integridad, realismo y la verificabilidad. Cambios en las empresas inevitablemente llevan a cambios en los requerimientos. La gestión de requerimientos incluye la planificación y gestión del cambio.