El anlisis de sistemas es una actividad que engloba la mayora de las tareas que

hemos llamado colectivamente ingeniera de sistemas basados en computadora.

El anlisis de sistemas se realiza teniendo presente los siguientes objetivos:
1. Identificar las necesidades del cliente.
2. Evaluar la vialidad del sistema.
3. Realizar una anlisis tcnico y econmico.
4. Asignar funciones al software, al hardware, a la gente, a la base de datos y a
otros elementos del sistema.
5. Establecer restricciones de coste y tiempo.
6. Crear una definicin del sistema que sea la base para todo el trabajo posterior
de ingeniera.
Para alcanzar con xito esos objetivos, se requiere experiencia, tanto en hardware
como en software (as como ingeniera humana y base de datos). Todava surgen tres
preguntas:
Cunto esfuerzo se debe emplear en el anlisis y en la definicin de
sistemas y de software? Es difcil establecer unas directrices definitivas para
determinar el esfuerzo de anlisis. El tamao del sistema y su complejidad, el
rea de aplicacin, el uso final y las obligaciones del contrato son slo unas
pocas de las muchas variables que afectan al esfuerzo total dedicado al
anlisis.
Quin lo hace? Todas las tareas han de ser dirigidas por un analista bien
formado y con experiencia. El analista trabaja en contacto con el personal
tcnico y administrativo, tanto del cliente como del que desarrolla el sistema.
Por qu es tan difcil? Se trata de una transformacin de un concepto
dudoso en un conjunto concreto de elementos tangibles. Debido a que durante
el anlisis la comunicacin es excepcionalmente densa, abundan las
oportunidades de mal entendimiento,
6.2 Identificacin de las necesidades.
El analista se entrevista con el cliente o su representante. La identificacin de las
necesidades es el punto de partida en la evolucin de un sistema basado en
computadora.
Para empezar, el analista da asistencia al cliente definiendo los objetivos del sistema;
la informacin que se va obtener, la informacin que se va suministrar, las funciones y
el rendimiento requerido. El analista se asegura de distinguir entre lo que "necesita" el
cliente (elementos crticos para la realizacin) y lo que el cliente "quiere" (elementos
deseables pero no esenciales).
Una vez identificado todos los objetivos, el analista realiza una evaluacin de la
informacin suplementaria: Existe la tecnologa necesaria para construir el sistema?,
Qu recursos de fabricacin y de desarrollo especiales se requerirn?, Qu lmites
se han impuesto a los costes y a la agenda?, etc.
La informacin recogida durante la etapa de identificacin de las necesidades se
especifica en un documento de conceptos del sistema.
Qu es un Requerimiento
Un requerimiento es una condicin o capacidad a la que el sistema (siendo
construido) debe conformar [ Rational ].
Un requerimiento de software puede ser definido como:
Una capacidad del software necesaria por el usuario para resolver un
problema o alcanzar un objetivo.
Una capacidad del software que debe ser reunida o poseda por un sistema o
componente del sistema para satisfacer un contrato, especificacin, estndar, u
otra documentacin formal.

Qu son Requerimientos
Los requerimientos de usuario representan el conjunto completo de resultados a ser
obtenidos utilizando el sistema.
Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer
ms todas las restricciones sobre la funcionalidad.
Los requerimientos forman un modelo completo, representando el sistema total a
algn nivel de abstraccin.

Rol de Requerimientos
Si un producto no es lo que el cliente o los usuarios quieren, entonces la calidad de la
construccin es irrelevante.
El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que se
necesita de un sistema. Proveer los requerimientos forma parte de un lenguaje que
todos comprenden, ya que todos estn involucrados, incluyendo los clientes.
El primer y bsico rol de los requerimientos es por lo tanto la comunicacin.

