Ingeniería del Software. 2.- Análisis de sistemas.

Tema 2 .- ANÁLISIS DE SISTEMAS

1. INTRODUCCIÓN

Un Sistema es un conjunto de elementos organizados para llevar a cabo algún método,

procedimiento o control mediante el procesamiento de información.

Los elementos de un sistema son:

• Software (Programas, estructuras de datos, procedimientos y

documentación asociada).
• Hardware (Ordenador + periféricos).
• Personas (usuarios, operadores soft, operadores hard).
• Bases de Datos (Información organizada a la que accede el software).
• Documentación (Manuales, listados, impresos, etc que explican el uso
del sistema).
• Procedimientos (Pasos que definen el uso de cada elemento del
sistema, pasos a seguir).

La ingeniería de sistemas informáticos, también llamada ingeniería de productos, es una

actividad de resolución de problemas. Es el usuario quién nos impone los objetivos y define las
restricciones del sistema, y a partir de aquí es el ingeniero de sistemas o analista de sistemas, quién
desarrolla la solución al problema planteado, utilizando todos los elementos del sistema
informático.

ELEMENTOS + ANALISTA = PRODUCTO

En los primeros momentos de creación de un sistema, no se tiene una visión muy clara de la
función deseada, por ello, es el ingeniero de sistemas quien debe delimitar el sistema,
identificando el ámbito de funcionamiento y el rendimiento deseados.
Esto se hace aplicando funciones a cada uno de los elementos del sistema, y quién lo hace es el
analista. En la asignación de funciones, vamos a asignar a cada elemento del sistema la función
que le corresponda.
A menudo se proponen y evalúan varias asignaciones.

El ingeniero de sistemas también debe considerar soluciones estándar al problema (si ya existe
algún sistema equivalente, o se pueden adquirir partes del producto a un tercero).

Una vez consideradas las posibles asignaciones se elige una, que será la que más se adapte a
nuestro sistema.

1
Ingeniería del Software. 2.- Análisis de sistemas.

EJEMPLO: Almacén de una editorial SISTEMA: Gestión de Almacén

Se quiere tener en todo momento actualizadas las existencias del almacén. Actualmente, los
productos llevan una etiqueta identificativa y un código de barras. El almacén estará dispuesto por
calles (A, B, C, ...); en cada calle hay plantas (1, 2, 3, ...) y en cada planta hay secciones (1,3,5,
...; 2, 4, 6, ...).Cada producto está localizable en una calle, planta y sección.

ASCENSOR

Tenemos que enterarnos bien de

como funciona actualmente para poder
optimizar al máximo

A B C D E

Fichero

Los pedidos se sirven secuencialmente; se coge un pedido y se apartan todos los pedidos
solicitados, preparándose el envío del material y emitiendo el albarán.

Posibles soluciones :
1. Un operario coge el pedido y busca el material (acude a un fichero manual donde está la
localización de los productos), actualiza el inventario y rellena el albarán.
Elementos ⇒ Personas + Documentación
2. Un operario coge el pedido, busca el material, utiliza un lector de código de barras que
actualiza el inventario y lista el albarán.
Elementos ⇒Personas + Documentación + Base de Datos + Hardware + Software
3. Un operario introduce los datos del pedido en el ordenador. Un robot recoge todo el material
del pedido. El robot lo lleva a un lector de códigos de barras y se actualiza el inventario y se
emite el albarán.
4. El operario lee el pedido a un robot con un dispositivo de reconocimiento de voz que le trae
los productos. El robot tiene un dispositivo de conexión I/O con el ordenador central para
recoger la información de la localización del producto y para actualizar el inventario.
Cuando tiene toda la información de los productos hace una ordenación por localización con
el fin de optimizar el tiempo. Emite los albaranes correspondientes.

2
Ingeniería del Software. 2.- Análisis de sistemas.

También se debe considerar soluciones estándar al problema. Una vez consideradas las posibles
asignaciones se elige una.

1. Informatizar Inventario.
Informatizar localización.
Albaranes de forma manual. En estos tres casos
Recogida del producto manual

2. Inventario informatizado. la entrada de pedidos

Localización informatizada.
Albaranes informatizados. es manual.
Recogida del producto manual.

3. Inventario informatizado.
Localización informatizada.
Albaranes informatizados

4. Todo informatizado con la entrada por escáner o reconocimiento de voz.

2. ANÁLISIS DEL SISTEMA

