UNIDAD N° 1: SISTEMAS DE INFORMACIÓN:

 DEFINICIÓN:
SISTEMAS: En el sentido más amplio, un sistema es un conjunto de componentes que
interaccionan entre sí para lograr un objetivo común.
La finalidad de un sistema es la razón de su existencia. Para alcanzar sus objetivos, los sistemas
interactúan con su medio ambiente. Los sistemas trabajan mejor cuando operan dentro de
niveles de desempeño tolerables. Los componentes que forman un sistema pueden ser a su vez
sistemas más pequeños llamados subsistemas.
Para alcanzar sus objetivos, los sistemas interactúan con su medio ambiente el cual está formado
por todos los objetos que se encuentran fuera de las FRONTERAS DE LOS SISTEMAS:
-SISTEMAS: →ABIERTOS: interactúan con el medio (producen Entradas y Salidas
→CERRADOS: NO interactúan con el medio ambiente
Cada componente es un subsistema. Funcionan para alcanzar fines específicos.
Las 5 M: Componentes de un Empresa:
1- Materiales. 2- Maquinas. 3- Mano de Obra. 4- Métodos. 5- Medio Ambiente.
Elementos Básicos de Control en un Modelo de Sistemas:
FRONTERA DEL SISTEMA
COMPONENTES DEL SISTEMA

ENTRADA SALIDA

ACTUAL ESTANDAR

MEDIOS COMPARACIÓN

RETROALIMENTACIÓN DE LOS RESULTADOS DE LA COMPARACIÓN

Los propósitos/metas se alcanzan cuando se mantiene el control.
Elemento de CONTROL- Modelo de Control Básico:
1. un Estandar para lograr un desempeño aceptable.
2. Un método para medir el desempeño actual.
3. Un medio para comparar el desempeño actual contra el estándar.
4. Un método de retroalimentación (reporta las diferencias a los electos de control).
¿A qué se llama sistemas organizacionales?
Toda organización es un sistema, un sistema organizacional, y está compuesta por
subsistemas organizacionales. Todo sistema organizacional depende en mayor o menor grado de
entidades abstractas que son los sistemas de información. Un sistema de información muestra el
medio por el cual los datos fluyen de un departamento a otro (o de una persona a otra). Los
sistemas de información proporcionan servicios a todos los demás sistemas de la organización y
enlazan todos sus componentes de manera tal que trabajen con eficiencia para alcanzar los
objetivos de la organización.
Para mantener su funcionamiento, estos sistemas deben estar bajo control. De la comparación de
la información acerca de las salidas (funcionamiento actual) con estándares preestablecidos
resulta la retroalimentación la cual trae por objeto el control y por consiguiente la
autorregulación.
¿Por qué los analistas deben comprender los sistemas organizacionales antes de
desarrollar sistemas de información?
Dado que los sistemas de información dan soporte a los demás sistemas de la organización, los
analistas tienen primero que estudiar el sistema organizacional como un todo para entonces
definir de manera correcta los requerimientos de información y detallar sistemas de información
adecuados.
Por lo tanto, para diseñar y usar sistemas de información de manera eficaz, primeramente es
necesario entender el entorno, la estructura, la función y las políticas de las organizaciones así
como el papel de la administración y la toma de decisiones de ésta.
Lo primero que se realiza es conocer la organización para recién poder detallar los sistemas de
información que lo componen. El organigrama de una empresa visualiza la relación entre los
distintos departamentos, pero no son muy completas las conclusiones que se derivan de él. Se
requiere una mayor investigación y análisis de estas relaciones. Además, se requiere indagar
1
bastante de cómo fluye la información, como se comunican las distintas áreas y las relaciones
entre departamento.
El resultado de dicho estudio permitirá detectar hechos relevantes relacionados con la
actividad de la empresa, solucionar problemas, determinar requerimientos, etc.
El Analista podrá determinar cómo y dónde un Sistema de Información será benéfico para
todos los usuarios del sistema (Análisis) y se encargará de su desarrollo e implementación
(Diseño).
¿Por qué se considera que los sistemas de información son el soporte de los sistemas
organizacionales?
Desde el punto de vista de los negocios, un Sistema de Información es una solución de
organización y administración basada en la Tecnología de Información a un reto que surge del
Medio Ambiente.
Los sistemas de información juegan un papel estratégico en la vida de las empresas:
o Afectan de manera directa la toma de decisiones.
o Apoyan el control, análisis y visión en una institución.
o Permiten un mejor desempeño global de la institución dentro de una economía altamente
globalizada y basada en la información.
o Permiten realizar tareas en períodos más cortos de tiempo y con una mayor agudeza en la
toma de decisiones.
o Reducen los costos de producción ya que las empresas tienden a ser más pequeñas,
utilizando menos mano de obra y siendo más sofisticadas por las tecnologías.
o Reducen los costos operativos.
o En algunos casos, producen cambios en las estructuras de las empresas:
 Al incorporar un sistema de información se puede tener un fuerte control sobre el Nivel
Operativo (actividad a cargo del Nivel Medio). La estructura centralizada se transforma
en una estructura en la que sólo existen el 1º y 3º nivel.
 También puede suceder que los sistemas de información lleguen a remplazar al Nivel
Nivel Directivo

a) b)
Nivel Gerencial
Estructura
Centralizada.
Nivel Operativo
Operativo.
¿A qué se llama sistemas de información?
Un sistema de información es un conjunto de subsistemas utilizados (equipo especifico,
programas, archivos y procedimientos) es lo que se denomina APLICACIÓN de sistemas de
información.
Un sistema de información es un conjunto de componentes interrelacionados que capturan,
almacenan, procesan y distribuyen la información para apoyar la toma de decisiones, el control
de las operaciones, el análisis de los problemas, la creación de nuevos productos y servicios, y la
visión en una institución. Esto implica tres actividades:
a) Alimentación o insumo: la captura o recolección de datos primarios dentro de la
institución o de su entorno para procesarlos en un sistema de información.
b) Procesamiento: la conversión del insumo en forma que sea más comprensible para los
seres humanos.
c) Producto o salida: la distribución de información procesada a las personas o en las
actividades en donde será usada.
Los sistemas de información también requieren de retroalimentación que es el producto
regresado a los miembros adecuados de la institución para ayudarles a evaluar que el insumo sea
el correcto.
Por lo tanto, la finalidad básica de los sistemas de información es manejar las entradas,
procesar los datos almacenados relacionados con la organización y producir
información, reportes y otras salidas.
Los componentes de un Sistema de Información Basado en Computadoras son:

2
 o Hardware: es el equipo físico empleado para la alimentación, procesamiento y salida de un
S.I.
o Software: son las instrucciones detalladas, previamente programadas, que controlan y
coordinan los componentes del hardware de un sistema de información.
o Tecnología de Almacenamiento: incluye los medios físicos y lógicos para el
almacenamiento y organización de la información en un sistema de información.
o Tecnología de Telecomunicaciones: incluye los dispositivos lógicos y software que
enlazan diversos componentes de hardware y transfieren la información de un lugar a otro.
Estos componentes se denominan en conjunto una APLICACIÓN. Sirven como soporte de un
sistema ORGANIZACIONAL.
¿Cómo representar las relaciones de los diferentes componentes?
ORGANIGRAMAS: se emplean con frecuencia para describir la forma en que están relacionados
los diferentes componentes de la organización (divisiones, departamentos, oficinas y empleados).
El organigrama constituye el soporte de la información. Se construye en base al relevamiento de
las funciones (tareas que hace cada uno). Aunque los organigramas indican con precisión las
relaciones FORMALES entre los diferentes componentes NO dicen nada con respecto a la forma en
que opera el sistema Organizacional (NO plasma todos los detalles importantes).

 CATEGORÍAS:
El analista de sistemas desarrolla diferentes tipos de Sistemas de Información para satisfacer las
diversas necesidades de una empresa:
1- Sistemas para el procesamiento de transacciones (TPS) : sustituye los procedimientos
manuales por otros basados en computadora. Trata con procesos de rutina bien estructurados.
Incluye aplicaciones para el mantenimiento de registros.
Los TPS tienen como finalidad mejorar las actividades rutinarias de una empresa y de las que
depende toda la organización; brindan velocidad y exactitud; además, se pueden programar para
seguir rutinas sin ninguna variación.
-Una transacción es cualquier suceso o actividad que afecta a toda la organización.
-El procesamiento de transacciones (conjunto de procedimientos para el manejo de estas),
incluye las siguientes actividades: cálculos, clasificación, ordenamiento, almacenamiento y
recuperación, y generación de resúmenes.
Todas estas actividades forman parte del nivel operacional de cualquier organización. El
estudio de un grupo de organizaciones también muestra la existencia de características similares
entre ellas:
1. Gran volumen de transacciones.
2. Gran similitud entre las transacciones.
3. Los procedimientos para el procesamiento de transacciones están bien comprendidos y se
pueden describir con detalle.
4. Existen muy pocas excepciones a los procedimientos normales.
Estas características permiten establecer rutinas para el manejo de transacciones. Las rutinas
describen qué buscar en cada transacción, los pasos y procedimientos a seguir, y lo que debe
hacerse en caso de que se presente una excepción.
-Los procedimientos para el proceso de transacciones se denominan procedimientos de
operación estándar.(Brindan velocidad y exactitud, se pueden programar para seguir rutinas sin
ninguna variación.)
2- Sistemas de información administrativa (MIS): proporciona la información que será
empleada en los procesos de decisión administrativos. Trata con el soporte de situaciones de
decisión bien estructuradas. Es posible anticipar los requerimientos de información más comunes.
Los MIS ayudan a los directivos a tomar decisiones y a resolver problemas que se presentan
con regularidad; para hacerlo, se requiere de cierta información. Dado que los procesos de
decisión están claramente definidos, entonces se puede identificar la información necesaria para
formular las decisiones. Se pueden desarrollar sistemas de información para que, en forma
periódica, prepare reportes para el soporte de decisiones.
Con frecuencia, los especialistas en sistemas de información describen las decisiones apoyadas
por estos sistemas como decisiones estructuradas.
-El aspecto estructurado se refiere al hecho de que los administradores conozcan de antemano
los factores que deben tenerse en cuenta para la toma de decisiones así como las variables con
influencia más significativa sobre el resultado de una decisión (buena o mala), mediante reportes
bien estructurados: información + estado de variables importantes.
3- Sistemas para el soporte de decisiones (DSS) : proporciona información a los directivos
que deben tomar decisiones sobre situaciones particulares.

