Fases Del Desarrollo de Sistemas

UNJBG Facultad de Ciencias Administrativas
FASES DEL DESARROLLO DE SISTEMAS

Prof. Manuel alvarado
CAPITULO I: ANALISIS PRELIMINAR
1. GENERALIDADES
A) PLANEAMIENTO ESTRATEGICO Y SISTEMAS DE INFORMACION
Política reactiva en sistemas de información. – Considera los sistemas

de información como arma defensiva táctica de la organización, para
hacer frente a los requerimientos de proceso de datos. Esta es la
situación en la que han sido los usuarios y directivos quienes han
impulsado el nacimiento de los proyectos, al hacer notar la necesidad
de apoyar las actividades que requieren mejoras. Así, se actúa como
reacción a tales necesidades. Tales situaciones provienen de la
combinación de:
 Problemas: Situaciones no deseables que impiden a la

Organización alcanzar plenamente sus propósitos.
 Oportunidades: Posibilidades de mejorar la Organización
inclusive ante ausencia de problemas (Ejm: reducción de costos).
 Normas: Todas nuevas disposiciones interna o externas.
Política proactiva en sistemas de información.- Esta ve a los sistemas

de información como un arma ofensiva estratégica, que permite a la
organización una ventaja competitiva. Se visualizan como una forma no
sólo de reducir costos sino de aumentar ingresos. Esta política se
concibe en los altos niveles de decisión, los que entienden la
necesidad de alinear los sistemas de información como soporte de apoyo
al logro de las metas trazadas en el planeamiento estratégico de la
organización.
El desarrollo del plan estratégico de sistemas de información puede

comprender estas tres etapas (Burch, “Diseño de S.I”):
a) Establecer las metas de los S.I.
b) Asignar prioridades a las solicitudes de proyectos de S.I.
c) Determinación de recursos y capacidad de los S.I. seleccionados.
B) PRINCIPIOS GENERALES QUE DEBE CONSIDERAR UN DESARROLLO DE SISTEMAS
- Implicar al usuario.- Que las soluciones cuenten con la

participación activa del usuario en cuanto a requerimientos e
interfaces.
- Aplicar una metodología uniforme.- Que todo desarrollo de sistemas
dentro de la organización siga una metodología formal, utilizada
por todos.
- Justificar los sistemas como inversiones de capital.- Evaluar la
viabilidad de cada alternativa existente en términos de costo y
beneficio.
Prof. Manuel Alvarado 1

- Contemplar la posibilidad de cancelar/revisar el proyecto.- El

desarrollo por etapas permite la posibilidad de reevaluar
constantemente su viabilidad.
- Delimitar los proyectos respecto al sistema global.- Es prudente
delimitar adecuadamente cada proyecto, sin perder su relación con
el marco general.
- Establecer diseños para situaciones crecientes y cambiantes.- Tomar
en cuenta el desarrollo para afrontar las condiciones cambiantes de
hoy, y recordar la característica de entropía, común a todo
sistema.
C) EL CICLO DE VIDA DE DESARROLLO DE SISTEMAS
Es un proceso mediante el cual el conjunto de especialistas y los

usuarios solicitantes o beneficiarios, elaboran un sistema de
información. Actualmente es una herramienta de gestión de proyectos
que permite planear, ejecutar y controlar los proyectos de desarrollo
de sistemas.
El ciclo de vida de desarrollo de sistemas es un proceso totalmente

independiente de la política imperante en la organización respecto a
los sistemas de información (reactiva o proactiva).
ALGUNOS ENFOQUES DEL CICLO DE VIDA DE DESARROLLO DE SISTEMAS
 YOURDON, “Análisis estructurado moderno”

CICLO DE VIDA ESTRUCTURADO
 ENCUESTA
 ANALISIS
 DISEÑO
 IMPLANTACION
 PRUEBAS DE ACEPTACION
 GARANTIA DE CALIDAD (PRUEBA FINAL)
 DESCRIPCION DEL PROCEDIMIENTO (MANUAL)
 CONVERSION DE BASES DE DATOS
 INSTALACION
 BURCH/GRUDNITSKI, “Diseño de sistemas de información”

PLANEACION, DESARROLLO Y ADMINISTRACION DE SISTEMAS DE INFORMACION
 PLANEAMIENTO ESTRATEGICO DE SISTEMAS DE INFORMACION

 ANALISIS DE SISTEMAS
 DISEÑO GENERAL DE SISTEMAS
 EVALUACION DE SISTEMAS
 DISEÑO DETALLADO DE SISTEMAS
 IMPLEMENTACION DE SISTEMAS
 ADMINISTRACION DE SISTEMAS
 RUMBAUGH/BLAHA, “Modelamiento y diseño orientado a objetos”

DESARROLLO ORIENTADO A OBJETOS

 ANALISIS
 DISEÑO DEL SISTEMA
 DISEÑO DE OBJETOS
 IMPLEMENTACION
2. ANALISIS PRELIMINAR
2.1 EQUIPO DEL PROYECTO
Depende del tamaño de la Institución y de la existencia/ausencia de

un planeamiento de sistemas. Son participantes comunes de equipos:
 Director del proyecto
 Jefe de equipo de proyecto
 Jefe de Analistas
 Jefe de programadores
 Jefe de usuarios
2.2 DEFINICIÓN DEL PROBLEMA / JUSTIFICACION
 Definición del problema

 Antecedentes (proyectos relacionados)
2.3 ESTUDIO DE FACTIBILIDADES
FACTIBILIDAD ECONOMICA
 Costo del hardware y software para las aplicaciones del sistema
 Beneficios en cuanto a reducción de costos con el nuevo sistema,
respecto al actual
 Costo de no llevar a cabo la implantación del nuevo sistema
 Otros
FACTIBILIDAD OPERATIVA
 Existe apoyo necesario de la alta dirección?
 El sistema será aceptado por los usuarios?
 Participarán los usuarios en la planeación y desarrollo?
 Generará impacto adverso el sistema propuesto?
 Grado de apoyo del sistema a los procesos existentes?
 Otros
FACTIBILIDAD TECNICA
 Capacidad técnica del equipo del proyecto de sistema.
 Existe o se puede adquirir el equipamiento para el proyecto?
 El sistema generará respuestas adecuadas considerando el número y
ubicación de usuarios?
 El sistema se adecuará a situaciones crecientes y cambiantes?
 Otros
FACTIBILIDAD LEGAL
 Existe algún tipo de restricción legal para desarrollar nuevo
sistema?
 Otros

2.4 ESTABLECIMIENTO DE OBJETIVOS DEL SISTEMA
 General
 Específicos
2.5 CRONOGRAMA DEL PROYECTO
 Diagrama Gantt
 Diagrama PERT
2.6 IDENTIFICACIÓN Y DEFINICIÓN DE REQUISITOS
TECNICA: ENTREVISTA
2.6.1 INTRODUCCION Y OBJETIVOS
Las entrevistas constituyen el medio de obtener información sobre:

 Los requisitos de usuario.
 Funcionamiento del sistema actual.
 Organización de la Unidad.
 Responsabilidades y funciones de los usuarios.
Por esta razón, la preparación y realización de las entrevistas juega un

papel primordial en las primeras etapas del desarrollo de sistemas, ya
que éstas permitirán sentar las bases sobre las cuales se desarrollará el
futuro sistema.
En muchas ocasiones puede ser conveniente sustituir la tradicional

entrevista «cara a cara» con el usuario, por reuniones en grupo con un
conjunto de usuarios especializados en las funciones a tratar por el
sistema. Esto tiene especial importancia, en el caso de que un sistema
abarque distintos sectores de la Organización, como por ejemplo,
distintas unidades que realizan funciones similares y el objetivo es
crear un estándar para unificar el procedimiento.
Adicionalmente, si no existiera un planeamiento estratégico de sistemas

en la Organización, será útil aprovechar la ocasión para sentar las bases
para la elaboración de un Plan de Sistemas de la Organización. La
realización de reuniones en grupo permite establecer nuevas ideas,
prioridades y objetivos al interior de la Organización.
2.6.2 RECOMENDACIONES DE DESARROLLO DE ENTREVISTAS
A continuación se dan unas recomendaciones generales sobre la técnica de