Cmo identificamos los Requerimientos
Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de
interlocucin con usuarios o clientes.
Este puede desarrollarse utilizando cualquiera de una variedad de tcnicas como
entrevistas para intercambiar opiniones, brainstorming, prototipeo, cuestionarios, etc.
Cuando los requerimientos se logran redactar a un significativo nivel de detalle,
tendremos listo el documento denominado Especificacin de Requerimientos.


Buena Especificacin de Requerimientos
Un resultado primario de esta administracin es la Especificacin de Requerimientos,
la cual define y documenta en forma completa el comportamiento externo del sistema
a ser construido.
Caracterizndose por:
Definidos sin ambigedad
Son completos
Tienen consistencia
Especifica el origen
Evita detalles de diseo
Estn enumerados
Beneficios de una Buena Administracin de Requerimientos
Mejor control de proyectos complejos.
Mejora en la calidad del software y en la satisfaccin del cliente.
Reduccin en los retrasos y en los costos del proyecto.
Mejora en la comunicacin del equipo.
Facilita la conformidad con estndares y regulaciones.
Los Problemas de la Administracin de Requerimientos
No son siempre obvios y tienen muchas fuentes.
No son siempre fciles de expresar en palabras.
Hay muchos tipos diferentes a distintos niveles de detalle.
El nmero puede llegar a ser inmanejable.
Estn relacionados a otros en una variedad de formas.
Hay muchos interesados y partes responsables.
Cambian.
Pueden ser sensibles al tiempo.

Anlisis del Flujo de Datos
La estrategia del flujo de datos muestra el empleo de stos en forma grfica. Las
herramientas usadas para seguir esta estrategia muestran todas las caractersticas
esenciales del sistema y la forma en que se ajustan entre s. Puede ser difcil
comprender en su totalidad un proceso de la empresa si se emplea para ello solo una
descripcin verbal; las herramientas para el flujo de datos ayudan a ilustrar los
componentes esenciales de un sistema junto con sus interacciones.
El anlisis de flujo de datos usa las siguientes herramientas:
Diagrama de flujo de datos (explicado ms adelante)
Diccionario de datos (explicado ms adelante)
Diagrama de estructura de datos (diagrama de E-R, ver documentacin del
curso de bases de datos I)
Grfica de estructura: herramienta de diseo que muestra con smbolos la
relacin entre los mdulos de procesamiento y el software de la computadora.
Describen la jerarqua de los mdulos componentes y los datos que sern
transmitidos entre ellos. Incluye el anlisis de las transformaciones entrada-
salida y el anlisis de las transacciones.

Diagramas de flujo de datos
Son una de las cuatro herramientas del anlisis estructurado. Es una herramienta
grfica que se emplea para describir y analizar el movimiento de los datos a travs de
un sistema, ya sea este manual o automatizado, incluyendo procesos, lugares para
almacenar datos y retrasos en el sistema. Los DFD, como se les conoce popularmente
son la herramienta ms importante y la base sobre la cual se desarrollan otros
componentes. La transformacin de datos de entrada en salida por medio de procesos
puede describirse en forma lgica e independiente de los componentes fsicos
(computadoras, gabinetes de archivos, y procesadores de texto) asociados con el
sistema.
Notacin: los DFD se pueden dibujar con solo cuatro notaciones sencillas, a saber:
Flujo de datos: movimiento de datos en determinada direccin, desde un
origen hasta un destino en forma de documentos, cartas, llamadas telefnicas
o virtualmente cualquier otro medio. El flujo de datos es un paquete de datos
Representacin:
Procesos: personas procedimientos o dispositivos que usan o producen
(transforman) datos.
Representacin:
Fuente o destino de datos: fuentes o destinos externos de datos, que pueden
ser personas, programas, organizaciones u otras entidades que interactan
con el sistema pero que se encuentran fuera de sus fronteras. La diferencia
fundamental con los procesos es que las fuentes o destinos no transforman
informacin, al menos no dentro de las fronteras del sistema que se est
modelando
Representacin:
Almacenamiento de datos: es el lugar donde se guardan los datos o al que
referencian los procesos en el sistema. El almacenamiento de datos puede
representar dispositivos tanto computarizados como no computarizados.
Representacin:
Los DFD se concentran en el movimiento de los datos a travs del sistema, no en los
dispositivos o el equipo. Los analistas identifican y describen, desde el inicio hasta del
final proceso, para comprender un rea de aplicacin o los datos que fluyen por todo el
sistema y entonces explican por qu los datos entran o salen y cul es el
procesamiento que se realiza con ellos. Es muy importante determinar cundo entran
los datos al rea de aplicacin y cundo salen de sta.
A medida que los analistas renen hechos y detalles, comprenden mejor el proceso;
esto los conduce a formular preguntas relacionadas con aspectos especficos del
mismo y los lleva a una investigacin adicional. La investigacin se divide en detalles
que tienen cada vez un nivel menor hasta que se comprenden todos los componentes
esenciales junto con sus interrelaciones.
Lo que se quiere dar a entender con esto, es que una investigacin de
sistemas produce muchos conjuntos de DFD, algunos (los primeros) brindan
panoramas de procesos importantes, mientras que otros (los que se obtienen
de los primeros) nos muestran con bastante detalle elementos dato, almacenes
de datos y pasos de procesamiento para componentes especficos de un
sistema grande.

