Fases Del Desarrollo de Sistemas para EXA 02

UNJBG Facultad de Ciencias Administrativas
FASES DEL DESARROLLO DE SISTEMAS
CAPITULO I: ANALISIS PRELIMINAR
1. GENERALIDADES
A) PLANEAMIENTO ESTRATEGICO Y SISTEMAS DE INFORMACION
Poltica reactiva en sistemas de informacin. Considera los sistemas

de informacin como arma defensiva tctica de la organizacin, para
hacer frente a los requerimientos de proceso de datos. Esta es la
situacin 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 acta como
reaccin a tales necesidades. Tales situaciones provienen de la
combinacin de:
2
Problemas: Situaciones no deseables que impiden a la
Organizacin alcanzar plenamente sus propsitos.
Oportunidades: Posibilidades de mejorar la Organizacin
inclusive ante ausencia de problemas (Ejm: reduccin de costos).
Normas: Todas nuevas disposiciones interna o externas.
1 Poltica proactiva en sistemas de informacin.- Esta ve a los

sistemas de informacin como un arma ofensiva estratgica, que permite
a la organizacin una ventaja competitiva. Se visualizan como una
forma no slo de reducir costos sino de aumentar ingresos. Esta
poltica se concibe en los altos niveles de decisin, los que
entienden la necesidad de alinear los sistemas de informacin como
soporte de apoyo al logro de las metas trazadas en el planeamiento
estratgico de la organizacin.
El desarrollo del plan estratgico de sistemas de informacin puede

comprender estas tres etapas (Burch, Diseo de S.I):
3
a) Establecer las metas de los S.I.
b) Asignar prioridades a las solicitudes de proyectos de S.I.
c) Determinacin de recursos y capacidad de los S.I. seleccionados.
B) 4 PRINCIPIOS GENERALES QUE DEBE CONSIDERAR UN DESARROLLO DE SISTEMAS
- Implicar al usuario.- Que las soluciones cuenten con la

participacin activa del usuario en cuanto a requerimientos e
interfaces.
- Aplicar una metodologa uniforme.- Que todo desarrollo de sistemas
dentro de la organizacin siga una metodologa formal, utilizada
por todos.
- Justificar los sistemas como inversiones de capital.- Evaluar la
viabilidad de cada alternativa existente en trminos 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 relacin con
el marco general.
- Establecer diseos para situaciones crecientes y cambiantes.- Tomar
en cuenta el desarrollo para afrontar las condiciones cambiantes de
hoy, y recordar la caracterstica de entropa, comn 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
informacin. Actualmente es una herramienta de gestin 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 poltica imperante en la organizacin respecto a
los sistemas de informacin (reactiva o proactiva).
ALGUNOS ENFOQUES DEL CICLO DE VIDA DE DESARROLLO DE SISTEMAS
5 YOURDON, Anlisis estructurado moderno

CICLO DE VIDA ESTRUCTURADO
BURCH/GRUDNITSKI, Diseo de sistemas de informacin

PLANEACION, DESARROLLO Y ADMINISTRACION DE SISTEMAS DE INFORMACION
RUMBAUGH/BLAHA, Modelamiento y diseo orientado a objetos

DESARROLLO ORIENTADO A OBJETOS
2. ANALISIS PRELIMINAR
2.1 EQUIPO DEL PROYECTO
Depende del tamao de la Institucin 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 DEFINICIN DEL PROBLEMA / JUSTIFICACION
Definicin del problema

Antecedentes (proyectos relacionados)
2.3 ESTUDIO DE FACTIBILIDADES

6 FACTIBILIDAD ECONOMICA
FACTIBILIDAD OPERATIVA
FACTIBILIDAD TECNICA
FACTIBILIDAD LEGAL
FACTIBILIDAD ECONOMICA
Costo del hardware y software para las aplicaciones del sistema
Beneficios en cuanto a reduccin de costos con el nuevo sistema,
respecto al actual
Costo de no llevar a cabo la implantacin del nuevo sistema
Otros
FACTIBILIDAD OPERATIVA
Existe apoyo necesario de la alta direccin?
El sistema ser aceptado por los usuarios?
Participarn los usuarios en la planeacin y desarrollo?
Generar impacto adverso el sistema propuesto?
Grado de apoyo del sistema a los procesos existentes?
Otros
7 FACTIBILIDAD TECNICA
Capacidad tcnica del equipo del proyecto de sistema.
Existe o se puede adquirir el equipamiento para el proyecto?
El sistema generar respuestas adecuadas considerando el nmero y
ubicacin de usuarios?
El sistema se adecuar a situaciones crecientes y cambiantes?
Otros
FACTIBILIDAD LEGAL
Existe algn tipo de restriccin legal para desarrollar nuevo
sistema?
Otros
2.4 ESTABLECIMIENTO DE OBJETIVOS DEL SISTEMA
General
Especficos
2.5 CRONOGRAMA DEL PROYECTO
Diagrama Gantt
Diagrama PERT
2.6 IDENTIFICACIN Y DEFINICIN DE REQUISITOS