3
 No todas las decisiones son de naturaleza recurrente. Algunas se presentan sólo una vez o
escasamente. Los DSS ayudan a los directivos que deben tomar decisiones no estructuradas o
decisiones semiestructuradas: cuando no existen procedimientos claros para tomarla y tampoco
es posible identificar, con anticipación, todos los factores que deben considerarse en la decisión.
Por lo tanto, un factor clave en el uso de estos sistemas es determinar la información
necesaria. En estos casos es imposible diseñar de antemano tanto el formato como el contenido
de los reportes del sistema. En consecuencia, los DSS deben tener una flexibilidad mayor que la
de los demás sistemas de información.
El criterio de los directivos tiene un papel importante en la toma de decisiones donde el
problema no es estructurado. Los DSS ayudan pero no reemplazan el criterio del directivo.
Conclusión:
Es imposible construir un Sistema de Información Monolítico: un sistema de información único
que satisfaga las necesidades de la Organización en todos sus niveles y funciones.
Lo que existe en una Organización es un grupo de sistemas de información por áreas, cada
uno con su propia visión y finalidad. En conjunto forman el Sistema de Información de una
Organización.
Diferencias y Similitudes:
T.P.S. M.I.S. D.S.S.
Apoyan las actividades del
Nivel Operativo. Nivel Gerencial Nivel Directivo
Estructura de las Situaciones Decreciente
Mayor Menor
Procesos de rutina bien Situaciones de decisión bien Situaciones de decisión no
estructurados. estructuradas. estructuradas.
Necesidades de Información Recurrente Decreciente
Mayor Menor
Ya que atienden actividades Las situaciones son únicas (no
Rutinarias. Periódicas. recurrentes).
Se conoce la información necesaria. No se conoce la información
necesaria.

(VER pirámide del libro )

 ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN:

o CICLO DE VIDA:
o ETAPAS: ANÁLISIS ESTRUCTURADO, PROTOTIPOS

Razón de la existencia de diferentes estrategias:

Las tres estrategias tienen un uso en Organizaciones de todo tipo y tamaño, pero algunas se
adecuan más a la estructura y objetivos de una Organización particular, brindándole mayor
utilidad. Además, en algunos casos se puede determinar de manera secuencial los factores que
deben considerarse en el desarrollo del sistema de información, pero en otros, debe ganarse
experiencia por medio de la experimentación conforme el sistema de información evoluciona por
etapas.
El desarrollo de un sistema de información requiere de muchas actividades y del empleo de
herramientas y modelos.
La metodología del desarrollo de sistemas es una forma estándar de organizar y coordinar
éstas actividades. La metodología es un conjunto de actividades a seguir para obtener un
producto durante el proceso de desarrollo de software. También se refiere a las técnicas que se
deben utilizar para obtener cada producto, y a la determinación de roles y perfiles de gente
necesaria.
Existen tres enfoques para la metodología del desarrollo de sistemas:

Cuadro Resumen:

4
 Estrategi
Descripción Características de Aplicación
a
Incluye las actividades de: - Requerimientos de información predecibles.
1. Investigación Preliminar. - Manejable como proyecto.
2. Determinación de - Requiere que los datos se encuentren en
Requerimientos. archivos y bases de datos.
CICLO DE VIDA.

3. Diseño del Sistema. - Gran volumen de transacciones y

CLÁSICO DEL

4. Desarrollo de Software. procesamiento.

5. Prueba de los Sistemas.
6. Implantación y Evaluación.
Método
- Requiere de la validación de los datos de
entrada.
- Abarca varios departamentos.
- Tiempo de desarrollo largo.
- Desarrollo por equipos de proyecto.

- Adecuado para todo tipo de aplicaciones.

- Mayor utilidad como complemento de otros
métodos de desarrollo.
- Se enfoca en lo que el sistema - Adecuado para todo tipo de aplicaciones.
o aplicación1 realizan sin - Mayor utilidad como complemento de otros
importar la forma en que métodos de desarrollo.
ESTRUCTURADO.

llevan a cabo su función (se

ANÁLISIS

abordan los aspectos lógicos y

no los físicos).
- Emplea símbolos gráficos para
Método de

describir el movimiento y
procesamiento de datos.
- Los componentes importantes
incluyen los D.F.D. y el
Diccionario de Datos.
- Desarrollo iterativo o en - Se emplea ya que a veces los
continua evolución donde el requerimientos de información no siempre
usuario participa directamente están bien definidos.
DE SISTEMAS.

en el proceso. - Condiciones únicas en la aplicación donde

PROTOTIPO

los encargados del desarrollo tienen poca

experiencia o información, o donde los
costos y riesgos de cometer un error pueden
Método del

ser altos.
- Asimismo, útil para probar la factibilidad del
sistema, identificar los requerimientos del
usuario, evaluar el diseño de un sistema o
examinar el uso de una aplicación.

¿Qué es el ciclo de vida del proyecto?

El método del ciclo de vida del desarrollo de sistemas (SDLC) es el conjunto de actividades
que los analistas, diseñadores y usuarios realizan para desarrollar e implementar un sistema de
información. Es un modelo con forma de cascada; hace una partición del proceso de desarrollo en
seis etapas formales que deben ser recorridas en forma secuencial con una muy formal división
del trabajo entre los usuarios finales y los especialistas en el diseño de sistemas. El modelo en
cascada ha sido útil para ayudar a estructurar y gestionar grandes proyectos de desarrollo de
software dentro de las organizaciones.
Este método incluye las actividades de:
 Investigación Preliminar:
En la primera fase, el analista tiene que ver con la identificación de problemas,
oportunidades y objetivos. Requiere que el analista observe honestamente lo que está
sucediendo en la organización. Luego, junto con los demás miembros de la organización, el
analista hace resaltar los problemas.
Las oportunidades son situaciones que el analista considera que pueden ser mejoradas
por medio del uso de sistemas de información computarizados.
La identificación de objetivos es también un componente importante de la primera fase.

1
Aplicación: Conjunto particular de subsistemas utilizados por un sistema de información (equipo específico,
programas, archivos y procedimientos).
5
 La solicitud para recibir ayuda de un sistema de información puede originarse por varias