El análisis del sistema se centra en todos los elementos del sistema, no sólo en el software.

Objetivos del análisis del sistema:

1. Identificar las necesidades del cliente.
2. Evaluar la viabilidad del sistema.
3. Realizar un análisis técnico y económico.
4. Asignar funciones a los elementos del sistema.
5. Establecer restricciones de coste y tiempo.
6. Crear una definición del sistema que sea la base para todo el desarrollo posterior.

Está comprobado que la inversión en tiempo y esfuerzo en el análisis de un sistema es muy

importante en el proceso de desarrollo del sistema. Supone un coste del 20 al 40% del total de
desarrollo del sistema. Está dirigido por el analista, y se considera un trabajo tan difícil y costoso
por ser la transformación de un concepto dudoso, en un conjunto concreto de elementos tangibles
que lo representan. Además durante el análisis la comunicación es excepcionalmente densa y
abundan las oportunidades de mal entendimientos, omisiones y errores. También se puede dar el
caso de que la percepción del sistema cambie a medida que avanza la actividad, invalidando el
trabajo anterior.

3
Ingeniería del Software. 2.- Análisis de sistemas.

2.1.- Identificación de las necesidades del cliente:

El primer paso en el análisis de cualquier sistema, es la entrevista con el cliente, para identificar
las necesidades.
El analista junto con el cliente determinan los objetivos del sistema:
• La información a suministrar,
• La información a obtener
• Las funciones y rendimiento requerido.

EL analista debe ser capaz de distinguir entre lo que el cliente necesita y lo que el cliente quiere.

Si el producto a desarrollar se va a vender a muchos clientes, es aconsejable hacer un estudio de

mercado, que dé una respuesta a las cuestiones siguientes:
• ¿Cuál es el mercado potencial del producto.?
• ¿Cómo es comparativamente este producto con los de la competencia.?
• ¿Qué posición ocupa este producto en la línea general de producción de la compañía.?

La información reunida durante el paso de identificación de necesidades es especificada en un

documento conceptual del sistema, que en algunas ocasiones es preparado por el cliente antes de
las reuniones con el analista.

2.2.- Estudio de viabilidad.

Todos los proyectos son realizables con recursos ilimitados y tiempo infinito, pero en condiciones
reales no ocurre así.

La viabilidad y el análisis de riesgo están relacionadas, si el riesgo del proyecto es alto, la

viabilidad de producir software de calidad se reduce. Antes de desarrollar un proyecto, debemos
considerar :

• Viabilidad Económica: (ANÁLISIS ECONÓMICO) Evaluación del coste

del desarrollo frente al beneficio final producido.
• Viabilidad técnica: (ANÁLISIS TÉCNICO) Estudio de la funcionalidad, el
rendimiento y las restricciones que puedan afectar a la posibilidad de
realización de un sistema aceptable, es decir, si existe la posibilidad técnica
de desarrollar el sistema.
• Viabilidad Legal: Determinación de cualquier infracción, violación o
ilegalidad que pudiera resultar del desarrollo del sistema.
• Alternativas: Las distintas alternativas tienen diferentes las asignaciones de
las funciones a los elementos del sistema, así el elegir una alternativa lleva
implícitas las asignaciones.

No es necesario realizar un estudio de viabilidad para sistemas en que la justificación económica es

obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe una alternativa
razonable.
4
Ingeniería del Software. 2.- Análisis de sistemas.

El esfuerzo empleado en el análisis de la viabilidad de un proyecto, aunque lleve a la cancelación

del mismo no es un esfuerzo en vano.

2.3.- Análisis económico y técnico

El análisis del coste-beneficio, ya estudiado en la viabilidad económica, es el más importante.

Es muy complicado de realizar porque los criterios varían según las características del sistema, el
tamaño del proyecto, la estrategia de amortización de esa inversión que lleve la empresa, etc.
Además suele ocurrir que parte de los beneficios obtenidos de un sistema informático sean
intangibles (mejoras de calidad, de condiciones de trabajo, etc.), por lo que son muy difíciles de
estimar en cifras.

El análisis técnico: comienza en la definición de la viabilidad técnica del sistema propuesto. Se

deben considerar que tecnologías, métodos, algoritmos o procesos se requieren y como afecta al
coste.
Hay herramientas disponibles para realizar el análisis técnico, basadas en técnicas de
optimización y modelos matemáticos (probabilidad, estadística, etc...), aunque no siempre es
posible una evaluación analítica.

