CONCEPTOS Y PRINCIPIOS DEL ANALISIS

La tarea del análisis de Requisitos es un proceso de:

 Descubrimiento
 Refinamiento
 Modelado y
 especificación

Se crean modelos de los requisitos de:

 Datos
 Flujo de Información y Control
 Comportamiento Operativo.

Ingenieria de
Analisis de Diseño
Sistemas de
Requisitos del del
Computadora
Software Software

Definición del software a Nivel Sistema

ANALISIS DE REQUISITOS

1.- El análisis de requisitos permite:

 Especificar la FUNCION y RENDIMIENTO del Software

 Indicar la INTERFAZ del Software con otros elementos del Sistema
 Establecer RESTRICCIONES que debe cumplir el Software

2.- Permite al Ingeniero de Software

Refinar la definición de del Software

Construir modelos de los dominios de:

 Datos
 Funcional
 Comportamiento

3.- Proporciona al ingeniero de Software modelos de diseño de:

 Datos
 Arquitectónico
 de Interfaz
 Procedimental

El análisis de requisitos del Software es el proceso de reunión de requisitos, se intensifica

y se centra especialmente en el Software

1
JGCC
Para comprender la naturaleza del Programa a construirse el Ingeniero de Software debe
comprender:

 El dominio de la información del Software

 La Función requerida
 Comportamiento
 Rendimiento e
 Interconección

Finalmente la especificación de los requisitos proporciona al Diseñador y Cliente medios

para evaluar la calidad del Software una vez construido.

El análisis de Requisitos del Software de divide en cinco áreas

a) Reconocimiento del problema
b) Evaluación y Síntesis
c) Modelado
d) Revisión

Inicialmente el analista estudia la especificación del Sistema si existe y el Plan del

Proyecto.

Entender el Software en el contexto de un Sistema

Establecer comunicación para el análisis que garantice un reconocimiento del problema

La meta del analista es el reconocimiento de los elementos básicos del problema tal como
los percibe el usuario.

EVALUACION Y SINTESIS DE LA SOLUCION

 Define todos los objetos de datos observables externamente

 Evaluar el Flujo y Contenido de la información

 Entender el comportamiento del software en el contexto de los acontecimientos que

afectan al Sistema
 Establecer características de Interfaz del sistema

 Descubrir restricciones adicionales de diseño.

Cada una de estas tareas sirve para describir el problema de manera que se pueda
sintetizar un enfoque o solución global.

TECNICAS DE COMUNICACIÓN

INICIO DEL PROCESO

Conlleva una serie de entrevistas preliminares y reuniones, y se tiene técnicas que

permiten realizar esta parte del análisis que es de importancia.

2
JGCC
TECNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA APLICACIÓN (TFEA)

Se forma un equipo conjunto de Clientes y Desarrolladores para:

 ꞏ Identificar el problema
 ꞏ Proponer soluciones
 ꞏ Negociar diferentes enfoques
 ꞏ Especificar un conjunto preliminar de requisitos de la solución

DIRECTRICES BASICAS PARA LA TFEA

a) Reuniones en un lugar neutral

b) Normas de preparación y partición
c) Agenda formal para cubrir todos los puntos importantes
d) Se debe nombrar un coordinador este puede ser un desarrollador o un cliente
e) Uso de mecanismos de definición ( hojas de trabajo, gráficos, pizarras, etc. )

El objetivo es identificar el problema, proponer elementos de solución, especificar un

conjunto de requisitos de la solución.

DESPLIEGE DE LA FUNCION DE CALIDAD (DFC)

Es una técnica de gestión de calidad. El DFC Traduce las necesidades del cliente en
requisitos técnicos del Software. Se concentra en Maximizar la satisfacción del cliente

El DFC debe cumplir con ciertos requisitos:

1. NORMALES se declaran los objetivos y metas para un producto o sistema, Ej.