razones: el proceso se inicia siempre con la petición de una persona.
Cuando se formula la solicitud comienza la primera actividad de sistemas, la
investigación preliminar. Esta actividad tiene tres partes:
a) Aclaración de la solicitud. Muchas solicitudes que provienen de empleados y usuarios
no están formuladas de manera clara. Antes de considerar cualquier investigación de
sistemas, la solicitud de proyecto debe examinarse para determinar con precisión lo que
el solicitante desea.
b) Estudio de factibilidad. Un resultado importante de la investigación preliminar es la
determinación de que el sistema solicitado sea factible. Existen tres aspectos
relacionados con el estudio de factibilidad:
1. Factibilidad técnica: el trabajo para el proyecto, ¿puede realizarse con el equipo
actual, la tecnología existente de software y el personal disponible?. Si se necesita nueva
tecnología, ¿cuál es la posibilidad de desarrollarla?.
2. Factibilidad económica: al crear el sistema, ¿los beneficios que se obtienen serán
suficientes para aceptar los costos?, ¿los costos asociados con la decisión de no crear el
sistema son tan grandes que se debe aceptar el proyecto?.
3. Factibilidad operacional: si se desarrolla e implementa, ¿será utilizado el sistema?,
¿existirá cierta resistencia al cambio por parte de los usuarios que dé como resultado una
disminución de los posibles beneficios de la aplicación?.
La determinación de la factibilidad en general de un proyecto solicitado significa el
encontrar cuáles son los objetivos organizacionales, y luego determinar si el proyecto
sirve para mover a la empresa hacia sus objetivos en alguna forma. Algunos objetivos
del proyecto pueden ser
- Reducir errores, aumentar la velocidad y precisión en la entrada de datos.
- Reducir el costo de las salidas mediante la simplificación o eliminación de informes
duplicados o innecesarios.
- Integrar los subsistemas del negocio.
- Mejorar los servicios al cliente para lograr un mayor nivel competitivo.
- Acortar el tiempo de procesamiento de datos.
- Automatizar los procedimientos manuales para mejorarlos en alguna forma.
c) Aprobación de la solicitud. No todos los proyectos solicitados son deseables o
factibles. Aquellos proyectos que son deseables y factibles deben incorporarse en los
planes. Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo
necesario para terminarlo y las necesidades de personal; con esta información se
determina dónde ubicarlo dentro de la lista existente de proyectos.
¿En que consiste la investigación preliminar?
Si se va a desarrollar un sistema ya sea por el método del ciclo de vida clásico de sistemas,
por la estrategia de prototipos, por análisis estructurado o por una combinación de estos
métodos, primero es necesario revisar la solicitud de proyecto.
La finalidad de la investigación preliminar es evaluar las solicitudes de proyectos; es la reunión
de información que permite a los miembros del comité evaluar los méritos de la solicitud de
proyecto y emitir un juicio, con conocimiento de causa, con respecto a la factibilidad del proyecto
propuesto (¿la solicitud merece o no la inversión de recursos en un proyecto de sistemas de
información?).
Los analistas que trabajan en la investigación preliminar deben satisfacer los siguientes
objetivos:
a) Aclarar y comprender la solicitud del proyecto.
b) Determinar el tamaño del proyecto.
c) Evaluar los costos y beneficios de diversas opciones.
d) Determinar la factibilidad técnica y operacional de las diferentes alternativas.
e) Reportar los hallazgos a la administración y formular recomendaciones que esbocen la
aceptación o rechazo de la propuesta.
Conducción de la investigación.
Los datos recogidos durante las investigaciones preliminares se reúnen por medio,
principalmente, de dos métodos:

6
 REVISION DE LOS DOCUMENTOS DE LA ORGANIZACION. Los analistas deben aprender
primero acerca de la organización que está involucrada en, o que se verá afectada por, el
proyecto. Los analistas aprenden estos detalles por medio del examen del organigrama y el
estudio de los documentos que describen los procedimientos de operación.
 CONDUCCION DE ENTREVISTAS. Presentan el punto de vista de los usuarios; permitiendo
conocer más sobre la naturaleza de la solicitud del proyecto y la razón de someterlo a
consideración. Las entrevistas deben proporcionar detalles que más adelante expliquen el
proyecto y demuestren si la ayuda tiene méritos económicos, operacionales y técnicos.
Prueba de la factibilidad del proyecto.
Se estudian tres pruebas de factibilidad (la posibilidad de que el sistema sea de utilidad para la
organización):
- Factibilidad operacional. ¿Trabajará el sistema cuando esté terminado e instalado?.
¿Existen barreras importantes para la implantación?. Entre las preguntas a contestar están:
• ¿Existe apoyo suficiente para el proyecto por parte de la administración?, ¿Y por parte de
los usuarios?. Si el sistema en uso es bien visto y es utilizado por muchas personas que
no ven ninguna razón para efectuar cambios, entonces es probable encontrar resistencia
al cambio.
• ¿Los métodos que actualmente se emplean en la empresa son aceptados por los
usuarios?. Si no es así, entonces los usuarios darán la bienvenida a cualquier cambio que
permita tener un sistema más útil y operacional.
• ¿Los usuarios han participado en la planeación y desarrollo del proyecto?. La
participación temprana disminuye, en general, los riesgos de rechazo hacia el sistema y
el cambio; asimismo aumenta las posibilidades de éxito de los proyectos.
• ¿El sistema propuesto causará perjuicios?. ¿Producirá resultados pobres en algún aspecto
o área?. ¿Se perderá el control en alguna área?. ¿Se perderá la facilidad de acceso a la
información?. ¿La productividad de los empleados será menor después que antes de la
implantación?. ¿Los clientes se verán afectados en forma poco favorable?. ¿El sistema
reducirá la productividad de otras áreas?.
- Factibilidad técnica. Entre los aspectos técnicos que aparecen, figuran:
 ¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?.
 ¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos requeridos
para usar el nuevo sistema?.
 ¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin importar el
número y ubicación de los usuarios?.
 Si se desarrolla el sistema, ¿puede crecer con facilidad?.
 ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de
los datos?.
- Factibilidad financiera y económica. Un sistema que puede ser desarrollado desde el
punto de vista técnico y que, además, será utilizado si se llega a instalar, debe ser una
buena inversión para la organización. Los beneficios financieros deben igualar o exceder a
los costos. Se estima lo siguiente:
 El costo de llevar a cabo la investigación completa de sistemas.
 El costo del hardware y software para la aplicación que se está considerando.
 Beneficios en la forma de reducción de costos o de menos errores costosos.
 El costo si nada sucede (es decir, si el proyecto no se lleva a cabo).
Para ser considerada como factible la propuesta debe pasar todas las pruebas. De lo contrario,
el proyecto no es factible.
 Determinación de Requerimientos:
Consiste en comprender todas las facetas importantes de la parte de la empresa que se
encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores,
deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas
clave:
1) ¿Qué es lo que se hace?.
2) ¿Cómo se hace?.
3) ¿Con qué frecuencia se presenta?.
4) ¿Qué tan grande es el volumen de transacciones o de decisiones?.
5) ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?.
6) ¿Existe algún problema?.
7) Si existe un problema, ¿qué tan serio es?.
8) Si existe un problema, ¿cuál es la causa que lo origina?.

7
 Entre las herramientas utilizadas para definir los requerimientos 2 de información en la
organización se encuentran: muestreo e investigación de los datos relevantes, entrevistas,
cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y
hasta la elaboración de prototipos. Además, las investigaciones detalladas requieren el
estudio de manuales y reportes, la observación en condiciones reales de las actividades del
trabajo y, muestras de formas y documentos con el fin de comprender el proceso en su
totalidad.
Conforma se reúnen los detalles, los analistas estudian los datos sobre requerimientos
con la finalidad de identificar las características que debe tener el nuevo sistema, incluyendo
la información que deben producir los sistemas junto con características operacionales tales
como controles de procesamiento, tiempos de respuesta y métodos de entrada y salida.
Al término de esta fase, el analista debe comprender el por qué de las funciones de la
organización y tener información completa sobre las personas, objetos, datos y
procedimientos involucrados.
Actividades para la determinación de los requerimientos:
 Anticipación:
Se trata de prever las características del nuevo sistema (los requerimientos) con base a
la experiencia previa.
La experiencia previa puede ayudar en la conducción de la investigación hacia las áreas y
aspectos más importantes, pero si se introducen atajos, la Anticipación de Requerimientos
sólo provocará problemas.
 Investigación:
Es el estudio y documentación del sistema actual utilizando Técnicas para encontrar
hechos y estructurando la investigación según los Requerimientos Básicos.

INVESTIGACIÓN
 Entrevistas.
 Cuestionarios.
TÉCNICAS PARA ENCONTRAR  Revisión de registros
HECHOS  Observación.
 Muestreo.
 Medición del Trabajo Administrativo.

REQUERIMIENTOS BÁSICOS
 Actividades de la Organización.
 Estructura orgánica y puestos de trabajo.
 Documentos y archivos existentes.
 Medios de tratamientos de la información.
 Circulación de la información.

 Especificación:
Los datos obtenidos en la recopilación de hechos se analizan para determinar los
Requerimientos.
Tiene 3 partes relacionadas entre sí:
 ANÁLISIS de los datos (de los hechos reales) recopilados para determinar el desempeño
del sistema.

DIAGNÓSTICO
 Identificación de Requerimientos esenciales que van desde detalles de operación hasta
criterios de desempeño.

LISTA DE REQUERIMIENTOS
 Selección de Estrategias para cumplir los Requerimientos identificados. Estas estrategias
forman la base del diseño.

ALTERNATIVAS DE SOLUCIÓN
 Diseño del Sistema:
Esta actividad produce los detalles que establecen la forma en la que el sistema cumplirá
con los requerimientos identificados durante la fase de análisis. Los especialistas en
sistemas se refieren, con frecuencia, a esta etapa como diseño lógico.
Existe una distinción entre: Diseño General y Diseño Detallado. En el diseño general se
elaboran especificaciones conceptuales; también se decide la estructura del sistema, el
2
Requerimiento: es una característica que debe incluirse en un nuevo sistema.
8
 estilo global del mismo, el diseño arquitectónico, los componentes de hardware, software y