TECNICA: ENTREVISTA
2.6.1 INTRODUCCION Y OBJETIVOS
Las entrevistas constituyen el medio de obtener informacin sobre:

Los requisitos de usuario.
Funcionamiento del sistema actual.
Organizacin de la Unidad.
Responsabilidades y funciones de los usuarios.
Por esta razn, la preparacin y realizacin de las entrevistas juega un

papel primordial en las primeras etapas del desarrollo de sistemas, ya
que stas permitirn 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 Organizacin, como por ejemplo,
distintas unidades que realizan funciones similares y el objetivo es
crear un estndar para unificar el procedimiento.
Adicionalmente, si no existiera un planeamiento estratgico de sistemas

en la Organizacin, ser til aprovechar la ocasin para sentar las bases
para la elaboracin de un Plan de Sistemas de la Organizacin. La
realizacin de reuniones en grupo permite establecer nuevas ideas,
prioridades y objetivos al interior de la Organizacin.
2.6.2 RECOMENDACIONES DE DESARROLLO DE ENTREVISTAS
A continuacin se dan unas recomendaciones generales sobre la tcnica de

entrevistas, haciendo nfasis en dos aspectos esenciales de las mismas:
Preparacin de un cuestionario (guin) para la entrevista.
Consolidacin 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
guin ha de ser suficientemente detallado para cubrir todos los aspectos
de inters, y dar oportunidad al usuario a preparar documentacin sobre
el sistema. Sin embargo, debe existir cuidado respecto a la extensin del
guin o cuestionario previo, evitando excesivos detalles.
Es importante elaborar el cuestionario, atendiendo al perfil y a
las responsabilidades del usuario a entrevistar. A continuacin, se
exponen una serie de consideraciones sobre los aspectos a tener en
cuenta, en funcin de dicho perfil de usuarios:
8 1. Entrevistas a los responsables de rea.
2. Entrevistas al resto de los usuarios.

El objeto de estas entrevistas es detallar aspectos funcionales ms
concretos. El guin para estas entrevistas deber contemplar:
2.1 Situacin Actual.

Descripcin de los sistemas de informacin actualmente

implantados (ya sean manuales o informatizados). Incluir:
2.1.1 Entorno fsico/lgico 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 electrnico de
datos, disquete, cinta magntica).
Frecuencia (tiempo real, varias veces al da,
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).
Datos involucrados.
Soporte (papel, intercambio electrnico de datos,
disquetes, cinta magntica).
Frecuencia (tiempo real, varias veces al da,
diariamente, semanalmente, etc)
2.1.5 Volumen de informacin manipulada.
2.1.6 Por sistema de informacin, 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 satisfaccin tcnica con los sistemas
actuales. La valoracin incluir aspectos como:
Disponibilidad de los sistemas de informacin.
Tiempos de respuesta.
Facilidad de uso.
Tiempo de espera si se piden modificaciones.
Puede utilizarse la tabla anterior para ponderar la
evaluacin.
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:
Datos involucrados.
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 crticos de xito.
CONSIDERACIONES.

Debe tenerse en cuenta que lo expuesto en esta tcnica es slo una

visin general de los aspectos ms relevantes que deben ser
tratados en cada tipo de entrevista. Para cada proyecto, deber
confeccionarse un guin detallado de las entrevistas que se
realicen, segn sea:
El tipo de proyecto.
El usuario entrevistado.
La experiencia del entrevistador y su conocimiento del sistema
analizado.
El guin de la entrevista se entregar con suficiente anticipacin
al responsable de usuarios, para que ste pueda garantizar su
distribucin a las personas involucradas.
En la realizacin de una entrevista, se abordarn los puntos a
tratar desde una visin general, al principio, para centrarse
gradualmente en aspectos ms detallados.
Consolidacin 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 utilizarn tcnicas de representacin para

ilustrar el funcionamiento del sistema actual, mediante un dibujo libre,
que permita contrastar con el usuario, el flujo de la informacin a
travs del sistema, as como las diversas tareas y responsabilidades en
el uso de esa informacin. Adems, se especificarn los requisitos de
usuario de una forma sencilla y medible, de manera que se pueda asignar
prioridades a dichos requisitos, y se validarn conjuntamente con el
usuario, dichas prioridades.
Por ltimo, en el caso que se disponga de las herramientas necesarias,