entrevistas, haciendo énfasis en dos aspectos esenciales de las mismas:
 Preparación de un cuestionario (guión) para la entrevista.
 Consolidación de la entrevista.
2.6.3 PREPARACION DE CUESTIONARIO (GUION).

Antes de realizar una entrevista es imprescindible enviar al usuario a

entrevistar, un cuestionario previo sobre los puntos a tratar. Dicho
guión ha de ser suficientemente detallado para cubrir todos los aspectos
de interés, y dar oportunidad al usuario a preparar documentación sobre
el sistema. Sin embargo, debe existir cuidado respecto a la extensión del
guión o cuestionario previo, evitando excesivos detalles.
Es importante elaborar el cuestionario, atendiendo al perfil y a
las responsabilidades del usuario a entrevistar. A continuación, se
exponen una serie de consideraciones sobre los aspectos a tener en
cuenta, en función de dicho perfil de usuarios:
1. Entrevistas a los responsables de área.

1.1 Funciones que realiza su departamento o grupo.
1.2 Sistemas de Información actuales (ya sean manuales o
mecanizados).
 Entradas, salidas, funcionalidad.
1.3 Relaciones o salidas a otros sistemas, definiendo:
 Destino de los datos (departamento o grupo dentro de un
departamento, y si es posible el nombre del sistema que
recibe la salida, cuando sea informatizado).
 Datos enviados a otros sistemas.
 Medios empleados (papel, intercambio electrónico de datos,
disket, cinta magnética).
 Frecuencia (tiempo real, varias veces al día, diariamente,
semanalmente, etc.).
1.4 Nivel de satisfacción técnica con el sistema de información
actual. Se establecerá una evaluación global sobre los siguientes
aspectos:
 Disponibilidad de los sistemas de información.
 Tiempos de respuesta.
 Facilidad de uso.
La evaluación se hará de acuerdo a la siguiente escala:
1.5 Identificar al resto de los usuarios del departamento o grupo

que deberá participar en futuras entrevistas.
Al final de la entrevista se levantará un acta de la reunión,

donde se resumirán los puntos tratados. El acta deberá ser
entregada a todos los participantes de la reunión.
2. Entrevistas al resto de los usuarios.

El objeto de estas entrevistas es detallar aspectos funcionales más
concretos. El guión para estas entrevistas deberá contemplar:
2.1 Situación Actual.
Descripción de los sistemas de información actualmente
implantados (ya sean manuales o informatizados). Incluir:
2.1.1 Entorno físico/lógico existente.
2.1.2 Tipos de entradas. Por cada tipo:
 Su origen (departamento, grupo o sistema en caso de
que exista, lo genera).

 Datos involucrados.
 Soporte utilizado (papel, intercambio electrónico de
datos, disquete, cinta magnética).
 Frecuencia (tiempo real, varias veces al día,
diariamente, semanalmente).
2.1.3 Procesos y funciones realizados por dichos sistemas.
2.1.4 Tipos de salida. Por cada uno:
 Destino (departamento, grupo de departamento o
sistema que lo recibe, si existe).
 Soporte (papel, intercambio electrónico de datos,
disquetes, cinta magnética).
 Frecuencia (tiempo real, varias veces al día,
diariamente, semanalmente, etc)
2.1.5 Volumen de información manipulada.
2.1.6 Por sistema de información, detallar los sistemas de
almacenamiento de datos involucrados, y para cada uno de
ellos especificar:
 Tipos de datos implicados.
 Identificar para cada dato si es identificativo o
significativo.
2.1.7 Principales ventajas e inconvenientes.
2.1.8 Nivel de satisfacción técnica con los sistemas
actuales. La valoración incluirá aspectos como:
 Disponibilidad de los sistemas de información.
 Tiempos de respuesta.
 Facilidad de uso.
 Tiempo de espera si se piden modificaciones.
Puede utilizarse la tabla anterior para ponderar la
evaluación.
2.2 Requisitos del Nuevo Sistema.

2.2.1 Nuevos procesos/funciones a realizar por el sistema.
2.2.2 Prioridades de esos procesos/funciones.
2.2.3 Nuevas consultas deseadas, incluyendo:
 Origen y destino de esos datos.
 Frecuencia.
2.2.4 Nuevos informes deseados.
2.2.5 Necesidades de seguridad sobre los datos.
2.2.6 Factores críticos de éxito.
CONSIDERACIONES.
 Debe tenerse en cuenta que lo expuesto en esta técnica es sólo una
visión general de los aspectos más relevantes que deben ser
tratados en cada tipo de entrevista. Para cada proyecto, deberá
confeccionarse un guión detallado de las entrevistas que se
realicen, según sea:
 El tipo de proyecto.
 El usuario entrevistado.

 La experiencia del entrevistador y su conocimiento del sistema

analizado.
 El guión de la entrevista se entregará con suficiente anticipación
al responsable de usuarios, para que éste pueda garantizar su
distribución a las personas involucradas.
 En la realización de una entrevista, se abordarán los puntos a
tratar desde una visión general, al principio, para centrarse
gradualmente en aspectos más detallados.
Consolidación de la Entrevista.
Una vez realizada la entrevista con el usuario, es conveniente

depurar y consolidar los resultados de la misma, para asegurar que se han
comprendido bien las especificaciones del usuario sobre el conjunto de
procedimientos de trabajo del sistema actual, así como sobre los
requisitos que debe satisfacer el nuevo sistema.
Para lo anterior se utilizarán técnicas de representación para

ilustrar el funcionamiento del sistema actual, mediante un dibujo libre,
que permita contrastar con el usuario, el flujo de la información a
través del sistema, así como las diversas tareas y responsabilidades en
el uso de esa información. Además, se especificarán los requisitos de
usuario de una forma sencilla y medible, de manera que se pueda asignar
prioridades a dichos requisitos, y se validarán conjuntamente con el
usuario, dichas prioridades.
Por último, en el caso que se disponga de las herramientas necesarias,

se podrán elaborar prototipos iniciales (los que se refinarán en el
análisis y diseño) o maquetas simples del nuevo sistema, en los que
figuren:
 Las pantallas de que consta.

 Los informes a obtener.
 La simulación de las funciones que realiza.
 La apariencia externa del mismo.
Estos prototipos ayudarán al usuario a especificar y concretar sus

necesidades.
2.7 ALCANCE (AMBITO DEL PROYECTO)
 Personas
 Grupos
2.8 RESTRICCIONES (LIMITACIONES)
 De equipo
 Políticas
 Económicas
 Tecnológicas
2.9 DISEÑO DEL MODELO ACTUAL (ARQUITECTURA DEL SISTEMA)

 Modelo de procesos actual

 Modelo de datos actual
2.10 ESTUDIO DE ALTERNATIVAS DE CONSTRUCCIÓN
 Plantear soluciones alternativas previas como avance al análisis.

CAPITULO II : ANALISIS DEL SISTEMA
3.0 GENERALIDADES
El análisis de sistemas comprende las siguientes actividades básicas:
 Resumen de los requerimientos del ususario.

 Construcción del modelo lógico del nuevo sistema
 Definición del diccionario de datos
RESUMEN DE LOS REQUERIMIENTOS DEL USUARIO.
Luego de haberse realizado las entrevistas a los usuarios, se

procede a efectuar un resumen y ordenamiento de los mismos, los cuales
constituyen la plataforma que guiará el análisis, diseño y las demás
etapas del desarrollo.
CONSTRUCCIÓN DEL MODELO LÓGICO DEL SISTEMA ACTUAL (OPCIONAL)
Alternativamente se puede representar mediante un modelo lógico, el

funcionamiento del sistema actual. La elaboración de este modelo, permite
profundizar en el conocimiento del sistema actual y facilitar la
identificación de los sistemas existentes.
 Las funciones de la Unidad que el sistema brinda apoyo.

 El flujo de información entre las mismas, representando la