A los primeros diagramas obtenidos se les conoce como diagramas de alto nivel,
mientras que a los resultantes de estos se les conoce como diagramas de bajo nivel.
En este sentido el primer diagrama que se obtiene se le conoce con el nombre de
diagrama de contexto, es un diagrama de nivel muy general (alto nivel); es tambin
conocido como diagrama de nivel 0. Contiene un solo proceso pero juega un papel
muy importante en el estudio del sistema en uso; ya que define fronteras. Todo lo que
no se encuentre dentro de las fronteras identificadas en el diagrama no forman parte
del estudio de sistemas. La forma en que funcionen otras organizaciones o elementos
externos (las fuentes y destinos) est fuera de nuestro control y no ser estudiado con
detalle.
Cada flujo de datos(cada flecha) emplea una etiqueta que describe que datos emplea.
Cuando los datos se mueven de un lugar a otro el flujo de datos apunta hacia el lugar
donde se dirige el flujo.

Ejemplo:
Un sistema est formado por varias actividades o procesos, cada uno de los
cuales contiene varios sub-procesos con marcadas interrelaciones entre ellos.
Por ejemplo un proceso de cuentas por pagar puede estar integrado por tres
sub-procesos que podran llamarse: autorizacin de la factura, revisin del
adeudo en la cuenta y elaboracin del cheque.
A su vez cada sub-proceso se divide en sub-procesos ms especficos.
Los nombres dados a los procesos especifican acciones y procedimientos de
control que realizan
Cada proceso se etiqueta adems con un nmero que identifica de donde
proviene (excepto el diagrama de contexto que solo se identifica con un nivel 0
ms el nombre que se le proporcione)
En trminos generales todo componente de los DFD se etiquetan con un
nombre que sea representativo.

Primer nivel del DFD
En el primer nivel, es muy importante identificar los principales procesos, y flujos que
dan en forma conjunta sentido operacional al sistema que se est modelando.
Algunos analistas consideran ventajoso trabajar primero con todos los flujos de datos y
asignar, como ya se dijo nombres que sean significativos y descriptivos. Se identifican
todos los procesos, como ya se mencion pero no se les da nombre hasta que sean
bien entendidos todos los flujos de datos. Despus cuando se les ha asignado nombre
a los procesos, si el analista tiene dificultas para ligar los flujos de datos con los
nombres apropiados entonces esta situacin indica que es necesario dividir aun ms
el proceso.

