Requisitos

605 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

Requisitos

  1. 1. Análisis de Requisitos del Sistema <ul><li>Identificación de Requisitos para el Software: </li></ul><ul><ul><li>Analista entrevista para obtener aspectos generales del cliente: </li></ul></ul><ul><ul><ul><li>¿Quién está detrás de la solicitud de trabajo? </li></ul></ul></ul><ul><ul><ul><li>¿Quién utilizará la solución? </li></ul></ul></ul><ul><ul><ul><li>¿Cuál será el beneficio económico del éxito de una solución? </li></ul></ul></ul><ul><ul><ul><li>¿Hay alguna otra alternativa para la solución que necesita? </li></ul></ul></ul>
  2. 2. Análisis de Requisitos del Sistema <ul><li>Entendimiento del problema </li></ul><ul><ul><ul><li>¿Cómo caracterizaría un «buen» resultado ó salida generados para una buena solución? </li></ul></ul></ul><ul><ul><ul><li>¿A qué tipo de problema(s) va dirigida esta solución? </li></ul></ul></ul><ul><ul><ul><li>¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución? </li></ul></ul></ul><ul><ul><ul><li>¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solución? </li></ul></ul></ul>
  3. 3. Análisis de Requisitos del Sistema <ul><li>Meta-preguntas (Preguntas sobre las preguntas) </li></ul><ul><ul><ul><li>¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son «oficiales»? </li></ul></ul></ul><ul><ul><ul><li>¿Estoy preguntando demasiado? </li></ul></ul></ul><ul><ul><ul><li>¿Hay alguien más que pueda proporcionar información adicional? </li></ul></ul></ul><ul><ul><ul><li>¿Hay algo más que debería preguntarle? </li></ul></ul></ul>
  4. 4. Análisis de Requisitos del Sistema <ul><li>Técnicas para Facilitar las especificaciones de una aplicación (TFEA): </li></ul><ul><ul><ul><li>La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. </li></ul></ul></ul><ul><ul><ul><li>Se establecen normas de preparación y de participación. </li></ul></ul></ul><ul><ul><ul><li>Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero lo suficientemente informal como para animar el libre flujo de ideas. </li></ul></ul></ul>
  5. 5. Análisis de Requisitos del Sistema <ul><li>Un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la reunión. </li></ul><ul><li>Se usa un «mecanismo de definición» (que puede ser hojas de trabajo, gráficos, carteles o pizarras). </li></ul><ul><li>El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución en una atmósfera que permita alcanzar el objetivo. </li></ul>
  6. 6. Análisis de Requisitos del Sistema <ul><li>Despliegue de la función de calidad (DFC) </li></ul><ul><ul><li>Traducción de las necesidades del cliente a requisitos técnicos de software. </li></ul></ul><ul><ul><ul><li>Identificación de 3 tipos de requisitos: </li></ul></ul></ul><ul><ul><ul><ul><li>Normales </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Objetivos y metas de producto </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Esperados </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Implícitos y fundamentales. A veces el cliente no los declara. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Innovadores </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Características más allá de las expectativas del cliente, y que suelen ser muy satisfactorias. </li></ul></ul></ul></ul></ul>
  7. 7. Análisis de Requisitos del Sistema <ul><li>Casos de uso </li></ul><ul><ul><li>Respuestas que deben obtenerse de ellos: </li></ul></ul><ul><ul><ul><li>¿Cuáles son las principales tareas o funciones que serán realizadas por el actor? </li></ul></ul></ul><ul><ul><ul><li>¿Cuál es el sistema de información que el actor adquiere, produce o cambia? </li></ul></ul></ul><ul><ul><ul><li>¿Qué actor informará al sistema de los cambios en el entorno externo? </li></ul></ul></ul><ul><ul><ul><li>¿Qué información necesita el actor sobre el sistema? </li></ul></ul></ul>
  8. 8. Análisis de Requisitos del Sistema <ul><li>Principios del análisis </li></ul><ul><ul><li>Operativos: </li></ul></ul><ul><ul><ul><li>Debe representarse y entenderse el dominio de información de un problema. </li></ul></ul></ul><ul><ul><ul><li>Deben definirse las funciones que debe realizar el software. </li></ul></ul></ul><ul><ul><ul><li>Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos). </li></ul></ul></ul><ul><ul><ul><li>Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente) </li></ul></ul></ul>
  9. 9. Análisis de Requisitos del Sistema <ul><li>Principios del análisis </li></ul><ul><ul><li>Operativos: </li></ul></ul><ul><ul><ul><li>El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación. </li></ul></ul></ul>
  10. 10. Análisis de Requisitos del Sistema <ul><li>Principios del análisis </li></ul><ul><ul><li>Directrices: </li></ul></ul><ul><ul><ul><li>Entender el problema antes de empezar a crear el modelo de análisis. </li></ul></ul></ul><ul><ul><ul><li>Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina. </li></ul></ul></ul><ul><ul><ul><li>Registrar el origen y la razón de cada requisito. </li></ul></ul></ul><ul><ul><ul><li>Usar múltiples planteamientos de requisitos. </li></ul></ul></ul><ul><ul><ul><li>Dar prioridad a los requisitos. </li></ul></ul></ul><ul><ul><ul><li>Trabajar-para eliminar la ambigüedad. </li></ul></ul></ul>
  11. 11. Análisis de Requisitos del Sistema <ul><ul><li>El dominio de la información: </li></ul></ul><ul><ul><ul><li>Agrupa elementos de datos u objetos que contienen números, texto, imágenes, audio, video o cualquier combinación de ellos. </li></ul></ul></ul>
  12. 12. Análisis de Requisitos del Sistema Aplicaciones de Software = Procesamiento de Datos
  13. 13. Análisis de Requisitos del Sistema <ul><ul><li>Los principios operativos exigen... </li></ul></ul><ul><ul><li>...un examen del dominio de la información y un: </li></ul></ul><ul><ul><li>MODELO DE DATOS: </li></ul></ul><ul><ul><ul><li>Contenido de la información y relaciones </li></ul></ul></ul><ul><ul><ul><li>Flujo de la Información </li></ul></ul></ul><ul><ul><ul><li>Estructura de la Información </li></ul></ul></ul>
  14. 14. Análisis de Requisitos del Sistema <ul><li>Tipos de modelos a crear durante la etapa de Análisis de Requisitos: </li></ul><ul><ul><ul><li>Modelos funcionales </li></ul></ul></ul><ul><ul><ul><li>Modelos de comportamiento </li></ul></ul></ul><ul><li>Papel del Modelo de datos </li></ul><ul><ul><ul><li>Ayuda al analista a entender la información, el comportamiento y las funciones del sistema </li></ul></ul></ul><ul><ul><ul><li>El modelo se convierte en un punto de revisión ó “checkpoint” para determinar el avance realizado </li></ul></ul></ul><ul><ul><ul><li>Se convierte en un fundamento de diseño del sistema, al proporcionar funciones esenciales. </li></ul></ul></ul>
  15. 15. Análisis de Requisitos del Sistema <ul><li>Partición (actividad de análisis): </li></ul><ul><ul><ul><li>Es la descomposición del problema en partes constitutivas para su resolución. </li></ul></ul></ul><ul><ul><ul><li>Puede ser vertical u horizontal , refiriéndose al orden jerárquico en que se resuelven los problemas. </li></ul></ul></ul><ul><ul><ul><li>Verticalmente se exponen detalles del sistema </li></ul></ul></ul><ul><ul><ul><li>Horizontalmente se “descomponen” etapas para revisión de detalles </li></ul></ul></ul>
  16. 16. Análisis de Requisitos del Sistema <ul><li>Visiones esenciales y de implementación </li></ul><ul><ul><ul><li>Esencial: Presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de la implementación. </li></ul></ul></ul><ul><ul><ul><li>Visión de Implementación: Introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de información. </li></ul></ul></ul><ul><li>Sin embargo, la mayoría de los sistemas basados en computadora se especifican de manera que se acomode a ciertos detalles de implementación. </li></ul>
  17. 17. Análisis de Requisitos del Sistema <ul><li>Principios básicos de especificación </li></ul><ul><ul><ul><li>Separar la funcionalidad de la implementación. </li></ul></ul></ul><ul><ul><ul><li>Desarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estímulos del entorno. </li></ul></ul></ul><ul><ul><ul><li>Establecer el contexto en que opera el software especificando la manera en que otros componentes del sistema interactúan con él. </li></ul></ul></ul><ul><ul><ul><li>Definir el entorno en que va a operar el sistema e indicar como «una colección de agentes altamente entrelazados reaccionan a estímulos del entorno (cambios de objetos) producidos por esos agentes» </li></ul></ul></ul>
  18. 18. Análisis de Requisitos del Sistema <ul><li>Principios básicos de especificación </li></ul><ul><ul><ul><li>Crear un modelo intuitivo en vez de un diseño o modelo de implementación. </li></ul></ul></ul><ul><ul><ul><li>Reconocer que «la especificación debe ser tolerante a un posible crecimiento si no es completa». Una especificación es siempre un modelo (una abstracción) de alguna situación real (o prevista) que normalmente suele ser compleja. De ahí que será incompleta y existirá a muchos niveles de detalle. </li></ul></ul></ul><ul><ul><ul><li>Establecer el contenido y la estructura de una especificación de manera que acepte cambios. </li></ul></ul></ul>
  19. 19. Análisis de Requisitos del Sistema <ul><li>Representación </li></ul><ul><ul><ul><li>El formato de la representación y el contenido deberían estar relacionados con el problema. </li></ul></ul></ul><ul><ul><ul><li>La información contenida dentro de la especificación debería estar escalonada. </li></ul></ul></ul><ul><ul><ul><li>Los diagramas y otras formas de notación deberían restringirse en número y ser consistentes en su empleo </li></ul></ul></ul><ul><ul><ul><li>Las representaciones deben permitir revisiones. </li></ul></ul></ul>
  20. 20. Análisis de Requisitos del Sistema <ul><ul><li>Especificación de los requisitos de software </li></ul></ul><ul><ul><ul><li>La Introducción establece las metas y objetivos del software, describiéndolo en el contexto del sistema basado en computadora. </li></ul></ul></ul><ul><ul><ul><li>La descripción de la información proporciona una detallada descripción del problema que el software va a resolver. </li></ul></ul></ul><ul><ul><ul><li>En la descripción funcional se describen todas las funciones requeridas para solucionar el problema. </li></ul></ul></ul><ul><ul><ul><li>Descripción del comportamiento examina la operativa del software como consecuencia de acontecimientos externos y características de control generadas internamente. </li></ul></ul></ul>
  21. 21. Análisis de Requisitos del Sistema <ul><ul><li>Especificación de los requisitos de software </li></ul></ul><ul><ul><ul><li>Criterios de validación actúa como una revisión implícita de todos los demás requisitos </li></ul></ul></ul><ul><ul><ul><li>Finalmente, la especificación incluye una Bibliografía y un Apéndice. </li></ul></ul></ul><ul><ul><ul><li>Puede incluir un prototipo funcional ó un Manual de Usuario preliminar , sirviendo para descubrir problemas en la interfaz hombre-máquina. </li></ul></ul></ul>

×