manera en que fluye la misma para el cumplimiento de las
funciones.
 Las entradas, salidas y almacenamiento de la información que
fluye del sistema, representando su tipo.
 Las comunicaciones con otras unidades de la organización.
En base a toda la información obtenida anteriormente, se revisan los

aspectos funcionales del sistema existente, logrando así:
 Identificar las principales entradas (aquella información que

será utilizada como fuente) del sistema.
 Identificar las principales funciones (los principales procesos)
que ejecuta el sistema tomando como base la información fuente.
 Identificar las principales salidas, (tipos de información que
genera) el sistema.
Esta revisión de los aspectos del sistema existentes, facilitará la

identificación de nuevos requisitos que debe satisfacerse.
CONSTRUCCIÓN DEL MODELO LÓGICO DEL NUEVO SISTEMA
Esta actividad tiene como objetivo resumir el funcionamiento del sistema

actual, de un modo conceptual (representado gráficamente con el modelo

lógico), y las nuevas alternativas propias del nuevo sistema a proponer,

es decir muestra a la organización en términos de las funciones
(procesos) que realiza y en términos de los datos involucrados en dichos
procesos.
Para realizar con éxito esta actividad se deben de realizar las

siguientes Tareas:
 Construcción del modelo actual de proceso, y nuevas alternativas.

 Construcción del modelo lógico actual de datos y nuevas
alternativas.
LOS MODELOS REPRESENTATIVOS DEL ANALISIS DE SISTEMAS
1. MODELO FUNCIONAL (DIAGRAMA DE FLUJO DE DATOS - DFD)

2. MODELO DE DATOS (DIAGRAMA ENTIDAD RELACION - DER)
3. MODELO DINAMICO (DIAGRAMA DE TRANSICION ESTADOS - DTE)
¿Cuál debe desarrollarse primero, para un sistema?- ¿Realmente se

necesitan hacer tres modelos distintos del sistema?
La respuesta es que depende del tipo de sistema que se esté desarrollando,

de la experiencia del analista o de los requerimientos del usuario
que hará necesario realizar primero uno u otro, o incluso paralelamente.
Tal vez el sistema es, por ejemplo, rico en FUNCIONES (procesos
industriales) o es más bien rico en DATOS. En sistemas de hace una o dos
décadas atrás esto podría hacer muy dudosa la decisión, pero hoy que los
sistemas tienden a ser cada vez más grandes y de mayor complejidad en sus
funciones, relaciones entre datos y en sus comportamientos dependientes
del tiempo, parece necesitarse al menos dos de estos modelos (el DFD y el
DER).
3.1 MODELO FUNCIONAL (DE PROCESOS) DEL SISTEMA : EL DFD
Un modelo funcional (de procesos) es la representación de un sistema

mediante un modelo lógico. Esto facilita la comprensión de aquel tanto
por parte de los usuarios como del equipo de desarrollo (especialistas).
Este modelamiento hace uso de la herramienta denominada DIAGRAMA DE FLUJO
DE DATOS (DFD) que permite visualizar un sistema como una red de procesos
funcionales. Algunos sinónimos usados para DFD son: Diagrama de burbujas y
modelo de procesos.
Símbolos del DFD: 1) PROCESO 2) FLUJO 3) ALMACEN 4) ENTIDAD EXTERNA
Un DFD permite representar la división del sistema en distintos niveles

de detalle lo que permite simplificar su complejidad mediante diferentes
procesos sencillos. Este “plano” de la realidad sirve para facilitar el
mantenimiento del sistema que la representa.
El DFD proporciona una representación del sistema mediante el uso de una

notación y reglas predeterminadas. Permite mostrar los principales
procesos o acciones del sistema y mediante la EXPLOSION, mostrar los
procesos contenidos en él. El resultado del análisis con DFD debe:

 Ser gráfico.
 Ser preciso y breve.
 Ser comprensible.
 Ser debidamente particionado en niveles.
 Ser bien documentado.
 No ser redundante.
 Establecer "Qué" Funciones se desarrollan, sin implicar "Cómo".
 No ambiguo.
3.1.1 ELEMENTOS BASICOS
Los elementos básicos que aparecen en cualquier Diagrama de Flujo de

Datos, son los siguientes:
 Entidad Externa.
 Proceso.
 Flujo de datos.
 Almacén de datos.
A) ENTIDAD EXTERNA (TERMINADOR)
Las Entidades Externas representan entes ajenos a nuestra aplicación,

pero que aportan o reciben información de la misma (con los cuales el
sistema se comunica). Normalmente un "terminador" es una persona o un
grupo, por ejemplo, una organización externa o una agencia gubernamental o
un grupo o departamento que esté dentro de la misma compañia u
organización, pero fuera del control del sistema que se está modelando. En
algunos casos, un "terminador" puede ser otro sistema con el cual hay
comunicación.
Siendo externos, ni el analista ni el diseñador del sistema están en

posibilidades de cambiar los contenidos de un terminador o la manera en la
que trabaja. Por otro lado, las relaciones que existan entre los
terminadores no se muestran en el modelo de DFD. Pudieran existir de hecho
diversas relaciones, pero, por definición, no son parte del sistema que se
está estudiando (yourdon). Se representan mediante un rectángulo.
NOMBRE
Reglas de Construcción:
1. Representa personas, organizaciones o sistemas que no pertenecen al

sistema.
2. En el caso que las entidades externas se comuniquen entre sí, ésto, no
se contemplaría en el diagrama, por estar fuera del ámbito de nuestro
sistema.
3. Puede aparecer en los distintos niveles del DFD.
4. Puede aparecer varias veces en un mismo diagrama, para evitar
entrecruzamientos de líneas.

5. Suministra información acerca de la conexión del sistema con el mundo

exterior.
B) PROCESO
Representa una actividad que transforma o manipula datos. Cada proceso se

nombra con una sola palabra, frase u oración sencilla que describe lo que
este "hace". Su representación dentro del DFD es (según gane/sarson y
yourdon/de marco respectivamente):
NIVEL
NIVEL
NOMBRE NOMBRE
NOMBRE representa un proceso determinado.
NIVEL representa el número que identifica al proceso y el nivel del DFD

en que nos encontramos. Es importante aclarar que este número no indica
necesariamente secuencia de realización del proceso, dado que los DFD no
representan una continuidad en el tratamiento de los datos.
Reglas de Construcción:
 Cuando un Flujo de datos entra en un proceso, sufre una

transformación. Un proceso no es ni origen ni final de los datos, sólo
lugar de transformación de los mismos. Por ello, cualquier flujo de
datos que entre en un proceso, ha de transformarse.
 Un proceso puede transformar un dato, en varios.
 Es necesario un proceso como intermediario entre una Entidad Externa y
un Almacén de Datos.
C) ALMACÉN DE DATOS
Un almacén de datos representa un depósito de información dentro del

sistema. Muestra colecciones (o agregados) de datos EN REPOSO que el
sistema debe recordar por un período de tiempo. Cuando los diseñadores
de Sistemas y los programadores terminan de construir el sistema, estos
almacenes existirán como ARCHIVOS O TABLAS de Bases de Datos. Esto último
hace que para algunos analistas con conocimiento de proceso de datos, sea
"tentador" referirse a los almacenes como archivos o Bases de datos, y de
hecho, es así como a menudo se implantan en un sistema computarizado;
pero un almacén también pudiera consistir de datos en microfilm, disco
óptico o algunas más de otras posibles formas electrónicas (yourdon).
Su representación dentro del DFD es (según gane/sarson y yourdon/de marco

respectivamente):
NOMBRE
ID NOMBRE

En la parte derecha se indica el nombre del almacén de datos y en la

parte izquierda se representa la identificación de dicho almacén dentro
del DFD. Si dentro de un DFD aparece repetido el mismo almacén de datos,
se le puede representar con dos líneas verticales (ver Fig.).
Es conveniente distinguir las diferentes utilidades que presentan los

almacenes de datos.
 En primer lugar, el almacenamiento permanente de datos, donde se