sus interfaces para establecer la estructura del sistema. El diseño detallado se ocupa de las
especificaciones precisas con respecto a las entradas, a las salidas, a los procesos que se
realizan, a los controles, a los archivos, etc. El diseño lógico es una de las partes del diseño
detallado.
Los analistas de sistemas comienzan el proceso de diseño identificando los reportes y
demás salidas que debe producir el sistema. Hecho lo anterior se determinan con toda
precisión los datos específicos para cada reporte o salida.
El diseño de un sistema también indica los datos de entrada, aquellos que serán
calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los
procedimientos de cálculo y los datos individuales. Los procedimientos que se escriben
indican cómo procesar los datos y producir las salidas.
Parte del diseño lógico es diseñar la interfaz de usuario. También incluye el diseño de
archivos bases de datos que guardarán la mayor parte de los datos necesarios para los
tomadores de decisiones de la organización.
Por último, el analista debe diseñar procedimientos de control y respaldo para proteger al
sistema y a los datos, y producir paquetes de especificaciones de software completas y
claramente delineadas para los programadores.
 Desarrollo de Software:
Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño
físico; ésta es otra de las partes del diseño detallado.
Los encargados de desarrollar software pueden instalar (o modificar y después instalar)
software comprado a terceros o escribir programas diseñados a la medida del solicitante. La
elección depende del costo de cada alternativa, del tiempo disponible para escribir el
software y de la disponibilidad de los programadores.
Los programadores también son responsables de la documentación de los programas y
de proporcionar una explicación de cómo y por qué ciertos procedimientos se codifican en
determinada forma. La documentación es esencial para probar el programa y llevar a cabo
el mantenimiento una vez que la aplicación se encuentre instalada.
 Prueba de Sistemas:
Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental
para asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo con
las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan
con entradas, conjuntos de datos de prueba, para su procesamiento y después se examinan
los resultados. Es mucho menos costoso encontrar problemas antes de que el sistema sea
entregado a los usuarios.
En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que
escribió los programas originales (asegurar que las pruebas sean completas e imparciales, y
que el software sea más confiable).
 Implantación y evaluación:
La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los
usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para
utilizarla.
Dependiendo del tamaño de la organización que empleará la aplicación y el riesgo
asociado con su uso, puede elegirse comenzar la operación del sistema sólo en un área de
la empresa. Algunas veces se deja que los dos sistemas, el viejo y el nuevo, trabajen en
forma paralela con la finalidad de comparar los resultados. En otras circunstancias, el viejo
sistema deja de utilizarse determinado día para comenzar a emplear el nuevo al día
siguiente.
Las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es
diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe
darse mantenimiento a las aplicaciones, realizar cambios o modificaciones en el software,
archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios.
El mantenimiento se realiza por dos razones:
a) Para corregir errores de software (los errores del software comercial son a veces
documentados como “anomalías conocidas”, y son corregidos cuando son lanzadas
nuevas versiones del software o versiones intermedias).
b) Para mejorar las capacidades del software en respuesta a las necesidades
organizacionales cambiantes y, por lo general, involucran algunas de las siguientes
tres situaciones:
- Los usuarios frecuentemente solicitan características adicionales después de que se
familiarizan con el sistema de cómputo y sus capacidades.

9
 - El negocio cambia a través del tiempo.
- El hardware y software están cambiando a un ritmo acelerado.
La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La
evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
 Evaluación operacional: valoración de la forma en que funciona el sistema, incluyendo
su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información,
confiabilidad global y nivel de utilización.
 Impacto organizacional: identificación y medición de los beneficios para la
organización en áreas tales como finanzas (costos, ingresos y ganancias), eficiencia
operacional e impacto competitivo. También se incluye el impacto sobre el flujo de
información interno y externo.
 Opinión de los administradores: evaluación de las actividades de directivos y
administradores dentro de la organización así como de los usuarios finales.
 Desempeño del desarrollo: la evaluación del proceso de desarrollo de acuerdo con
criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y
estándares, y otros criterios de administración de proyectos. También se incluyen la
valoración de los métodos y herramientas utilizadas en el desarrollo.

Desventajas del ciclo de vida clásico:

- Poco adecuado para los sistemas de escritorio.
- Este enfoque es muy costoso y consumidor de tiempo.
- Este enfoque es inflexible y desmotiva el cambio.
- Este enfoque es poco apropiado para las aplicaciones orientada a la toma de decisiones.
- El modelo en cascada asume que los requisitos de un sistema pueden ser congelados antes
de comenzar el diseño.
- Congelar los requisitos requiere seleccionar el hardware. La terminación de un gran
proyecto puede llevar años. Dada la velocidad de obsolencia de la tecnología es bastante
probable que el software final utilice un hardware obsoleto.
- En caso de sistemas no desarrollados para un cliente, como los productos software que
salen al mercado, los requisitos son determinados por los que lo desarrollan. En ese caso,
es deseable desarrollar primero una parte del sistema y posteriormente optimizarlo.
- Envía al cliente el primer producto solamente después de que se ha consumido el 99% de
los recursos para el desarrollo. Esto significa que la mayor parte de la retroalimentación del
cliente sobre sus necesidades se obtiene una vez que se han consumido los recursos.

Ventajas del ciclo de vida clásico:

- Se emplea para desarrollar sistemas con un gran procesamiento de operaciones y sistemas
de información para administración, en donde los requerimientos son altamente
estructurados y bien definidos. Permanece adecuado para sistema técnicos complejos.
- Adecuado cuando la nueva aplicación reemplaza a una ya existente y obsoleta (comparando
costos) ya que se conocen todas las especificaciones.
- Las etapas están organizadas de un modo lógico. Es decir, una etapa no puede llevarse a
cabo hasta que se hayan tomado ciertas decisiones de más alto nivel, debe esperar hasta
que esas decisiones estén tomadas.
- Cada etapa incluye cierto proceso de revisión y se necesita una aceptación del producto
antes de que la salida de la etapa pueda usarse.
- El ciclo es iterativo (reconoce problemas encontrados en etapas inferiores que afectan a las
decisiones de las etapas superiores).

Nota Introducción – Análisis Estructurado:

El objetivo que persigue al A.E. es organizar las tareas asociadas con la
determinación de requerimientos para obtener la comprensión completa y exacta de
una situación dada.
La palabra estructurado significa que:
1) el método intenta estructurar el proceso de determinación de los
requerimientos comenzando con la documentación del sistema existente.

10
 2) El proceso está organizado de tal forma que intenta incluir todos los detalles
relevantes que describen al sistema en uso.
3) Es fácil verificar cuando se han omitido detalles relevantes
4) La identificación de los requerimientos será similar entre varios analistas e
incluirá las mejores soluciones y estrategias para las oportunidades de
desarrollo de sistema.
5) Los documentos de trabajo generados para documentar los sistemas existentes
y propuestos son dispositivos de comunicación eficientes.

¿Qué es el análisis estructurado?

Es un método para el Análisis de Sistemas (manuales o automatizados) que conduce al
desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya
existentes.
Como varios analistas conducen la investigación estudiando los componentes del sistema en
forma independiente, es necesario que sigan un proceso estructurado. Estructurado significa que
las tareas asociadas con la Determinación de Requerimientos:
- Anticipación
- Investigación
- Especificación
• Análisis  Diagnóstico
• Identificación de Requerimientos  Lista de Requerimientos
• Selección de Estrategias  Alternativas de Solución
se organizan en forma tal que sea posible documentar el sistema existente con exactitud,
ejecutando cada etapa del proceso con eficacia (buscando los objetivos apropiados) y eficiencia
(correcta) para proponer las mejores alternativas de solución y generando a su vez documentos
(del sistema existente y del propuesto) que faciliten la comunicación entre analistas y usuarios.
En este método se enfoca en lo que el sistema o aplicación realizan sin importar la forma en
que llevan a cabo su función (se abordan los aspectos lógicos y no los físicos). Emplea símbolos
gráficos para describir el movimiento y procesamiento de datos.
Este método permite comprender de manera completa sistemas grandes y complejos por
medio de:
1) La división del sistema en componentes.
2) La construcción de un modelo del sistema.
El método incorpora elementos tanto del análisis como de diseño.
ANALISIS ESTRUCTURADO:
Se concentra en especificar lo que se requiere que haga el sistema o la aplicación.
Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de
los componentes físicos.
Los elementos esenciales del análisis estructurado son:
• Descripción gráfica: para describir un sistema se prepara un bosquejo que señale sus
características, identifique la función para la que sirve e indique cómo éste interactúa con
otros elementos.
En lugar de las palabras el análisis estructurado utiliza símbolos, o iconos, para crear un
modelo gráfico del sistema. Estos modelos muestran los detalles del sistema pero sin
introducir procesos manuales o computarizados, archivos en cinta o disco magnético, o
procedimientos operativos y de programas.
Los iconos identifican los elementos básicos de los procesos, el flujo de datos, el sitio
donde se almacenan los datos, y las fuentes y destinos de éstos. Se dibuja una línea
alrededor del sistema para señalar que elementos se encuentran dentro del sistema y
cuáles fuera de su frontera.
El diagrama lógico de flujo de datos muestra las fuentes y destinos de los datos,
identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los
grupos de datos que relacionan una función con otra y señala los almacenes de datos a los
que se tiene acceso.
• Diagramas de flujo de datos: la descripción completa de un sistema está formada por un
conjunto de diagramas de flujo de datos –DFD-.

11
 Con este método se sigue un proceso descendente (top-down). El modelo original se