Peticiones de representación gráfica
2. ESPERADOS implícitos ala sistema o producto, pueden ser tan fundamentales: Ej.
Facilidad, interacción Hombre - máquina, buen funcionamiento y fiabilidad.
3. INNOVADORES mas allá de la expectativa del cliente. Ej. un software de procesador de
texto, con características estándar. El producto entregado tiene capacidad de diseño
especiales

PRINCIPIOS OPERATIVOS DEL ANALISIS

Todos los métodos de análisis se relacionan por un conjunto de principios operativos:

1. Se deben entender y representar el dominio de la información de un problema

2. Debe definirse las funciones que debe realizar el software
3. Debe representarse el comportamiento del software (como consecuencia de
acontecimientos) externos
4. Deben dividirse los modelos que representan información, función y comportamiento
de manera que se descubran los detalles por capas o jerarquías
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la
implementación.

DOMINIO DE LA INFORMACION

Todas las aplicaciones del software pueden denominarse como procesamiento de datos
Este término contempla el entendimiento de los requisitos del software. El software se
construye procesar datos, para transformar datos de una forma a otra, es decir para
aceptar entrada de información, manipularla de alguna manera y producir una salida de
información.

Es importante recalcar, sin embargo que el software también procesa acontecimientos.

Un acontecimiento representa algún aspecto de control del sistema y no es más que un
dato binario (encendido o apagado, verdadero o falso).

EJ: un sensor de presión, detecta la presión que excede de un valor de seguridad y envía
una señal de alarma al software de vigilancia.

3
JGCC
El principio operativo del análisis requiere el examen del dominio de la información y se
tiene tres visiones de los datos y del control a mendida que se procesa cada uno en un
programa:

 Contenido de la información y sus relaciones

 Flujo de la información
 Estructura de la información

Para comprender el dominio de la información se debe estudiar cada una de estas

visiones:

1. El contenido de la información representa los objetos individuales de datos y control

que componen una colección mayor de Información a la que transforma el software.
Ej. Objeto de Dato cheque es una composición de varios componentes de información
importantes: el nombre del beneficiario, el líquido pagable, el importe neto,
deducciones, etc. Por lo tanto, el contenido cheque es definido por atributos
necesarios para crearlo. Los objetos de datos y de control pueden relacionarse con
otros objetos de datos. Ejemplo el objeto de datos cheque tiene una o más relaciones
con los objetos empleado, banco y otros, relaciones que se deben definir

2. Como el flujo de información representa los cambios de datos a media que se mueven
dentro de un Sistema. Los objetos de entrada se transforman para intercambiar
información (datos/control), hasta que se transforman en una información de salida.
Las transformaciones que se aplican a los datos son Funciones o Subfunciones que
realiza el software.
Los datos que se mueven entre dos transformaciones definen la interfaz de cada
función.
3. La estructura de la información representa la organización interna de los elementos de
datos o de control.

EJ: gráfico del flujo de transformación de la información.

datos y control objeto salida

Objeto entrada transforma Transforma
cion 1 cion 2

almacen de datos

4
JGCC
MODELADO

Los modelos se crean para entender mejor la entidad que se va a construir.

MODELO SOFTWARE

El modelo debe ser capaz de modelar:

 La información que transforma el software

 Las funciones y Subfunciones que permiten que ocurra las transformaciones
 El comportamiento del sistema, cuando ocurren estas transformaciones

Los modelos se centran en lo que debe hacer el sistema y no en cómo lo hace, los
modelos que se crean emplean una notación gráfica que muestra:
 Información
 Procesamientos
 Comportamiento del sistema

MODELOS FUNCIONALES

El software transforma información y para hacerlo debe realizar al menos tres funciones
genéricas:

 Entrada
 Procesamiento
 Salida

Cuando se crean modelos funcionales de una aplicación, el ingeniero de software se

concentra en funciones específicas del problema.

El modelo funcional empieza con un modelo sencillo al nivel de contexto por ejemplo
nombre del software que se va a construir, efectuando una serie de iteraciones se
consigue mas detalles funcionales para, representar una minuciosa definición de toda la
funcionalidad del sistema

