El documento discute los beneficios del desarrollo de software basado en componentes, incluyendo el ahorro de tiempo y esfuerzo a través de la reutilización de componentes previamente desarrollados y probados, la reducción de costos en comparación con el desarrollo de software desde cero, y la obtención de un producto de mejor calidad al combinar componentes individuales que pueden ser continuamente mejorados. También señala que es importante seleccionar componentes apropiados y asegurarse de que no contengan fallas para garantizar la confi

1. Paginas http://lsi.ugr.es/~mvega/docis/requeintro.pdf
El Desarrollo de Software Basado en Componentes en mi criterio tiene muchas ventajas,
una de las principales se basa en la reutilización de componentes, de esta manera, los
componentes se los diseña con el objetivo de poder ser reutilizados en otros proyectos,
favoreciendo a la necesidad de realizar software complejo en cortos periodos de tiempo y
a la vez con un menor esfuerzo en la realización del mismo, los costos son mucho menores
que desarrollar un software desde cero, la reutilización de código previamente realizado y
probado nos facilita el trabajo, mejorando la fiabilidad del producto final.
Estos componentes de software ya desarrollados, son combinados adecuadamente para
obtener un producto final de buena calidad, pues dado que un componente puede ser
construido y luego mejorado continuamente, la calidad de un software basado en
componentes mejorará con el tiempo, para esto hay que realizar una precisa búsqueda y
selección de componentes apropiados que se emplearán en el desarrollo del software.
Con esto hay que tener especial cuidado pues si al ensamblar los distintos componentes
uno de ellos no es confiable, el software en cuestión tendría fallas. En resumen el
Desarrollo de Software Basado en Componentes, como ventajas podría decir que nos
ahorra tiempo por la reutilización de componentes, esfuerzo, dinero, y además
obtenemos un software de buena calidad..
INTRODUCCIÓN
El proceso de industrialización del software, exige que los ingenieros y técnicos planteen
nuevas alternativas para incrementar la productividad de los desarrolladores y analistas
en el desarrollo de sistemas de software.
En este contexto, el estudio evalúa la productividad de un desarrollador realizando una
comparación entre un sistema desarrollado reutilizando software, y otro sin reutilización
de software. Para ello, en la evaluación se utiliza el Método Aproximativo de Costo y
Productividad (COCOMO)
REUTILIZACIÓN DE SOFTWARE
Mientras que los usuarios demandan mayor complejidad y funcionalidad de los sistemas
de software; los desarrolladores por su parte, tienen que manejar la complejidad propia
de la lógica de negocios, así como la complejidad de la herramienta de programación, con
los limitados recursos económicos y de tiempo. En este escenario, la reutilización de
software, se constituye como una de las mejores opciones para disminuir los plazos de
entrega.

2. Existen diferentes técnicas de reutilización sistemática de software (4), dentro del
esquema de la programación orientada a objetos (POO) uno de ellos es la reutilización de
componentes, a través de la creación de clases abstractas, e interfases.
El arquitecto Alexander Christopher, de la Universidad de Oxford, fue quien proporcionó
el fundamento teórico que posteriormente consolidó la reutilización de software, por
medio de 2 libros publicados en 1977: "A Pattern Language y A Timeless way of Building".
Alexander; se refería a construcciones urbanas, alienándolo en estructuras recurrentes a
las que denominó patrones(1).
Los continuos avances en la Inform´atica y las Telecomunicaciones estan haciendo
cambiar la forma enla que se desarrollan actualmente las aplicaciones software. En
particular, el incesante aumento de la potencia de los ordenadores personales, el
abaratamiento de los costes del hardware y las comunicaciones, y la aparici´on de redes
de datos de cobertura global han disparado el uso de los sistemas abiertos y distribuidos.
Esto ha provocado, entre otras cosas, que los modelos de programaci´on existentes se
vean desbordados, siendo incapaces de manejar de forma natural la complejidad de los
requisitos que se les exigen para ese tipo de sistemas. Comienzan a aparecer por tanto
nuevos paradigmas de programaci´on, como pueden ser la coordinaci´on, la
programaci´on orientada a componentes, o la movilidad, que persiguen una mejora en los
procesos de construcci´on de aplicaciones software. En ellos se trabaja tanto en
extensiones de los modelos existentes como en nuevos modelos, en la estandarizaci´on de
sus interfaces y servicios, y la pertinaz b´usqueda del cada vez m´as necesario mercado
global de componentes software.
Estos son parte de los nuevos retos con los que se enfrenta actualmente la ingenier´ıa del
software.
Uno de los enfoques en los que actualmente se trabaja constituye lo que se conoce como
Desarrollo de Software Basado en Componentes (DSBC), que trata de sentar las bases para
el dise˜no y desarrollo de aplicaciones distribuidas basadas en componentes software
reutilizables. Dicha disciplina cuenta actualmente con un creciente inter´es, tanto desde el
punto de vista acad´emico como desde el industrial, en donde la demanda de estos temas
es cada d´ıa mayor.
La presente lecci´on pretende servir como una breve introducci´on a algunos de los
conceptos y m´etodos fundamentales sobre los que se apoya el DSBC. En particular, nos
centraremos en las arquitecturas software y los marcos de trabajo, la programaci´on
orientada a componentes, y en las plataformas de componentes distribuidas. Asimismo,
discutiremos sobre lo que deber´ıa constituir una metodolog´ıa para el DSBC. Por
supuesto, a´un queda mucho trabajo por hacer para poder hablar realmente de una
Ingenier´ıa del Software Basada en Componentes, pero sin duda las bases se est´an
sentando para hacer de esta disciplina una realidad en un futuro cercano.