se podrn elaborar prototipos iniciales (los que se refinarn en el
anlisis y diseo) o maquetas simples del nuevo sistema, en los que
figuren:
9
Las pantallas de que consta.
Los informes a obtener.
La simulacin de las funciones que realiza.
La apariencia externa del mismo.
Estos prototipos ayudarn al usuario a especificar y concretar sus

necesidades.
2.7 ALCANCE (AMBITO DEL PROYECTO)
Personas
Grupos
2.8 RESTRICCIONES (LIMITACIONES)

De equipo
Polticas
Econmicas
Tecnolgicas
2.9 DISEO DEL MODELO ACTUAL (ARQUITECTURA DEL SISTEMA)
Modelo de procesos actual

Modelo de datos actual
2.10 ESTUDIO DE ALTERNATIVAS DE CONSTRUCCIN
Plantear soluciones alternativas previas como avance al anlisis.

CAPITULO II : ANALISIS DEL SISTEMA
3.0 GENERALIDADES
El anlisis de sistemas comprende las siguientes actividades bsicas:
Resumen de los requerimientos del ususario.

Construccin del modelo lgico del nuevo sistema
Definicin 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 anlisis, diseo y las dems
etapas del desarrollo.
CONSTRUCCIN DEL MODELO LGICO DEL SISTEMA ACTUAL (OPCIONAL)
Alternativamente se puede representar mediante un modelo lgico, el

funcionamiento del sistema actual. La elaboracin de este modelo, permite
profundizar en el conocimiento del sistema actual y facilitar la
identificacin de los sistemas existentes.
Las funciones de la Unidad que el sistema brinda apoyo.

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

aspectos funcionales del sistema existente, logrando as:
Identificar las principales entradas (aquella informacin que

ser utilizada como fuente) del sistema.
Identificar las principales funciones (los principales procesos)
que ejecuta el sistema tomando como base la informacin fuente.
Identificar las principales salidas, (tipos de informacin que
genera) el sistema.
Esta revisin de los aspectos del sistema existentes, facilitar la

identificacin de nuevos requisitos que debe satisfacerse.
CONSTRUCCIN DEL MODELO LGICO DEL NUEVO SISTEMA
Esta actividad tiene como objetivo resumir el funcionamiento del sistema

actual, de un modo conceptual (representado grficamente con el modelo

lgico), y las nuevas alternativas propias del nuevo sistema a proponer,

es decir muestra a la organizacin en trminos de las funciones
(procesos) que realiza y en trminos de los datos involucrados en dichos
procesos.
Para realizar con xito esta actividad se deben de realizar las

siguientes Tareas:
Construccin del modelo actual de proceso, y nuevas alternativas.

Construccin del modelo lgico actual de datos y nuevas
alternativas.
11 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)
Cul 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 ms bien rico en DATOS. En sistemas de hace una o dos
dcadas atrs esto podra hacer muy dudosa la decisin, pero hoy que los
sistemas tienden a ser cada vez ms 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 representacin de un sistema

mediante un modelo lgico. Esto facilita la comprensin 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 sinnimos usados para DFD son: Diagrama de burbujas y
modelo de procesos.
Smbolos del DFD: 1) PROCESO 2) FLUJO 3) ALMACEN 4) ENTIDAD EXTERNA
Un DFD permite representar la divisin 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 representacin del sistema mediante el uso de una

notacin 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 anlisis con DFD debe:

Ser grfico.
Ser preciso y breve.
Ser comprensible.
Ser debidamente particionado en niveles.
Ser bien documentado.
No ser redundante.
Establecer "Qu" Funciones se desarrollan, sin implicar "Cmo".
No ambiguo.
3.1.1 ELEMENTOS BASICOS
10 Los elementos bsicos que aparecen en cualquier Diagrama de Flujo de

Datos, son los siguientes:
Entidad Externa.
Proceso.
Flujo de datos.
Almacn de datos.
12
1. Puede aparecer en los distintos niveles del DFD. ENTIDAD
2. Puede aparecer varias veces en un mismo diagrama, para evitar
entrecruzamientos de lneas. ENTIDAD
3. No es ni origen ni final de los datos, slo lugar de transformacin de
los mismos. PROCESO
4. No debe estar referido al entorno fsico ALMANCEN
5. No es un activador de procesos. FLUJO
A) ENTIDAD EXTERNA (TERMINADOR)
Las Entidades Externas representan entes ajenos a nuestra aplicacin,

pero que aportan o reciben informacin de la misma (con los cuales el
sistema se comunica). Normalmente un "terminador" es una persona o un
grupo, por ejemplo, una organizacin externa o una agencia gubernamental o
un grupo o departamento que est dentro de la misma compaia u
organizacin, pero fuera del control del sistema que se est modelando. En
algunos casos, un "terminador" puede ser otro sistema con el cual hay
comunicacin.
Siendo externos, ni el analista ni el diseador del sistema estn 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 definicin, no son parte del sistema que se
est estudiando (yourdon). Se representan mediante un rectngulo.
NOMBRE