guardan los datos que sirven de referencia de uso del sistema, es
decir, los datos permanentes, sobre los que el sistema necesita
guardar información (ALMACENES PRINCIPALES).
 Por otra parte, el almacenamiento transitorio de los datos antes de
ser usados por un proceso.
 Por último, para asegurar la consistencia entre todas las técnicas
utilizadas en la Fase de Análisis, se establecerá una relación precisa
entre los almacenes de datos "principales" de un DFD y las entidades
de los Diagramas Entidad-relación del modelo de datos. "Cada almacén
principal de un DFD representa un conjunto completo de entidades del
DER (una o varias entidades) y cada entidad de un DER pertenece a un
único almacén principal de un DFD". Esto facilitará las validaciones
cruzadas entre los dos diagramas.
Reglas de construcción:
 Representa la información en reposo.

 No puede crear, destruir ni transformar datos.
 No puede estar comunicado directamente con otro Almacén o Entidad
Externa.
 El flujo de datos (Entrada o Salida) no lleva necesariamente nombre
cuando incide sobre su contenido completo.
 No debe estar referido al entorno físico y por tanto, no se deben
pensar en términos de tablas convencionales de las Bases de Datos.
 No se representa la clave de acceso de ese almacén, sino sólo la
operación que se realiza (lectura, escritura, actualización).
D) FLUJO DE DATOS
Los Flujos de Datos establecen la comunicación entre procesos, almacenes

y entidades externas, llevando información necesaria. Su representación
dentro del DFD es una flecha dirigida recta o curvada (tanto según
gane/sarson y yourdon/de marco):
Reglas de construcción:
 El concepto de flujo de datos es similar al de un “canal", a través de

la cual fluye una información de estructura conocida.
 Los datos no pueden ser creados ni destruidos por un flujo de datos.
 Sirve para conectar el resto de los componentes del DFD.
 No es un activador de procesos.

 Cuando un proceso almacena datos, la flecha de flujo de datos se

indica en la dirección del almacén de datos y a la inversa, si es el
proceso el que lee datos en el almacén.
GANE / SARSON YOURDON / DE MARCO
ENTIDAD NOMBRE NOMBRE

EXTERNA
NIVEL NIVEL
PROCESO
NOMBRE NOMBRE
ALMACEN ID NOMBRE
DE DATOS NOMBRE
FLUJO DE
DATOS
3.1.2 PRINCIPIOS FUNDAMENTALES DE CONSTRUCCION DEL MODELO FUNCIONAL
EL DIAGRAMA DE CONTEXTO - CARACTERISTICAS
 El primer DFD que va a aparecer es el que se va a llamar DIAGRAMA DE

CONTEXTO y es, precisamente, el gráfico que va a proporcionar el
ámbito del proyecto objeto de estudio. En él, aparecerá todo aquello
que necesite o envíe datos del o hacia el sistema a desarrollar. Estos
se representan por los objetos denominados Entidades Externas.
 El objetivo es realizar una declaración formal del dominio.

 Un sólo proceso representará el área que se está estudiando.
 El contexto queda definido por los flujos de entrada y salida y las
entidades externas. Estas últimas han de aparecer preferiblemente en
este nivel (en otros sólo para mejorar la comprensión del resto del
DFD).

ENT.EXT
P0
NOMBRE ENT.EXT.
SISTEMA
.
ENT.EXT.
FIG. FORMA TIPICA DEL DIAGRAMA DE CONTEXTO
DESCOMPOSICIÓN O EXPLOSIÓN POR NIVELES
Los Diagramas de Flujo de Datos deben representar el Sistema de la forma

más clara posible. Para ello se basarán en el principio de descomposición
o explosión en distintos niveles de detalle. El primer paso hacia la
descomposición es hacer “explotar” el diagrama de contexto.
La descomposición por niveles permite analizar el sistema desde el ámbito

general al detalle, pasando por sucesivos niveles intermedios (filosofía
de arriba-abajo o "top-down"). La utilización de esta técnica implica la
descomposición o explosión de cada proceso en otro DFD.
En resumen, el sistema deberá estar representado conteniendo:
 Un diagrama de contexto (primer nivel).

 Varios DFD en niveles intermedios.
 Varios DFD en el último nivel de detalle.
En cualquier momento puede aparecer un proceso que no necesite

descomponerse y es lo que se llama PROCESO PRIMITIVO (PP) O ATOMICO. En
él, sólo se detallará la entrada y salida que tenga, además de la
descripción asociada que explique lo que realiza.
El procedimiento a seguir para la representación del sistema en

diferentes niveles de detalle, se indica a continuación:
1. Representar el Diagrama de Contexto.

2. Representar el DFD de primer nivel, indicando los distintos
subsistemas o áreas funcionales en que se descompone nuestro sistema.
3. Descomponer cada uno de los procesos que aparecen en el DFD de primer
nivel, hasta llegar a un nivel suficiente de detalle.
4. Si es necesario, reagrupar y reorganizar los distintos subsistemas que
se han identificado inicialmente, esto implicará reasignar procesos a
otras áreas funcionales o incluso crear nuevas áreas funcionales, es
decir, subir de nivel para hacer redefiniciones.
5. Repetir el proceso de descomposición hasta llegar a un nivel
suficiente de detalle.

En la figura siguiente se representan los distintos niveles que pueden

surgir a la hora de desarrollar nuestro sistema de información. Alli se
pueden observar hasta 4 niveles, iniciando esta descomposición con la
“explosión” del diagrama de contexto.
La identificación de las áreas funcionales o subsistemas se hará

atendiendo, entre otros, a los siguientes criterios:
 Funciones organizativas o administrativas propias del sistema a

desarrollar y específicas de la problemática de la Unidad.
 Homogeneidad de las funciones realizadas por los procesos
pertenecientes a un área funcional o subsistema.
 Localización geográfica de los procesos.
 Procesos que actualicen los mismos almacenes de datos se colocarán en
el mismo subsistema o área funcional.
El objetivo final será conseguir que las comunicaciones o enlaces entre

distintos subsistemas o áreas funcionales, sean lo más explícitas y
homogéneas posible. Las ventajas de la descomposición son las siguientes:
 Es comprensible para usuarios no informáticos.

 Los procesos en el último nivel están relacionados lógicamente.
 Los procesos en el nivel 3, de eventos, están separados en el tiempo.
 Facilita las referencias cruzadas con otros productos obtenidos en la
metodología, concretamente con el Catálogo de Eventos obtenido en la
Tarea de Construcción del Modelo entidad-evento.

EJEMPLO DE UN D.D. PARA DFD : ESPECIFICANDO PROCESOS

( USANDO : PSEUDOCODIGO )
1.1 Detalle 1.2

Verificación Alumno Verificación 1.3
Alumno Curso Detalle Verificación
Curso Récord
PROCESO 1.1 : VERIFICACION DE ALUMNO
DESCRIPCION.- Verificar que un alumno está expedito para realizar su

matrícula, mediante verificación de sus datos personales.
ENTRADAS : Ficha de matrícula.

SALIDAS : Detalle de alumno.
COMIENZA
SI Existe-Alumno-Ok = "Si"
[Mostrar datos de alumno]
Ir a proceso que realizó llamada
OTRO
Desplegar mensaje "Alumno No existe"
Ir a proceso que realizó llamada
FIN_SI
TERMINA
PROCESO 1.3 : VERIFICA ESTADO DE RECORD
DESCRIPCION- Verificar la aprobación de los cursos anteriores o cursos

pre-requisitos para cada uno de los cursos consignados en la ficha, sea por
proceso manual o generación automática.
ENTRADAS : Detalle de cursos, RECORD_AC.

SALIDAS : MATRICULA, Oasa, Alumno, Obun.
COMIENZA
Ir a almacén RECORD
Mientras Existe-Curso-Ok = "Si"
SI Curso-aprobado-Ok="No"
Desplegar mensaje "Curso no aprobado"
Ir a proceso que hizo llamada (salir)
FIN-SI
FIN-Mientras
TERMINA
3.2 MODELO DE DATOS DEL SISTEMA: EL D.E.R.