3. INTRODUCCION
¿Qué son Requerimientos?
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas
definiciones que existen para requerimiento, ha continuación se presenta la definición que
aparece en el glosario de la IEEE .
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
(2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema
para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una
representación documentada de una condición o capacidad como en (1) o (2).
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no
funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de
realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir
salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma
puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de
usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad,
portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de
requerimientos en estado de madurez, deben presentar una serie de características tanto
individualmente como en grupo. A continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a
construir, y además su capacidad, características físicas o factor de calidad no pueden ser
reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es
decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que
permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o
pruebas.
* Dificultades para definir los requerimientos *
• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

4. • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables
que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes
del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada
proyecto.
* Ingeniería de Requerimientos vs. Administración de Requerimientos *
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado
Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una
especificación de requisitos de software correcta y completa.
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se
basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan los
requerimientos como una base para la estimación del esfuerzo necesario en un proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se
esta tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son
la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o
no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base
para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma
mas adecuada posible.
Características de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un sistema de software entonces
debemos de definir que características deben de poseer los requerimientos adecuadamente
formulados.
Los requerimientos deben ser:
Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo
sabemos si cumplimos con él o no?
Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe de
hacer (y no como debe de hacerlo)
Lo más abstracto y conciso posible. Para evitar malas interpretaciones.
* Fundamentos del Análisis de Requerimientos *
Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos
necesarios para definir un proyecto de software.
Es la etapa más crucial del desarrollo de un proyecto de software.

5. La IEEE los divide en funcionales y no funcionales:
Funcionales: Condición o capacidad de un sistema requerida por el usuario para resolver un
problema o alcanzar un objetivo.
No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer un contrato, un
estándar, una especificación u otro documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los
requerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, un
programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, El
ámbito del programa, establecido inicialmente durante la ingeniería del sistema, es refinado en
detalle. Se analizan y asignan a los distintos elementos de los programas las soluciones
alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de
requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función y
comportamiento de los programas en detalles concretos, El que desarrolla el software actúa como
interrogador, consultor y el que resuelve los problemas.
El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla,
pero las apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los
cambios por mala interpretación o falta de información. El dilema con el que se enfrenta un
ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo: "Sé
que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste
oír sea lo que yo quise decir".
Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y
detallados, y además contienen múltiples relaciones entre sí. Lo que nos da a concluir, que el
conjunto de requerimientos de un sistema computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones
simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizar
todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos.
El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema y
el diseño de programas. El análisis de requerimientos facilita al ingeniero de sistemas especificar
la función y comportamiento de los programas, indicar la interfaz con otros elementos del
sistema y establecer las ligaduras de diseño que debe cumplir el programa. El análisis de
requerimientos permite al ingeniero refinar la asignación de software y representar el dominio de
la información que será tratada por el programa. El análisis de requerimientos de al diseñador la
representación de la información y las funciones que pueden ser traducidas en datos, arquitectura
y diseño procedimental. Finalmente, la especificación de requerimientos suministra al técnico y al
cliente, los medios para valorar la calidad de los programas, una vez que se haya construido.
* Tareas del Análisis *
El análisis de requerimientos puede dividirse en cuatro áreas:
1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.
Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de proyecto. Es

6. importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó
para generar las estimaciones de la planificación. A continuación, debe establecerse la
comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del
problema.
El analista debe establecer contacto con el equipo técnico y de gestión del usuario / cliente y con
la empresa que vaya a desarrollar el software. El gestor del programa puede servir como
coordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo del
analista es reconocer los elementos básicos del programa tal como lo percibe el usuario / cliente.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del
análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas
las funciones del programa, establecer las características de la interfase del sistema y descubrir
las ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma que
pueda sintetizarse un enfoque o solución global.
Las tareas asociadas con el análisis y especificación existen para dar una representación del
programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente
desarrolla una especificación de requerimientos del software completamente por sí mismo. Esto
se presenta raramente en el mundo real. En el mejor de los casos, la especificación se desarrolla
conjuntamente entre el cliente y el técnico.
Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interfase e
información, se especifican los criterios de validación para demostrar una comprensión de una
correcta implementación de los programas. Estos criterios sirven como base para hacer una
prueba durante el desarrollo de los programas. Para definir las características y atributos del
software se escribe una especificación de requerimientos formal. Además, para los casos en los
que se desarrolle un prototipo se realiza un manual de usuario preliminar.
Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del proceso
de desarrollo, Pero de hecho, este borrador del manual de usuario fuerza al analista a tomar el
punto de vista del usuario del software. El manual permite al usuario / cliente revisar el software
desde una perspectiva de ingeniería humana y frecuentemente produce el comentario: "La idea es
correcta pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir tales
comentarios lo más tempranamente posible en el proceso.
Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven como
base para una revisión conducida por el cliente y el técnico. La revisión de los requerimientos casi
siempre produce modificaciones en la función, comportamiento, representación de la
información, ligaduras o criterios de validación. Además, se realiza una nueva apreciación del
plan del proyecto de software para determinar si las primeras estimaciones siguen siendo validas
después del conocimiento adicional obtenido durante el análisis.
* Obteniendo de la información *
Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de
software, este entendimiento es necesario para poder construir software que satisfaga las
necesidades de nuestro cliente.
Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que

7. para recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas
con el cliente o recabando documentación que describa la manera que el cliente desea que
funcione el sistema de software.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio
involucra un costo. Por eso es necesario tener archivada una copia de la documentación original
del cliente, así como cada revisión o cambio que se haga a esta documentación. Como cada
necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para
saber cuales de ellas serán satisfechas por el software y cuales por algún otro producto del
sistema.
* Especificación de Requisitos de Software *(SRS)
La especificación de requisitos de software es la actividad en la cual se genera el documento, con
el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades
del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus
funciones, definiendo los requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de
sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.
Es importante destacar que la especificación de requisitos es el resultado final de las actividades
de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente
básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de
pruebas, y todo aquel involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con
las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el
producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de
sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y
control de la evolución del sistema.
La SRS posee las mismas características de los requerimientos: completa, consistente, verificable,
no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de
la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que
una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para
que una SRS se considere modificable, cada requerimiento debe ser modificable y así
sucesivamente. Las características de la SRS son verificadas en la actividad de Validación,
descrita en el punto.
La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura
y escritura de la misma. Será un documento familiar para todos los involucrados, además de
asegurar que se cubren todos los tópicos importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia
plantilla.
Clasificación de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus
características no pueden ser tratados iguales.
La siguiente es una recomendación de como pueden ser clasificados los requerimientos aunque
cada proyecto de software pueda usar sus propias clasificaciones.
• Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto

8. tipo de requerimientos que se clasifican en esta categoría por que:
El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que
funcione. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos,
bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como
congestión en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de
considerar dentro de los requerimientos.
• Requerimientos "ergonómicos"
Él mas conocido de los requerimientos ergonómicos es la interfase con el usuario o GUI (Graphic
User Interface). En otras palabras, los requerimientos ergonómicos son la forma en que el ser
humano interactúa con el ser sistema.
• Requerimientos de Interfase
La interfase es como interactúa el sistema con el ser humano o con otros sistemas (el enfoque es
prácticamente el opuesto a los requerimientos ergonómicos), La interfase es la especificación
formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el
protocolo, el tipo de información, el medio para comunicarse y el formato de los datos que se van
a comunicar.
* Actividades de la Ingeniería de Requerimientos *
En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas,
sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son
aplicadas de manera continua y en orden variado.
Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo
de desarrollo, las actividades de la IR varían tanto en número como en nombres. La tabla #1
muestra algunos ejemplos de las actividades identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de
actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades
principales que son:
• Análisis del Problema
• Evaluación y Negociación
• Especificación
• Validación
• Evolución
* Principios de Especificación *
La especificación, independientemente del modo en que se realice, puede ser vista como un
proceso de representación. Los requerimientos se representan de forma que conduzcan
finalmente a una correcta implementación del software.
Baltzer y Goldman proponen ocho principios para una buena especificación:
PRINCIPIO #1. Separar funcionalidad de implementación.
Primero, por definición, una especificación es una descripción de lo que se desea, en vez de cómo
se realiza (implementa). Las especificaciones pueden adoptar dos formas muy diferentes. La
primera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir un
conjunto particular de salida. La forma general de tales especificaciones es encontrar
[un/el/todos] resultado tal que P (entrada), donde P representa un predicado arbitrario. En tales
especificaciones, el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el

9. que (en vez de cómo). En parte, esto es debido a que el resultado es una función matemática de la
entrada (la operación tiene puntos de comienzo y parada bien definidos) y no esta afectado por el
entorno que le rodea.
PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso.
Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al
comportamiento de alguna entidad que interactúe con dicho entorno. Su comportamiento no
puede ser expresado como una función matemática de su entrada. En vez de ello, debe emplearse
una descripción orientada al proceso, en la cual la especificación del que se consigue mediante la
especificación de un modelo del comportamiento deseado en términos de respuestas funcionales,
a distintos estímulos del entorno.
PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es una
componente.
Un sistema esta compuesto de componentes que interactúan. Solo dentro del contexto del
sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de
una componente especifica. En general, un sistema puede ser modelado como una colección de
objetos pasivos y activos. Estos objetos están interrelacionados y dichas relaciones entre los
objetos cambian con el tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales
los objetos activos, llamados agentes, responden. Las respuestas pueden causar posteriormente
cambios y, por tanto, estímulos adicionales a los cuales los agentes deben responder.
PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistema
compuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema especificado es
una agente, Los otros agentes, los cuales son por definición inalterables debido a que son parte
del entorno, limitan el ámbito del diseño subsecuente y de la implementación. De hecho, la única
diferencia entre el sistema y su entorno es que el esfuerzo de diseño e implementación
subsecuente opera exclusivamente sobre la especificación del sistema. La especificación del
entorno facilita que se especifique la interfaz del sistema de la misma forma que el propio
sistema, en vez de introducir otro formalismo.
PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo.
La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o
implementación. Debe describir un sistema tal como es percibido por su comunidad de usuario.
Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio; los
agentes deben modelar los individuos, organizaciones y equipo de ese dominio; y las acciones que
ejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser posible
incorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Algunas
de estas leyes proscriben ciertos estados del sistema (tal como "dos objetos no pueden estar en el
mismo lugar al mismo tiempo"), y por tanto limitan el comportamiento de los agentes o indican
la necesidad de una posterior elaboración para prevenir que surjan estos estados.
PRINCIPIO #6. Una especificación debe ser operacional.
La especificación debe ser completa y lo bastante formal para que pueda usarse para determinar
si una implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente.
Esto es, dado el resultado de una implementación sobre algún conjunto arbitrario de datos
elegibles, debe ser posible usar la especificación para validar estos resultados. Esto implica que la
especificación, aunque no sea una especificación completa del como, pueda actuar como un
generador de posibles comportamientos, entre los que debe estar la implementación propuesta.
Por tanto, en un sentido extenso, la especificación debe ser operacional.

10. PRINCIPIO #7. La especificación del sistema debe ser tolerante con la incompletitud y
aumentable.
Ninguna especificación puede ser siempre totalmente completa. El entorno en el que existe es
demasiado complejo para ello. Una especificación es siempre un modelo, una abstracción, de
alguna situación real (o imaginada). Por tanto, será incompleta. Además, al ser formulad
existirán muchos niveles de detalle. La operacionalidad requerida anteriormente no necesita ser
completa. Las herramientas de análisis empleadas para ayudar a los especificadores y para probar
las especificaciones, deben ser capaces de tratar con la incompletitud. Naturalmente esto debilita
el análisis, el cual puede ser ejecutado ampliando el rango de comportamiento aceptables, los
cuales satisfacen la especificación, pero tal degradación debe reflejar los restantes niveles de
incertidumbre.
PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada.
Los principios anteriores tratan con la especificación como una entidad estática. Esta surge de la
dinámica de la especificación. Debe ser reconocido que aunque el principal propósito de una
especificación sea servir como base para el diseño e implementación de algún sistema, no es un
objeto estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones.
Tales modificaciones se presentan en tres actividades principales: formulación, cuando se está
creando una especificación inicial; desarrollo, cuando la especificación se esta elaborando
durante el proceso iterativo de diseño e implementación; y mantenimiento, cuando la
especificación se cambia para reflejar un entorno modificado y / o requerimientos funcionales
adicionales.
• Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa él
¿Qué? Y no él ¿Cómo?. Estos requerimientos al tiempo que avanza el proyecto de software se
convierten en los algoritmos, la lógica y gran parte del código del sistema.
• Requerimientos de desempeño
Estos requerimientos nos informan las características de desempeño que deben de tener el
sistema. ¿Que tan rápido?, ¿Que tan seguido?, ¿Cuantos recursos?, ¿Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el
desempeño de un sistema es tan crítico como su funcionamiento.
• Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradación, potabilidad, flexibilidad,
contabilidad y capacidad de actualización. Este tipo de requerimientos es también muy
importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones críticas
que no deben de estar fuera de servicio por periodos prolongados de tiempo.
• Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el sistema. ¿Que tipo de
usuarios son?, ¿Que tipo de operadores?, ¿Que manuales se entregarán y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de código dentro del
sistema, son muy importantes en el proceso de diseño ya que facilitan la introducción y
aceptación del sistema en donde será implementado.
• Restricciones de diseño
Muchas veces las soluciones de un sistema de software son normadas por leyes o estándares, este
tipo de normas caen como "restricciones de diseño".
• Materiales
Aquí se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante
para definir los costos de industrialización del sistema.

11. * Manejo de requerimientos *
De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra:
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de
software. Este acuerdo son los requerimientos del sistema alojados al software." … ". Este acuerdo
cubre requerimientos técnicos y no técnicos (como fechas de entrega). El acuerdo forma las bases
para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a través de todo
su ciclo de vida." … "Bajo las restricciones del proyecto, el grupo de manejo de requerimientos
toma las medidas necesarias para que los requerimientos que están bajo su responsabilidad estén
documentados y controlados"
¿De que manera podemos controlar los requerimientos de software si estos siempre evolucionan
con el tiempo?. El CMM nos proporciona las guías para lograrlo.
"Para lograr el control de los requerimientos, el grupo de requerimientos revisa los
requerimientos antes de que estos sean incorporados al proyecto de software y cada vez que los
requerimientos cambian los planes, productos, y actividades son ajustadas para quedar en línea
con los nuevos requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos
débenos de tomar en cuenta dos cosas.
• Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, y
no son impuestos por en su totalidad por presiones externas ajenas al proyecto.
El requerimiento técnico podrá ser impuesto por el mercado o presiones de la competencia, pero
entonces los requerimientos no técnicos (Calidad, Costo y Tiempo de entrega) deberán estar
especificados de común acuerdo con el grupo de requerimientos del proyecto de software.
• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si cambia uno
forzosamente deberán cambiar los demás. Esto es: más contenido técnico implica o más costo, o
menos calidad o más tiempo estimado de entrega. De modo que los cambios técnicos deberán ser
aprobados por el grupo de requerimientos y este grupo estimará los impactos en tiempo, costo,
calidad. El resultado de la estimación es la entrada a los líderes del proyecto para decidir si el
cambio se acepta o no.
* ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *
Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades de los usuarios,
lo cual no resulta posible si no integra y pone al alcance del consumidor de forma comprensible
los fundamentos de todos los aspectos del desarrollo. Para captar las necesidades específicas de
los usuarios es indispensable que los documentos que recogen los requerimientos se redacten
utilizando métodos pragmáticos.
Se debe utilizar una metodología detallada de definición de los requerimientos de usuario.
Organizar entrevistas destinadas a obtener la máxima información posible acerca de los
requerimientos de los usuarios. Traducir las oportunidades / necesidades en requerimientos del
proyecto. Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear un
documento de requerimientos generales. Conseguir la participación y confirmación del usuario.
Los gerentes y usuarios del sistema también poseen un papel importante en le diseño del sistema;
no es solamente el proyecto del analista. Durante el diseño, a algunos se les pide que revisen los
borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de
los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada.

12. La participación del usuario proporciona al analista una retroalimentación importante conforme
avanza en el diseño; además asegura a los usuarios tengan un conocimiento no técnico de lo
realizara o no el nuevo sistema.
Esta visión general del diseño de sistemas subraya los aspectos de diseño que se verán mas
adelante en el diseño de la salida de sistema.
* REQUERIMIENTOS DEL SISTEMA *
Los Sistemas de Información por computadora normalmente están integrados por muchos
componentes. En la mayor parte de los casos, es difícil para los analistas entender todos estos
componentes aún mismo tiempo; por lo tanto los investigadores tienen que comenzar con
preguntas de tipo general con relación al propósito del sistema sus entradas y salidas de los
procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una investigación en forma
seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda trabajar en
forma independiente.
Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de
información. Se clasifican en dos tipos:
1.- Flujo de Datos.
2.- Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de Información.
* Estrategia del Flujo de Datos *
Cuando se siguen un flujo a través de los procesos de negocio, que es el propósito del análisis del
flujo de datos, le indica a los analistas una gran cantidad de datos sobre como sé esta llevando a
cabo los objetivos de la compañía. Al manejar las transacciones y completar las tareas, los datos
de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten.
El análisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta los
hallazgos en los diagramas de flujo de datos.
* Estrategia del Análisis de Decisiones *
La estrategia del análisis de decisiones es un complemento del análisis del flujo de datos. Esta
estrategia realza el estudio de los objetivos de una operación y de las decisiones que deben
realizarse para cumplir con los objetivos.
Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, la
estrategia de análisis de decisión con frecuencia utiliza por parte de alta gerencia para desarrollar
la toma de decisiones.
La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a una
estrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la opción
que toma un supervisor de departamento para aceptar o rechazar pedidos.
La decisión de rechazar pedidos generalmente ocurre con más frecuencia, de manera que las
condiciones y acciones normalmente se conocen como un aspecto importante.
* Etapas en la Estrategia del Análisis del Flujo de Datos *
1. - Estudiar las operaciones y procesos en marcha.

13. 2. - Identificar cómo se procesan los datos al manejar transacciones y terminar las tareas.
3. - Seguir el flujo de datos:
* Proceso
* Almacenamiento
* Recuperación
* Salida
4. - Añadir gradualmente detalles a los niveles inferiores.
Etapas en la Estrategia del Análisis de Decisión
1. -Estudiar los objetivos y decisiones necesarias.
2. - Desarrollar un modelo del proceso de decisión.
3. - Probar el modelo con datos de prueba.
4. - Identificar los requerimientos del proceso para los datos.
* Requerimientos De Entrada *
Es el enlace que une al sistema de información con el mundo y sus usuarios, en esta existen
aspectos generales que todos los analistas deben tener en cuenta estos son:
• Objetivos del Diseño de Entrada.
• Captura de Datos para la Entrada.
Objetivo del Diseño de Entrada
Consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la
realización de los procesos necesarios para poner los datos de transacción en una forma utilizable
para su procesamiento así como la entrada de los datos se logra al instruir a la computadora para
que lea ya sea documentos escritos, impresos ó por personas que los escriben directamente al
sistema.
Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos,
controlar los errores y mantener la sencillez de los pasos necesarios, estos son:
• Control de la Calidad de Entrada
• Evitar los Retrasos
• Evitar los errores en los datos
• Evitar los pasos adicionales
• Mantener la Sencillez del Proceso
Control de la Calidad de Entrada:
Existen varias razones por las cuales un buen diseñador debe controlar la cantidad de datos en la
entrada:
- Las Operaciones de preparación y entrada dependen de las personas dado que los costos de
mano de obra son altos y la preparación de ingreso de los datos también lo son.
-
La fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan
las computadoras para realizar sus tareas.
Evitar los Retrasos:
También conocido con el nombre de cuello de botella son siempre uno de los objetivos que el
analista evita al diseñar la entrada, una forma de evitarle es utilizar los documentos de retorno.
Evitar los errores en los datos:

14. La tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea esta menores
serán las oportunidades para cometer errores. Es común encontrar en las operaciones de ventas
por lo menos un 3% de errores en las operaciones de entrada de datos.
Evitar los Pasos Adicionales:
Algunas veces el volumen de transacciones y la cantidad de datos en preparación es algo que no
se puede controlar por ello el analista experimentado, evitara diseños para la entrada que traigan
una mayor cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta un
proceso muchas veces al transcurso de un día.
Mantener la sencillez del Proceso:
El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo
proporcionarán métodos para el control de los errores, la simplicidad funciona y es aceptada por
cualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y que
no exista ninguna garantía para el éxito al instalar un sistema complejo y que domine.
Captura de Datos para la Entrada:
En una transacción existen datos importantes y otros que no, el analista debe saber cuales
utilizará y cuales en realidad deben formar la entrada. Existen dos tipos de datos:
• datos variables
• datos de identificación
Datos Variables:
Son aquellos que cambian para cada transacción o toman de decisión.
Datos de Identificación:
Estos son los que identifican en forma única el artículo que esta siendo procesado.
* Requerimientos De Salida *
Niveles de diseño
El diseño de sistema se representa a través de dos fases: el diseño lógico y el diseño físico.
Cuando los analistas formulan un diseño lógico; escriben las especificaciones detalladas del
nuevo sistema; esto es, describen sus características: las salidas, entradas, archivos y bases de
datos y procedimientos; todos de manera que cubran los requerimientos del proyecto.
El diseño lógico de un sistema de información es como el plano de un ingeniero para armar un
automóvil: muestra las características principales(motor, transmisión y área para los pasajeros)y
como se relacionan unas con otras(donde se conectan entre sí los componentes del sistema, o por
ejemplo, cuan separadas están las puertas.
Los informes y la producción del analista son los componentes de todo el mecanismo que emplea
el ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje.
El diseño lógico también especifica las formas de entrada y las descripciones de las pantallas de
todas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de las
transacciones y los datos del proveedor. Las especificaciones de los procedimientos describen
métodos para introducir los datos, corridas de informes copiados de archivos y detección de
problemas.
El diseño físico, actividad que sigue el diseño lógico, produce programas de software, archivos y
un sistema en marcha, las especificaciones del diseño indican a los programadores que debe
hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por
parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los

15. archivos.
Utilización de los Datos de Requerimientos:
El alcance del diseño de sistemas se guía por el marco de referencia para el nuevo sistema
desarrollado durante el análisis. Los datos de los requerimientos, recopilados durante la
investigación, conforman las actividades y componentes del sistema. Los analistas formulan un
diseño lógico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar
como resultado de un nuevo diseño.
El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de requerimientos.
En primer lugar se identifican las características generales, como informes y entradas; en el
diseño de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato
específico para establecer cuanto espacio dejar en la información, en la pantalla de despliegue
visual o archivo.
A lo largo de los años hemos visto una evolución de ideas y técnicas en el campo del análisis de
sistemas. La cual cabe en tres períodos amplios según Yourdon:
1. El análisis de sistema convencional, anterior a los años 70´s, caracterizado por especificaciones
tipo novela victoriana que eran difíciles de leer y entender, y casi imposibles de mantener.
2. El análisis estructurado clásico, de mediados de los años 70´s, a mediados de los años 80´s.
Esto se caracterizó por primeras versiones de modelos gráficos, y énfasis en el modelado de las
implementaciones actuales de un sistema antes de modelar el nuevo.
3. El análisis estructurado moderno, en el cual se introducen mejoras sobre todo para modelar
sistemas de tiempo real y relaciones de situaciones complejas. Aumentando por ende la
comunicación entre el analista y el sistema.
En la actualidad las técnicas modernas están siendo fusionadas, para así lograr un mejor método
que pueda hacerle frente a las necesidades de las diferentes fases del ciclo de vida del sistema,
incluyendo a la fase de análisis. Obteniendo de está manera mejores resultados que pueda
interpretar el analista en forma rápida y precisa.
En primera instancia debemos decir que el análisis estructurado según Senn "permite al analista
conocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo que
proporciona la base para asegurar que no se omite ningún detalle pertinente". El objetivo que
persigue el análisis estructurado es organizar las tareas asociadas con la determinación de
requerimientos para obtener la comprensión completa y exacta de una situación dada. Se puede
decir adicionalmente que los componentes del análisis estructurado son los siguientes: símbolos
gráficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas.
Después de relacionarnos brevemente con la terminología básica, podemos entrar en aspectos
relacionados con los cambios del análisis estructurado.
Podemos decir que para finales de los años 60´s e inicios de los 70´s el análisis estructurado
surge de la necesidad de buscar una forma interpretativa más rápida y eficiente, de tal manera
que se pudiesen definir los requerimientos del usuario y las especificaciones funcionales del
sistema. Pero esto no se daba porque lo que existía eran grandes volúmenes de información que
había que leer por completo y que acarreaban una serie de problemas de: monolitismo,
redundancia, ambigüedad e imposibilidad de mantener. Es por ello que surge una amplia
variedad de diagramas que permiten representar las especificaciones funcionales en forma
sencilla y rápida, aumentando por ende el grado de comunicación entre las especificaciones
funcionales y el usuario final (analista, programador, diseñador).
Posteriormente, a mediados de los años 70´s estando el análisis estructurado clásico en su
apogeo aparecen una serie de dificultades que limitan al analista hacer un buen desempeño de
sus actividades. Entre estos problemas según Yourdon podemos mencionar:

16. • Distinción difusa y poca, definida entre los modelos lógicos y los modelos físicos.
• Limitación para modelar sistemas en tiempo real.
• El modelo de datos se hacía de una manera primitiva.
Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis estructurado clásico tales
como: diagramas de entidad-relación, diagramas de transición de estados, división de eventos,
modelos esenciales y modelos de implantación. Pero a pesar de esto según Yourdon se siguieron
dando más problemas como los siguientes:
• Tras la segunda y tercera correcciones de un diagrama, el analista se volvía cada vez más
apuesto y renuente a hacer más cambios.
• Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el modelo del
sistema en modelos de menor nivel, quedando por ende, funciones primitivas.
• A menudo no se incorporaban en el modelo del sistema los cambios en los requerimientos del
usuario sino hasta después de la fase de análisis del proyecto.
Inclusive las correcciones de los diagramas había que hacerlas en forma manual, para asegurar
que fuesen consistentes y estuviesen completas; lo cual era bastante tedioso y dejaba por fuera
muchos errores que debían de encontrarse. Pero para mediados de los 80´s aparecieron las
herramientas CASE que trataron de subsanar estos problemas. Las herramientas CASE
(Ingeniería de software auxiliada por computadora) se utilizan para dibujar diagramas de flujo de
datos y otros además de llevar a cabo una variedad de labores de revisión de errores.
Finalmente, algunos usuarios tenían dificultades al tratar con los modelos gráficos del análisis
estructurado y preferían alguna otra forma de modelar los requerimientos y comportamiento del
sistema; es por ello que aparecen las herramientas de generación de prototipos (mediados de los
80´s) que son considerados como una alternativa al análisis estructurado para tales usuarios.
También se utiliza para recordar en forma breve y precisa lo que se ha hecho a lo largo de todo el
desarrollo del sistema, para no perder la secuencia de lo que se está realizando.
En la actualidad muchas de estas herramientas se están utilizando para facilitar la fase de
análisis, e inclusive se están elaborando o fusionando lo mejor de cada una de las técnicas que
atienden las necesidades de todas las fases del ciclo de vida del sistema; para así obtener un mejor
aprovechamiento, entendimiento, y rendimiento al momento que se ponga a correr el sistema.
Disminuyendo de esta manera la serie de errores que se cometían anteriormente, con la
introducción de herramientas más especializadas y fáciles de utilizar.
Diversos aspectos del análisis estructurado han cambiado gradualmente a lo largo de los últimos
años. Las principales áreas de cambio incluyen lo siguiente según Yourdon:
• Cambios de terminología.
• Partición de acontecimientos.
• La desenfatización del modelado físico actual.
• Herramientas de modelado en tiempo real.
• Integración más cercana del modelado de procesos y datos.
En un futuro no muy lejano se piensa que se darán, si es que ya no se están dando, los siguientes
cambios o pautas en el ámbito total en lo que se refiere a análisis según Yourdon:
• Mayor difusión del análisis de sistemas, sobre todo en los siguientes grupos: los niveles
superiores de administración en organizaciones gubernamentales y de negocios, los niños, y
profesionales de la computación en los países del tercer mundo.
• Impacto sobre la industria de software del tercer mundo.
• Proliferación de las herramientas automatizadas, aunque no todos los analistas tienen acceso a
las últimas herramientas de análisis.

17. • Impacto de los desastres de mantenimiento.
• Integración del análisis estructurado con la inteligencia artificial.
Podemos adicionar que el futuro del análisis estructurado va a depender mucho también de que
tan rápido pueda ajustarse el mismo a los cambios tecnológicos que se viven hoy en día. Debido a
que han estado surgiendo otras técnicas en otras áreas como lo es la orientada a objetos, la cual
prevé un buen futuro y muchas mejoras para los sistemas actuales.
* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE*
Fue la aparición del diseño y la programación estructurada alrededor de los años 60´s la que
dieron cabida al surgimiento del análisis estructurado, ya que existía la necesidad de utilizar una
notación gráfica para representar los datos y los procesos que los transforman". Es por ello que
surgen una serie de temas afines tales como: herramientas automatizadas (CASE), prototipos,
diagramas de entidad-relación etc.
Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada por computadora),
elaboración de prototipos, símbolos gráficos, diccionarios de datos, descripciones de procesos y
procedimientos, reglas, diagramas de estados, diagramas de entidad-relación, diagramas de
transición de eventos, división de eventos, modelos esenciales y modelos de implantación.
* Métodos de Análisis Orientados al Flujo de Datos *
La información se transforma como un flujo a través de un sistema basado en computadora. El
sistema acepta entrada de distintas formas; aplica un hardware, software y elementos humanos
para transformar la entrada en salida; y produce una salida en distintas formas. La entrada puede
ser una señal de control transmitida por un transductor, una serie de números escritos por un
operador humano, un paquete de información transmitido por un enlace a red, o un voluminoso
archivo de datos almacenado en memoria secundaria. La transformación puede comprender una
sencilla comparación lógica, un complejo algoritmo numérico, o un método de inferencia basado
en regla de un sistema experto. La salida puede encender un sencillo led o producir un informe de
200 páginas. En efecto, un modelo de flujo de datos puede aplicarse a cualquier sistema basado
en computadora independientemente del tamaño o complejidad.
La función global del sistema se representa como una transformación sencilla de la información,
representada en la figura como una burbuja. Una o más entradas. Representadas como flechas
con etiqueta, conducen la transformación para producir la información de salida. Puede
observarse que el modelo puede aplicarse a todo el sistema o solo a un elemento de software. La
clave es representar la información dada y producida por la transformación.
* Diagramas de Flujos de Datos *
Conforme con la información se mueve a través del software, se modifica mediante una serie de
transformaciones. Un diagrama de flujos de datos (DFD), es una técnica grafica que describe el
flujo de información y las transformaciones que se aplican a los datos, conforme se mueven de la
entrada a la salida. El diagrama es similar en la forma a otros diagramas de flujo de actividades, y
ha sido incorporado en técnicas de análisis y diseños propuesto por Yourdon y Constantine,
DeMarco y Gane y Sarson. También se le conoce como un grafo de flujo de datos o un diagrama
de burbujas.

18. * Diccionario de Datos *
Un análisis del dominio de la información puede ser incompleto si solo se considera el flujo de
datos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos de
información. Por tanto, el analista debe disponer de algún otro método para representar el
contenido de cada flecha de un DFD.
Se ha propuesto el diccionario de datos como una gramática casi formal para describir el
contenido de los elementos de información y ha sido definido da la siguiente forma:
El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD, en
una especificación del proceso y en el propio diccionario de datos. Los datos compuestos (datos
que pueden ser además divididos) se definen en términos de sus componentes; los datos
elementales (datos que no pueden ser divididos) se definen en términos del significado de cada
uno de los valores que puede asumir. Por tanto, el diccionario de datos esta compuesto de
definiciones de flujo de datos, archivos [datos almacenados] y datos usados en los procesos
[transformaciones]...
* Descripciones Funcionales *
Una vez que ha sido representado el dominio de la información (usando un DFD y un diccionario
de datos), el analista describe cada función (transformación) representada, usando el lenguaje
natural o alguna otra notación estilizada. Una de tales notaciones se llama ingles estructurado
(también llamado lenguaje de diseño del programa o proceso(LDP)). El ingles estructurado
incorpora construcciones procedimentales básicas –secuencia, selección y repetición- junto con
frases del lenguaje natural, de forma que pueden desarrollarse descripciones procedimentales
precisas de las funciones representadas dentro de un DFD.
* Métodos Orientados a la Estructura de Datos *
Hemos ya observado que el dominio de la información para un problema de software comprende
el flujo de datos, el contenido de datos y la estructura de datos. Los métodos de análisis
orientados a la estructura de datos representan los requerimientos del software enfocándose
hacia la estructura de datos en vez de al flujo de datos. Aunque cada método orientado a la
estructura de datos tiene un enfoque y notación distinta, todos tienen algunas características en
común: 1) todos asisten al analista en la identificación de los objetos de información clave
(también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos);
2)todos suponen que la estructura de la información es jerárquica; 3)todos requiere que la
estructura de datos se represente usando la secuencia, selección y repetición; y 4) todos dan una
conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de
programa.
Como los métodos orientados al flujo de datos, los métodos de análisis orientados a la estructura
de datos proporcionan la base para el diseño de software. Siempre puede extenderse un método
de análisis para que abarque el diseño arquitectural y procedimental del software.