3.- MODELADO DE LA ARQUITECTURA DEL SISTEMA.

Una vez asignadas las funciones del sistema informático, se crea un modelo del sistema donde
queden reflejadas las interrelaciones entre los distintos elementos del sistema.
Este modelo nos va a servir de base para los siguientes pasos del análisis y de diseño.

Una característica común de la arquitectura de todos los sistemas es la transformación de la

información del tipo: entrada - proceso – salida. Hatley y Pirbhai han extendido esta visión para
incluir: proceso de la interfaz de usuario y proceso de mantenimiento y autocomprobación.

La documentación que acompaña a los diagramas que se han creado del sistema, describe la
información de cada subsistema y el flujo de información entre ellos.

Está compuesto de:

1. NARRATIVA DE MÓDULO: describe que hace el subsistema, que información procesa

y como está relacionado con los otros subsistemas. Esto habrá que hacerlo para cada uno de
los sistemas representado en los DFAs.

2. DICCIONARIO DE ARQUITECTURA: contiene una lista de los elementos de

información que aparecen en el diagrama de flujo de la arquitectura y sus descripciones.
Ejemplo :
* Nombre del elemento de información: CB del libro
* Descripción del elemento de información: CodLibro+CodAutor+FEdic
* Tipo (Dato o Control): DATO

5
Ingeniería del Software. 2.- Análisis de sistemas.

* Origen (Subsistema o Externo): Entidad EXTERNA Lector CB

* Destino (Subsistema o Externo): Subsistema del lector de CB
* Camino de comunicación: Bus de Datos

4.- ESPECIFICACIÓN DEL SISTEMA.

Es el documento que describe la función y el rendimiento de un sistema informático, y las

restricciones de desarrollo. Se limitan las asignaciones a los elementos del sistema, se describe la
información que sirve de entrada y de salida al sistema.

Va a servir como base para después hacer toda la ingeniería:

* Hardware
* Software
* BD
* Humana

Resumiendo, contiene todo lo explicado anteriormente en este tema.

5. REVISIÓN DE LA ESPECIFICACIÓN DEL SISTEMA

Aquí se evalúa la corrección de la definición contenida en la especificación del sistema. Esta

revisión se realiza en dos partes:

1. Se realiza con el analista y el cliente comprobando que se ha definido correctamente el

ámbito del proyecto, la funcionalidad, el rendimiento, los interfaces, el análisis del entorno
y sobre todo hay que comprobar si los objetivos que el analista ha marcado y la percepción
de los objetivos del sistema del mismo coinciden con los del cliente. Si esto no es así es que
algún paso de los anteriores se ha realizado mal.

2. Tenemos que realizar la evaluación técnica de los elementos y funciones del sistema.

Una vez finalizada la revisión de la especificación del sistema, se pasa al desarrollo de las
ingenierías mencionadas anteriormente.

Resumiendo, en este punto del desarrollo se ha conseguido :

• Identificar las necesidades del usuario.

• Determinar la viabilidad técnica y económica.
• Asignar las funciones y el rendimiento a los elementos del sistema.
• Desarrollar un modelo arquitectónico del sistema.
• Crear el documento de especificación del sistema.

6. ANÁLISIS DE REQUISITOS

6
Ingeniería del Software. 2.- Análisis de sistemas.

El análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y

especificación.

Es la tarea de ingeniería de Software que establece un puente entre la asignación del software a
nivel de sistema y el diseño del software.

El análisis de requisitos facilita al ingeniero de sistemas la especificación de la función y del

rendimiento del software, la descripción del interfaz con otros elementos del sistema y el
establecimiento de las restricciones de diseño que debe considerar el software, por ello, se
considera como un medio para valorar la calidad del software una vez construido.

Tareas del análisis de requisitos:

• Reconocimiento del problema: saber cual es el problema y tener la misma idea de él

que el cliente. El analista estudia la especificación del sistema siendo su objetivo
reconocer los elementos básicos del problema tal y como los perciben el usuario y el
cliente.

• Evaluación y síntesis: el analista se centra en que datos produce y consume el sistema,

que funciones debe realizar este sistema, que interfaces están definidos y que restricciones
se aplican al sistema.

• Modelado: vamos a elegir el tipo de modelo a utilizar. El analista va a crear modelos del
sistema para entender mejor el flujo de datos y de control, el procesamiento funcional y el
contenido de la información. Igual que antes, a partir de las plantillas representamos
nuestro sistema en un entorno gráfico. A partir de este modelo sacaremos la
especificación.