Es una notación gráfica para MODELAR DATOS, que describe con un alto nivel
de abstracción, la distribución de datos almacenados en un sistema. Es muy
DIFERENTE DEL DFD, que modela las funciones que lleva a cabo el sistema; y
es muy diferente del diagrama de transición de estados, que modela el
comportamiento dependiente del tiempo, de un sistema.
Es importante modelar los datos de un sistema porque las estructuras de

datos y las relaciones pueden ser tan complejas que se decida enfatizarlas
y examinarlas independientemente del proceso que se llevará a cabo. Es el
modelo mayormente mostrado a los ejecutivos de más alto nivel para la toma
de decisiones y a otro grupo importante: el de Administración de Bases de
Datos.
Este modelo fue creado por P. Chen y desde entonces han aparecido autores
que han tratado de mejorar o adaptar su idea original para hacerlo más
aplicable. En la práctica actual existen dos tendencias en el uso de la
simbología para representar el modelo de datos de un sistema:
 Variantes de la simbología DER planteada por P. Chen.

 Simbología planteada por James Martin.
3.2.1 COMPONENTES DE UN DIAGRAMA ENTIDAD-RELACION
A) ENTIDAD
Se representa (P. Chen) mediante un RECTANGULO. Representa una

colección o conjunto de objetos del mundo real. Cada miembro individual
de una entidad se denomina INSTANCIA, donde:
 Cada una puede identificarse de una manera única. Por ejemplo, una
instancia de la entidad ALUMNO: por un código o nombre, que lo
diferencia de otra instancia.
 Cada una es indispensable para el sistema. Es decir que para que la

entidad sea real, debe poder decirse que el sistema no puede operar,
sin tener acceso a las instancias.
 Cada una puede ser descrita por uno o más datos. Por ejemplo, una
instancia de la Entidad PROFESOR mediante nombre y dirección.
Profesor Curso
B) RELACION
Representa un conjunto de conexiones entre entidades. Se representa

(P. Chen) con un ROMBO. Es útil reconocer que cada instancia de la
relación representa una asociación entre cero o más ocurrencias de una
entidad con cero o más ocurrencias de otra.

Dicta
Profesor Curso
Relación
C) ATRIBUTOS (DESCRIPTORES)
Son valores que representan las propiedades elementales

(características) de las entidades y relaciones.
REPRESENTACION:
1) Con apoyo de un círculo por cada atributo (P. Chen).
2) Directamente al lado de la entidad ó relación (otros autores).
Id_Prof
Profesor Profesor Nom_Prof
Dir_Prof
O o o
Id_Prof Nom_Prof Dir_Prof
* ATRIBUTO MULTIVALORADO .- Es un atributo que puede tomar múltiples

valores para una ocurrencia de una entidad. Tomemos como ejemplo la
entidad PROFESOR, con atributos:
Nom_Prof -> Javier Gonzales

Tel_Prof -> 472-6475 , 472-7488, 472-4455
Aqui, Tel_Prof es MULTIVALORADO (varios números telefónicos).
3.2.2 DEFINICIONES ASOCIADAS AL DIAGRAMA ENTIDAD-RELACION
A) TIPO DE PARTICIPACION DE UNA ENTIDAD EN LA RELACION
MANDATORIO (OBLIGATORIO).- Este tipo de participación implica que una

entidad DEBE participar necesariamente en la relación.
OPCIONAL.- Una una entidad PUEDE O NO participar en la relación con otra

entidad. Un pequeño círculo, indica participación OPCIONAL.
Dicta
1 1
Profesor o Curso
Mandatorio Opcional
B) LA CARDINALIDAD

La Cardinalidad muestra el número de entidades que pueden participar

en el relacionamiento. Esta participación es impuesta por las reglas
propias de la Institución (negocio). En cuanto a simbología, YOURDON no
define una propia y usa más bien una aproximación de la de CHEN. Se
presentan 4 posibles situaciones.
Uno-a-Uno (1:1) Uno-a-Muchos (1:N)
Dicta Dicta
1
1 1 N
Profesor Curso Profesor Curso
Muchos-a-Uno (N:1) Muchos-a-Muchos (M:N)
Dicta Dicta
N 1 M N
Profesor Curso Profesor Curso
C) IDENTIFICADOR
Es el atributo que se utiliza como clave para identificar de forma

única a una entidad. Los demás quedan como "descriptores".
- Un IDENTIFICADOR SIMPLE implica que un solo atributo se ha considerado

suficiente para representar unívocamente una entidad.
- Un IDENTIFICADOR COMPUESTO significa que ha sido necesario el uso de 2 o

más atributos para identificar de forma única a una entidad (clave
compuesta por dos o más atributos).
3.2.3 MECANISMOS DE ABSTRACCION (SUBTIPO/SUPERTIPO)
Esto se refiere a que en ocasiones, las entidades se ubican en un

cierto nivel o categoría, en lo que representa una forma de abstracción
(proceso mental mediante el cual nos concentramos solo en los aspectos
relevantes de un conjunto de objetos). Los casos más representativos son
la GENERALIZACION y la AGREGACION.
GENERALIZACION
Es un mecanismo de abstracción mediante el cual, un conjunto de tipos

de objetos (entidades) se consideran como una clase genérica de entidades
de más alto nivel. En la siguiente figura, se muestra un ejemplo de
generalización en que la entidad EMPLEADO es una generalización de GERENTE
y SECRETARIA. Notemos que la entidad supertipo EMPLEADO se describe por
atributos que se aplican a todos los subtipos pero existen atributos que
solo son aplicables a uno de los subtipos lo que hizo necesaria tal
abstracción.
EMPLEADO
GERENTE SECRETARIA
AGREGACION
Es un mecanismo de abstracción mediante el cual, un nuevo tipo de

objetos (entidad) es definido a partir de otras entidades llamadas
componentes. Un ejemplo de agregación puede verse en la siguiente figura,
donde se notan que los subtipos son, efectivamente COMPONENTES del
supertipo.
COMPUTADOR
CASE TECLADO MONITOR
3.2.4 GUIA PARA OBTENER EL DIAGRAMA E-R EXTENDIDO
Se identifican las entidades y las asociaciones entre ellas para

modelar los requerimientos de datos (mediante un ESQUEMA CONCEPTUAL).
A) IDENTIFICAR ENTIDADES Y ATRIBUTOS
1) Entidades tienen información descriptiva, los atributos no.
Indica que debemos tener claro que, para considerar a una entidad
como tal, deberá ser posible describirla con atributos , sinó, tal dato
sebe ser considerado un atributo.
2) Atributos multivalorados deben clasificarse como entidades.
Si existe un atributo que tiene múltiples valores, es mejor

considerarlo como una entidad y evitar tratarlo como un atributo de una
entidad.
3) Asignar atributos a entidades, que la describan directamente.
Esto nos indica que debemos seleccionar los atributos de forma que
representen convenientemente a una entidad. Asi, por ejemplo: es más
propio, que "OFICINA" sea un atributo de DEPARTAMENTO en lugar de serlo
de la entidad EMPLEADO.
4) Evitar identificadores compuestos, tanto como sea posible.
Significa evitar que el identificador de una entidad (clave de la

entidad) esté conformado por el encadenamiento de varios atributos. En
algunos casos será más conveniente definir nuevas entidades. Otra

alternativa es mantener el identificador compuesto, si éste es

razonablemente natural.
5) Los atributos que tienen una relación muchos-a-uno con una entidad,
deberían ser una entidad.
Significa que si un atributo (descriptor) de una entidad tiene una

relación muchos-a-uno con otra entidad, el atributo debería ser
clasificado como una entidad, aún cuando tal atributo no tenga sus propios
descriptores. Asi, definidas las entidades:
- ALMACEN (Identificador: Num-Almacén, Descriptores:Propietario,CIUDAD)

- REGION
Debido a que hay una relación muchos-a-uno entre CIUDAD y REGION

(varias ciudades corresponden a una región en nuestro País), entonces
CIUDAD debería ser considerada como entidad.
B) IDENTIFICAR JERARQUIAS
1) Identificar subconjuntos para posibilidad de generalización.
Esto nos indica que debemos determinar la posibilidad de que ciertas