detalla en diagramas de bajo nivel que muestran características adicionales del sistema.
Cada proceso puede desglosarse en DFD cada vez más detallados. Esta secuencia se repite
hasta que se obtienen suficientes detalles que permiten al analista comprender en su
totalidad la parte del sistema que se encuentra bajo investigación.
Los DFD son símbolos que me muestran como fluyen los datos dentro de la organización.
Datos en
Flujo de reposo
datos Datos de pedido Almacén de datos
Entidades Cliente Pedido
Recep
externas Nota de cionar
pedido pedid
o Confe Depósito
Datos en Pedido cciona
movimiento aceptado
r Factura
factur
a

• Diccionario de datos: todas las definiciones de los elementos en el sistema (flujos de datos,
procesos y almacenes de datos) están descritos en forma detallada en el diccionario de
datos.

COMPONENTES DEL ANALISIS ESTRUCTURADO:

1) Símbolos Gráficos: íconos y convenciones para identificar y describir los
componentes de un sistema junto con las relaciones entre estos componentes.
2) Diccionarios de Datos: descripciones de todos los datos utilizados en el sistema.
Puede ser manual o automatizado (y estar incluido en el diccionario de un
proyecto más grande que quizás contenga las descripciones de los procesos que
integran el sistema)
3) Descripciones de procesos y procedimientos: declaraciones formales que
emplean técnicas y lenguajes que permiten a los analistas describir actividades
importantes que forman parte del sistema
4) Reglas: estándares para describir y documentar el sistema en forma correcta y
completa.

DISEÑO ESTRUCTURADO:
Es otro elemento del análisis estructurado que emplea la descripción gráfica, se enfoca en el
desarrollo de especificaciones del software. La meta del diseño estructurado es crear programas
formados por módulos independientes unos de otros desde el punto de vista funcional.
La herramienta fundamental del diseño estructurado es el diagrama estructurado. Su finalidad
no es mostrar la lógica de los programas, sino describen la interacción entre módulos
independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.
Conclusión:
En el Análisis Estructurado: modelo el nuevo sistema mediante un conjunto de D.F.D.  En el
Diseño Estructurado: especifico los programas que tendrá el nuevo sistema.
Métodos del ciclo de vida y de análisis estructurado:
 Diferencia Fundamental:
ANÁLISIS ESTRUCTURADO  es adecuado para todo tipo de situaciones.
Método del CICLO DE VIDA  es adecuado para desarrollar aplicaciones que implican un
análisis riguroso y formal de requerimientos, especificaciones predefinidas y sólidos
controles sobre el desarrollo de sistemas.
 Combinación:
Ambos métodos suelen combinarse: por ejemplo, se puede optar por desarrollar D.F.D.
como una forma para documentar las relaciones entre componentes durante la
investigación detallada de algún sistema o se pueden definir los archivos y datos en un
Diccionario de Datos centralizado.
Desventajas de la Combinación:
 El desarrollo de diagramas y esquemas consume mucho tiempo, sobre todo si el sistema es

grande y complejo. Solución  Herramientas asistidas por computadora (Ej.: Easy Case).
 Se omiten elementos importantes que forman parte del sistema (Ej.: personas,
procedimientos de control).

12
 Análisis de Flujo de Datos: concepto. Herramientas del análisis de flujo de datos: diagrama de
Flujo de Datos, Diccionario de Datos, Diagramas de Estructura de Datos y Gráfica de
Estructura. Notación Yourdon y Gane-Sarson.
ANÁLISIS DE FLUJO DE DATOS:
Es una herramienta para:
- documentar el sistema existente y
por medio del Método de Análisis
- determinar los Requerimientos de
Estructurado.
información

Para la comprensión de los Requerimientos de información los analistas deben conocer el papel
central que tienen los datos y ser capaces de conceptualizar la forma en que se mueven a través
de la organización (cómo entran, son procesados, almacenados, recuperados, analizados,
utilizados, cambiados y presentados como salidas).
El Análisis de Flujo de Datos permite esto logrando una REPRESENTACIÓN GRÁFICA que
enfatiza la lógica subyacente del sistema.
HERRAMIENTAS DEL ANÁLISIS DE FLUJO DE DATOS:
Ayudan a ilustrar los componentes esenciales del sistema junto con sus iteraciones. Abarcan
tanto la Determinación de Requerimientos como el Diseño de sistemas.
1. DIAGRAMAS DE FLUJO DE DATOS (D.F.D.):
Utilizan símbolos para describir y analizar el movimiento de los datos a través del sistema.
Según el enfoque que utilizan pueden ser
LÓGICOS:
Independientes de la implantación  Se concentran en especificar lo que se requiere que el
sistema haga.
FÍSICOS:
Dependientes de la implantación  Se concentran en especificar cómo se implementará el
sistema.
2. DICCIONARIO DE DATOS:
Contiene las características lógicas del almacenamiento de los datos (nombre, descripción,
alias, contenidos y organización), la descripción de flujos y especificación de procesos que
utiliza el sistema.
Sirve como punto de partida para identificar los requerimientos de las Bases de Datos en el
diseño del sistema.
3. DIAGRAMA DE ESTRUCTURA DE DATOS:
Describe la relación entre entidades (personas, lugares, eventos y objetos) de un sistema y
el conjunto de información relacionada con la entidad.
No considera el almacenamiento físico de los datos.
4. GRÁFICA DE ESTRUCTURA:
Muestra mediante símbolos la relación entre los módulos de procesamiento y el software de
la computadora.
Describe la jerarquía entre módulos y los datos transmitidos entre ellos.
Incluye el análisis de las transformaciones Entrada - Salida de transacciones.
Las primeras 2 herramientas se usan durante la Determinación de Requerimientos, las 2
últimas en el Diseño.
NOTACIÓN YOURDON Y GANE-SARSON:
Notación
Notación
ELEMENTO GANE -
YOURDON
SARSON
FLUJO DE DATOS:
Movimiento de datos en determinada dirección desde un origen
hacia un destino en forma de documentos, cartas, llamadas
telefónicas o virtualmente por cualquier otro medio.
PROCESO:
Personas, procedimientos o dispositivos que utilizan o producen
(transforman) datos. No se identifica el componente físico.

FUENTE O DESTINO DE DATOS (ENTIDAD):

Pueden ser personas, programas, Organizaciones u otras
entidades externas que interactúan con el sistema.
ALMACEN DE DATOS:
El lugar donde se guardan los datos, ya sean dispositivos
13
 computarizados o no. (No se incluyen los almacenamientos
temporales).
Cada elemento posee una etiqueta con un nombre descriptivo.
En el caso de los procesos la etiqueta es un Nombre y un Número (no tiene que ver con la
secuencia de procesos, indica el Nivel al que pertenece el proceso).
VENTAJAS DEL ANÁLISIS DE FLUJO DE DATOS:
-La fácil comprensión de la notación permite el trabajo conjunto con los usuarios (se pueden
prevenir errores).
-El enfoque lógico permite conceptualizar el sistema en forma independiente a la
implementación física.
-Los diagramas de alto nivel permiten una visión general de todo el sistema y los diagramas de
bajo nivel permiten aislar áreas de interés y obtener mayores detalles.
-Muestra las actividades en forma concurrente lo que permite reflejar la naturaleza dinámica 3
del sistema real y, por lo tanto, representarlo con mayor exactitud (el objetivo del Análisis
de Flujo de Datos es estudiar el movimiento de los datos).
Desarrollo de Diagramas de Flujo de Datos: Diagrama de Contexto, Expansión de Procesos.
DIAGRAMAS DE FLUJO DE DATOS - DESARROLLO:
Se sigue la técnica TOP - DOWN de Análisis Descendente (de lo general a lo específico); el
modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del
sistema. Cada proceso se desglosa en D.F.D. más detallados hasta llegar a un nivel en el que se
comprenda en su totalidad la parte del sistema que se investiga.
PASOS:
1. Estudiar y listar las actividades de la Organización para determinar:
- Entidades Externas.
- Flujos De Datos.
- Procesos.
- Almacenes De Datos.
utilizando las Técnicas para encontrar hechos.
2. Crear un DIAGRAMA DE CONTEXTO que muestre las Entidades Externas y los Flujos de
Datos que entran y salen del sistema. No mostrar ningún proceso detallado ni almacenes de
datos.
3. Trazar el DIAGRAMA 0. Mostrar en forma general los procesos junto con los almacenes que
utiliza.
4. Crear un DIAGRAMA HIJO para cada uno de los procesos del Diagrama 0.
5. Revisar buscando errores y asegurándose que las etiquetas asignadas a cada proceso y flujo
de datos son significativas.
6. Desarrollar un D.F.D. FÍSICO a partir del D.F.D. LÓGICO. Distinguir entre procesos
manuales y automatizados. Describir los archivos actuales y los reportes por nombre y
añadir controles para indicar cuándo terminan los procesos o suceden errores.
7. Dividir el D.F.D. físico separando o agrupando partes del diagrama para facilitar la
programación e implantación.
EXPLICACIÓN:
2. DIAGRAMA DE CONTEXTO:
Es el Diagrama de más Alto Nivel que muestra las características generales del Proceso
que representa al sistema completo ( Etiqueta de la burbuja: Nombre: SISTEMA DE
Nombre_Proceso. Número: 0).
Define el sistema que va a ser estudiado determinando sus fronteras.
Muestra las Entidades Externas (que si bien en el estudio no interesan y se encuentran
fuera de nuestro control, es necesario mostrar su interacción con el sistema) y los Flujos de
Datos que entran y salen del sistema.
No muestra ningún proceso detallado ni almacenes de datos (Sólo se pueden mostrar los
Almacenes de Datos que son compartidos con las Entidades Externas).
Las entradas y salidas especificadas en este nivel deben permanecer constantes en los
diagramas subsecuentes.
3. DIAGRAMA 0 (Diagrama de 1º Nivel):
Detalla el Proceso del Diagrama de Contexto.
Muestra en forma general los procesos que forman el Proceso de Nivel 0.
Etiqueta:

3
Naturaleza Dinámica (naturaleza funcional): el sistema real cumple funciones que se manifiestan por el desarrollo de un
número de procesos coordinados entre sí para alcanzar ciertos objetivos.
14
 Nombre: Usa un formato VERBO - NOMBRE - ADJETIVO. El VERBO indica la función del
proceso, el NOMBRE cuál será la salida principal y el ADJETIVO la salida específica. Ej.:
Imprimir - Reporte - de Inventario.
Número: Proceso 1.0, Proceso 2.0, etc.
Es importante enfatizar la atención en los Flujos de Datos entre los procesos.
Debe ser CONSISTENTE con el Diagrama de Contexto (mantener los Flujos y las
Entidades Externas).
Puede incluir nuevos Almacenes y Flujos de Datos.
4. DIAGRAMAS HIJOS:
Se describe con mayor detalle cada uno de los procesos del Diagrama 0 (si es necesario).
Etiqueta:
Nombre: formato VERBO - NOMBRE - ADJETIVO.
Número: Proceso 1.1, Proceso 1.2, etc. (Número_Padre . NúmeroProceso).
Deben cumplir con la Regla de Balanceo Vertical (o Consistencia): un Diagrama Hijo no
puede Producir Salida o Recibir Entrada que el proceso padre no produzca o reciba. (Se
deben mostrar todos los Flujos del padre).
Si pueden incluir nuevos Almacenes (Ej.: de transacciones) y Flujos de datos de bajo
nivel (los utilizados dentro del proceso y por ejemplo los de errores).
Generalmente no muestran las Entidades Externas (sólo los Flujos de E-S con ellas).
5. EVALUACIÓN DE LOS D.F.D.:
Implica revisar buscando errores y asegurándose que las etiquetas asignadas a cada
proceso y flujo de datos son significativas.
Las siguientes situaciones indican posibles errores:
- Inconsistencias.
- Elementos sin nombre.
- Almacenes a los que nunca se hace referencia.
- Conexión directa entre Almacenes y Entidades Externas (deben conectarse solamente
con el proceso).
- Procesos con varias finalidades (se deben dividir).
- Procesos sin Flujos de entrada o sin Flujos de salida.
- Flujos incoherentes con los procesos.
- Flujos que se dividen en 2 o más Flujos diferentes (sin pasar por un proceso).
- Demasiados datos en el Diccionario.
Y demás situaciones que no cumplen con las reglas de construcción.
Se debe tener en cuenta que en algunos casos no se puede tratar de errores sino de
deficiencias del sistema o falta de información.
6. Desarrollar un D.F.D. FÍSICO a partir del D.F.D. LÓGICO.
Distinguir entre procesos manuales y automatizados. Describir los archivos actuales y los
reportes por nombre y añadir controles para indicar cuándo terminan los procesos o
suceden errores.
Idealmente, los sistemas son desarrollados analizando el sistema actual (el D.F.D. lógico
actual) y añadiendo después características que debe incluir el nuevo sistema (el D.F.D.
lógico propuesto). Por último se desarrollan los mejores métodos para implementar el
nuevo sistema (D.F.D. físico).
A veces se omite el primer paso (por cuestión de tiempo) construyendo directamente el
D.F.D. lógico propuesto. Los beneficios de no omitirlo son:
- Se conservan las características esenciales del sistema antiguo en el nuevo.
- Se obtiene una transición gradual para el diseño del nuevo sistema.
7. Partición de los D.F.D.:
Cada proceso es analizado para determinar si debe ser un procedimiento manual o
automatizado.
Los procesos automatizados son agrupados subsecuentemente en una serie de
programas diseñados para ser por lotes4 o en línea5.
Se debe considerar si:
a) Hay procesos ejecutados por diferentes grupos de usuarios;
b) Hay procesos que se ejecutan al mismo tiempo;
c) Hay procesos que ejecuten tareas similares;
d) Los procesos por lotes pueden ser combinados para un procesamiento eficiente (Ej.:
un programa para la confección de varios reportes que utilizan los mismos archivos);
4
Proceso por Lotes: los datos del proceso, tanto de E como de S, están compuestos completamente por información
almacenada, generada y accesada por la computadora que no requiere intervención humana.
5
Proceso en Línea: requiere la interfaz con el usuario.
15
 e) Los procesos pueden ser combinados en un programa para tener consistencia de datos
(Ej.: Imprimir Reporte de Deudas e Imprimir Notificaciones de Deuda para enviar a los
clientes; si se actualiza la B.D. entre estos procesos, los datos serán inconsistentes);
f) Los procesos pueden ser partidos en diferentes programas por razones de seguridad.
D.F.D. LÓGICOS Y FÍSICOS:
D.F.D. LÓGICOS D.F.D. FÍSICOS
MODELAN:
Cómo funciona la Organización. Describen los Cómo será implementado el sistema (o cómo
eventos junto con los datos que requieren y opera el sistema actual), incluyendo el
producen. hardware, software, archivos y personas
involucradas en el mismo.
(Se agregan procesos: ej.: ABM de registros,
validación)
Cada PROCESO representa:
Una actividad. Programas, módulos de programas y
procedimientos manuales.
Cada ALMACÉN representa:
Conjunto de datos sin tomar en cuenta la Archivos y Bases de Datos físicos, archivos
forma de almacenamiento. manuales.
Tipo de Almacenes de datos:
Almacenes permanentes (Maestros). Archivos maestros y de transacciones.
Cualquier proceso que opera en 2 momentos
diferentes debe estar conectado por un
Almacén de datos (frecuentemente de
transacciones: guarda datos entre procesos).
CONTROLES del sistema:
Muestra controles de la Organización. Muestra controles para la validación de datos
de Entrada, para la obtención de un registro,
para asegurar la terminación satisfactoria de
un proceso y para la seguridad del sistema
(Ej.: registro de eventos).
VENTAJAS:
D.F.D. LÓGICOS D.F.D. FÍSICOS
1. Mejor comunicación con los usuarios. 1. Diferencian procesos manuales de
2. Sistemas más estables (no se basan en un automatizados.
método de implementación particular). 2. Detallan más los procesos (a comparación
3. Mejor comprensión de la Organización por con los lógicos).
los analistas. 3. Secuencian los procesos que deben
4. Flexibilidad de mantenimiento. ordenarse.
5. Eliminación de redundancias y creación más 4. Identifican Almacenes de datos temporales.
fácil del modelo físico. 5. Especifican los nombres actuales de
archivos e impresiones.
6. Añaden controles para asegurar la correcta
realización de los procesos.
REGLAS PARA EL DIBUJO DE D.F.D. LÓGICOS:
1. Todos los nombres de los Flujos de Datos deben reflejar los datos que fluyen entre
procesos, almacenes, fuentes o destinos.
2. Sólo deben entrar al proceso los datos que necesita para llevarse a cabo.
3. Los procesos deben ser independientes entre sí (no conocer nada uno del otro).
4. Los procesos deben estar en continua ejecución (se debe suponer que siempre están listos
para funcionar).
5. Cualquier Flujo de Datos que abandone un proceso debe estar basado en los datos que
entran al proceso.
6. Todos los Flujos de Datos deben iniciarse o terminar en un proceso (Ej.: Proceso 
Almacén; Entidad Externa  Proceso).
7. Los procesos denotan un cambio o transformación de datos, y por lo tanto, sus salidas
deben transformar los Flujos de entrada tomando una de las siguientes formas:
- Flujo de datos con mayor información.
- Respuesta o Cambio en la forma de los datos (Ej.: de U$S a porcentajes).
- Cambio de Condición (de no autorizado a autorizado).