8. No es ni origen ni final de los datos, slo lugar de transformacin de
los mismos. PROCESO
Reglas de Construccin:
9. Representa personas, organizaciones o sistemas que no pertenecen al

sistema.
10. En el caso que las entidades externas se comuniquen entre s, sto,
no se contemplara en el diagrama, por estar fuera del mbito de
nuestro sistema.
13. No es ni origen ni final de los datos, slo lugar de transformacin
de los mismos. PROCESO
14. No debe estar referido al entorno fsico ALMANCEN
15. No es un activador de procesos. FLUJO
16. Suministra informacin acerca de la conexin 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 oracin sencilla que describe lo que
este "hace". Su representacin dentro del DFD es (segn gane/sarson y
yourdon/de marco respectivamente):
NIVEL
NIVEL
NOMBRE NOMBRE
NOMBRE representa un proceso determinado.
NIVEL representa el nmero que identifica al proceso y el nivel del DFD

en que nos encontramos. Es importante aclarar que este nmero no indica
necesariamente secuencia de realizacin del proceso, dado que los DFD no
representan una continuidad en el tratamiento de los datos.
Reglas de Construccin:
Cuando un Flujo de datos entra en un proceso, sufre una

transformacin. No es ni origen ni final de los datos, slo lugar de
transformacin 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 Almacn de Datos.
C) ALMACN DE DATOS
Un almacn de datos representa un depsito de informacin dentro del

sistema. Muestra colecciones (o agregados) de datos EN REPOSO que el
sistema debe recordar por un perodo de tiempo. Cuando los diseadores
de Sistemas y los programadores terminan de construir el sistema, estos
almacenes existirn 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 almacn tambin pudiera consistir de datos en microfilm, disco
ptico o algunas ms de otras posibles formas electrnicas (yourdon).
Su representacin dentro del DFD es (segn gane/sarson y yourdon/de marco

respectivamente):
NOMBRE
ID NOMBRE
En la parte derecha se indica el nombre del almacn de datos y en la

parte izquierda se representa la identificacin de dicho almacn dentro
del DFD. Si dentro de un DFD aparece repetido el mismo almacn de datos,
se le puede representar con dos lneas 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 informacin (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 tcnicas
utilizadas en la Fase de Anlisis, se establecer una relacin precisa
entre los almacenes de datos "principales" de un DFD y las entidades
de los Diagramas Entidad-relacin del modelo de datos. "Cada almacn
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 almacn principal de un DFD". Esto facilitar las validaciones
cruzadas entre los dos diagramas.
Reglas de construccin:
Representa la informacin en reposo.

No puede crear, destruir ni transformar datos.
No puede estar comunicado directamente con otro Almacn 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 fsico y por tanto, no se deben

pensar en trminos de tablas convencionales de las Bases de Datos.
No se representa la clave de acceso de ese almacn, sino slo la
operacin que se realiza (lectura, escritura, actualizacin).
D) FLUJO DE DATOS
Los Flujos de Datos establecen la comunicacin entre procesos, almacenes

y entidades externas, llevando informacin necesaria. Su representacin
dentro del DFD es una flecha dirigida recta o curvada (tanto segn
gane/sarson y yourdon/de marco):
Reglas de construccin:
El concepto de flujo de datos es similar al de un canal", a travs de

la cual fluye una informacin 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. FLUJO
Cuando un proceso almacena datos, la flecha de flujo de datos se
indica en la direccin del almacn de datos y a la inversa, si es el
proceso el que lee datos en el almacn.
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 grfico que va a proporcionar el
mbito del proyecto objeto de estudio. En l, aparecer todo aquello
que necesite o enve datos del o hacia el sistema a desarrollar. Estos
se representan por los objetos denominados Entidades Externas.
El objetivo es realizar una declaracin formal del dominio.

Un slo 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 slo para mejorar la comprensin del resto del
DFD).
ENT.EXT
P0
NOMBRE ENT.EXT.
SISTEMA
.
ENT.EXT.
FIG. FORMA TIPICA DEL DIAGRAMA DE CONTEXTO
DESCOMPOSICIN O EXPLOSIN POR NIVELES
Los Diagramas de Flujo de Datos deben representar el Sistema de la forma

ms clara posible. Para ello se basarn en el principio de descomposicin
o explosin en distintos niveles de detalle. El primer paso hacia la
descomposicin es hacer explotar el diagrama de contexto.
La descomposicin por niveles permite analizar el sistema desde el mbito

