1 / 45

Elicitación De Requerimientos Lic. Mario G. Oloriz

Elicitación De Requerimientos Lic. Mario G. Oloriz. Agosto 2004. Elicitación. Es el proceso de adquirir (“eliciting”) [sonsacar] todo el conocimiento relevante necesario para producir un modelo de los requerimientos de un dominio de problema

ianna
Download Presentation

Elicitación De Requerimientos Lic. Mario G. Oloriz

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Elicitación De Requerimientos Lic. Mario G. Oloriz Agosto 2004

  2. Elicitación • Es el proceso de adquirir (“eliciting”) [sonsacar] todo el conocimiento relevante necesario para producir un modelo de los requerimientos de un dominio de problema • Objetivo: entender el dominio del problema en particular • ¿Dónde encontrar el conocimiento? • Problemas: • Forma no utilizable del conocimiento • Dificultad cuando se trata de un experto humano

  3. Temario • Técnicas de elicitacion • Ingeniería de requerimientos como proceso social • Ingeniería de requerimientos y elicitación de conocimiento • Conclusión

  4. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  5. Partiendo del usuario • El más intuitivo de los enfoques • Razones de las dificultades: • Poca claridad del usuario • Dificultad del usuario para transmitir su conocimiento • Diferencias entre usuario y analista • El usuario puede no querer el sistema • Se dispone de una serie de técnicas

  6. Partiendo del usuarioTécnicas • Entrevista de comienzo y final abierto • Entrevistas estructuradas • Brainstorming

  7. Entrevistas de comienzo y final abierto • Forma más simple de interacción analista-usuario • El analista deja que el usuario hable de su tarea • Ambiente informal • Útiles para obtener visiones generales • No son útiles para obtener información detallada

  8. Entrevistas estructuradas • Direcciona al usuario hacia aspectos específicos de requerimientos a elicitar • Son útiles para información detallada • Preguntas cerradas, abiertas, de sondeo y de guía • Información para obstáculos y soporte

  9. Brainstorming • Se utiliza para resolver la falta de consenso entre usuarios • Es útil combinarlo con la toma de decisiones • Ayuda a entender el dominio del problema • Encara la dificultad del usuario para transmitir • Reduce la falta de consenso • Ayuda a entender: al usuario y al analista

  10. Partiendo del usuarioResumen • El medio más directo para la elicitación • Se requieren habilidades especiales del analista • Problemas: • tiempo limitado del usuario • dificultades sicológicas

  11. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  12. Análisis de objetivo y meta • Propósito: • colocar los requerimientos en un contexto mayor • comprender la relación de ese problema con los problemas y objetivos del sistema mayor (la jerarquía sistémica vale para los SBC) • tener los requerimientos adecuados

  13. Análisis de objetivo y metaConceptos básicos • Metas • un estado del sistema, o • un conjunto de valores deseados para un número de parámetros. • ejemplo: en una empresa 1M$ de ganancia, (“ganancia”=parámetro y 1M$=valor del parámetro) • Varian su específicidad (abstracción) al subir el nivel • Metas estratégicas • Metas tácticas • Metas operacionales • Objetivos • son las metas más abstractas • ejemplo: “aumentar la utilidad”

  14. Análisis de objetivo y metaJerarquía de metas • Se organiza una jerarquía de metas • Resulta un lattice con niveles: • Metas más abstractas (objetivos) • Metas • Metas menos abstractas (sub-metas) • En un nivel de la jerarquía, dos metas pueden: • soportarse mutuamente • ser mutuamente conflictivas • Restricciones: impiden alcanzar las metas.

  15. Análisis de objetivo y metaResumen • El enfoque del análisis objetivo-meta ve el dominio del problema como consistente en objetivos, metas, sub-metas (medios), organizados en una jerarquía de meta-submeta (fin-medio), y restricciones • Propósito de la jerarquía de objetivos: • identificar los requerimientos de software en el contexto del dominio del problema • “mapear” los requerimientos hasta los objetivos de alto nivel del sistema

  16. Análisis de objetivo y metaPasos en el análisis • Analizar la organización y el ambiente externo • Crear una jerarquía meta-submeta consistente en: objetivos organizacionales, metas y restricciones y sus relaciones (soporte, conflicto, restricción) • Validar y consensuar el modelo • Identificar la parte de la jerarquía meta-submeta que modeliza la parte de procesamiento de la información de la organización • Eliminar los casos de conflictos en el modelo anterior con los stakeholders • Seleccionar tareas (requerimientos) por eliminación de alternativas

  17. Análisis de objetivo y metaVentajas • Permite una clara comprensión del dominio del problema • Requerimientos del problema en un contexto mayor • Considerar soluciones potenciales

  18. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  19. EscenariosConceptos básicos • Escenario = historia que ilustra cómo un sistema puede satisfacer necesidades del usuario • Descripción idealizada pero detallada de una instancia específica de interacción hombre-máquina • Medios diversos (texto, dibujos, diagramas) • Estructurados en diálogos o narrativas • Similitud con los prototipos

  20. EscenariosVentajas • Los usuarios encuentran más fácil transmitir su experticia a través de “contar una historia” • Es una solución prometedora al problema de la comunicación

  21. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  22. Análisis de formularios • Formulario = colección estructurada de variables que está formateada para soportar ingreso de datos y su recuperación • Es una fuente importante pues: • es un modelo formal • es un modelo de datos • a menudo contienen información sobre la organización • sus instrucciones de uso encierran conocimiento sobre el dominio • su análisis puede automatizarse

  23. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  24. Lenguaje natural • Forma más habitual de representación del conocimiento • La mayoría de lo que vale la pena conocer sobre el dominio del problema puede formularse en NL • Categorías de elicitación en NL: • enfoques que interactúan con el usuario • enfoques que elicitan desde un texto en NL • Su atractivo reside en: • vocabulario preexistente • informalidad • sintaxis

  25. Lenguaje naturalResumen • Es una fuente importante de conocimiento • Dos limitaciones: • el NL es muy complejo • la ambigüedad del NL

  26. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  27. Reuso de requerimientos • Idea de base: los requerimientos capturados para alguna aplicación pueden usarse en otra similar • Razones que la hacen interesante: • mejora global del proceso • similitud en sistemas • calidad

  28. Reuso de requerimientosAplicación • Problemas de aplicación: • acceso a los documentos de los requerimientos • “adecuabilidad” de un viejo requerimiento • Prerequisitos de aplicación: • acceso a los requerimientos de los sistemas existentes • facilidades para seleccionar, testear y modificar viejos requerimientos • más barato que obtener los requerimientos desde cero

  29. Reuso de requerimientosEnfoques existentes • Reuso de especificaciones. Desarrollo y mantenimiento de una biblioteca de componentes reusables de requerimientos • Análisis de Dominio. Es el precursor del reuso de requerimientos • Ingeniería reversa. Obtener información de alto nivel de información de menor nivel

  30. Reuso de requerimientosReuso de especificaciones • Abarca las bibliotecas de requerimientos reusables así como las técnicas para reusarlos • Hay varios enfoques: • Knowledge-Based Requirements Assistant (KBRA) • Aprendiz de requerimientos • Razonamiento analógico

  31. Reuso de requerimientosAnálisis de Dominio • Crear una estructura para reusar requerimientos a través de: • identificar categorías de dominios de problemas • identificar y formalizar los conceptos comunes entre los diferentes dominios de aplicación • organizar bibliotecas de componentes reusables • DA ayuda a la comprensión del dominio del problema • La elicitación de requerimientos deviene en selección, adaptación e incorporación • DA abarca todo el ciclo de vida del software.

  32. Reuso de requerimientosIngeniería reversa • Proceso de análisis de un sistema SW para: • identificar componentes e interrelaciones • crear representaciones (otra forma o mayor nivel) • Construir SRS a partir de información de menor nivel • Salida: especificaciones del sistema original • Factores de éxito: • disponibilidad, accesibilidad, testeabilidad y modificabilidad de los requerimientos existentes • similitud del nuevo sistema SW con uno existente

  33. Técnicas de elicitacion • Partiendo del usuario • Análisis de objetivo y meta • Escenarios • Análisis de formularios • Lenguaje natural • Reuso de requerimientos • Análisis de tareas

  34. Análisis de tareas • útil en la interacción hombre-máquina. • describe la tarea de los usuarios en términos: • de actividades que ejecutan y cómo están estructuradas • del conocimiento requerido para ejecutar esas actividades • opción: análisis jerárquico de tareas, en resumen, el análisis de tareas: • es un valioso input el proceso de RE • el conocimiento sobre el dominio del problema se refiere al viejo sistema • es una base para el futuro sistema

  35. Análisis de tareasAnálisis jerárquico. Ejemplo Recibir pedido Archivar hasta procesamiento Procesar pedido controlar datos clientes verificar datos fijos controlar nivel de crédito controlar productos verificar datos fijos verificar stock controlar condicion de entrega lugar de entrega fecha de entrega Post proceso archivar copia enviar a Despacho y a Créditos registrar cumplimiento

  36. Temario • Técnicas de elicitacion • RE como proceso social • RE y elicitación de conocimiento • Conclusión

  37. RE como proceso social • RE en un contexto social • No hacerlo es fuente de fallas de los sistemas: • no se construye para atender los requerimientos, o • no soporta las reales necesidades de los usuarios • Premisas • los aspectos sociales y técnicos son igualmente importantes • interdependencia de ambos aspectos • Los requerimientos son • producto de la interacción usuario-técnico • solo tienen sentido en el contexto organizacional.

  38. RE como proceso socialParticipación del usuario • Es importante mayor participación del usuario y que los equipos de desarrollo deben ser más pensados en su constitución. • Participantes en el desarrollo (Macaulay): • interesados financieramente • responsable por el diseño e implementación • responsable por la introducción del sistema • interesados en el uso

  39. RE como proceso socialMétodos etnograficos • Características: • alternativa a los enfoques clásicos • podría producir SRS de mayor calidad • conocimiento no registrado formalmente. • Los analistas son: • observadores pasivos • no aíslan las tareas • Resultados de las investigaciones tienden a: • comprobar la utilidad del enfoque • su uso requiere más elaboración y estructuración • difícil de entender y consumidor de tiempo • complemento de técnicas más “duras”

  40. Temario • Técnicas de elicitacion • RE como proceso social • RE y elicitación de conocimiento • Conclusión

  41. RE y elicitación de conocimiento • Hay propuestas de fusionar ambos enfoques. • Ingeniería del conocimiento: transferir el “expertise” a un programa de computación. • Similitud de los problemas del analista • Principal dificultad: la comprensión el dominio del problema

  42. RE y elicitación de conocimientoIngeniería del conocimiento • Obstáculos en la extracción del conocimiento: • dificultad en explicar acciones y decisiones • lenguaje del ingeniero de conocimiento y el usuario • relación con usarios, con experiencias y necesidades conflictivas • se generaron técnicas para superarlos • Clasificación de las técnicas: • observación • elicitación no estructurada • mapping • análisis formal • elicitación estructurada • Técnicas de RE corresponden a estos tipos

  43. RE y elicitación de conocimiento • Intercambiabilidad de las técnicas • Los analistas de RE pueden mejorar los resultados aplicando técnicas de elicitación del conocimiento

  44. Temario • Técnicas de elicitacion • RE como proceso social • RE y elicitación de conocimiento • Conclusión

  45. Conclusión • Problema principal: adquirir el conocimiento de los usuarios y otras fuentes • Técnicas vistas: • entrevistas al usuario, muy usadas, requieren preparación; • análisis de objetivos/metas, exitosas para alcanzar consenso; • escenarios: atacan la limitación de memoria, requiren del expertise de los usuarios; • análisis de formularios, bypass del usuario y una importante fuente de conocimiento; • análisis del NL: hacia el medio más conveniente para el usuario; • reuso: punto de partida en un conjunto de requerimientos reusables; • ciencia social: atienden a las reglas sociales y las prácticas de la organización;

More Related