16
 - Cambio de Contenido (integración o separación de la información contenida en 1 o más
Flujos de entrada).
- Cambio en la organización (reacomodo de datos).
EXPANSIÓN DE PROCESOS:
Las explosiones se realizan hasta que se llega a comprender completamente cada proceso.
Lineamiento: Un proceso por tarea (una finalidad).
En los 2 o 3 primeros niveles se ignora el manejo de excepciones y errores.
Algunos analistas trabajan primero con todos los Flujos asignándoles nombres significativos.
Identifican todos los procesos pero no los nombran hasta que están bien comprendidos todos los
Flujos. Si después de nombrar los procesos encuentran dificultades para ligarlos con los Flujos 
esta situación indica que es necesario dividir aún más el proceso.
Generalmente se deben emplear entre 3 y 7/9 procesos (ocupando una hoja de papel) para la
explosión. Si se supera este número será difícil de manejar y dibujar, y perderá su utilidad.
Si se utiliza una herramienta automatizada, las restricciones anteriores pueden ser
innecesarias. Sin embargo los Flujos de Datos deben estar escritos en forma SIGNIFICATIVA.
Diccionario de Datos: Construcción.
Un diccionario de datos contiene las definiciones de todos los Elementos que forman parte del
flujo de datos en el sistema:
-Flujos de Datos.
-Almacenes de Datos.
-Procesos.
Contiene los "datos de los datos" (Metadatos) que utiliza el sistema.
Se desarrolla durante el Análisis de Flujo de Datos y también sirve durante el Diseño del
sistema.
Para su construcción se toman como base los D.F.D.
Pueden ser manuales o automatizados. Si bien los automatizados producen glosarios de datos,
listados cruzados y reportes de errores con un considerable ahorro de tiempo a comparación de
los manuales, son muy costosos.
IMPORTANCIA:
Permite:
1. MANEJAR LOS DETALLES EN SISTEMAS GRANDES: al tener registrada toda la información.
2. COMUNICAR UN SIGNIFICADO COMÚN: coordinando las definiciones y evitando
suposiciones entre todos los analistas que trabajan en el sistema.
3. DOCUMENTAR LAS CARACTERÍSTICAS DEL SISTEMA: La descripción formal de las
características del sistema proporciona una comprensión más completa de éste.
4. FACILITAR EL ANÁLISIS DE LOS DETALLES CON LA FINALIDAD DE EVALUAR LAS
CARACTERÍSTICAS Y DETERMINAR DÓNDE EFECTUAR CAMBIOS:
Las características a evaluar son:
 Naturaleza de las Transacciones: Las actividades de la Organización que se llevan a
cabo mientras se emplea el sistema, incluidos los datos necesarios para aceptar,
autentificar y procesar cada actividad.
 Consultas: Solicitudes para la recuperación o procesamiento de información para
generar una respuesta específica.
 Salida y generación de Reportes: Resultados del procesamiento que son presentados
al usuario en un formato adecuado.
 Archivos y Bases de Datos: Detalles de las transacciones y registros maestros que son
de interés para la Organización.
 Capacidad: Habilidad del sistema para aceptar, procesar y almacenar transacciones y
datos.
5. LOCALIZAR ERRORES Y OMISIONES EN EL SISTEMA.
ELEMENTOS Y ESTRUCTURAS DE DATOS
Definición: Un ELEMENTO DE DATOS (o CAMPO) es la unidad más pequeña con significado.
Ej.: Fecha de la Factura.
Son los bloques básicos para todos los demás datos del sistema.
El formulario de Descripción de Elemento debe contener:
1. ID (Opcional).
2. NOMBRE DESCRIPTIVO ÚNICO.
Debe ser comprensible y significativo.
Algunas Organizaciones imponen estándares para la definición de Nombres (que
generalmente imitan los estándares de los Lenguajes de Programación usados).
3. ALIAS.

17
 Son los distintos nombres que recibe un mismo dato. Ej.: Nota de Pedido  Orden de
Compra.
4. DESCRIPCIÓN.
Indica de manera breve lo que el dato representa en el sistema.
Debe escribirse de manera que todas las palabras sean comprensibles para cualquier lector.
5. Si el ELEMENTO es BÁSICO o DERIVADO.
Elemento BÁSICO: es proporcionado como entrada.
Elemento DERIVADO: es creado por un proceso como resultado de alguna operación.
6. LONGITUD.
Identifica el número de espacios necesarios para cada dato sin considerar la forma en que
serán almacenados.
Estándar: no mayor que 30 caracteres (sin espacios en blanco).
7. TIPO.
Alfabético, alfanumérico, numérico, fecha, monetario, etc.
8. FORMATO DE ENTRADA Y SALIDA.
Ej.: Nº de Orden de compra: formado por un Prefijo que indica el departamento que la
generó + Nº Orden.
 Nº de Orden de compra: A9999
9. CRITERIOS DE VALIDACIÓN.
Un Elemento puede ser:
- Discreto: con determinados valores fijos.
 se deben indicar los Valores y sus Significados.
- Continuo: con un rango de valores.
 se debe indicar el Límite Superior y el Límite Inferior.
10. VALOR POR OMISIÓN.
Es desplegado en las pantallas de captura y usado para reducir la cantidad de tecleo que
pueda tener que hacer el operador.
11. Área de Comentarios adicionales u OBSERVACIONES.
Ejemplo:

Descripción de Elemento de Datos

ID
Nombre Número de Cliente
Alias Número de cuenta por cobrar
Descripción Identifica de manera única a un cliente que ha hecho
cualquier transacción de negocios en los últimos 5 años.
Características

Longitud 6 Decimales
Formato de Entrada 9(6)
Formato de Salida 9(6)
Valor por omisión

 Básico  Derivado
Tipo:
 Alfanumérico  Alfabético  Numérico  Fecha  Monetario
Criterios de Validación

 Continuo  Discreto
Límite Inferior < 999999 Valor Significado
Límite Superior >0

Debe pasar una prueba de dígito verificador módulo

Comentarios 11.

18
 Definición: Una ESTRUCTURA DE DATOS (o REGISTROS) Es un grupo de ELEMENTOS DE
DATOS relacionados que juntos describen un componente del sistema. Ej.: Factura.
RELACIONES ESTRUCTURALES:
SECUENCIAL:
Define la concatenación de 2 o más datos.
Pueden contener otras estructuras de datos.
Ejemplo:
Estructura: DATOS DEL ESTUDIANTE
Elementos:
NOMBRE
NOMBRE DE PILA
APELLIDO
DIRECCIÓN
TELÉFONO
DE SELECCION (uno u otro):
Define alternativas (2 o más) para datos incluidos en una Estructura de Datos.
Ejemplo:
Estructura: DATOS DEL ESTUDIANTE
Elementos:
NOMBRE
APELLIDO
DIRECCIÓN
TELÉFONO
y uno de los siguientes
Nº DE MATRÍCULA
Nº DE SEGURO SOCIAL
ESTADO
uno de los siguientes
GRADUADO
NO GRADUADO
DE ITERACION (repetitiva):
Define la repetición de un componente 0 o más veces (algunas veces se define el mínimo y
el máximo de iteraciones).
Ejemplo:
Estructura: INSCRIPCIONES
Elementos:
PERIODO
AÑO
ESTUDIANTE
Desde una y hasta siete iteraciones de MATERIAS
CLAVE
NOMBRE
HORARIO
PROFESOR
OPCIONAL:
Es un caso especial de la Relación de Iteración; los datos pueden estar o no incluidos (0 o 1
iteración).
Ejemplo: Nombre del cónyuge, Especialización, etc.
NOTACIÓN:
Se utilizan símbolos especiales para minimizar la cantidad de texto necesario en las
descripciones.
SÍMBOLO SIGNIFICADO USO
= Compuesto de.
+ Y (Concatenación). Relación de
Secuencia.
[] Uno u otro. Relación de Selección.
{} Iteración. Relación de Iteración.
() Opcional. Relación Opcional.
** - Comentarios.
Ejemplo:
Cliente = Número de cliente +
Nombre de cliente +
19
 Dirección +
Teléfono
FLUJOS Y ALMACENES DE DATOS
Definición: El formulario de Descripción de FLUJO DE DATOS debe contener:
1. ID, número de identificación (Opcional).
2. Nombre descriptivo único. Es el texto que aparece en el diagrama.
3. Descripción general.
4. Origen.
5. Destino.
6. Una indicación de si el Flujo es un Registro de un Archivo o contiene un Reporte,
Formulario, Pantalla o Interno (usado entre procesos).
7. Nombre de la Estructura de Datos describiendo sus Elementos.
8. Volumen por unidad de tiempo. (Ej.: Registros por día).
9. Área de Comentarios adicionales u Observaciones.
Ejemplo:

Descripción del Flujo de Datos

ID
Nombre Pedido de cliente
Contiene información del pedido del cliente y es
Descripción usada
para actualizar los archivos maestro de clientes y de artículo para
producir un registro de pedido.
Origen Destino

Tipo de flujo de datos

 Archivo  Pantalla  Reporte  Formulario  Interno
Estructura de datos viajando con el Flujo Volumen/tiempo
Información del pedido 10/hora

Comentarios La información de un registro de pedido para un pedido

de cliente. El pedido puede ser recibido por correo, fax o por
llamada
telefónica directa del cliente al departamento de procesamiento de
pedidos.

Definición: El formulario de Descripción de ALMACÉN DE DATOS debe contener:

1. ID. Es una entrada obligatoria para prevenir la redundancia.
2. Nombre descriptivo único.
3. Alias.
4. Descripción.
5. Tipo de Archivo (Manual o Computarizado).
6. Formato (en caso de ser Computarizado).
Base de Datos o archivo tradicional (Indexado, Secuencial, Directo).
7. Cantidad máxima y promedio de registros en el archivo. Crecimiento anual.
Esta información ayuda al analista a predecir la cantidad de espacio de disco requerida para la
aplicación, y es necesaria para la planeación de adquisición de hardware.
8. Nombre de Juego de Datos.
Especifica el nombre del archivo, en caso de ser conocido.
9. Nombre de la Estructura de Datos.
Proporciona un enlace a los Elementos que contiene definidos en el Diccionario de Datos.
Las claves primaria y secundaria deben ser Elementos de la Estructura.
10. Área de Comentarios adicionales u Observaciones.
Ejemplo:

20
 Descripción del Almacén de Datos

ID D1
Nombre Archivo maestro de clientes
Alias Archivo maestro de consumidores
Descripción Contiene un registro para cada cliente

Características

Tipo  Manual  Computarizado

Formato  Indexado  Secuencial  Directo  Base de Datos
Tamaño de registro (caracteres) 200 Tamaño de bloque: 4000
Cantidad de Registros: máximo 45000 Promedio: 42000
Por ciento de crecimiento anual: 6 %

Nombre del Juego de Datos

Miembro para copia
Estructura de Datos
Clave Primaria
Claves Secundarias
Registro de Cliente
Nombre del Cliente
Nombre del Cliente
Código postal
Cantidad comprada en el año

Comentarios Un cliente puede ser conservado aunque no haya hecho

compras pero haya pedido un catálogo.

PROCESOS
Definición: El formulario de Descripción de PROCESO debe contener:
1. Número de proceso (debe corresponder con el ID de proceso en el D.F.D.).
2. Nombre (debe corresponder con el del D.F.D.).
3. Descripción.
4. Entrada (Flujos de Entrada usando los nombres del D.F.D. y del Diccionario de Datos).
5. Salida (Flujos de Salida usando los nombres del D.F.D. y del Diccionario de Datos).
6. Indicación del Tipo de Proceso (por Lote, en Línea o Manual).
Todos los procesos en línea requieren diseño de pantalla, y todos los procesos manuales deben
tener procedimientos bien definidos para los empleados que ejecutan las tareas del proceso.
7. Resumen de la Lógica del proceso (especificación (español estructurado)).
8. Si hay suficiente espacio en el formulario para una descripción completa en lenguaje
estructurado, o si hay una Tabla o Árbol de decisión mostrando la lógica, incluir el nombre
correspondiente.
9. Lista de puntos no resueltos, partes de lógica incompletos u otros asuntos.
La manera de completar este formulario facilita el enlace del proceso con el Diagrama de Flujo
de Datos del Diccionario de Datos.
Ejemplo:

21
 Descripción de Proceso

Número 1.2
Nombre Verificar la mercancía ordenada
Descripción Asocia toda factura que se reciba con un Nº válido de
Orden de compra.
Entrada Detalles de la Factura
Detalles de la Orden de Compra
Salida Paquete de Factura
Paquete no verificado

Tipo de proceso Nombre de subprograma/función

 En línea  Por lote  Manual

Resumen de la Lógica

Referirse a: Nombre:
 Lenguaje Estructurado  Tabla de decisión  Árbol de decisión
Asuntos no resueltos:

¿Qué es un prototipo?
La elaboración de prototipos consiste en el desarrollo de un sistema no funcional rápido y
barato para fines de demostración y evaluación, de manera que los usuarios puedan determinar
mejor sus requerimientos de información. Este método consiste en un desarrollo iterativo
(proceso de diseño preliminar, de probarlo, afinarlo y probarlo de nuevo) o en continua evolución
donde el usuario participa directamente en el proceso de análisis y diseño.
Por lo tanto, un prototipo es una versión operativa preliminar de un sistema de información.
Es la primera versión de un sistema de información: es el modelo original.
El método de prototipos es menos formal que el del ciclo de vida. En vez de generar
especificaciones detalladas y documentos de autorizaciones, el prototipo genera rápidamente un
modelo operativo del sistema. Los requerimientos se determinan dinámicamente a medida que el
prototipo se construye. El análisis del sistema, el diseño y la implantación ocurren al mismo
tiempo.
Etapas en la construcción de prototipos:
ETAPA 1: Identificar los requerimientos básicos del usuario. El diseñador del sistema trabaja
con el usuario sólo lo suficiente para obtener sus necesidades básicas de
información.
ETAPA 2: Desarrollar un prototipo inicial. El diseñador del sistema crea rápidamente un
prototipo operativo; éste puede llevar a cabo sólo las funciones más importantes
del sistema propuesto o puede ser todo el sistema con un archivo restringido.
ETAPA 3: Uso del prototipo. Se estimula al usuario a que trabaje con el sistema con el objeto
de determinar qué tan bien satisface sus necesidades y para hacer
recomendaciones para mejorarlo.
ETAPA 4: Revisión y mejora del prototipo. El desarrollador del sistema anota todos los
cambios solicitados por el usuario y afina el prototipo de acuerdo con ellos. Luego
de que el prototipo ha sido revisado, el ciclo regresa a las etapas 3 y 4, que se
repiten hasta que el usuario quede satisfecho.
Tal como lo sugieren los pasos anteriores, la construcción de prototipos no es un proceso de
desarrollo por prueba y error. Cuando ya no se requiere más iteraciones, el prototipo aprobado se
transforma en un prototipo operativo que proporciona las especificaciones finales para la
aplicación. En general, se opta por una de las siguientes cuatro opciones:
1. Volver a desarrollar el prototipo. Significa volver a programar por completo, empezando
desde el principio.
2. Implantar el prototipo como sistema terminado. El prototipo mismo se adopta como la
versión definitiva de producción del sistema.

22
3. Abandonar el proyecto. El prototipo ha proporcionado información suficiente para
demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados
dentro del marco de la tecnología existente o de lineamientos económicos u operaciones.
4. Iniciar otra serie de construcción de prototipos. La información ganada con la
experiencia sugiere ya sea un enfoque totalmente distinto o características contrastantes.
Características del prototipo de sistemas:
- Se emplea ya que a veces los requerimientos de información no siempre están bien
definidos.
- Condiciones únicas de la aplicación donde los encargados del desarrollo tienen poca
experiencia o información, o donde los costos y riesgos de cometer un error pueden ser
altos.
- Asimismo, útil para probar la factibilidad del sistema, identificar los requerimientos del
usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.
Desventajas del prototipo de sistemas:
- Los prototipos pueden no ser adecuados para todas las aplicaciones.
- El método y las herramientas de desarrollo usadas en la elaboración de prototipos, tienen
limitaciones muy serias.
- Las aplicaciones que están orientadas hacia el manejo sencillo de datos y administración de
registros son buenos candidatos para los prototipos. Sin embargo, sistemas basados en
procesamiento por lotes o que descansan en operaciones complejas de cálculos y en una
lógica de procedimientos compleja son en general inadecuados para el proceso de
prototipos.
- Los prototipos están mejor adaptados para las aplicaciones más pequeñas. Los grandes
sistemas deben subdividirse de manera que los prototipos puedan construirse en partes,
una a la vez.
- Hacer un prototipo de manera muy rápida puede esquivar pasos esenciales en el desarrollo
de sistemas. El análisis básico de sistemas y el de requerimientos no se pueden hacer en
cortos circuitos.
Ventajas del prototipo de sistemas:
- Los prototipos son de mayor utilidad cuando existe alguna incertidumbre sobre los
requerimientos o soluciones de diseño. Puede ser difícil señalar por adelantado los
requerimientos o pueden cambiar sustancialmente a medida que progresa la implantación
(aplicaciones orientadas a las decisiones).
- Los prototipos son especialmente útiles para el diseño de la interface con el usuario final
(la parte del sistema con la que el usuario interactúa, como las pantallas en línea y las
pantallas o informes de acceso de datos) de un sistema de información.
- El prototipo permite que los usuarios reaccionen de inmediato a las partes del sistema con
las cuales tratarán.
- Los prototipos son útiles cuando los requerimientos de los usuarios son lo suficientemente
claros, pero los desarrolladores de sistemas pueden no estar seguros de ciertas
características técnicas del diseño de la solución.
- Los prototipos estimulan el involucramiento intenso de los usuarios finales a todo lo largo
del desarrollo del ciclo de vida de los sistemas. Además, la satisfacción y la moral del
usuario se ven estimuladas porque se le puede presentar un sistema que trabaja en la
realidad, aun cuando sea preliminar por un período corto.
- Los prototipos producen sistemas que satisfacen los requerimientos de los usuarios, en
especial cuando son usados en aplicaciones para el soporte de la toma de decisiones.
- Prometen eliminar el exceso en los costos de desarrollo y los errores de diseño que ocurren
cuando los requerimientos no son totalmente captados desde la primera vez.
Métodos del ciclo de vida y de prototipos:
 Diferencia Fundamental:
MÉTODO DE PROTOTIPOS: es más rápido, iterativo e informal.
 Combinación:
Ejemplo: Los requerimientos se pueden evaluar con rapidez por medio de la construcción de
un prototipo que permita obtener la retroalimentación con respecto a las características
importantes del sistema. Estos resultados pueden ser incorporados durante la evolución del
proyecto por medio del método del Ciclo de Vida.

23