general al detalle, pasando por sucesivos niveles intermedios (filosofa
de arriba-abajo o "top-down"). La utilizacin de esta tcnica implica la
descomposicin o explosin 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, slo se detallar la entrada y salida que tenga, adems de la
descripcin asociada que explique lo que realiza.
El procedimiento a seguir para la representacin del sistema en

diferentes niveles de detalle, se indica a continuacin:
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 descomposicin 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 informacin. Alli se
pueden observar hasta 4 niveles, iniciando esta descomposicin con la
explosin del diagrama de contexto.

La identificacin 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 especficas de la problemtica de la Unidad.
Homogeneidad de las funciones realizadas por los procesos
pertenecientes a un rea funcional o subsistema.
Localizacin geogrfica de los procesos.
Procesos que actualicen los mismos almacenes de datos se colocarn 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 ms explcitas y
homogneas posible. Las ventajas de la descomposicin son las siguientes:
Es comprensible para usuarios no informticos.

Los procesos en el ltimo nivel estn relacionados lgicamente.
Los procesos en el nivel 3, de eventos, estn separados en el tiempo.
Facilita las referencias cruzadas con otros productos obtenidos en la
metodologa, concretamente con el Catlogo de Eventos obtenido en la
Tarea de Construccin del Modelo entidad-evento.
EJEMPLO DE UN D.D. PARA DFD : ESPECIFICANDO PROCESOS

( USANDO : PSEUDOCODIGO )
1.1 Detalle 1.2

Verificacin Alumno Verificacin 1.3
Alumno Curso Detalle Verificacin
Curso Rcord
PROCESO 1.1 : VERIFICACION DE ALUMNO
DESCRIPCION.- Verificar que un alumno est expedito para realizar su

matrcula, mediante verificacin de sus datos personales.
ENTRADAS : Ficha de matrcula.

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 aprobacin de los cursos anteriores o cursos

pre-requisitos para cada uno de los cursos consignados en la ficha, sea por
proceso manual o generacin automtica.
ENTRADAS : Detalle de cursos, RECORD_AC.

SALIDAS : MATRICULA, Oasa, Alumno, Obun.
COMIENZA
Ir a almacn 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 notacin grfica para MODELAR DATOS, que describe con un alto nivel
de abstraccin, la distribucin 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 transicin 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 ms alto nivel para la toma
de decisiones y a otro grupo importante: el de Administracin 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 ms
aplicable. En la prctica actual existen dos tendencias en el uso de la
simbologa para representar el modelo de datos de un sistema:
Variantes de la simbologa DER planteada por P. Chen.

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

coleccin 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 cdigo 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 ms datos. Por ejemplo, una
instancia de la Entidad PROFESOR mediante nombre y direccin.
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
relacin representa una asociacin entre cero o ms ocurrencias de una
entidad con cero o ms ocurrencias de otra.
Dicta
Profesor Curso
Relacin
C) ATRIBUTOS (DESCRIPTORES)
Son valores que representan las propiedades elementales

(caractersticas) de las entidades y relaciones.
REPRESENTACION:
1) Con apoyo de un crculo por cada atributo (P. Chen).
2) Directamente al lado de la entidad relacin (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 mltiples

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 nmeros telefnicos).
3.2.2 DEFINICIONES ASOCIADAS AL DIAGRAMA ENTIDAD-RELACION
A) TIPO DE PARTICIPACION DE UNA ENTIDAD EN LA RELACION
MANDATORIO (OBLIGATORIO).- Este tipo de participacin implica que una

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

entidad. Un pequeo crculo, indica participacin OPCIONAL.
Dicta
1 1
Profesor o Curso
Mandatorio Opcional
B) LA CARDINALIDAD
La Cardinalidad muestra el nmero de entidades que pueden participar

en el relacionamiento. Esta participacin es impuesta por las reglas
propias de la Institucin (negocio). En cuanto a simbologa, YOURDON no
define una propia y usa ms bien una aproximacin 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 dems quedan como "descriptores".
- Un IDENTIFICADOR SIMPLE implica que un solo atributo se ha considerado

suficiente para representar unvocamente una entidad.

- Un IDENTIFICADOR COMPUESTO significa que ha sido necesario el uso de 2 o

ms atributos para identificar de forma nica a una entidad (clave
compuesta por dos o ms 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 categora, en lo que representa una forma de abstraccin
(proceso mental mediante el cual nos concentramos solo en los aspectos
relevantes de un conjunto de objetos). Los casos ms representativos son
la GENERALIZACION y la AGREGACION.
GENERALIZACION
Es un mecanismo de abstraccin mediante el cual, un conjunto de tipos

de objetos (entidades) se consideran como una clase genrica de entidades
de ms alto nivel. En la siguiente figura, se muestra un ejemplo de
generalizacin en que la entidad EMPLEADO es una generalizacin 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
abstraccin.
EMPLEADO
GERENTE SECRETARIA
AGREGACION
Es un mecanismo de abstraccin mediante el cual, un nuevo tipo de

objetos (entidad) es definido a partir de otras entidades llamadas
componentes. Un ejemplo de agregacin 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 informacin 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 mltiples 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 ms
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 ms conveniente definir nuevas entidades. Otra
alternativa es mantener el identificador compuesto, si ste es
razonablemente natural.
5) Los atributos que tienen una relacin muchos-a-uno con una entidad,
deberan ser una entidad.
Significa que si un atributo (descriptor) de una entidad tiene una