Expansin de los procesos a diagramas de mayor nivel
Una vez que se ha desarrollado el sistema como est descrito en el diagrama de
primer nivel, es indudable que el analista formule preguntas en relacin con la forma
que se lleven a cabo los procesos. (Ver documento de determinacin de
requerimientos) En general se debe estar seguro de:
Todos los flujos de datos que explican el proceso en el diagrama previo deben
incluirse en el diagrama del siguiente nivel inferior
Los flujos y almacenes de datos nuevo se aaden si son usados internamente
por el proceso para eslabonar otros procesos introducidos por primera vez en
la expansin de este nivel. Se deben mostrar los flujos y almacenes de datos
originados en el proceso dentro en este nivel.
Ninguna entrada debe contradecir las descripciones de los DFD de niveles ms
altos (si lo hacen uno o ambos son incorrectos y deben introducirse cambios)
En general la expansin de niveles depende de la naturaleza y complejidad del
sistema que se modele; no es posible especificar un nmero de niveles, en general se
debe continuar con el proceso de expansin todo lo que sea necesario para
comprender los detalles del sistema y la forma en que trabaja, teniendo cuidado de
verificar todos los aspectos con usuarios que conocen el sistema, en general, se debe
expandir todo aquel proceso que incluyen varias tareas para las que es necesario, el
flujo de datos entre diferentes personas o localidades. Por otra parte no requieren
expansin aquellas tareas que son realizadas por una persona o en un escritorio,
donde no existe flujo de datos.

Reglas adicionales para el dibujo de DFD: ya se han identificado la mayor parte de
los lineamientos que se siguen para el dibujo de los DFD, he aqu algunas ms:
Cualquier flujo de datos que abandone un proceso debe estar basado en los
datos que entran al proceso
Todos los flujos de datos tienen un nombre que refleja los datos que fluyen
entre procesos, almacenes de datos, fuentes o destinos
Solo deben entrar al proceso, los datos necesarios para llevarlo a cabo
Un proceso no debe saber nada de ningn otro en el sistema, es decir debe ser
independiente, la nica dependencia que debe existir es aquella basada en sus
propios datos de entrada y salida
Los procesos siempre estn en continua ejecucin, no se inician ni tampoco se
detienen. Los analistas siempre deben suponer que un proceso est listo para
ejecutar su trabajo
La salida de los procesos puede tomar una de las siguientes formas
Flujo de datos con informacin aadida por el proceso (i.e: una anotacin a una
factura)
Una respuesta o cambio en la forma de los datos (i.e: un cambio en la forma de
expresar las utilidades -de a $-)
Un cambio de condicin (i.e: de autorizado a no autorizado)
Cambio de contenido (i.e: integracin o separacin de la informacin contenida
en uno o ms flujos entrantes de datos)
Cambios en la organizacin (i.e: separacin fsica o redondeo de datos)
La norma comn es definir cada nivel inferior en trminos de 3 a 7 procesos
para cada proceso de nivel superior, si son necesarios ms detalles se puede
hacer en el siguiente nivel.
Los almacenes y flujos de datos que son relevantes solo para el interior del
proceso, son ocultados hasta que el proceso se extiende con mayor detalle
Los datos que fluyen hacia los procesos experimentan cambios. Por
consiguiente, el flujo de datos de salida tiene un nombre diferente al de la
entrada; si no se efecta algn cambio en el flujo de datos, entonces cul es
la finalidad del proceso?
En cuanto a los nombres de los procesos lo ms apropiado es escoger un
verbo y un sujeto que reciba la accin y no nombre generales que no digan
nada. Si un nombre de proceso es vago o complejo tal vez se deba subdividir
el proceso an ms.
Por otra parte no se ha mencionado nada an sobre controles en los DFD, no hemos
mencionado nada al respecto sobre como manejar errores o excepciones, por ejemplo
el procesamiento de facturas incorrectas. Aunque esta informacin es necesaria para
el anlisis final, no es importante identificar todos los flujos de datos (los errores o
excepciones son tambin flujos de datos). Los diagramas secundarios (por debajo del
segundo o tercer nivel), deben mostrar el manejo de errores y excepciones del
proceso.
Aun as ciertos detalles fsicos como el da de la semana que se debe hacer un pago u
otros controles de este tipo son innecesarios en los DFD, puesto que no tienen nada
que ver con los aspectos lgicos y de datos de la determinacin de requerimientos.
Los elementos importantes para comprender un proceso durante el anlisis lgico de
flujo de datos, no son el nmero de copias que se requieren de un documento sino las
descripciones de los datos necesarios para llevar a cabo el proceso.
Diccionario de datos
Un diccionario de datos es un catlogo, un depsito, de los elementos de un sistema.
Estos elementos se centran alrededor de los datos y la forma en que estn
estructurados para satisfacer los requerimientos y las necesidades de la organizacin.
En l se encuentran la lista de todos los elementos que forman parte del flujo de datos
en todo el sistema.
Importancia del diccionario:
Los analistas usan los diccionarios de datos por cinco razones principales:
Manejar los detalles en sistemas grandes
Comunicar un significado comn para todos los elementos del sistema
Documentar las caractersticas del sistema
Facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas
y determinar donde efectuar cambios en el sistema
Localizar errores y omisiones en el sistema