entidades puedan ser mejor representadas, considerándolas subconjuntos de
otras de mayor nivel.
C) DETERMINAR LOS RELACIONAMIENTOS ENTRE ENTIDADES
Aquí se tratan los datos que no se consideraron ENTIDADES o ATRIBUTOS

pero, en cambio, representan relaciones entre aquellas.
1) Se deben eliminar los relacionamientos redundantes.
Significa que, aunque están permitidos dos o más relacionamientos

entre dos mismas entidades, debemos cuidar de que tales relacionamientos
no representen lo mismo.
2) Definir, sólo de ser necesario, relacionamientos ternarios.
Se refiere a que en ciertos casos podría ser necesario o útil,

considerar un relacionamiento ternario en lugar de, por ejemplo, dos
binarios u otra alternativa.
EJEMPLO DE MODELAMIENTO DE DATOS : METODOLOGIA VARIANTE DE P.CHEN

Vendedor
N 1 1
Pasajero Boleto
1 N
Bus Mante-
nimiento
1
Ciudad
1
1 N
N Piloto
EJEMPLO DE MODELAMIENTO DE DATOS : METODOLOGIA DE JAMES MARTIN
Boleta
Habitación Huesped Empleado
Servicio
Comprobante

RESUMEN DE ALGUNAS NOTACIONES : SEGÚN METODOLOGIA DE AUTORES
A se relaciona A se relaciona A se relaciona A se relaciona

con B con 1 o más B con 1 o ning. B con “0” o mas B
CH A (1,1) B A (1,n) B A (0,1) B A (0,n) B
MT A B A B A B A B
SH A B A B A c B A c B
CH : CHEN MT : MARTIN SH : SHLAER
3.3 MODELO DINAMICO DEL SISTEMA : EL D.T.E.
Enfatiza el comportamiento del Sistema, dependiente del tiempo

(Yourdon). En la mayoría de los casos, este comportamiento ha importado a
una categoría especial de sistemas, conocidos como Sistemas de tiempo
real. Entre ellos, podemos mencionar:
 Control de procesos.
 Conmutación telefónica
 Control y Mando Militares
 Captura de datos de alta velocidad.
Los sistemas de este tipo manejan normalmente fuentes externas de

datos de alta velocidad y deben proporcionar alguna respuesta y datos de
salida de manera rápida.
Para los sistemas orientados a negocios de tamaño promedio, lo

anterior no es tan importante por lo general, pues no es tan crítico el
aspecto del tiempo. Es, sin embargo, muy importante en grandes y complejos
sistemas de negocios de hoy, que manejen aspectos de tiempo real en su
comportamiento, tales como:
- Sistemas con entradas de miles de terminales.

- Sistemas con entradas de alta velocidad.
- Sistemas de satélites de comunicaciones.

Por lo anterior, aunque no tengamos (como en nuestro caso) que tratar

con tales problemas, debemos tener conceptos del modelaje para sistemas
con comportamiento dependiente del tiempo.
3.3.1 NOTACION PARA LOS DIAGRAMAS DE TRANSICION DE ESTADOS
1) ESTADO.- Muestra algún comportamiento del sistema que es observable y

que perdura durante algún período finito. Es la situación en la que se
encuentra una persona o cosa en un momento determinado. Se representa
mediante un RECTANGULO. Las situaciones más comunes se refieren a sistemas
de procesos no orientados a negocios, algunos de los cuales son, por
ejemplo:
- Esperar a que un usuario dé su contraseña de acceso.

- Acelerar un motor.
- Esperar datos de un instrumento.
Notamos, de los ejemplos, que la mayor parte implican que el sistema

está "esperando a que algo ocurra" o muestran la porción de interface
humana que la mayoría de los sistemas en línea tiene, y NO expresan que la
computadora "esté haciendo algo". Así, cualquier estado observable en el
que el sistema se pueda encontrar, sólo puede corresponder a períodos en
los que:
a) Está esperando que algo ocurra en el ambiente externo.

b) Está esperando que una actividad actual, cambie a otra.
2) CAMBIO DE ESTADO.- Que muestra el cambio de una actividad a otra, de

un ente (persona o cosa). Se representa mediante FLECHAS que conectan un
estado con otro, como en el presente ejemplo de un CONTESTADOR TELEFONICO.
En Reposo
Esperando llamada Grabando mensaje Rebobinando Dando el mensaje
Responde llamada
3) CONDICIONES Y ACCIONES.- Las condiciones causan un cambio de estado y

las acciones se refieren a lo que el sistema hace cuando cambia de estado.
Ambas se colocan junto a la flecha que conecta dos estados relacionados.
Un ejemplo para un CAJERO AUTOMATICO, resume la notación del DTE.
En reposo

Se presionó “Inicio”
[Dá mensaje “inserte tarjeta”]
Se dió “Reinicio”
Esperando tarjeta
Tarjeta insertada
[Despliega “Ingrese contraseña”] “Reinicio”o mal contraseña
[ Borra pantalla ]
Esperando contraseña
Contraseña ingresada Se dió “Reinicio”

[Despliega “Seleccione función”] [ Borra pantalla ]
Esperando elección
Dá efectivo Dá estado cuenta Deposita fondos
3.4 EL DICCIONARIO DE DATOS
Aunque no tiene la presencia de los DFDs, DERs o DTEs, los DD son

cruciales. Sin los diccionarios de datos, el modelo de los requerimientos
del usuario no puede considerarse completo; todo lo que se tendría es una
información relativa, "una visión" del sistema. Sin el diccionario de
datos, el usuario, por ejemplo, no podrá estar seguro de que entendió los
detalles de la aplicación.
El diccionario de datos es un listado organizado de todos los datos

pertinentes al sistema, con definiciones precisas para que tanto el
usuario como el analista tengan un entendimiento común de todas las
entradas, salidas, almacenes de datos y cálculos intermedios.
NOTACION DEL DICCIONARIO DE DATOS
Para una notación concisa y compacta, existen muchos esquemas comunes

utilizados por los analistas de sistemas. Aquí mostramos uno de los más
comunes y usa símbolos sencillos (Yourdon):
* Para describir el significado del término.

** Indica definición conocida (significado universal).
= Significa : "está compuesto de".
+ Significa : "y".
@ Identificador de atributo clave.
() Optativo (puede estar presente o ausente).

{ } Iteración (Para representar ocurrencias de un dato)

[ ] Seleccionar una de varias alternativas.
| Separador de alternativas.
DEFINICIONES RESPECTO AL DD
ALIAS.- Es una alternativa de nombre para un dato cuando se trata con

diversos grupos de usuarios en distintas áreas y se insista en usar
distintos nombres para decir lo mismo. Permite mayor claridad y se
relaciona con el nombre primario u oficial.
LONGITUD.- Número de caracteres que ocupa un dato.

DATO ELEMENTAL.- Es el nivel más importante de datos. Es la unidad más
pequeña con un significado para los analistas de sistemas o usuarios. Por
ejemplo, el número de la factura, su fecha de expedición y la cantidad,
son datos elementales incluídos en el flujo de datos de la facturación.
Los datos elementales son las unidades básicas para todos los demás datos
del sistema. Por sí mismos no implican suficiente significado para ningún
usuario.
USO DEL DICCIONARIO DE DATOS CON EL DFD
La existencia del diccionario utilizado como herramienta de apoyo,

respecto al DFD, sirve para describir el significado de los procesos,
flujos y almacenes que se muestran en los DFD.
USO DEL DICCIONARIO DE DATOS CON EL DER
En el enfoque estructurado, el diccionario de datos, además de ser

usado para detallar los flujos de datos, los almacenes y las
especificaciones de procesos que corresponden al DFD, debe extenderse para
incluir los detalles de un DER. Estos detalles implican las relaciones
entre las entidades en un DER.
Lo más significativo que debemos recordar es que, en lo general, LAS

ENTIDADES DE UN DER SE CORRESPONDEN CON LOS ALMACENES EN UN DFD.
EJEMPLO DE DESCRIPCIÓN EN UN DICCIONARIO DE DATOS
Alumno Alias: Estudiante
* Constituye la entidad más importante en la Facultad y por

