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 problema
2) Evaluación y síntesis - qué ¿? -
3) Modelado del sistema
4) Especificación del soft
5) 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.

1
- Un coordinador para coordinar la reunión.
- 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
- 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
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.