Contenido de un registro del diccionario:
Campos: es el nivel ms importante de datos; ninguna unidad ms pequea
tiene significado para los analistas. La descripcin de los datos debe ir
acompaada por los siguientes elementos:
Estructuras de datos: son un grupo de datos elementales que estn
relacionados con otros y que en conjunto describen un componente del
sistema. Los flujos de datos, o los almacenes de datos son ejemplo de
estructuras de datos. Dicho de otra forma si las estructuras estn en
movimiento reciben el nombre de flujos y si son estticas son almacenes de
datos. Se construyen sobre cuatro relaciones de componentes; que bien
pueden ser datos o estructuras de datos tambin. Se pueden usar las
siguientes combinaciones ya sea en forma individual o en conjuncin con
alguna otra:
Relacin secuencial
Relacin de seleccin
Relacin de iteracin
Relacin opcional

Notacin empleada en el Diccionario de datos:
Se usa smbolos especiales con la finalidad de limitar la cantidad de texto necesario
empleado para describir las relaciones entre los datos y al mismo tiempo mostrar con
claridad las relaciones estructurales.
La simbologa empleada se describe a continuacin:

Smbolo Significado Explicacin Uso
= Es equivalente a Alias Denota sinnimos
+ Y
Concatenacin,
componentes que siempre
estn incluidos en una
estructura
Denota una relacin
de secuencia
[] Uno u otro
Define opciones entre los
componentes de una
estructura
Denota una relacin
de seleccin
{} Iteraciones de
Define la repeticin de un
componente de la
estructura
Denota una relacin
de iteracin
() Opcional
Define componentes de la
estructura que puede o no
estar presente una sola vez
Denota una relacin
opcional.

Registro de las descripciones de datos en el diccionario:
Flujos de datos
Nombre del flujo de datos
Descripcin
Proviene de los procesos
Para los procesos
Estructuras de datos:
Almacenes de datos
Nombre del almacn
Descripcin
Flujos de datos recibidos
Flujos de datos proporcionados
Descripcin de los datos (mencin a los datos o estructuras que contiene)
Volumen
Acceso
Estructuras de datos (es aqu donde es emplea la notacin descrita en la tabla
anterior)
Nombre de la estructura
Descripcin
Contenido
Volumen
Elementos datos
Nombre del dato
Descripcin
Tipo
Longitud
Alias
Rango de valores
Lista de valores especficos (en caso que existan)
Otros detalles de edicin
Procesos
Nombre del proceso
Descripcin
Flujos que entran
Flujos que salen
Resumen de la lgica