relacin muchos-a-uno con otra entidad, el atributo debera ser
clasificado como una entidad, an cuando tal atributo no tenga sus propios
descriptores. Asi, definidas las entidades:
- ALMACEN (Identificador: Num-Almacn, Descriptores:Propietario,CIUDAD)

- REGION
Debido a que hay una relacin muchos-a-uno entre CIUDAD y REGION

(varias ciudades corresponden a una regin en nuestro Pas), entonces
CIUDAD debera ser considerada como entidad.
B) IDENTIFICAR JERARQUIAS
1) Identificar subconjuntos para posibilidad de generalizacin.
Esto nos indica que debemos determinar la posibilidad de que ciertas

entidades puedan ser mejor representadas, considerndolas 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 estn permitidos dos o ms relacionamientos

entre dos mismas entidades, debemos cuidar de que tales relacionamientos
no representen lo mismo.
2) Definir, slo de ser necesario, relacionamientos ternarios.
Se refiere a que en ciertos casos podra 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
Habitacin Huesped Empleado
Servicio
Comprobante
RESUMEN DE ALGUNAS NOTACIONES : SEGN METODOLOGIA DE AUTORES
A se relaciona A se relaciona A se relaciona A se relaciona

con B con 1 o ms 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 mayora de los casos, este comportamiento ha importado a
una categora especial de sistemas, conocidos como Sistemas de tiempo
real. Entre ellos, podemos mencionar:
Control de procesos.
Conmutacin telefnica
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 rpida.
Para los sistemas orientados a negocios de tamao promedio, lo

anterior no es tan importante por lo general, pues no es tan crtico 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 satlites 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 algn comportamiento del sistema que es observable y

que perdura durante algn perodo finito. Es la situacin en la que se
encuentra una persona o cosa en un momento determinado. Se representa
mediante un RECTANGULO. Las situaciones ms 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 contrasea 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 porcin de interface
humana que la mayora de los sistemas en lnea tiene, y NO expresan que la
computadora "est haciendo algo". As, cualquier estado observable en el
que el sistema se pueda encontrar, slo puede corresponder a perodos 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 notacin del DTE.
En reposo
Se presion Inicio
[D mensaje inserte tarjeta]
Se di Reinicio
Esperando tarjeta
Tarjeta insertada
[Despliega Ingrese contrasea] Reinicioo mal contrasea
[ Borra pantalla ]
Esperando contrasea
Contrasea ingresada Se di Reinicio

[Despliega Seleccione funcin] [ Borra pantalla ]
Esperando eleccin
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 tendra es una
informacin relativa, "una visin" del sistema. Sin el diccionario de
datos, el usuario, por ejemplo, no podr estar seguro de que entendi los
detalles de la aplicacin.
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 comn de todas las
entradas, salidas, almacenes de datos y clculos intermedios.
NOTACION DEL DICCIONARIO DE DATOS
Para una notacin concisa y compacta, existen muchos esquemas comunes

utilizados por los analistas de sistemas. Aqu mostramos uno de los ms
comunes y usa smbolos sencillos (Yourdon):
* Para describir el significado del trmino.