MODELOS DE COMPORTAMIENTO

La mayoría del software responde a los acontecimientos del mundo exterior. Esta
característica estimulo - respuesta, es la base del Modelo de Comportamiento
Un programa siempre esta en un estado observable externamente (ejemplo: calculando,
imprimiendo, etc.) que cambia sólo cuando ocurre otro acontecimiento. Por ejemplo el
software estará en estado de espera hasta que un reloj interno le indique que ha pasado
cierto intervalo de tiempo.

Un modelo de comportamiento crea una representación de estados del software y los

acontecimientos que causan estos cambios de estado.

Los modelos creados durante el análisis de requisitos desempeñan papeles importantes.

Rol de los modelos:

 Se debe comprender la información, función y comportamiento del sistema, facilitando

la tarea del análisis de requisitos
 La clave es la revisión para determinar si se ha completado la consistencia y
especificación.
 Se debe convertir en fundamento para el Diseño

PARTICION
5
JGCC
Descompone un problema en sus partes constitutivas. Conceptualmente se establece una
representación jerárquica de la información o de la función y después partimos el
elemento de orden superior:
 Exponiendo más detalles cada vez al movernos verticalmente en la jerarquía
 O descomponiendo el problema si se mueve horizontalmente en la jerarquía.

Es decir se establece la descomposición horizontal para dividir en funciones y

subfunciones y la partición vertical es la que se efectúa en más detalles.

Tomemos como el ejemplo del software “Hogar Seguro”. Se establece una representación
jerárquica de la información o función y partimos el elemento de orden superior, después
de la descomposición vertical de las funciones, tomamos la función Monitorización de
sensores y efectuamos la partición vertical.

SOFTWARE HOGAR SEGURO

SOFTWARE HOGAR SEGURO

CONFIGURAR SISTEMA MONITORIZACION INTERACTURA USUARIO

SENSORES

RASTREOS DE SUCESOS DEL ACTIVACION FUNCIONES

SENSOR ALARMA

LECTURA DEL IDENTIFICACION TIPO ACTIVAR/DESACTIVAR ACTIVAR ALARMA MARCADO DE NOS.

ESTADO SENSOR DE SUCESO SENSOR SONORA DE TELEFONO

CREACION DE PROTOTIPOS DEL SOFTWARE

Existen casos en que se emplea los principios operativos del Análisis para la creación del
Modelo del Software y luego para su posterior Diseño

Hay situaciones en que se usan los requisitos definidos por las Técnicas para Facilitar la
Especificación de la Aplicación, Despliegue de la Función de Calidad, y además de aplicar
el POA para el Modelo del Software (Prototipo) para que valore el cliente y el
desarrollador.

Existen circunstancias en las que se requiere un Prototipo al comienzo del Análisis, a

través del cual se obtiene eficazmente los requisitos.

6
JGCC
SELECCION DEL ENFOQUE DE CREACION DE PROTOTIPOS

Existen dos clasificaciones de prototipos:

PROTOTIPO CERRADO

Se dice que es un prototipo desechable, sirve como una demostración de los requisitos.
Una vez que se ha conseguido definir los requisitos se desecha y se hace Ingeniería de
Software con un paradigma diferente.

PROTOTIPO ABIERTO

Es un Prototipo evolutivo, se emplea como primera parte de una actividad de Análisis a la

que seguirá el Diseño y Construcción.
El Prototipo del Software es la primera evolución del Sistema.

METODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPO

Desarrollo Rápido para que el cliente valore los resultados y recomiende cambios
oportunos.
Para el desarrollo Rápido existen tres clases genéricas de Métodos y Herramientas:

1. Técnicas de la cuarta generación

2. Componentes de Software reutilizables
3. Especificaciones Formales y Entornos para prototipos.

TECNICAS DE LA CUARTA GENERACION

 Son lenguajes de consulta e informes de Bases de Datos

 Generadores de programas y aplicaciones
 Lenguajes no procedimentales de alto nivel

COMPONENTES DEL SOFTWARE