consiguiente la fuente principal de información. Ellos alimentan al
sistema y también toman datos del mismo *
@Cod_Alum + Nomb_Alum + Cod_Fac + Direc
ALUMNOS = {Alumno}

Curso Alias: Currícula
* Cada materia que el estudiantelleva en un período académico *
@Cod_Cur + Nomb_curso + Thrs
CURSOS = { Curso }
Detalle de alumno
* Corresponde a tener a la vista, los datos personales básicos de un

alumno. *
Detalle de curso
* Indica que se verifica, teniendo a la vista, los datos básicos de un

curso *
3.5 OTRAS ESPECIFICACIONES : HERRAMIENTAS CASE
HERRAMIENTAS CASE COMO APOYO AL MODELAMIENTO DE SISTEMAS.
CASE, (Computer Aided Software Engineering) agrupa a una serie de

productos destinados a la automatización de la producción de Sistemas. En
general, existe una clasificación específica para los CASE:
 Los UPPER CASE automatizan, escencialmente las etapas de

planificación, análisis y diseño.
 Los LOWER CASE automatizan la fase de generación de código.
La aplicación de metodologías debe considerarse una política de

mediano plazo en la Empresa. No es cómoda y rápida de implantar y genera
costos de capacitación del personal, pero no hay otro camino. El
beneficio a buscar: Tiempo más corto de desarrollo una vez asimilada, una
mayor calidad del producto, con menores costos de mantenimiento y mejor
documentación e información del sistema.
El futuro del desarrollo de S.I. está ligado al uso generalizado

(por parte de los especialistas) de metodologías de desarrollo soportadas
por herramientas CASE. La representación de flujos de procesos y de los
datos y sus relaciones permiten clarificar el funcionamiento del Sistema,
antes de atacar el desarrollo.
Es necesario recalcar que, dado que los CASE se basan en la

propuesta sugerida por determinadas metodologías, es necesario que el
analista tenga conocimiento previo de la existencia y conceptos en que se
basan dichas metodologías.

Los CASE actualmente más accesibles en el mercado, para un nivel

intermedio, soportan , cada uno en su enfoque, las metodologías públicas
de mayor acceso hoy en día. Así por ejemplo:
EASY CASE : Upper Case para Análisis y Diseño Estructurado. Permite

trabajar con los tres modelos: funcional, de datos y dinámico y soporta
varias metodologías: Yourdon, Martin, Chen, entre otras.
ERWIN : Orientado hacia el modelo de datos (diseño lógico y físico) y

permite una interface que se comporta como un DDL (Data Definition
Languaje ~ Lenguaje de definición de datos).
WITH CLASS : (Upper Case para ADOO, distribuída inicialmente en Perú, por
M+S, en Shareware). Soporta el modelamiento planteado por la metodología
OMT de James Rumbaugh.
RATIONAL ROSE : Herramienta CASE para modelamiento y diseño creado para

equipos de desarrollo visual. Existe en versiones: modelador, profesional
y empresarial. Requiere unos 100 Mb. Está trabajando paralelamente al
proyecto de unificación de metodologias de modelamiento para desarrollo de
sistemas con enfoque O-O (UML). Se comporta mínimamente como interface DDL
(generando codigo de definición de tablas de base de datos).

CARACTERISTICAS DE LA HERRAMIENTA : EASY CASE
EasyCASE (Computer Aided Software Engineering) es una herramienta

CASE basado en diccionario de datos que asiste en proyectos de desarrollo
estructurado de análisis de sistemas en la etapa de análisis (modelo
funcional, modelo de datos y modelo dinámico).
METOLOGÍAS SOPORTADAS:
Yourdon/DeMarco
Gane & Sarson
SSADM
Ward-Mellor
Martin
Chen
Bachman
IDEFIX
TIPOS DE DIAGRAMAS:
Data Flow Diagrams (DFDs)
Transformation Schema (real-time DFDs)
Structure Charts (STCs)
State Transition Diagrams (STDs)
Entity Relationship Diagrams (ERDs)
Data Model Diagrams (DMDs)
Data Structure Diagrams (DSDs)
HERRAMIENTA CASE : EASYCASE

ELABORANDO UN PROYECTO CON EASY CASE
1.- Crear, dentro de la carpeta denominada "Ecwin" una nueva carpeta con
un mobre para el proyecto a elaborar (y donde se guardarán todos los
diagramas).
2.- Para ingresar a EasyCase Seleccionar: Inicio

Programas
EasyCASE Professional 4.22
EasyCASE muestra una identificación del usuario mediante "User Name". El