** Indica definicin conocida (significado universal).
= Significa : "est compuesto de".
+ Significa : "y".
@ Identificador de atributo clave.
() Optativo (puede estar presente o ausente).
{} Iteracin (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.- Nmero de caracteres que ocupa un dato.

DATO ELEMENTAL.- Es el nivel ms importante de datos. Es la unidad ms
pequea con un significado para los analistas de sistemas o usuarios. Por
ejemplo, el nmero de la factura, su fecha de expedicin y la cantidad,
son datos elementales includos en el flujo de datos de la facturacin.
Los datos elementales son las unidades bsicas para todos los dems datos
del sistema. Por s mismos no implican suficiente significado para ningn
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, adems 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 ms significativo que debemos recordar es que, en lo general, LAS

ENTIDADES DE UN DER SE CORRESPONDEN CON LOS ALMACENES EN UN DFD.
EJEMPLO DE DESCRIPCIN EN UN DICCIONARIO DE DATOS
Alumno Alias: Estudiante
* Constituye la entidad ms importante en la Facultad y por

consiguiente la fuente principal de informacin. Ellos alimentan al
sistema y tambin toman datos del mismo *
@Cod_Alum + Nomb_Alum + Cod_Fac + Direc
ALUMNOS = {Alumno}
Curso Alias: Currcula
* Cada materia que el estudiantelleva en un perodo acadmico *
@Cod_Cur + Nomb_curso + Thrs
CURSOS = { Curso }
Detalle de alumno
* Corresponde a tener a la vista, los datos personales bsicos de un

alumno. *
Detalle de curso
* Indica que se verifica, teniendo a la vista, los datos bsicos 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 automatizacin de la produccin de Sistemas. En
general, existe una clasificacin especfica para los CASE:
Los UPPER CASE automatizan, escencialmente las etapas de

planificacin, anlisis y diseo.
Los LOWER CASE automatizan la fase de generacin de cdigo.
La aplicacin de metodologas debe considerarse una poltica de

mediano plazo en la Empresa. No es cmoda y rpida de implantar y genera
costos de capacitacin del personal, pero no hay otro camino. El
beneficio a buscar: Tiempo ms corto de desarrollo una vez asimilada, una
mayor calidad del producto, con menores costos de mantenimiento y mejor
documentacin e informacin del sistema.
El futuro del desarrollo de S.I. est ligado al uso generalizado

(por parte de los especialistas) de metodologas de desarrollo soportadas
por herramientas CASE. La representacin 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 metodologas, es necesario que el
analista tenga conocimiento previo de la existencia y conceptos en que se
basan dichas metodologas.
Los CASE actualmente ms accesibles en el mercado, para un nivel

intermedio, soportan , cada uno en su enfoque, las metodologas pblicas
de mayor acceso hoy en da. As por ejemplo:
EASY CASE : Upper Case para Anlisis y Diseo Estructurado. Permite

trabajar con los tres modelos: funcional, de datos y dinmico y soporta
varias metodologas: Yourdon, Martin, Chen, entre otras.
ERWIN : Orientado hacia el modelo de datos (diseo lgico y fsico) y

permite una interface que se comporta como un DDL (Data Definition
Languaje ~ Lenguaje de definicin de datos).
WITH CLASS : (Upper Case para ADOO, distribuda inicialmente en Per, por
M+S, en Shareware). Soporta el modelamiento planteado por la metodologa
OMT de James Rumbaugh.
RATIONAL ROSE : Herramienta CASE para modelamiento y diseo creado para

equipos de desarrollo visual. Existe en versiones: modelador, profesional
y empresarial. Requiere unos 100 Mb. Est trabajando paralelamente al
proyecto de unificacin de metodologias de modelamiento para desarrollo de
sistemas con enfoque O-O (UML). Se comporta mnimamente como interface DDL
(generando codigo de definicin 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 anlisis de sistemas en la etapa de anlisis (modelo
funcional, modelo de datos y modelo dinmico).
METOLOGAS 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 guardarn todos los
diagramas).
2.- Para ingresar a EasyCase Seleccionar: Inicio

Programas
EasyCASE Professional 4.22
EasyCASE muestra una identificacin del usuario mediante "User Name". El

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

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

caso), EasyCASE nos muestra la ventana de dilogo. 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
(an no hacer clic en "OK" !!) :
A.- Escribir all el nombre del sistema

B.- Seleccionar la metodologa (autor) para el modelo de procesos.
C.- Seleccionar la metodologa (autor) para el modelo de datos.
D.- Hacer clic en el botn para Definir el diagrama de contexto.
5.- Se muestra la ventana de dilogo "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 opcin "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 modificacin
F : Editar el nmero del objeto para modificacin
G : Define la explosin del proceso seleccionado
H : Edita el diccionario de datos para el objeto seleccionado
1 : Zoom rpido
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 jerarqua.

PALETA DE OBJETOS PARA DFD (Yourdon)

1 2 3 4 5
1 : Devuelve el modo edicin 5 : Almacn de datos