• Especificación: la forma ideal, si están bien todos los pasos anteriores, es que el analista
desarrolle una especificación y sea revisada y aprobada por el cliente. Realmente, lo que
ocurre es que se desarrolla de forma conjunta por el analista y el cliente. Se establecen los
criterios de validación, que sirven para demostrar que se ha llegado a un buen
entendimiento del sistema, y de la forma de implementar con éxito el software.
De estas fases surgen dos documentos:
* Especificación Formal de Requisitos
* Manual del Usuario Preliminar: nos dice que es lo que va a ofrecer el
programa

• Revisión: Se reúnen el analista y cliente, y se entregan los documentos creados

anteriormente. En esta fase, siempre surge algún cambio que puede ser de:
* Alguna función del Sistema
* Datos del sistema
* Rendimiento del sistema
* Restricciones
Este punto de análisis de requisitos es como el anterior con la comprobación del cliente.

7. PRINCIPIOS DE ANÁLISIS

7
Ingeniería del Software. 2.- Análisis de sistemas.

En las dos últimas décadas se han desarrollado varios métodos de análisis y especificación del
software.
Cada método tiene su propia notación y un punto de vista únicos, pero todos tienen en común
estos principios:

7.1.- Ámbito de información del problema.

El software se construye para procesar datos: habrá una entrada, una manipulación de datos
y una salida. Además de procesar datos se procesan sucesos, que son controlados por los datos
de control. Un suceso representa un aspecto de control del sistema, que normalmente es un dato
booleano (ej : señal de alarma).

El ámbito de información contiene tres planteamientos diferentes de los datos y del

control a medida que son procesados por un programa:

• Flujo de información.
• Contenido de información.
• Estructura de información.

1. FLUJO DE INFORMACIÓN: representa la manera de que los datos y el control

cambian conforme se mueven a través de un sistema:

INFO STMA. INFO STMA. INFO.

TRANSFOR- TRANSFOR-
ENTRADA MACION 1 INTERMEDIA MACION 2 SALIDA

Ejemplo: FACTURA DE UN CLIENTE

* INFORMACIÓN DE ENTRADA: Nombre del cliente

* TRANSFORMACIÓN 1: Acceso a BD; de aquí sacamos CódigoCliente
* INFORMACIÓN INTERMEDIA: NombreCliente, CódigoCliente, ...
* TRANSFORMACIÓN 2: Acceso a BD
* INFORMACIÓN DE SALIDA: Factura

2. CONTENIDO DE LA INFORMACIÓN: representa los elementos de datos

individuales que componen otros elementos mayores de información

Ejemplo:

FACTURA= Nombre del cliente + CódigoCliente + NombreProducto +

CódigoProducto + PrecioProducto + etc.

3. ESTRUCTURA DE LA INFORMACIÓN: representa la organización interna de los

distintos elementos de datos y de control (vectores, matrices, árboles, ...) y las posibles
relaciones entre las distintas informaciones. (Se debe recordar que la especificación de
los tipos de datos corresponde a la fase de diseño).
8
Ingeniería del Software. 2.- Análisis de sistemas.

7.2.- MODELADO.

Hay distintas técnicas de modelado. Los métodos de análisis son realmente métodos de
modelado. Creamos modelos de los sistemas para tener un mejor entendimiento del sistema a
construir.

El modelo debe ser capaz de modelar : la información que transformará el software, las
funciones que permiten que se produzca esta transformación y el comportamiento del sistema a
medida que se produce la transformación.

Hay varios modelos de análisis dentro de los paradigmas:

* Estructurado
* Orientado a objetos

7.3.- PARTICIÓN.

Normalmente los problemas son demasiado grandes y complejos, por ello se tiende a dividir
en partes mas sencillas con relaciones entre ellas, de forma que el conjunto realice la función
global.

Establecemos una representación jerárquica de la función descomponiéndola en sus partes

fundamentales de forma que se descubran los detalles de manera progresiva.

7.4.- PLANTEAMIENTOS ESENCIALES Y DE IMPLEMENTACIÓN.

El proceso de análisis debe ir de la información esencial al detalle de la implementación.

El planteamiento esencial de los requisitos del software presenta las funciones que han de
realizarse y la información que ha de procesarse, independientemente de los detalles de
implementación.

El planteamiento de implementación de los requisitos del software presenta algunos detalles

de la implementación real de las funciones de procesamiento y de las estructuras de
información.