Capitulo_11 Conceptos y Principios Del Analisis
Click here to load reader
-
Upload
rino-tovar-abreu -
Category
Documents
-
view
1.117 -
download
12
Transcript of Capitulo_11 Conceptos y Principios Del Analisis
![Page 1: Capitulo_11 Conceptos y Principios Del Analisis](https://reader038.fdocuments.mx/reader038/viewer/2022100420/5571f75b49795991698b458e/html5/thumbnails/1.jpg)
CAPITULO 11
CONCEPTOS Y PRINCIPIOS DEL ANALISIS
Tanto el desarrollador como el cliente tienen un papel activo en el análisis y especificación de los requisitos.
11.1 ANALISIS DE REQUISITOS
Es una tarea que permite al ingeniero de sistemas:- Especificar la función y rendimiento del soft.- Indicar la interfaz del soft con otros elementos del sistema- Establecer las restricciones que debe cumplir el soft- Construir los modelos de dominios de datos, funcional y comportamiento- Proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha
construído el soft.
Puede dividirse en 5 áreas:1) Reconocimiento del problema2) Evaluación y síntesis - qué ¿? -3) Modelado del sistema4) Especificación del soft5) Revisión
El desarrollador puede no estar seguro de que un enfoque específico consiga apropiadamente el funcionamiento y rendimiento adecuados. Por esta y otras muchas razones, se puede llevar a cabo un enfoque alternativo del análisis de requisitos, denominado prototipato o creación de prototipos.
11.2 TECNICAS DE COMUNICACIÓN
11.2.1 Inicio del proceso
Para empezar la comunicación entre cliente y desarrollador se lleva a cabo: reunión o entrevista preliminar. Se sugiere que el analista empiece preguntando cuestiones de contexto libre, es decir un conjunto de preguntas que llevarán a un entendimiento básico del problema. Pero el formato de pregunta-respuesta de reunión tipo, no es un enfoque que haya tenido mucho éxito. Esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituírse después por una modalidad que combine elementos de resolución de problema, negociación y especificación.
11.2.2 técnicas para facilitar las especificaciones de una aplicación.
El enfoque de Técnicas para facilitar las especificaciones de la aplicación (TFEA), es partidario de la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución.TFEA – DIRECTRICES BÁSICAS:- La reunión se celebra en un lugar neutral y acuden tanto clientes como los desarrolladores.- Se establecen normas de preparación y de participación.- 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.- Un coordinador para coordinar la reunión.
1
![Page 2: Capitulo_11 Conceptos y Principios Del Analisis](https://reader038.fdocuments.mx/reader038/viewer/2022100420/5571f75b49795991698b458e/html5/thumbnails/2.jpg)
- Se usa un mecanismo de definición – gràficos, carteles, pizarra, hojas de trabajo –- Objetivo: identificar el problema, proponer elementos de solución.
11.2.3 Despliege de la función de calidad
El despliegue de la función calidad (DFC) es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnico del software. DFC identifica 3 tipos de requisitos:- Requisitos normales : se declaran objetivos y metas para un producto o sistema durante
reuniones con el cliente. Si estos requisitos están presentes el cliente estará satisfecho.- Requisitos esperados : son implícitos al producto o sistema y pueden ser tan
fundamentales que el cliente no los declara explícitamente. Su ausencia será motivo de una insatisfacción significativa.
- Requisitos innovadores : estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias. El producto entregado contiene ciertas capacidades no esperadas.
El despliegue de función se utiliza para determinar el valor de cada función requerida para el sistema.
11.3 PRINCIPIOS DEL ANALISIS
Todos los métodos de análisis se relacionan por un conjunto de Principios operativos:1) Debe representarse y entenderse el dominio de información de un problema.2) Deben definirse las funciones que debe realizar el sotf.3) Debe representarse el comportamiento del soft (como consecuencia de acontecimientos
externos)4) Deben dividirse los modelos que representan información, función y comportamiento.5) El modelo del análisis debería ir desde la información esencial hasta el detalle de la
implementación.
Directrices para la ingeniería de requisitos(Davis):- Entender el problema antes de crear el modelo de análisis.- Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-
máquina.- Registrar el origen y la razón de cada requisito.- Usar múltiples planeamientos de requisitos.- Dar prioridad a los requisitos.- Trabajar para eliminar la ambigüedad.
11.3.1 El dominio de la información.
El primer principio operativo de análisis requiere el examen del dominio de la información. Este dominio contiene 3 visiones diferentes: 1) el contenido de la información – datos y control -2) el flujo de la información – como cambian los datos y control - 3) la estructura de la información – organización interna de datos y control –
11.3.2 Modelado
Los modelo se crean para entender mejor la entidad que se va a construir y es fundamental para un buen trabajo de análisis:
2
![Page 3: Capitulo_11 Conceptos y Principios Del Analisis](https://reader038.fdocuments.mx/reader038/viewer/2022100420/5571f75b49795991698b458e/html5/thumbnails/3.jpg)
- Modelos funcionales: el soft. transforma la información y para hacerlo, debe realizar al menos tres funciones genéricas: entrada- procesamiento y salida. Este modelo empieza con un sencillo modelo a nivel de contexto.
- Modelos de comportamiento : la mayoría del software responde a los acontecimientos del mundo exterior (estímulo- respuesta). Esto forma parte de este modelo, que muestra los estados del soft y los acontecimientos que causan que cambie de estado.
11.3.3 Partición
Es dividir los problemas que son demasiados grandes o complejos para entenderlos globalmente. La partición descompone a un problema en sus partes constitutivas.El enfoque de partición también puede aplicarse al dominio de la información y al de comportamiento.
11.3.4 Visiones esenciales y de implementación
Visión esencial: de los requisitos del software presenta las funciones a conseguir y la información a procesar mínimos sin tener en cuenta los detalles de la implementación.Visión de implementación: de los requisitos del software introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información.
11.4 CREACION DE PROTOTIPOS
11.4.1 Enfoque
La creación de prototipos puede ser cerrada o abierta:- Cerrada : Prototipo desechable: sirve únicamente como una basta demostración de los
requisitos. Después se desecha.- Abierta: Prototipo evolutivo: es empleado como primera parte de una actividad de
análisis a la que seguirá el diseño y la construcción. Es la primera evolución del sistema terminado.
11.4.2 Métodos y herramientas para el desarrollo de prototipos.
Para crear rápidamente prototipos existen:- Técnicas de cuarta generación : amplia gama de lenguajes de consultas e informes de
bases de datos, generadores de programas. - Componentes de software reutilizables : ensamblar, más que construir, con
componentes ya existentes. - Especificaciones formales y entornos para prototipos
11.5 ESPECIFICACION
11.5.1 Principios de la especificación:1) Separar la funcionalidad de la implementación.2) Desarrollar un modelo de comportamiento 3) Establecer el contexto en que opera el software.4) Definir el entorno en que va a opera el sistema.5) Crear el modelo intuitivo en vez de un diseño o modelo de implementación.6) Establecer el contenido y la estructura de una especificación de manera que acepte
cambios.
11.5.2 Representación:
3
![Page 4: Capitulo_11 Conceptos y Principios Del Analisis](https://reader038.fdocuments.mx/reader038/viewer/2022100420/5571f75b49795991698b458e/html5/thumbnails/4.jpg)
Los requisitos del soft pueden especificarse de varias maneras. Directrices a seguir:- El formato de la representación y el contenido debería estar relacionados con el problema.- La información contenida dentro de la especificación debería estar escalonada.- La numeración de párrafos y diagramas debería indicar el nivel de detalle que se muestra.- Los diagramas y otras formas de notación deberían restringirse en número y ser
consistentes den su empleo.- Las representaciones deben permitir revisiones.
11.5.3. La especificación de los requisitos del software.
Esquema como estructura para la especificación:- Introducción- Descripción de la información- descripción funcional- descripción del comportamiento- criterios de validación- bibliografía - apéndice
en muchos casos una especificación de requisitos puede estar acompañada de un prototipo ejecutable o en papel o un manual del usuario.
11.6 REVISION DE LA ESPECIFICACION
Es llevada a cabo tanto por el desarrollador como por el cliente. Inicialmete la revisión se lleva a cabo a nivel macroscópico. Se estudian las siguientes cuestiones:- Metas y objetivos declarados.- Descripto todas las interfaces importantes.- Definidos el flujo y la estructura de la información- Diagramas.- Funciones principales- Requisitos alternativos.- Riesgos tecnológicos.- Manual del usuario, etc.
Directrices para una revisión detallada:- Conectores persuasivos.- Términos imprecisos- Listas incompletas.- Verbos de significados imprecisos.- Pronombres de significados ambiguos.- Frases que impliquen certidumbre. Etc.
La especificación firmada se convierte en un contrato para el desarrollo del software.
4