2 : Entidad externa 6 : Divis. flujo compuesto
3 : Proceso 7 : Flujo
4 : Proceso instancia 8 : Texto para ttulos
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 posicin (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 botn derecho del mouse.
3. Del men contextual seleccionar name.
4. En el cuadro de dilogo, 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 conexin.
3. Desde la matriz de enlaces que aparece, seleccionar en forma especfica el cuadrito en la
posicin desde la cual empezar la conexin y, sin soltar el botn 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 especficamente el cuadrito de la posicin en la que se desea terminar la conexin.

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

2 : Entidad 7 : Relacin
3 : Entidad dbil 8 : Subtipo/Supertipo
4 : Entidad asociativa 9 : Texto para ttulos
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 posicin (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 botn derecho del mouse.
7. Del men contextual seleccionar name.
8. En el cuadro de dilogo, 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 conexin.
3. Desde la matriz de enlaces que aparece, seleccionar en forma especfica el cuadrito en la
posicin desde la cual empezar la conexin y, sin soltar el botn 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 especficamente el cuadrito de la posicin en la que se desea terminar la conexin.
5. La cardinalidad por omisin es : muchos a muchos.
ESTABLECER NUEVA CARDINALIDAD A UNA RELACION DER.
1. Seleccionar con el mouse el objeto RELACION deseado.

2 Pulsar el botn derecho del mouse.
3. Del men contextual seleccionar .
4. En el cuadro de dilogo, seleccionar la cardinalidad para el inicio (Start) y fin (End) para la
relacin. El start corresponde al lado izquierdo (o superior) y el end corresponde al lado
derecho (o superior) del objeto relacin 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 opcin Print Scale se puede cambiar la escala acomodndola al papel.
Crear un archivo .PRN
Mediante un CHECK a Print to file, aunque es ms recomendable la opcion export de Tools.
Establecer carctersticas en la impresora
Hacer click sobre el botn Setup.

Fases Del Desarrollo de Sistemas para EXA 02

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fases Del Desarrollo de Sistemas para EXA 02

Uploaded by

Copyright:

Available Formats

UNJBG Facultad de Ciencias Administrativas

FASES DEL DESARROLLO DE SISTEMAS

CAPITULO I: ANALISIS PRELIMINAR

A) PLANEAMIENTO ESTRATEGICO Y SISTEMAS DE INFORMACION

Poltica reactiva en sistemas de informacin. Considera los sistemas

1 Poltica proactiva en sistemas de informacin.- Esta ve a los

El desarrollo del plan estratgico de sistemas de informacin puede

B) 4 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

5 YOURDON, Anlisis estructurado moderno

BURCH/GRUDNITSKI, Diseo de sistemas de informacin

RUMBAUGH/BLAHA, Modelamiento y diseo orientado a objetos

2.1 EQUIPO DEL PROYECTO

Depende del tamao de la Institucin y de la existencia/ausencia de

2.2 DEFINICIN DEL PROBLEMA / JUSTIFICACION

Definicin del problema

2.3 ESTUDIO DE FACTIBILIDADES

Prof. Manuel Alvarado 2

2.4 ESTABLECIMIENTO DE OBJETIVOS DEL SISTEMA

2.5 CRONOGRAMA DEL PROYECTO

2.6 IDENTIFICACIN Y DEFINICIN DE REQUISITOS

Prof. Manuel Alvarado 3

2.6.1 INTRODUCCION Y OBJETIVOS

Las entrevistas constituyen el medio de obtener informacin sobre:

Por esta razn, la preparacin y realizacin de las entrevistas juega un

En muchas ocasiones puede ser conveniente sustituir la tradicional

Adicionalmente, si no existiera un planeamiento estratgico de sistemas

2.6.2 RECOMENDACIONES DE DESARROLLO DE ENTREVISTAS

A continuacin se dan unas recomendaciones generales sobre la tcnica de

2.6.3 PREPARACION DE CUESTIONARIO (GUION).

Antes de realizar una entrevista es imprescindible enviar al usuario a

8 1. Entrevistas a los responsables de rea.

2. Entrevistas al resto de los usuarios.

Prof. Manuel Alvarado 4

Descripcin de los sistemas de informacin actualmente

2.2 Requisitos del Nuevo Sistema.

Prof. Manuel Alvarado 5

Debe tenerse en cuenta que lo expuesto en esta tcnica es slo una

Una vez realizada la entrevista con el usuario, es conveniente

Para lo anterior se utilizarn tcnicas de representacin para

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

Estos prototipos ayudarn al usuario a especificar y concretar sus

2.7 ALCANCE (AMBITO DEL PROYECTO)

2.8 RESTRICCIONES (LIMITACIONES)

Prof. Manuel Alvarado 6

2.9 DISEO DEL MODELO ACTUAL (ARQUITECTURA DEL SISTEMA)

Modelo de procesos actual

2.10 ESTUDIO DE ALTERNATIVAS DE CONSTRUCCIN

Plantear soluciones alternativas previas como avance al anlisis.

Prof. Manuel Alvarado 7

CAPITULO II : ANALISIS DEL SISTEMA

El anlisis de sistemas comprende las siguientes actividades bsicas:

Resumen de los requerimientos del ususario.

RESUMEN DE LOS REQUERIMIENTOS DEL USUARIO.

Luego de haberse realizado las entrevistas a los usuarios, se

CONSTRUCCIN DEL MODELO LGICO DEL SISTEMA ACTUAL (OPCIONAL)

Alternativamente se puede representar mediante un modelo lgico, el