Un Prototipo se bebe tratar de ensamblar más que construir mediante un conjunto de

componentes de Software existente.
Entre los componentes tenemos:

 Estructura de datos (Base de datos)

 Componente arquitectónico de Software (programa)
 Componente Procedimental (modulo)

Usar un nuevo producto de software existente como prototipo de un nuevo y mejorado

producto competitivo. Esta es una forma de reutilización en la creación de prototipos.

ESPECIFICACIONES FORMALES Y ENTORNOS PARA PROTOTIPOS

Los entornos interactivos deberán:

 Permitir crear interactivamente especificación basada en lenguaje de un sistema de

software
 Invoquen herramientas automáticas que traducen la especificación basada en lenguaje
en código ejecutable.
 permitan al cliente usar código ejecutable del prototipo para, refinar los requisitos
formales.

7
JGCC
ESPECIFICACION
La especificación de los requisitos implica calidad de solución

Principios de la Especificación:

1. Separar la Funcionalidad de la Implementación

2. Desarrollar un Modelo del Comportamiento deseado de un sistema que comprendas
datos y respuestas funcionales del sistema a varios estímulos del entorno
3. establecer el contexto en que opera el software especificando la manera en que otros
componentes del sistema interactuan con el
4. Definir el entorno en que operará el sistema e indicar como una “colección de agentes
altamente entrelazados que reaccionan a estímulos del entorno (cambios de objetos).
5. Crear un modelo intuitivo en vez de un diseño o modelo de Implementación.
6. Reconocer que “la especificación debe ser tolerante a un posible crecimiento si no es
completa “. Una especificación es un modelo (abstracción) de alguna situación real.
7. Establecer el contenido y la estructura de una especificación de manera que acepte
cambios.

La especificación debe verse como un proceso de Prestación.

REPRESENTACION

 El formato de la Representación y el contenido deberían 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 restringir el numero y ser
consistentes en su empleo
 Las representaciones deben permitir Revisiones

ESPECIFICACION DE LOS REQUISITOS DEL SOFTWARE

Es la culminación de la tarea del Análisis

Se usa una estructura para la especificación

 Introducción
 Descripción de la Información
 Descripción Funcional
 Descripción de comportamiento
 Criterios de validación ( esta es la mas importante e irónicamente la mas ignorada)

La especificación de requisitos de Software:

 Puede estar acompañada de un Prototipo Ejecutable

 Un Prototipo en papel
 O un manual de usuario preliminar, el manual de usuario representa al software como
caja negra

REVISION DE ESPECIFICACION

La revisión de especificación y /o Prototipo es llevado a cabo tanto por el usuario como

por el desarrollador
La especificación formal es el fundamento para el diseño y subsiguientes actividades de
Ingeniería de Software, se debe tener extremo cuidado al realizar la revisión.
La revisión se lleva a nivel de Macro y Detallado

RESUMEN
8
JGCC
El análisis de requisitos es la primera fase técnica del proceso de Ingeniería del Software.
En este punto se refinan la declaración general del ámbito del software en una
especificación concreta que se convierte en el fundamento de todas las actividades
siguientes de la ingeniería del software.

El análisis debe enfocarse en los dominios de la información, funcional y de

comportamiento del problema. Para entender mejor lo que se requiere, se crean modelos,
los problemas sufren una partición y se desarrollan representaciones que muestra la
esencia de los requisitos y posteriormente los detalles de la implementación.

En muchos casos no es posible especificar completamente un problema en una etapa tan

temprana. La creación de prototipos ofrece un enfoque alternativo que produce un modelo
ejecutable del software en el que se puedan refinar los requisitos. Se necesitan
herramientas especiales para poder realizar la creación de prototipos.

Como resultado del análisis se desarrolla la especificación de requisitos del software. La

revisión esencial para asegurarse de que el cliente y el desarrollador tienen el mismo
concepto del sistema. Desgraciadamente, incluso con los mejores métodos, la cuestión es
que el problema sigue cambiando.

9
JGCC