nombre que allí aparece (en este caso "Manuel" es el nombre que se le dio
a la máquina cuando ella fue instalada. Si queremos trabajar con un
proyecto creado con un nombre de usuario diferente (de otra máquina), se
deberá indicar el nombre de dicho usuario. Luego hacer clic en "OK".
3.- Al mostrarse la ventana de diálogo "Project", se debe seleccionar la

carpeta creada dentro de ECWIN (del paso 1) y hacer clic en botón "Open".
Como nota aclaratoria: En dicha carpeta se observará una "P" si es que un
proyecto ya fue trabajado antes, de lo contrario no.
Además, cuando se trata de un nuevo proyecto a crear (sólo en dicho

caso), EasyCASE nos muestra la ventana de diálogo. Hacer clic en
"Aceptar".

Easy CASE For Windows
Manuel es el primer usuario en el proyecto actual. A Manuel se le han

asignado las responsabilidades de administrador del proyecto
Aceptar Cancelar
4.- Easy case visualiza la ventada "Create New Project Configuration".

Ahí se deben seguir 4 pasos secuenciales obligatorios, como se indica
(aún no hacer clic en "OK" !!) :
A.- Escribir allí el nombre del sistema

B.- Seleccionar la metodología (autor) para el modelo de procesos.
C.- Seleccionar la metodología (autor) para el modelo de datos.
D.- Hacer clic en el botón para Definir el diagrama de contexto.
5.- Se muestra la ventana de diálogo "Create context diagram". Aquí se

digita el nombre del 1ER diagrama en "Context Name", y luego "OK".
6.- Se vuelve a mostrar la ventana "Create New Project Configuration".

Ahora hacer clic en "OK". Se mostrará la ventana "New Object", allí dar
el nombre del proceso principal (Sistema) y "OK". Finalmente se muestra
la pizarra de trabajo para comenzar a elaborar el modelo de procesos
(DFD). AL finalizar cada modelo, usar la opción "Save All", de "File".

DESCRIPCION DE ELEMENTOS BASICOS DE EASY CASE
BOTONES PRINCIPALES DE LA BARRA DE HERRAMIENTAS
A B C D E F G H 1 2 3 4 5 6 7 8 9
A : Crear un nuevo diagrama

B : Abrir un diagrama existente
C : Grabar cambios hechos a un diagrama
D : Imprimir diagrama actual
E : Editar el nombre del objeto para modificación
F : Editar el número del objeto para modificación
G : Define la explosión del proceso seleccionado
H : Edita el diccionario de datos para el objeto seleccionado
1 : Zoom rápido
2 . Zoom 10% , arriba / abajo
3 . Grid : On / Off
4 : Regleta : On / Off
5 : Paleta de objetos : On / Off
6 : Perspectiva : On / Off
7 : Abre padre de diagrama actual
8 : Explota el proceso actual
9 : Abrir diagrama en jerarquía.

PALETA DE OBJETOS PARA DFD (Yourdon)

1 2 3 4 5
1 : Devuelve el modo edición 5 : Almacén de datos

2 : Entidad externa 6 : Divis. flujo compuesto
3 : Proceso 7 : Flujo
4 : Proceso instancia 8 : Texto para títulos
6 7 8
COLOCAR OBJETOS DFD SOBRE LA PIZARRA
1. Seleccionar con el mouse el objeto (Entidad externa, proceso, flujo, etc.) deseado, desde la
paleta de objetos.
2. Colocar el objeto sobre una parte de la pizarra, haciendo clic sobre ella.
3. Redimensionar o acomodar el objeto en una nueva posición (opcional).
4. Colocar otros objetos (Opcional, pues se puede proceder a darle un nombre)
ESTABLECER UN NOMBRE A CADA OBJETO DFD
1. Seleccionar con el mouse el objeto (Entidad externa, proceso, flujo, etc.).

2. Pulsar el botón derecho del mouse.
3. Del menú contextual seleccionar “name”.
4. En el cuadro de diálogo, dar un nombre apropiado.
CONECTAR OBJETOS DFD MEDIANTE OBJETO FLUJO ( )
1. Seleccionar el objeto flujo, desde la paleta de objetos.

2. Seleccionar el objeto ORIGEN, desde el cual iniciar la conexión.
3. Desde la matriz de enlaces que aparece, seleccionar en forma específica el cuadrito en la
posición desde la cual empezar la conexión y, sin soltar el botón del mouse, arrastrar el flujo
hasta el objeto DESTINO.
4. Hacer clic sobre el objeto DESTINO para que aparezca la matriz de enlaces y, en ese momento,
seleccionar específicamente el cuadrito de la posición en la que se desea terminar la conexión.

PALETA DE OBJETOS PARA DER (J. Martin)
1 2 3 4 5
1 : Devuelve el modo edición 6 : Exclusividad mutua

2 : Entidad 7 : Relación
3 : Entidad débil 8 : Subtipo/Supertipo
4 : Entidad asociativa 9 : Texto para títulos
5 : Entidad partida
6 7 8 9
COLOCAR ENTIDADES DER SOBRE LA PIZARRA
1. Seleccionar con el mouse la entidad deseada, desde la paleta de objetos.

2. Colocar la entidad sobre una parte de la pizarra, haciendo clic sobre ella.
3. Redimensionar o acomodar la entidad en una nueva posición (opcional).
4. Colocar otras entidades (opcional, pues se puede proceder a darle un nombre)
ESTABLECER UN NOMBRE A CADA OBJETO DER
5. Seleccionar con el mouse la entidad a nombrar.

6. Pulsar el botón derecho del mouse.
7. Del menú contextual seleccionar “name”.
8. En el cuadro de diálogo, dar un nombre apropiado.
CONECTAR ENTIDADES DER CON OBJETO RELACION
1. Seleccionar el objeto flujo, desde la paleta de objetos.

2. Seleccionar la entidad ORIGEN, desde el cual iniciar la conexión.
3. Desde la matriz de enlaces que aparece, seleccionar en forma específica el cuadrito en la
posición desde la cual empezar la conexión y, sin soltar el botón del mouse, arrastrar la
RELACION hasta la entidad DESTINO.
4. Hacer clic sobre la entidad destino para que aparezca la matriz de enlaces y, en ese momento,
seleccionar específicamente el cuadrito de la posición en la que se desea terminar la conexión.
5. La cardinalidad por omisión es : muchos a muchos.
ESTABLECER NUEVA CARDINALIDAD A UNA RELACION DER.
1. Seleccionar con el mouse el objeto RELACION deseado.

2 Pulsar el botón derecho del mouse.
3. Del menú contextual seleccionar .
4. En el cuadro de diálogo, seleccionar la cardinalidad para el inicio (Start) y fin (End) para la
relación. El start corresponde al lado izquierdo (o superior) y el end corresponde al lado
derecho (o superior) del objeto relación seleccionado.

NOTA: Luego de colocado cada objeto, es indistinto nombrarlos primero o conectarlos antes o
viceversa.
CUADRO DE DIALOGO PARA IMPRIMIR DESDE EASY CASE
Variar la escala para acomodar al papel
Mediante la opción “Print Scale” se puede cambiar la escala acomodándola al papel.
Crear un archivo .PRN
Mediante un CHECK a “Print to file”, aunque es más recomendable la opcion “export” de “Tools”.
Establecer carácterísticas en la impresora
Hacer click sobre el botón “Setup”.

Fases Del Desarrollo de Sistemas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fases Del Desarrollo de Sistemas

Cargado por

Copyright:

Formatos disponibles

UNJBG Facultad de Ciencias Administrativas

FASES DEL DESARROLLO DE SISTEMAS

CAPITULO I: ANALISIS PRELIMINAR

A) PLANEAMIENTO ESTRATEGICO Y SISTEMAS DE INFORMACION

Política reactiva en sistemas de información. – Considera los sistemas

 Problemas: Situaciones no deseables que impiden a la

Política proactiva en sistemas de información.- Esta ve a los sistemas

El desarrollo del plan estratégico de sistemas de información puede

B) PRINCIPIOS GENERALES QUE DEBE CONSIDERAR UN DESARROLLO DE SISTEMAS

- Implicar al usuario.- Que las soluciones cuenten con la

Prof. Manuel Alvarado 1

- Contemplar la posibilidad de cancelar/revisar el proyecto.- El

C) EL CICLO DE VIDA DE DESARROLLO DE SISTEMAS

Es un proceso mediante el cual el conjunto de especialistas y los

El ciclo de vida de desarrollo de sistemas es un proceso totalmente

ALGUNOS ENFOQUES DEL CICLO DE VIDA DE DESARROLLO DE SISTEMAS

 YOURDON, “Análisis estructurado moderno”

 BURCH/GRUDNITSKI, “Diseño de sistemas de información”

 PLANEAMIENTO ESTRATEGICO DE SISTEMAS DE INFORMACION

 RUMBAUGH/BLAHA, “Modelamiento y diseño orientado a objetos”

Prof. Manuel Alvarado 2

2.1 EQUIPO DEL PROYECTO

Depende del tamaño de la Institución y de la existencia/ausencia de

2.2 DEFINICIÓN DEL PROBLEMA / JUSTIFICACION

 Definición del problema

2.3 ESTUDIO DE FACTIBILIDADES

Prof. Manuel Alvarado 3

2.4 ESTABLECIMIENTO DE OBJETIVOS DEL SISTEMA

2.5 CRONOGRAMA DEL PROYECTO

2.6 IDENTIFICACIÓN Y DEFINICIÓN DE REQUISITOS

2.6.1 INTRODUCCION Y OBJETIVOS

Las entrevistas constituyen el medio de obtener información sobre:

Por esta razón, la preparación y realización de las entrevistas juega un

En muchas ocasiones puede ser conveniente sustituir la tradicional

Adicionalmente, si no existiera un planeamiento estratégico de sistemas

2.6.2 RECOMENDACIONES DE DESARROLLO DE ENTREVISTAS

A continuación se dan unas recomendaciones generales sobre la técnica de

2.6.3 PREPARACION DE CUESTIONARIO (GUION).

Prof. Manuel Alvarado 4

Antes de realizar una entrevista es imprescindible enviar al usuario a

1. Entrevistas a los responsables de área.

1.5 Identificar al resto de los usuarios del departamento o grupo

Al final de la entrevista se levantará un acta de la reunión,

2. Entrevistas al resto de los usuarios.

Prof. Manuel Alvarado 5

2.2 Requisitos del Nuevo Sistema.

Prof. Manuel Alvarado 6

 La experiencia del entrevistador y su conocimiento del sistema

Una vez realizada la entrevista con el usuario, es conveniente

Para lo anterior se utilizarán técnicas de representación para

Por último, en el caso que se disponga de las herramientas necesarias,

 Las pantallas de que consta.

Estos prototipos ayudarán al usuario a especificar y concretar sus

2.7 ALCANCE (AMBITO DEL PROYECTO)

2.8 RESTRICCIONES (LIMITACIONES)

2.9 DISEÑO DEL MODELO ACTUAL (ARQUITECTURA DEL SISTEMA)

Prof. Manuel Alvarado 7

 Modelo de procesos actual

2.10 ESTUDIO DE ALTERNATIVAS DE CONSTRUCCIÓN

 Plantear soluciones alternativas previas como avance al análisis.

Prof. Manuel Alvarado 8

CAPITULO II : ANALISIS DEL SISTEMA

El análisis de sistemas comprende las siguientes actividades básicas: