Analisis de Sistema de 677

c
Análisis del Sistema de Información c

c
c
ÍNDICEc
c
c
DESCRIPCIÓN Y OBJETIVOS c c2c
c
c ACTIVIDAD 1: DEFINICIÓN DEL SISTEMA c c6c
c

c cc
c

c cc

c c c
c !

"#
$

%
c c&c
c ACTIVIDAD ASI 2: ESTABLECIMIENTO DE REQUISITOS c c10c
c '(
)*#

c c+c
c

, "c cc
c

)*#

c cc
c !-

)*#

c cc
c ACTIVIDAD 3: IDENTIFICACIÓN DE SUBSISTEMAS DE ANÁLISIS c c14c
c

#(

c c!c
c
#(

c c.c
c ACTIVIDAD 4: ANÁLISIS DE LOS CASOS DE USO c c16c
c !

,
#, " cc
c !

'(/ c c c
c ACTIVIDAD 5: ANÁLISIS DE CLASESc c18c
c .

) (

(# c&c
c .

c c+c
c .

0
1
c c+c
c ACTIVIDAD 6: ELABORACIÓN DEL MODELO DE DATOS c c21c
c (
2,# c cc
c (
23
c cc
c
1
23
c cc
c !

2

,

c c!c
c ACTIVIDAD 7: ELABORACIÓN DEL MODELO DE PROCESOS c c25c
c '(
2$
c c.c
c

c cc
c ACTIVIDAD 8: DEFINICIÓN DE INTERFACES DE USUARIO c c27c
c

$

0 1 c c c
c

$

c c&c
c

%
4
# 1$ c c+c
c !

,

1 cc
c .

%
c cc
c ACTIVIDAD 9: ANÁLISIS DE CONSISTENCIA Y ESPECIFICACIÓN DE REQUISITOS c c33c
c &-

2 c c.c
c &

,

2 c c.c
c &-

2 c c
c &! (

)*#

5 6)7c c&c
c ACTIVIDAD 10: ESPECIFICACIÓN DEL PLAN DE PRUEBAS c c40c
c +

$#( c c!c
c +

)*#

$#( c c!c
c +

$#(

c c!c
c ACTIVIDAD 11: APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN c c44c
$
(

c c!!c
c 1c
c
c
c
PARTICIPANTES EN LAS ACTIVIDADES DEL PROCESO c c45c
c
TÉCNICAS/PRÁCTICAS UTILIZADAS EN LAS ACTIVIDADES DEL PROCESO c46c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
2c c
c
c
c
DESCRIPCIÓN Y OBJETIVOSc
c
El objetivo de este proceso es la obtención de una especificación detallada del
sistema de información que satisfaga las necesidades de información de los usuarios y
sirva de base para el posterior diseño del sistema. c
c
Al ser una metodología que cubre tanto desarrollos estructurados como orientados a
objetos, las actividades de ambas aproximaciones están integradas en una estructura
común.c
c
En la primera actividad, Definición del Sistema, se lleva a cabo la descripción inicial
del sistema de información, a partir de los productos gen erados en el proceso Estudio de
Viabilidad del Sistema (EVS). Se delimita el alcance del sistema, se genera un catálogo de
requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel.
También se identifican los usuarios que participan en el proceso de análisis, determinando
sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de
trabajo a seguir. c
c
La definición de requisitos del nuevo sistema se realiza principalmente en la actividad
Establecimiento de Requisitos. El objetivo de esta actividad es elaborar un catálogo de requisitos
detallado, que permita describir con precisión el sistema de información, y que además sirva de
base para comprobar que es completa la especificación de los modelos obtenidos en las actividades
Identificación de Subsistemas de Análisis, Análisis de Casos de Uso, Análisis de Clases,
Elaboración del Modelo de Datos, Elaboración del Modelo de Procesos y Definición de Interfaces de
Usuario. Hay que hacer constar que estas actividades pueden provocar la actualización del
catálogo, aunque no se refleja como producto de salida en las tareas de dichas actividades, ya que
el objetivo de las mismas no es crear el catálogo sino definir modelos que soporten los requisitos.c
c
Para la obtención de requisitos en la actividad Establecimiento de Requisitos se toman como
punto de partida el catálogo de requisitos y los modelos elaborados en la actividad Definición del
Sistema, completándolos mediante sesiones de trabajo con los usuarios. Estas sesiones de trabajo
tienen como objetivo reunir la información necesaria para obtener la especificación detallada del
nuevo sistema. Las técnicas que ayudan a la recopilación de esta información pueden variar en
función de las características del proyecto y los tipos de usuario a entrevistar. Esta técnica facilita la
comunicación con los usuarios y en el análisis orientado a objetos constituye la base de la
especificación. A continuación se identifican las facilidades que ha de proporcionar el sistema, y las
restricciones a que está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y
control de accesos, etc. Toda esta información se incorpora al catálogo de requisitos.c
c
En la actividad Identificación de Subsistemas de Análisis, se estructura el sistema de
información en subsistemas de análisis, para facilitar la especificación de los distintos
modelos y la traza de requisitos. c
c
En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso
de análisis estructurado, se procede a la elaboración y descripción detallada del modelo de datos y
cde procesos, y en el caso de un análisis orientado a objetos, se elaboran el modeloc
dec clases y el de interacción dec objetos,c mediante c el análisis de los casos de uso. Sec
c c c c c
c c c c c

A li i l Si t I f i c c
c
c
c
E ifi , i i ,t l i t f t l i t l i ,t l
f t t ll , i l ,f t i f f l i t .c
c
E l ti i A li i i t i E ifi i i it ASI ,
li l ifi i li i l l , l fi c:
c
l t
, t l t i ti t l i f i i
c i l t l i it .c
i t t , l t l t l l .
t , l i it i li t i
l i l t i tili , li i , l i ,
c li , t . .
E l ti i E ifi i l Pl P , t l l l l
l ,i i i ifi i , l t l i l
Si t I f i .c
c
ti i i ti l i i i i i i l l li i l

i t i f i , i ti i i tit tí l i it

i tifi i i l i t , t t , t t .
!
P f ilit l l i l i , tili t i i t ti , i "
!
i l t ti , it l i f ili i l i t l

l t i f i i t l i .c
c
E l i i t fi t l l i ti i l A li i l
Si t I f i , t t ll t t ll
i t j t , i ti i l li l l ll
li i l t .c
c
c c c
#$fi%i&i'% ($l Si)t$*+c c ) +,l$&i *i $%t- ($c
E t
c
c
c
c c
.$/0i)it-)c
c
1c c
S'l - $%c
($%tifi&+&i'% ($c
c
I
23i$%t +&i'% +c
c c
S0,)i )t $*+) ($ A %4li )i )c

c c
2,j$t-)c
c c
c c
c c c
5c c ' - $%c
S l
%4li)i) ($ 6+)-) ($c ) 30& 03+(-c
c
E t t
c c
A c
7)-c
c
c c c
c c c
c c & 8 (+($)c
A ti i
9c &-*0%$)c
c
c
A%4li )i ) ($ 6l +)$)c
c
c c c
:c c c
+,-3+&i '% ($lc
c
El c c
;-($l- ($ #+t-)c <<c ?
c
c
=c <>c P3$)$%t +&i'% c
c
c c c
A %4li )i ) ($c E)@$&ifi &+&i'% ($l c A @3-,+&i'% A %4li)i )c

c
6-%)i)t$%&i+c Pl+% ($ P30$,+)c Si) t$*+ ($c

c
Ac I %f -3*+&i'%c
c
c
El+,-3+&i '% ($lc
c
c c
;-($l- ($ #+t-)c
c
c c c
c
c Bc
c #$fi%i&i'% ($c
% $3 +&$) ($ 7)0+3i-c
I t f
c
c
Objetivo general
"lograr establecer un sistema en la empresa que permita el correcto funcionamiento de la entidad."
Objetivos específicos
G Mostrar los beneficios que ofrece el diseñar sistemas.

G Ofrecer un panorama claro de los usos prácticos del análisis.
G Explicar los elementos principales de una interfaz gráfica de usuario, sus beneficios y usos en los
sistemas informáticos actuales.
G Dar a conocer cómo los diagramas ayudan a ver el correcto funcionamiento del sistema.
Definición de la problemática
Problema general
De acuerdo a un previo análisis que la empresa ³ASTI´ realizo al negocio ³Rosarito Games´, se pudo
detectar que el principal problema que presenta, es que no se cuenta con un sistema lo suficientemente
eficiente para llevar a cabo el adecuado funcionamiento en lo que respecta el manejo de sus clientes,
empleados y almacén del mismo, además, el sistema de registro es totalmente realizado a mano, por lo
que en ocasiones presentan perdida de información.
Problemas específicos
Los problemas que se pudieron detectar rápidamente fueron los siguientes:
1) Problemas de control de información
Sistema manual:
G El procedimiento para el registro de cualquier actividad que realiza el negocio es completamente
manual.
Perdida de información:
G Existe mucha perdida de información, debido a que no cuenta con un medio de almacenamiento
para dicha información. No existe control.
2) Problemas en almacén
G En ocasiones no se llega a encontrar todas las cajas de los juegos.
3) Problemas para el control de empleados

G No cuentan con algún tipo de registro para llevar a cabo la asistencia de los empleados.
c c c
c c
c c
c c
c c
LISIS EL SISTEM E I O MIÓ (EST T O) c c
c c
c c
c c
c
c ul do d l c cc ccc c c c cc c cc c c cc c c cc cc c c c c
c E udio d Vi bilid d c cc ccc c c c cc c cc c c c c c c cc cc c c c
c
c
c
d l Si m d c cc ccc c c c cc c cc c c c c c c c c c c c c c
c In orm ión c cc ccc c c

c c c c c c c c c c
c cc c cc
c c c c c
c
c c
c c c
c c c
c c
c c
cc
c c
cc
c c
c c
c c
c
c
c
c cc ccc c c c cc c cc c c cc c c cc cc c c c
ö i i l c
c
c cc ccc c c cc c c c c c c c c c c c c c
ISEÑO EL c
1c
c
S l i c c t l c SISTEM E c
DC
E
H
c cc ccc c c cc c c c c c c c c c c c c
c ö
FG
F
I
c
c
c c c c c c c c c c c c c c c c c c c c c c c c c c
c c ö t l c cc ccc c c c cc c c cc c c c c c c cc cc c i it c I O MIÓ c
IK J
L
M
FM
c
c c
i it c
c c c c c c c c c c c c c c c c c c c c c c c c c
ö Gl i c
c
NS R N
O
PQ
N
c cc ccc c c c cc c c c c c c c c c c c c c c
c 3c
c
t l m
ö c t t lc c
V
ö
TU
N
T
c c
c
c c
c c
c c c
c c c
c
c
c
c
c
c
c c
c c
c
c
c
c
c c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c ö t l i c Si t m c
XY NV O
Z T T
X N P
c cc ccc c c c cc c c cc c c c c c c cc cc c c
ö M l t
c
c
[X T V
\ W
c 10c
Z] P
X NO
c c ccc ccc c c c cc c c c
c
c c c
9c
c c
11c
c c c c
c
c ö M l P c
c c c c c c c c c c c c c c c c c c
Ali i ?lSi tm ?If m i c

c c ccc ccc c c c c c c
c c c
c c c c c c c
c c c
c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c
c c c c c c c c c c c c c c c c c c c c c c c c c c c c
ö M l c
c
XY
a Y
l k Xb\ Z ^
]` Z
jh X X
f Xc _]
_ d X]
c c ccc ccc c c c c c c c cc c c c c c c c c c c
c
c c c
i l c
Y
c c ccc ccc c c c c c c c cc c c c c c c c c c c
fg e Z

c
c c
c
c c c c c c c c c c c c c c c c c c c c c c c c c c c c
i i c
m
c c ccc ccc c c c cc c c c
7c c c c c c c c c c c c c ö
hi
c
c c
c
c
c
c c c
c c c
c c c
c c c
c
c
c
c
c
c
c c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
i t m c
c
c
go
gn
g
f
pg
c
c c c c c c c c c c c c c c cc c c c c c c c c c c c c
c En r d Ex rn c lt lc
z uv
| wv
ö

y rst
r
c ccc ccc c c c cc c c cc c c c c c c cc cc c c
A li i c
{
c
~ } x
z
8c
c
ö E t
c
c
i t i c

c c c c c c c c c c c c c c c c c c c c c c c c c c c
m ti l c ö I t f i c
{
c ccc ccc c c c cc c cc c c c c c c cc cc c
x
|

|
z

c
i t l i c c

c c c c c c c c c c c c c c c c c c c c c c c c

c

c c c c c c c c c c c c c cc c c c c c c c c c c c c
c
ö E t t R

c
c ccc ccc c c c cc c cc c c c c c c c c c c c c
ÎR c
c
c
? t ?l i tm c ccc
c c c
ccc c
c c c c
c
c
c
c
cc c
c c c
cc
c c
c
c
c
c
c
c
c
c
c
c
c
c
c c
c c
c c
c c
c
c c
c

c O i c ccc ccc c c c cc c cc c c c c c c cc cc c c c
c c ccc ccc c c c cc c cc c c c c c c c c c c c c c
c
c
c
c
c
c
c
c
Alii?lSitm ?Ifm i c
c
c
c
LISIS EL SISTEM E I O MIÓ (O IE TIÓ O ETOS) c
c
c
c
c ul do d l c c c c cc c c c c c cc c c cc c c c cc cc cc c c c
c E udio d Vi bilid d c c c c cc c c c c c cc c c cc c c c c c cc c c c c c
d l Si m d c
c c c c c c c c c c c c c c c c c c c c c c c c c c c c c
c c c c cc c c c c cc c c c c c cc c c c c c cc c c c c c
c
In orm iónc c c c cc
c
c
c
c
c
c
c c
c c
cc
cc
c
c
c
c
cc
cc
c
c
c
c
c
c
c c
c c
cc
cc
c
c
c
c
c
c
c
c
c
®
c c c c cc c c c c c cc c c cc c c c c c cc c c c c c
ö i i l c
1c tl ?c

ö

c c c c cc c c c cc c c c c cc c c c c c cc c c c
c c c c c c c c c c c
c c c c c c c c c c c c c c c
c
c
c
l i c
iit c
c c
c
c
c
c
c
c
c
c
c c
c
c
c
c
c
c
c
c
c
c
c
c c
c
c c
c
c
c
c
c
c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c c
c
c
c
c
c
c
c
c
c
c
tl ? c
c
c c ö c c c cc c c c c cc cc c c cc c c c c c cc c c c ö Gl ic
c
iit c ö t t ?lc
c

c c c c cc c c c c cc c c cc c c c c c cc c c c
c c c c c cc c c c c cc c 3c c cc c c c c c cc c c c
Sitm c
c
c
ö tl ? m c
c
c c c c c cc c c c c c c c c c c cc c c c c c c c c c c
ö M?l ? ic
c
ISEÑO EL c
tl ? i cc

c c ö c c cc c c c c cc c c c c cc c c c c c cc c c c
SISTEM E c
c
ö M?l ? miic

c c c c c c cc c c c c cc c c c c cc c c c cc c
11c c c c
I O MIÓ c
c
c 9c 10c ö M?l ? c
¡
¢
c c c c c cc c c c c cc c c c cc c c c c c c ?
c c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c c c
c
c
c
c
c
c
c
c c
c
c c c
c
c
c
c
c
c
c
c
c c
c
c
c c c c c c cc c c c c cc cc c c c cc c c c c c cc c c c
c c
c ö i i ?c
¥
c c c c c cc c c c c c c c c c c c cc c c c c c c c c
¤
c
c c c c c cc c c c c c c c c c cc c c c c c c c c c c c
c c
c
c c
c
c c
c c
cc
cc
c
c
c
c
c
c
c
c cc
c c c
c c c c
c
cc
cc
c
c
c
c
c
c
c c
c c
c c
cc
c
c
c
c
c
c itm c
c
En r d Ex rn c
c
c c
c
c
c
c
c
c
c
c c
c c
c
c
c
c
c
c
c
c
c c
c c
c c
c c
c
c
c
c
c c
c c
c
c
c
c
c
c
c
c
c
c
c c
c c
c
c
c
c
c
c ö lt ? ?lc
c
c
c
Alii ?c
c c c c cc c c c c cc c c c c cc c c c c c cc c c c
c c
ö Et? c c c c c c c c c c c c c c c c c c c c c c c c c c
@iti c
c
c c c c c c c c c c c c c
8c c c c c c c c c c c c c c
c c
c c
c
c
c
m ti ? l c
c
c
c
c
c c
c
c
c
c
c
c
cc
c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c c
c
c
c
c
c
c
c c
c
c
c c
c
c
c
c
c
c
c
c
cc
c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c c
c
c
c
c
c
c
cc
c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
ö M?l ? @l c c
c
c
c
c it l i c c c c cc c c c c c cc c c cc c c c c c cc c c c ö Itf ? ic c

c
ö Ett ? c
©¨
ª

¦
§
c c c c cc c c c c c cc c c cc c c c c c cc c c c c
R

c
cc c c c c c c c c c c c c c c c c c c c c c c c c c c c
? t ?l itm c
¦
«¦
«
¬
c c c c cc c c c c c cc c c cc c c c c c cc c c c c
c
c
c
c
c c
c c c
cc
c
c
c
c
c
c
c
c
c
c
c c
c c
c
c
c
c
c c
cc
c
c
c
c
c
c
c
c c
c c c
c c
c
c
c
c
c
c ÎR c c
i c
c
c c c c cc c c c c c cc c c cc c c c c c cc c c c c c
Dc
6c Análisis del Sistema de Informaciónc
c
c
c
ACTIVIDAD : DEINICIÓN DEL SISTEMAc
c
Esta actividad tiene como objetivo efectuar una descripción del sistema, delimitando
su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios
representativos. Las tareas de esta actividad se pueden haber desarrollado ya en parte en
el proceso de Estudio de Viabilidad del Sistema (EVS), de modo que se parte de los
productos obtenidos en dicho proceso para proceder a s u adecuación como punto de
partida para definir el sistema de información. c
c
c
c Tareac c Productosc c Técnicas y Prácticasc c Participantesc
1.1c Determinación delc c Catálogo de Requisitosc c Sesiones de Trabajoc c jefe de Proyectoc
c Alcance del Sistemac c Glosarioc c Catalogaciónc c Analistasc
c c á :c c Diagrama de Flujo dec c .c
c c c Contexto del Sistemac c Datosc c .c
c c c Modelo Conceptual dec c Modelo Entidad /c c c
c c c Datosc c Relación Extendidoc c c
c c !

! :c c Casos de Usoc c c
c c c Modelo de Negocioc c Diagrama de Clasesc c c
c c c Modelo de Dominioc c c c c
1.2c Identificación delc c Catálogo de Requisitosc c Sesiones de Trabajoc c jefe de Proyectoc
c Entorno Tecnológicoc c Descripción General delc c Catalogaciónc c Analistasc
c c c Entorno Tecnológico delc c Diagramas dec c Directores de los c
c c c Sistemac c Representaciónc c Usuariosc
c c c c c c c Equipo de Soportec
c c c c c c c Técnicoc
1.3c Especificación dec c Catálogo de Normas c c Sesiones de Trabajoc c jefe de Proyectoc
c Estándares yc c c c Catalogaciónc c Analistasc
c Normasc c c c c c Directores de los c
c c c c c c c Usuariosc
c c c c c c c Equipo de Soportec
c c c c c c c Técnicoc
1.4c Identificación dec c Catálogo de Usuariosc c Sesiones de Trabajoc c jefe de Proyectoc
c Usuariosc c Planificaciónc c Catalogaciónc c Analistasc
c Participantes yc c c c c c Directores de los c
c Finalesc c c c c c Usuariosc
c

c
c
En esta tarea se delimita el sistema de información, utilizando como punto de partida
el modelo de procesos especificado en la descripción de la solución del proceso Estudio de
Viabilidad del Sistema (EVS). Se indica qué procesos pertenecen al ámbito del Sistema de
Información y se identifican las entidades externas a l sistema que aportan o reciben
información. Asimismo, se obtiene un modelo conceptual de datos identificando las
entidades y relaciones que forman parte del sistema de información objeto de este análisis
a partir del modelo abstracto de datos generado en la tarea Evaluación de Alternativas y
Selección (EVS 6.2). c
c
En el caso de análisis orientado a objetos, antes de la captura de requisitos
empleando los casos de uso, puede ser conveniente establecer el contexto del sistema a
partir del modelo de negocio obtenido en el proceso Estudio de Viabilidad del Sistema
(EVS), y además, opcionalmente, del modelo de dominio. El modelo de negocio especifica
los procesos a los que se quiere dar respuesta en el sistema de información, en forma de
casos de uso de alto nivel, y el subconjunto de objetos del dominio requerido para ello. c
c
c
c
c
c
c
Análisis del Sistema de Informaciónc 7c
c
c
c
En esta actividad se realiza, también, la definición del catálogo de requisitos del
sistema a partir del catálogo de requisitos generado en el proceso Estudio de Viabilidad del
Sistema (EVS).c
c
Para obtener esta información es necesario llevar a cabo sesiones de trabajo con los
usuarios responsables del sistema de información que se está analizando. c
c
Productos c
c
De entrada c
c
G Descripción de la Solución
G Catálogo de requisitos
G De salida
G Catálogo de Requisitos
G Glosario
á

á
G Contexto del Sistema
G Modelo Conceptual de Datos
á

!
!
G Modelo de Negocio
cG Modelo de Dominio
Técnicas c
c
G Diagrama de Flujo de Datos
G Modelo Entidad / Relación extendido
G Diagrama de Clases
Gc Casos de Uso
Prácticas c
c
G Sesiones de Trabajo
G Catalogación
c
Participantes c
c
G jefe de Proyecto
G Analistas
G Directores de los Usuarios
c

á

c
c
El objetivo de esta tarea es definir, a alto nivel, el entorno tecnológico que se requiere
para dar respuesta a las necesidades de información, especificando sus posibles
condicionantes y restricciones. Para ello se tiene en cuenta el entorno tecnológico
propuesto en la descripción de la solución, que se obtuvo en el proceso Estudio de
Viabilidad del Sistema (EVS). c
c
c
c
c
Esta información se obtiene mediante sesiones de trabajo con los usuarios y el apoyo
de los responsables de Tecnologías de Información y Comunicaciones que se considere
necesario.c
c
Productos c
c
De entrada c
c
G Descripción de la Solución (EVS)
á

á
G Contexto del Sistema (1.1)
á

!
!
G Modelo de Negocio (1.1)
G Modelo de Dominio (1.1)
De salida

G Descripción General del Entorno Tecnológico del Sistema
c
Prácticas c
c
G Catalogación
G Diagrama de Representación
c
Participantes c
c
G jefe de Proyecto
G Analistas
G Equipo de Soporte Técnico
c
á
á
c
c
La realización de esta tarea permite considerar las referencias para el sistema de información
en estudio, desde el punto de vista de estándares, normativas, leyes o recomendaciones, que
deben tenerse en cuenta a lo largo de todo el proceso de desarrollo.c
c
El producto resultante se obtiene a ctualizando el catálogo de normas elaborado en el
proceso Estudio de Viabilidad del Sistema (EVS), incorporando toda la información que,
desde el punto de vista de la instalación, se considere necesario contemplar para la
elaboración de los distintos produ ctos del ciclo de vida. c
c
Productos c
c
De entrada c
c
G Catálogo de Normas (EVS 3.1)
G Descripción General del Entorno Tecnológico del Sistema (1.2)
G Estándares y Normativas de la Instalación (externo)
á

á
á

!
!
G Modelo de Negocio ( 1.1)
c
c
Análisis del Sistema de Informaciónc 9c
c
c
c
De salida

G Catálogo de Normas

Prácticas

G Catalogación
c
Participantes c
c
G jefe de Proyecto
G Analistas
c

!
c
c
En esta tarea se identifican los usuarios participantes y finales, interlocutores tanto en
la obtención de requisitos como en la validación de los distintos productos y la aceptación
final del sistema. Para ello, se actualiza el catálogo de usuarios generado previamente en
el Estudio de Viabilidad del Sistema (EVS). c
c
Dada la importancia que la cola boración de los usuarios tiene en el proceso de
obtención de los requisitos, es conveniente determinar quiénes van a participar en las
sesiones de trabajo, especificando sus funciones y asignando responsabilidades. Así
mismo, se informa del plan de trabajo a los usuarios identificados. c
c
El alcance de este plan de trabajo se limita al proceso de análisis. c
c
Productos c
c
De entrada c
c
G Catálogo de Usuarios (EVS 1.3 y EVS 2.2)
G Catálogo de Requisitos ( 1.2)
á

á
á

!
!
De salida
G Catálogo de Usuarios
G Plan de Trabajo
c
Prácticas c
c
G Catalogación
c
Participantes c
c
Gc jefe de Proyecto c c c
c c c c
c c c
c
c
c
G Analistas
c
c
c
c
ACTIVIDAD 2: ESTABLECIMIENTO DE
REQUISITOSc
c
En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos a partir de
la información facilitada por el usuario, completándose el catálogo de requisitos obtenido en la
actividad Definición del Sistema (1). El objetivo de esta actividad es obtener un catálogo detallado
de los requisitos, a partir del cual se pueda comprobar que los productos generados en las
actividades de modelización se ajustan a los requisitos de usuario.c
c
Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden,
exige continuas realimentaciones y solapamientos, entre sí y con otras tareas realizadas en
paralelo. No es necesaria la finalización de una tarea para el comienzo de la siguiente. Lo
que se tiene en un momento determinado es un catálogo de requisitos especificado en
función de la progresión del proceso de análisis. c
c
Se propone como técnica de obtención de requisitos la especificación de los casos de uso de
la orientación a objetos, siendo opcional en el caso estructurado. Dicha técnica ofrece un diagrama
simple y una guía de especificación en las sesiones de trabajo con el usuario.c
c
c
c
c Tarea c c Productosc c Técnicas y Prácticasc c Participantesc c
.2.1c Obtención dec c Catálogo de Requisitosc c Sesiones de Trabajoc

c Usuarios Expertosc c
c Modelo de Casos de Usoc c Catalogaciónc c Analistasc

c c c c c
c Requisitosc c
c Casos de Usoc
c c c c c c
c c c c c c c
2.2c Especificación dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c
Modelo de Casos de Uso c Catalogaciónc c Analistasc

c c c c c
c Casos de Usoc c c
c Especificación de Casos dec c Casos de Usoc
c
c c c c
c c c c c
c c c Usoc c c c c c
2.3c Análisis dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c
Modelo de Casos de Uso c Catalogaciónc c Analistasc

c c c c c
c Requisitosc c c
c
c c c c
c c c c c
2.4c Validación dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c
c Modelo de Casos de Usoc c Catalogaciónc c Analistasc

c c c c c
c Requisitosc
c
c c c c
c c c c c
c
c
c
!

" # c
c
En esta tarea comienza la obtención detallada de información mediante sesiones de
trabajo con los usuarios, previamente identificados en la activi dad Definición del Sistema
(1).c
c
Se recoge información de los requisitos que debe cumplir el software. En la definición de los
requisitos, que sirven de base para establecer los niveles de servicios del sistema, hay quec
c
Análisis del Sistema de Informaciónc 11 c
c
c
c
Tener en cuenta, si existen, las posibles restricciones del entorno, tanto hardware como
software, que puedan afectar al sistema de información. c
c
También se definen las prioridades que hay que asignar a los requisitos,
considerando los criterios de los usuarios acerca de las funcionalidades a cubrir. c
c
Los principales tipos de requisitos que se deben especificar son, por ejemplo: c
c
Funcionales.

Rendimiento.
Seguridad.
Implantación.
c Disponibilidad del sistema.
En el caso de orientación a objetos se especifican, además, los casos de uso
asociados a los requisitos funcionales. c
c
Los casos de uso son una técnica de especificación de requisitos válida tanto en
desarrollos estructurados como en orientación a objetos, aunque en este último caso se
propone como técnica obligatoria al ser necesaria como referencia a lo largo de todo el
ciclo de vida. En esta tarea se elabora el modelo de casos de uso, según las normas y
estándares de la organización, identificando: c
c
Actores.

Casos de uso.
c Breve descripción de cada caso de uso.
Los productos obtenidos en la tarea Determinaci ón del Alcance del Sistema (1.1), son
tomados como referencia durante la obtención de requisitos, de forma que todos los
requisitos especificados se encuentren dentro d el ámbito del sistema de información. c
c
Productos c
c
De entrada c
c
G Catálogo de Requisitos (1.4)
G Descripción General del Entor no Tecnológico del Sistema ( 1.4)
G Catálogo de Usuarios (1.4)
G Plan de Trabajo (1.4)
á

á
á

!
!
De salida

G Modelo de Casos de Uso
c
Técnicas c
c
G Casos de Uso

Prácticas

G Catalogación
c
c
c
c
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
á
$ c
c
Esta tarea es obligatoria en el caso de orientación a objetos, y opcional en el caso de
análisis estructurado, como apoyo a la obtención de requisitos. c
c
El objetivo de esta tarea es especificar cada caso de uso identificado en la tarea
anterior, desarrollando el escenario. c
c
Para completar los casos de uso, es preciso especificar información relativa a: c
c
Descripción del escenario, es decir, cómo un actor interactúa con el sistema, y cuál
es la respuesta obtenida.
Precondiciones y pos condiciones.
Identificación de interfaces de usuario.
Condiciones de fallo que afectan al escenario, así como la respues ta del sistema
c (escenarios secundarios).
En escenarios complejos, es posible utilizar como técnica de especificación los
diagramas de transición de estados, así como la división en casos de uso más simples,
actualizando el modelo de casos de uso. c
c
Para la obtención de esta información es imprescindible la participación activa de los
usuarios.c
c
Productos c
c
De entrada c
c
G Catálogo de Requisitos ( 2.1)
G Modelo de Casos de Uso (2.1)
De salida

Gc Especificación de Casos de Uso
Técnicas c
c
G Casos de Uso

Prácticas

G Catalogación
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
c
c
c
c
c
c
c

" # c
c
En esta tarea se estudia la información capturada previamente en esta actividad,
para detectar inconsistencias, ambigüedades, duplicidad o escasez de información, etc. c
c
También se analizan las prioridades establecidas por el u suario y se asocian los
requisitos relacionados entre sí. c
c
El análisis de los requisitos y de los casos de uso asociados permite identificar
funcionalidades o comportamientos comunes, reestructurando la información de los casos
de uso a través de las generalizaciones y relaciones entre ellos. c
c
Mediante sesiones de trabajo con los usuarios, se contrastan las conclusiones del
análisis de la información recogida. c
c
Productos c
c
De entrada c
c
G Especificación de Casos de Uso (2.2)
De salida

G Especificación de Casos de Uso
c
Técnicas c
c
G Casos de Uso

Prácticas

G Catalogación
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
%
" # c
c
Mediante esta tarea, los usuarios confirman que los requisitos especificados en el
catálogo de requisitos, así como los casos de uso, son válidos, consistentes y completos. c
c
Productos c
c
De entrada c
c
c
c
c
c
c
c
De salidac
c
c
Técnicas c
c
G Casos de Uso

Prácticas

G Catalogación
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
c
c
c
c ACTIVIDAD : IDENTIICACIÓN DEc

SUBSISTEMAS DE ANÁLISISc
c
El objetivo de esta actividad, común tanto para análisis estructurado como para

(/, es facilitar el análisis del sistema de información llevando a
cabo ladescomposición del sistema en subsistemas. Se realiza en paralelo con el resto de
las actividades de generación de modelos del análisis. Por tanto, se asume la necesidad de
una realimentación y ajuste continuo con respecto a la definición de los subsistemas, sus
dependencias y sus interfaces. c
c
c
c
.3.1c Determinación dec á :c Diagrama de Flujo dec c jefe de Proyectoc c
c Modelo de Procesosc Datosc c Analistasc

c c c c c
c Subsistemas dec c c
!

! :c Diagrama de Paquetesc
c c c c c
c Análisisc
c c c
Descripción dec (Subsistemas)c
c
c c c c c
c c c c c c c
c c c Subsistemas de Análisisc c c c c c
c c c Descripción de Interfacesc c c c c c
c c c entre Subsistemasc c c c c c
c
.3.2c Integración dec c Desarrollo y Aceptaciónc c
Diagrama de Flujo dec c
c jefe de Proyectoc c
c
c Subsistemas dec á :c c Datosc c Analistasc

c Modelo de Procesosc Diagrama de Paquetesc
c
c c c c c c
c
Análisisc
c c c c
c
c c !

! :c c
c (Subsistemas)c c
c
c
c
c
c c c Descripción dec c c c c c
c

c
c
La descomposición del sistema en subsistemas debe estar, principalmente, orientada
a los procesos de negocio, aunque también es posible adoptar otros criterios lógicos. Entre
los criterios que pueden ayudar a su identificación, se encuentran los siguientes: c
c
c Homogeneidad de procesos. c c
c c c
c c
c
c
c
Servicios comunes.
Prioridad.
Afinidad de requisitos.

c Localización geográfica.
En análisis estructurado, los subsistemas coinciden habitualmente con el primer nivel
de descomposición del Diagrama de Flujo de Datos (diagrama 0), de modo que llevan
implícita la definición de dependen cia y de interfaz. c
c
En análisis orientado a objetos, se identifican y definen las dependencias entre subsistemas
analizando los elementos compartidos entre ellos o las interfaces entre subsistemas. En el caso de
que se decida abstraer un subsistema para su análisis como una unidad con una funcionalidad
concreta, se puede, opcionalmente, definir la interfaz de dicho subsistema para poder delimitar su
comportamiento y utilización en el modelo general del sistema. Por tanto, se establece como
obligatoria la asociación entre subsistemas indicando sólo la dependencia. Además, opcionalmente,
se propone la especificación de la interfaz de subsistemas de análisis, y la definición del
comportamiento del sistema.c
c
En ambos casos, se asignan los requisitos y casos de uso a cada uno de los
subsistemas identificados, actualizando el catálogo de requisitos. c
c
Productos c
c
De entrada c
c
c á

á c
G Contexto del sistema (1.1)
á

!
!
G Modelo de negocio ( 1.1)
G Modelo de dominio ( 1.1)
G Modelo de casos de uso (2.4)
G Especificación de casos de uso (2.4)
De salida

á

á
G Modelo de procesos
á

!
!
G Descripción de subsistemas de análisis
Gc Descripción de interfaces entre subsistemas
Técnicas c
c
G Diagrama de Paquetes 6#(
7
c
Participantes c
c
G jefe de Proyecto
G Analistas
c

c
c
El objetivo de esta tarea es la coordinación en la elaboración de los distintos modelos de
análisis de cada subsistema, asegurando la ausencia de duplicidad de elementos y la precisión en
la utilización de los términos del glosario. Esta tarea se realiza en paralelo con el resto dec
c
c
c
c
c
las actividades de elaboración de modelos del análisis, y permite tener una visión global y
unificada de los distintos modelos. c
c
Como consecuencia de la coordinación de modelos, se pueden identificar elementos
comunes con posible implicación en la propia definición de subsistemas y en sus
dependencias o interfaces. c
c
Productos c
c
De entrada c
c
c á

á c
G Modelo de procesos (3.1)
á

!
!
G Descripción de subsistemas de análisis (3.1)
G Descripción de interfaces entre subsistemas (3.1)
De salida

á

á
G Modelo de Procesos
á

!
!
G Descripción de Subsistemas de Análisis
Gc Descripción de Interfaces entre Subsistemas
Técnicas c
c
G Diagrama de Paquetes 6#(
7
c
Participantes c
c
G jefe de Proyecto
G Analistas
c
c
c
c
ACTIVIDAD 4: ANÁLISIS DE LOS CASOS DE USOc
c
El objetivo de esta actividad, que sólo se realiza en el caso de
!

! , es identificar las clases cuyos objetos son necesarios para realizar un caso de
uso ydescribir su comportamiento mediante la interacción dichos objetos. c
c
Esta actividad se lleva a cabo para cada uno de los casos de uso contenidos en un
subsistema de los definidos en la actividad Identif icación de Subsistemas de Análisis (3).
Las tareas de esta actividad no se realizan de forma secuencial sino en paralelo, con
continuas realimentaciones entre ellas y con las realizadas en las actividades
Establecimiento de Requisitos ( 2), Identificación de Subsistemas de Análisis (3), Análisis de
Clases (5) y Definición de Interfaces de Usuario ( 8).c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c Tareac c Productos c c Técnicas y Prácticasc c Participantes c c
.4.1c Identificación dec c Modelo de Clases dec c Diagrama de Clasesc c Analistasc c
Análisisc
c c c c c c c
c
c
Clases Asociadasc c c c
c
c
c
c
c
c
c
c
c
c
c a un Caso de Usoc c c c c c c c
4.2c Descripción de lac c Análisis de la Realizaciónc c Diagrama de Interacciónc c Analistasc c
de los Casos de Usoc de Objetos (secuencia oc c c

c c c c c c
c Interacción dec c c c
Objetosc colaboración)c
c c c c c c c
c
c
c c
c
c
c
c c
c c
c c
c
c
c

$
$
c
c
En esta tarea se comienzan a identificar los objetos necesarios para realizar el caso
de uso, basándose en la especificación que tenemos del mismo. c
c
A partir del estudio del caso de uso, se extrae una lista de objetos candidatos a ser clases. Es
posible que, inicialmente, no se disponga de la información necesaria para identificar todas, por lo
que se hace una primera aproximación que se va refinando posteriormente, durante esta actividad y
en el proceso de diseño. Además, algunos de los objetos representan mejor la información del
sistema si se les identifica como atributos en vez de como clases. Para poder diferenciarlas, es
necesario estudiar el comportamiento de esos objetos en el diagrama de interacción y además se
debe tener en cuenta una serie de reglas, como puede ser el suprimir palabras no pertinentes, con
significados vagos o sinónimos.c
c
Una vez definidas cada una de las clases, se incorporan al modelo de clases de la
actividad Análisis de Clases (5), donde se identifican sus atributos, responsabilidades y
relaciones.c
c
Las clases que se identifican en esta tarea pueden ser: c
c
Clases de Entidad (representan la información manipulada en el caso de uso).
Clases de Interfaz de Usuario (se utilizan para describir la interacción entre el sistema
y sus actores. Suelen representar abstracciones de ventanas, interfaces de
comunicación, formularios, etc.).
Clases de Control (son responsables de la coordinación, secuencia de transacciones
c y control de los objetos relacionados con un caso de uso).
Productos c
c
De entrada c
c
De salida

G Modelo de Clases de Análisis
c
Técnicas c
c

Participantes

G Analistas
c
c
c
c
c
c

! c
c
El objetivo de esta tarea es describir la cooperación entre los objetos utilizados para
la realización de un caso de uso, que ya fueron identificados en la tarea anterior. c
c
Para representar esta información, se usan diagramas de interacción que contienen
instancias de los actores participantes, objetos, y la secuencia de mensajes intercambiados
entre ellos. Se pueden establecer criterios para determinar qué tipo de objetos y mensajes
se va a incluir en este diagrama, como por ejemplo: si se incluyen objetos y llamadas a
bases de datos, objetos de interfaz de usuario, de control, etc. Estos diagramas pueden ser
tanto de secuencia como de colaboración, y su uso depende de si se quieren centrar en la
secuencia cronológica o en cómo es la comunic ación entre los objetos. c
c
En aquellos casos en los que se especifique más de un escenario para un caso de
uso, puede ser conveniente representar cada uno de ellos en un diagrama de interacción.
También es recomendable, sobre todo en el caso anterior, compl etar los diagramas con
una descripción textual. c
c
Productos c
c
De entrada c
c
De salida

G Análisis de la Realización de los Casos de Uso

Técnicas

G Diagrama de Interacción de Objetos (de secuencia o de colaboración)

Participantes

G Analistas
c
c
c
c
ACTIVIDAD 5: ANÁLISIS DE CLASESc
c
El objetivo de esta actividad que sólo se realiza en el caso de
!

! es describir cada una de las clases que ha surgido, identificando las
responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas. Para
esto, se debe tener en cuenta la normativa establecida en la tarea Especificación de
Estándares y Normas (1.3), de forma que el modelo de clases cumpla estos criterios, con el
fin de evitar posibles inconsistencias en el diseño. c
c
Teniendo en cuenta las clases identificadas en la actividad Análisis de los Casos de
Uso (4), se elabora el modelo de clases para cada subsistema. A me dida que avanza el
análisis, dicho modelo se va completando con las clases que vayan apareciendo, tanto del
estudio de los casos de uso, como de la interfaz de usuario necesaria para el sistema de
información.c
c
c
c
c
c
c
c
5.1c Identificación dec c Modelo de Clases dec c Diagrama de Clasesc c Analistasc c
Análisisc c Diagrama de Transiciónc c

c c c c c c
c Responsabilidadesc c c c
c Comportamiento de Clasesc c de Estadosc

c c c c c c
c y Atributosc c c
de Análisisc
c
c c c c c c c
c c c c c c c c
5.2c Identificación dec c Modelo de Clases dec c Diagrama de Clasesc c Analistasc c
Análisisc
c c c c c c c
c
c
Asociaciones yc c
c c
c c
c c
c c
c c
c
c
c Agregacionesc c c c c c c c
c
5.3c Identificación dec c
c Modelo de Clases dec c
c Diagrama de Clasesc
c c
cAnalistasc
c
c
c
c
c
Generalizacionesc c
c c
Análisisc c
c
c
c
c
c
c
c
c
c
c
c
c
&

"

c
c
El objetivo de esta tarea es identificar las responsabilidades y atributos relevantes de
una clase.c
c
Las responsabilidades de una clase definen la funcionalidad de esa clase, y están
basadas en el estudio de los papeles que desempeñan sus objetos dentro de los distintos
casos de uso. A partir de estas responsabilidades, se puede comenzar a encontrar las
operaciones que van a pertenecer a la clase. Estas deben ser rel evantes, simples, y
participar en la descripción de la responsabilidad. c
c
Los atributos de una clase especifican propiedades de la clase, y se identifican por
estar implicados en sus responsabilidades. Los tipos de estos atributos deberían ser
conceptuales y conocidos en el dominio. c
c
De manera opcional, se elabora una especificación para cada clase, que incluye: la
lista de sus operaciones y las clases que colaboran para cubrir esas operaciones y una
descripción de las responsabilidades, atributos y operacio nes de esa clase. c
c
Para aquellas clases cuyo comportamiento dependa del estado en el que se
encuentren se realiza, también de manera opcional, un diagrama de transición de estados. c
c
Productos c
c
De entrada c
c
G Modelo de Clases de Análisis (4.1)
De salida

cG Comportamiento de Clases de Análisis
Técnicas c
c
c G Diagrama de Transición de Estados
Participantes c
c
Gc Analistasc c c
c c c c
c c c c
c
c
c
&

c
c
En esta tarea se estudian los mensajes establecidos entre los objetos del diagrama
de interacción para determinar qué asociaciones existen entre las clases correspondientes.
Estas asociaciones suelen corresponderse con expresiones verbales incluidas en las
especificaciones.c
c
Las relaciones surgen como respuesta a las demandas en los distintos casos de uso,
y para ello puede existir la necesidad de definir agregaciones y herencia entre objetos. Una
asociación está caracterizada por: c
c
Los papeles que desempeña.
Su direccionalidad, que representa el sentido en el que se debe interpretar.
Su cardinalidad, que representa el número de instancias implicadas en la asociación. Dichas
características pueden obtenerse a partir de la especificación de los casos de uso.
c
A medida que se establecen las relaciones entre las clases, se revisa la
especificación de subsistemas de análisis en la actividad Identificación de Subsistemas de
Análisis (3), para conseguir optimizar los subsistemas. c
c
Productos c
c
De entrada c
c
G Análisis de la Realización de los Casos de Uso (4.2)
De salida

c
Técnicas c
c

Participantes

G Analistas
c
&

'
(
c
c
El objetivo de esta tarea es representar una organización de las clases que permita
una implementación sencilla de la herencia y una agrupación semántica de las diferentes
clases, basándose siempre en las normas y estándares definidos en la actividad Definición
del Sistema (1).c
c
Productos c
c
De entrada c
c
Gc Modelo de Clases de Análisis (5.2)c
c
c
c
c
c
c
c
De salidac
c

Técnicas


Participantes

G Analistas
c
c
c
c
ACTIVIDAD 6: ELABORACIÓN DEL MODELO DE
DATOSc
c
El objetivo de esta actividad que se lleva a cabo únicamente en el caso de

á es identificar las necesidades de información de cada uno de los procesos
que conforman el sistema de información, con el fin de obtener un modelo de datos que
contemple todas las entidades, relaciones, atributos y reglas de negocio necesarias para
dar respuesta a dichas necesidades. c
c
El modelo de datos se elabora siguiendo un enfoque descendente ( 857c
c
A partir del modelo conceptual de datos, obtenido en la tarea Determinación del
Alcance del Sistema (1.1), se incorporan a dicho modelo todas las entidades que vayan
apareciendo, como resultado de las funcionalidades que se deban cubrir y de las
necesidades de información del usuario. Es necesario tener en cuenta el catálogo de
requisitos y el modelo de procesos, productos que se están generando en paralelo en las
actividades Establecimiento de Requisitos (2), Identificación de Subsistemas de Análisis (3)
y Elaboración del Modelo de Procesos (7). c
c
Una vez construido los modelos conceptuales y definidas sus entidades, se resuelven
las relaciones complejas y se completa la información de entidades, relaciones, atributos y
ocurrencias de las entidades, generando el modelo lógico d e datos.c
c
Como última tarea en la definición del modelo, se asegura la normalización hasta la
tercera forma normal para obtener el modelo lógico de datos normalizado. c
c
Finalmente, si procede, se describen las necesidades de migración y carga inicial de
los datos.c
c
Esta actividad se realiza en paralelo, y con continuas realimentaciones, con otras
tareas realizadas en las actividades Establecimiento de Requisitos (2), Identificación de
Subsistemas de Análisis (3), Elaboración del Modelo de Procesos (7) y Definición de
Interfaces de Usuario (8). c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
6.1c Elaboración delc c Modelo Conceptual dec c Modelo Entidad /c c Analistasc c
Datosc Relación Extendidoc

c c c c c c
c
c
Modeloc c
c
c c
c
c
c
c
c
c
c
c
c Conceptual dec c c c c c c c
c Datosc c c c c c c c
6.2c Elaboración delc c Modelo Lógico de Datosc c Modelo Entidad /c c Analistasc c
Relación Extendidoc
c c c c c c c
c
c
Modelo Lógico dec c c
c c c
c
c
c
c
c
c
c
6.3c Normalización delc c Modelo Lógico de Datosc c Normalizaciónc c Analistasc c
Modelo Lógico dec c Normalizadoc

c c c c c c c
c c c c c c
c c c c c c c c
6.4c Especificación dec Plan de Migración y Cargac c Sesiones de Trabajoc c Usuarios Expertosc c
Necesidades dec c Inicial de Datosc c Analistasc

c c c c c c
c c c c
c Equipo de soportec
c c c c c c c
c Migración dec c c c c c
Técnicoc
c c c c c c c
c
c
Datos y Cargac c
c c
c c
c c
c
c
c c
c
c Inicialc c c c c c c c
c
c
c
) á
* $
c
c
Para la elaboración del modelo conceptual de datos, generalmente se parte de un modelo
conceptual especificado en la tarea Determinación del Alcance del Sistema (1.1).c
c
El objetivo de esta tarea es identificar y definir las entidades que quedan dentro del
ámbito del sistema de información, los atributos de cada entidad (diferenciando aquellos
que pueden convertirse en identificadores de la entidad), los dominios de los atributo s y las
relaciones existentes entre las entidades, indicando las cardinalidades mínimas y máximas.
Estas relaciones pueden ser múltiples, recursivas, de explosión e implosión,
generalizaciones y agregaciones. c
c
También se identifican aquellas entidades de datos que no forman parte del modelo,
pero que están relacionadas con alguna entidad del mismo, indicando a su vez el tipo de
relación y las cardinalidades mínimas y máximas. c
c
Asimismo, se pueden describir las reglas de negocio, también llamadas restricciones
semánticas, en lenguaje natural o mediante expresiones lógicas. c
c
Productos c
c
De entrada c
c
G Modelo Conceptual de Datos (1.1)
De salida

G Modelo Conceptual de Datos

Técnicas

G Modelo Entidad / Relación Extendido
c
c
c
c
c
c
c
c
Participantes c
c
Gc Analistasc
c
)á
* + c
c
En esta tarea se obtiene el modelo lógico de datos a partir del modelo conceptual
para lo cual se realizarán las acciones siguientes: c
c

Resolver las relaciones complejas que pudieran existir entre las distintas entidades.
Eliminar las relaciones redundantes que puedan surgir como consecuencia de la
resolución de las relaciones complejas.
Eliminar cualquier ambigüedad sobre el significado de los atributos.
Identificar las relaciones de dependencia entre entidades .
Completar la información de las entidades y los atributos, una vez resueltas las
relaciones complejas.

c Revisar y completar los identificadores de cada entidad.
También se debe especificar para cada entidad el número máximo y medio de
ocurrencias, estimaciones de crecimiento por periodo, tipo y frecuencia de acceso, así
como aquellas características relativas a la seguridad, confidencialidad, disponibilidad, etc.
consideradas relevantes. c
c
Productos c
c
De entrada c
c
G Modelo Conceptual de Datos (6.1)
De salida

G Modelo Lógico de Datos
c
Técnicas c
c
G Modelo Entidad / Relación Extendido

Participantes

G Analistas
c
)(
* + c
c
El objetivo de esta tarea es revisar el modelo lógico de datos, garantizando que
cumple al menos con la tercera forma normal. c
c
La normalización es una técnica cuya finalidad es eliminar redundancias e
inconsistencias en las entidades de datos, evitando anomalías en la manipulación de éstas
y facilitando su mantenimiento. c
c
La primera forma normal consiste en la prohibición de grupos repetitivos, es decir, la
existencia de atributos con más de un valor. La segunda y tercera formas normales se
basan en el conocimiento semántico de los datos y sus relaciones, expresadas como
dependencias funcionales. Esta identificación de dependencias exige una especial
atención en la actividad Establecimiento de Requisitos (2). c
c
c
c
c
c
c
c
c
La técnica de normalización puede exigir la modificación de entidades, la creación de
nuevas entidades y la reorganización de atributos, por lo tanto, es necesaria una revisión
del modelo. c
c
Productos c
c
De entrada c
c
G Modelo Lógico de Datos (6.2)
De salida

G Modelo Lógico de Datos Normalizado

Técnicas

G Normalización
c
Participantes c
c
Gc Analistasc
c
)á
*

$
c
c
Está tarea se realiza si es necesaria una migración de datos de otros sistemas, o una
carga inicial de información. c
c
Se especifican las necesidades de migración o carga inicial de los datos requeridos
por el sistema. Como punto de partida, se toma el modelo lógico de datos normalizado,
junto con las estructuras de datos del sistema o sistemas origen. c
c
Es preciso tener en cuenta aspectos tales como: c
c
Planificación de la migración y carga inicial.
Prioridad en las cargas.
Requisitos de conversión de información: necesidades de depuración de información,
importación de información complementaria, validaciones y controles, etc.
Plan de pruebas específico.
Necesidades especiales de equipamiento hardware y estimaciones de capacidad, en
función de los volúmenes de las estructuras de datos origen.
Necesidades especiales de utilidades software.
Posibles modificaciones del sistema origen, que faciliten la ejecución o verificación de
c la migración o carga inicial.
Como resultado de esta tarea se obtiene una primera especificación del plan de
migración de datos y carga inicial del sistema, que se completará en el proceso Diseño del
Sistema de Información (DSI). c
c
Productos c
c
De entrada c
c
G Modelo Lógico de Datos Normalizado (6.3)
G Estructuras de Datos del Sistema Origen (externo)
c
c
c
c
c
c
De salidac
c
G Plan de Migración y Carga Inicial de Datos

Prácticas

c
Participantes c
c
G Usuarios Expertos
G Analistas
c
c
c
c
ACTIVIDAD 7: ELABORACIÓN DEL MODELO DE
PROCESOSc
c
El objetivo de esta actividad, que se lleva a cabo únicamente en el caso de

á , es analizar las necesidades del usuario para establecer el conjunto de procesosque
conforma el sistema de información. Para ello, se realiza una descomposición de dichos procesos
siguiendo un enfoque descendente (85), en varios niveles de abstracción, donde cada nivel
proporciona una visión más detallada del proceso definido en el nivel anterior.c
c
Con el fin de facilitar el desarrollo posterior, se debe llegar a un nivel de
descomposición en el que los procesos obtenidos sean claros y sencillos, es decir, buscar
un punto de equilibrio en el que dichos procesos tengan significado por sí mismos dentro
del sistema global y a su vez la máxima independencia y simplicidad.c
c
Esta actividad se lleva a cabo para cada uno de los subsistemas identificados en la
actividad Identificación de Subsistemas de Análisis (3). Las tareas de esta actividad se
realizan en paralelo y con continuas realimentaciones con otras tare as ejecutadas en las
actividades Establecimiento de Requisitos (2), Elaboración del Modelo de Datos (6) y
Definición de Interfaces de Usuario (8). c
c
c
c
c Tareac c Productosc c Técnicas y Prácticasc c Participantesc c
7.1c Obtención delc c Modelo de Procesosc c Diagrama de Flujo dec c Analistasc c
c Matriz de Procesos /c Datosc

c c c c c c
c Modelo dec c c c
Localización Geográficac c Matricialc
c
c c c c c c
c
Procesos delc c c c c
(ampliada)c
c c c c c c c
c
c Sistemac c
c c
c
c
c
c
c
c
c
c
c
7.2c Especificación dec c Descripción de Interfaz conc c c Analistasc c
otros Sistemasc
c c c c c c c
c Interfaces conc c c c c c c
otros Sistemasc
c c c c c c c c
c c c c c c c c
c
c
c
, !

*
c
c
En esta tarea se lleva a cabo la descripción de los subsistemas definidos en la actividad
Identificación de Subsistemas de Análisis (3), mediante la descomposición en sucesivosc
c
c c
c
c
c
Niveles de procesos. La técnica que se propone es el diagrama de flujo de datos ampliado
con eventos, si fuera necesario. c
c
Se describe la estructura de los flujos y de los almacenes de datos, y se elabora una
especificación para cada proceso primitivo, especificación que permita conocer en detalle el tipo de
tratamiento (en línea o por lotes), la operativa asociada, las restricciones y limitaciones impuestas al
proceso, y las características de rendimiento que se consideren relevantes.c
c
Por tanto, para cada proceso primitivo identificado, se analizan las características
propias con el fin de establecer su frecuencia de ejecución, procesos asociados y
limitaciones o restricciones en su ejecución, como tiempos máximos de respuesta, franja
horaria y períodos críticos, número máximo de usuarios concurrentes, etc. Este análisis
permite establecer los criterios de distribución de los componentes software al definir, en el
proceso de diseño, la arquitec tura física del sistema. c
c
Para cada proceso primitivo, también se debe especificar qué procesos van a estar
bajo control del usuario y cuáles bajo control del sistema. Asimismo, se define su
localización geográfica y se determina su disponibilidad. c
c
Productos c
c
De entrada c
c
De salida

G Matriz de Procesos / Localización Geográfica (ampliada)
c
Técnicas c
c
G Matricial
c
Participantes c
c
Gc Analistasc
c
,á

c
c
En esta tarea se describen, con detalle, las interfaces con otros sistemas de información, con
el fin de definir y delimitar el modo en que el sistema va a relacionarse con el exterior.c
c
Para cada interfaz identificada, se especifica: c
c
Procesos del sistema de información asociados.
Especificaciones funcionales de los sistemas origen o destino.
Formatos de los datos intercambiados.
Aspectos operativos de la interfaz: en lotes o en línea y medio físico utilizado.
Frecuencia o periodicidad del intercambio.
Evento que desencadena la interfaz.
Validaciones, requisitos especiales de seguridad, etc.
Modificaciones o adaptaciones necesarias en los sistemas origen o destino.
c
c
c
c
Las interfaces con otros sistemas forman parte del modelo de procesos, pero se
recomienda que su especificación se realice como anexo al diagrama de flujo de datos en
aquellos casos en que la naturaleza de la interfaz, por sus características especiales
(complejidad, uso temporal, etc.), lo aconseje. c
c
Productos c
c
De entrada c
c
G Modelo de Procesos (7.1)
De salida

G Descripción de Interfaz con otros Sistemas

Participantes

G Analistas
c
c
c
c
ACTIVIDAD : DEINICIÓN DE INTERACES DE
USUARIOc
c
En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos
de pantallas, diálogos, e informes, principalmente. El objetivo es realizar un análisis de los
procesos del sistema de información en los que se requiere una interacción del usuario,
con el fin de crear una interfaz que satisfaga todos los requisitos establecidos, teniendo en
cuenta los diferentes perfiles a quiénes va dirigido. c
c
Al comienzo de este análisis es necesario seleccionar el entorno en el que es operativa la
interfaz, considerando estándares internacionales y de la instalación, y establecer las directrices
aplicables en los procesos de diseño y construcción. El propósito es construir una interfaz de
usuario acorde a sus necesidades, flexible, coherente, eficiente y sencillo de utilizar, teniendo en
cuenta la facilidad de cambio a otras plataformas, si fuera necesario.c
c
Se identifican los distintos grupos de usuarios de acuerdo con las funciones que
realizan, conocimientos y habilidades que poseen, y características del entorno en el que
trabajan. La identificación de los diferentes perfiles permite conocer mejor las necesidades
y particularidades de cada uno de ellos. c
c
Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes
o en línea). Para cada proceso en línea se especifica qué tipo de información requiere el
usuario para completar su ejecución realizando, para ello, una descomposición en diálogos
que refleje la secuencia de la interfaz de pantalla tipo carácter o pantall a gráfica.c
c
Finalmente, se define el formato y contenido de cada una de las interfaces de
pantalla especificando su comportamiento dinámico. c
c
Se propone un flujo de trabajo muy similar para desarrollos estructurados y orientados
a objetos, coincidiendo en la mayoría de las tareas, si bien es cierto que en orientación a
objetos, al identificar y describir cada escenario en la especificación de los casos de uso, se
hace un avance muy significativo en la toma de datos para la posterior definición de la
interfaz de usuario. c
c
c
c
c
Como resultado de esta actividad se genera la especificación de interfaz de usuario,
como producto que engloba los siguientes elementos: c
c
Principios generales de la interfaz.
Catálogo de perfiles de usuario.
Descomposición funcional en diálogos.
Catálogo de controles y elementos de diseño de interfaz de pantalla.
Formatos individuales de interfaz de pantalla.
Modelo de navegación de interfaz de pantalla.
Formatos de impresión.
Prototipo de interfaz interactiva.
Prototipo de interfaz de impresión.
c
c
c Tarea c c Productosc c Técnica s y Prácticasc c Participantesc c
8.1c Especificación dec c Especificación de Interfazc c Sesiones de Trabajoc c Usuarios Expertosc c
de Usuario:c c Analistasc
c c c c c c
c Principiosc c c c c
Principios Generales dec c c

c c c c c c c
c Generales de lac c c c c
la Interfazc
c c c c c c c
c
c
Interfazc c
c c
c c
c c
c
c
c
c
c
c
8.2c Identificación dec c
c Especificación de Interfazc cc
Diagrama dec c
c Usuarios Expertosc c
c
c Perfiles yc c de Usuario:c c Descomposiciónc c Analistasc c
Catálogo de Perfiles de c c Funcionalc

c c c c c c
c Diálogos (Soloc c c c
Usuarioc Sesiones de Trabajoc
c
c c c c c
c
para
c c c c c c
c c
Descomposiciónc c Catalogaciónc c c c
á )c
c c c c c
c
c c
c
c
Funcional en Diálogosc c Diagrama dec c
c
c
c
c
c c c c c Representaciónc c c c
8.3c Especificación dec c Especificación de Interfazc

c Prototipadoc c Usuarios Expertosc c
de Usuario:c Catalogaciónc c Analistasc

c c c c c
c Formatosc c c
Formatos Individuales dec c Sesiones de Trabajoc
c
c c c c c c
c
Individuales de lac c c c c
c c
Interfaz de Pantallac Casos de Usoc c c c
c
Interfaz dec c c c c c
c
Catálogo de Controles yc
c c c c c c
Pantallac
c c c c c c c
c
c c
c
c
Elementos de Diseño dec c
c
c
c
c
c
c
c
c
c c c Interfaz de Pantallac c c c c c
8.4c Especificación delc c Especificación de Interfazc c Diagrama de Transiciónc c Usuarios Expertosc c
Comportamientoc c de Usuario:c de Estadosc c Analistasc

c c c c c
c c c
Modelo de Navegaciónc c Prototipadoc

c c c c c c
c Dinámico de lac c c c
de Interfaz de Pantallac c Sesiones de Trabajoc
c
c c c c c
c
Interfazc c
Prototipo de Interfazc
c c c
c Matricialc
c c c c c
c c c c c c
c c c Interactivac c Diagrama de Interacciónc c c c
c c c c c de Objetosc c c c
8.5c Especificación dec c Especificación de Interfazc c Prototipadoc c Usuarios Expertosc c
de Usuario:c c Sesiones de Trabajoc c Analistasc

c c c c c
c Formatos dec c c
Formatos de Impresiónc c c
c c c c c c c
c Impresiónc c c c
Prototipo de Interfaz dec
c
c c c c c c c
c c c c c c c c
c c c Impresiónc c c c c c
c
c
c
- á

'

(c
c
El objetivo de esta tarea es especificar los estándares, directrices y elementos
generales a tener en cuenta en la definición de la interfaz de usuario, tanto para la inter faz
interactiva (gráfica o carácter), como para los informes y formularios impresos. c
c
En primer lugar, se selecciona el entorno de la interfaz interactiva (gráfico, carácter,
etc.), siguiendo estándares internacionales y de la instalación, y se determinan los
principios de diseño de la interfaz de usuario, contemplando: c
c
c
c
c

Directrices generales en cuanto a la interfaz y aspectos generales de interacción.
Principios de composición de pantallas y criterios de ubicación de los distintos
elementos dentro de cada formato.
Normas para los mensajes de error y aviso, codificación, presentación y
comportamientos.

Normas para la presentación de ayudas.
Hay que establecer criterios similares para la interfaz impresa:

Directrices generales.

Principios de composición de informes y formularios.

c Normas de elaboración, distribución y salvaguarda de la información.
Productos c
c
De entrada c
c
G Descripción General del Entorno Tecnológico (1.2)
G Catálogo de Normas (1.3)
De salida

G Especificación de Interfaz de Usuario:
Principios Generales de la Interfaz
c
Prácticas c
c

Participantes

G Usuarios Expertos
G Analistas
c
-

c
c
El objetivo de esta tarea es identificar los perfiles de usuario, de acuerdo a su nivel de
responsabilidad y al alcance o naturaleza de las funciones que realizan, así como analizar
las características más relevantes de los usuarios que van a asumir esos perfiles,
valorando tanto su conocimiento técnico, es decir, la mecánica necesaria para usar la
interfaz eficazmente, como de negocio, en cuanto a la comprensión de las funciones que
realizan, relación entre func iones y condicionantes en su ejecución. Para tal fin se genera
un catálogo de perfiles de usuario. c
c
Se identifican los procesos en línea o interactivos, a partir del modelo de procesos,
producto generado en paralelo en la actividad Elaboración del Modelo d e Procesos (7). Hay
que incluir en estos procesos, en general, todos los que requieren una comunicación en
línea con el usuario, tanto manual como informatizado, con el fin de orientarlos en un
conjunto similar para su implementación en el contexto de la interfaz. Se clasifican en
función de su prioridad, frecuencia, comunicación con otros procesos, seguridad,
restricciones de horario, etc. c
c
Se realiza una descomposición básica de dichos procesos en diálogos, en función de
las necesidades y tipo de información que requiera el usuario para llevar a cabo cada
proceso, y de sus características propias. Finalmente, se asignan los diálogos a los perfiles
de usuario, completando el catálogo. c
c
c
c
c
c
c
Es importante resaltar que la descomposición funcional en diálogos tiene distinto alcance para
un entorno basado en caracteres y para un entorno gráfico. Mientras en el primero, debido a las
limitaciones existentes, es suficiente utilizar una jerarquía de pantallas para determinar el
encadenamiento entre las mismas, en el segundo, el hecho de poder acceder y navegar a cualquier
pantalla hace que este paso sea más complejo. De todos modos aunque exista la posibilidad de
acceder a cualquier pantalla desde la principal, siempre existen restricciones que pueden
condicionar la secuencia de ejecución. Por este motivo, en un entorno gráfico se debe reflejar
también esta secuencia mediante la descomposición funcional en diálogos.c
c
En un análisis orientado a objetos, esta tarea no se realiza, puesto que se ha
analizado esta información en la especificación de los casos de uso. c
c
Productos c
c
De entrada c
c
G Especificación de Interfaz de Usuario (8.1)
De salida

Descomposición Funcional en Diálogos
c Catálogo de Perfiles de Usuario
Técnicas c
c
G Diagrama de Descomposición Funcional

Prácticas

G Diagrama de Representación
G Catalogación
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
-á
!
.

(
c
c
El objetivo de esta tarea es especificar cada formato individual de la interfaz de
pantalla, desde el punto de vista estático. Para cada proceso en línea identificado en la
tarea anterior o en la especificación de los casos de uso, y teniendo en cuenta los formatos
estándar definidos en la tarea Especificación de Principios Generales de la Interfaz (8.1),
se definen los formatos individuale s de la interfaz de pantalla requerida para completar la
especificación de cada diálogo. c
c
En el caso de un análisis orientado a objetos, estos formatos individuales van
completando las especificaciones de los casos de uso. c
c
En un análisis estructurado se tiene en cuenta, para la realización de esta tarea, el
modelo de datos y el modelo de procesos generados en paralelo en las actividades
Elaboración del Modelo de Datos (6) y Elabo ración del Modelo de Procesos (7).c
c
c
c
También se considera el catálogo de requisitos, para especificar las interfaces
relacionadas con las consultas. c
c
En la definición de cada interfaz de pantalla se deben definir aquellos aspectos
considerados de interés para su posterior diseño y construcción:c
c
Posibilidad de cambio de tamaño, ubicación, modalidad (modal del sistema, modal
de aplicación), etc.
Dispositivos de entrada necesarios para su ejecución.
Conjunto y formato de datos asociados, identificando qué datos se usan y cuáles se
generan como consecuencia de su ejecución.
Controles y elementos de diseño asociados, indicando cuáles aparecen inicialmente
c activos e inactivos al visualizar la interfaz d e pantalla.
Productos c
c
De entrada c
c
G Especificación de Interfaz de Usuario ( 8.2)
á

!
!
De salida

Formatos Individuales de Interfaz de Pantalla

Catálogo de Controles y Elementos de Diseño de Interfaz de Pantalla
c
Técnicas c
c
G Casos de Uso

Prácticas

G Prototipado
G Catalogación
Gc Sesiones de Trabajo
Participantes c
c
G Usuarios Expertos
G Analistas
c
-á
$

(c
c
El objetivo de esta tarea es definir los flujos entre los distintos formatos de interfaz de
pantalla, y también dentro del propio formato. Este comportamiento se describe mediante
un modelo de navegación de interfaz de pantalla. c
c
Para cada formato individual de pantalla o ventana, definido en la tarea Especificación
de Formatos Individuales de la Interfaz de Pantalla (ASI 8.3), se establece la entrada lógica
de los datos y las reglas de validación, incluyendo dependencia de valores (reflejo de los
requisitos de validación de sistema). c
c
c
c
c
c
c
c
Se analiza y determina la secuencia de acciones específicas para completar cada
diálogo, tal y como se ejecuta en el ámbito de la interfaz, así como las condiciones que se
deben cumplir para su inicio, y las posibles restricciones durante su ejecución. El
comportamiento está dirigido y representado por los controles y los eventos que provocan
su activación.c
c
Se identifican aquellos diálogos o formatos considerados críticos para el correcto
funcionamiento del sistema, basándose en el número de usuarios, frecuencia de uso, datos
implicados, alcance de las funciones asociadas al diálogo, diálogos comunes a diferentes
funciones, marco de seguridad establecido en los requisitos del sistema, etc. c
c
Para los diálogos o comportamientos complejos de interfaz se propone la técnica de
diagrama de transición de estados, siendo suficiente en la mayoría de los casos una
especificación del comportamiento con matrices control / evento / acción, detallándose la
acción con una descripción textual. c
c
Se propone, opcionalmente, la realización de prototipos como técnica de ayuda a la
especificación y validación de la i nterfaz de usuario. c
c
Productos c
c
De entrada c
c
á

!
!
De salida

Modelo de Navegación de Interfaz de Pantalla
c Prototipo de Interfaz Interactiva

Técnicas c
c
G Diagrama de Transición de Estados
G Matricial
cG Diagrama de Interacción de Objetos
Prácticas c
c
G Prototipado
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
-&á
!
c
c
El objetivo de esta tarea es especificar los formatos y características de las salidas o
entradas impresas del sistema. c
c
c De acuerdo a los estándares establecidos en la tarea Especificación de Principiosc
Generales de la Interfaz (8.1),c se definen losc formatos individuales de informes yc
c c c c
cc c c
c
c
c
Formularios, estos últimos si son necesarios, así como sus características principales,
entre las que se especifican la periodicidad, confidencialidad, procedimientos de entrega o
difusión, y salvaguarda de copia. c
c
Opcionalmente, se recomienda la utilización de prototipos. c
c
Productos c
c
De entrada c
c
De salida

G Especificación de Interfaz de
Usuario: Formatos de Impresión
Prototipo de Interfaz de Impresión
c
Prácticas c
c
G Prototipado
c
Participantes c
c
G Usuarios Expertos
G Analistas
c
c
c
c
ACTIVIDAD : ANÁLISIS DE CONSISTENCIA Y
ESPECIICACIÓN DE REQUISITOSc
c
El objetivo de esta actividad es garantizar la calidad de los distintos modelos
generados en el proceso de Análisis del Sistema de Información, y asegurar que los
usuarios y los Analistas tienen el mismo concepto del sistema. Para cumplir dicho objetivo,
se llevan a cabo las siguientes acciones: c
c

Verificación de la calidad técnica de cada modelo.

Aseguramiento de la coherencia entre los distintos modelos.

c Validación del cumplimiento de los requisitos.
Esta actividad requiere una herramienta de apoyo para realizar el análisis de
consistencia. También se elabora en esta actividad la Especificación de Requisitos
Software (ERS), como producto para la aprobación formal, por parte del usuario, de las
especificaciones del sistema. c
c
La Especificación de Requisitos Software se convierte en la línea base para los
procesos posteriores del desarrollo del software, de modo que cualquier petición de cambio
en los requisitos que pueda surgir posteriormente, debe ser evaluada y aprobada. c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
9.1c Verificación de losc c Especificación de Interfazc c

c c Analistasc c
c Modelosc c de Usuarioc c c c Equipo dec c
á :c Arquitecturac
c c c c c
c c c c c c
c c c Modelo Lógico de Datosc c c c c c
c c c Normalizadoc c c c c c
c c c Modelo de Procesosc c c c c c
c c !

! :c c c c c c
c c Modelo de Casos de Usoc c c c c c
c c c Especificación de Casos dec c c c c c
c c Modelo Clases de Análisisc c c c c c
c c c Comportamiento de Clasesc c c c c c
c c c de Análisisc c c c c c
c c c Análisis de la Realizaciónc c c c c c
c c c de los Casos de Usoc c c c c c
9.2c Análisis dec c Resultado de Análisis dec c Matricialc c Analistasc c
Consistenciac Cálculo de Accesosc c Equipo dec

c c c c c
c Consistenciac c c c
c Especificación de Interfazc c Lógicosc Arquitecturac

c c c c c
c entre Modelosc c
de Usuarioc Caminos de Accesosc
c
c c c c c
c c c c c c c
c c á :c c Lógicos en Consultasc c c c
c c !

! :c c c c c c
c c c Modelo de Clases dec c c c c c
c c c Análisisc c c c c c
9.3c Validación de losc c Especificación de Interfazc c Prototipadoc c Analistasc c
de Usuarioc c Usuarios Expertos c

c c c c c c
c Modelosc c c c c
á :c
c c c c c c
c c c c c c c
c c !

! :c c c c c c
c c c entre Subsistemasc c c c c
c Modelo de Clases dec
c
c c c c c c c
c c c Análisisc c c c c c
c
c
c
c
c Tareac c Productos c Técnicas y Prácticasc c Participantes c c
9.4c Elaboración de lac c Especificación dec c c Analistasc c
Requisitos Software (ERS)c c

c c c c c c
c
c
Especificación dec c
c c c
c
c
c
c
c
c Requisitosc c c c c c c
c Software (ERS)c c c c c c c
c
/ %
* c
c
El objetivo de esta tarea es asegurar la calidad formal de los distintos modelos,
conforme a la técnica seguida para la elaboración de cada producto y a las normas
determinadas en el Catálogo de Normas. c
c
Productos c
c
De entrada c
c
G Catálogo de Normas (1.3)
á

á
á

!
!
G Comportamiento de Clases de Análisis (5.1)
G Descripción de Subsistemas de Análisis (3.2)
G Descripción Interfaces entre Subsistemas (3.2)
De salida

G Especificación de Interfaz de Usuario
G Comportamiento de Clases de Análisis
c G Descripción Interfaces entre Subsistemas
Participantes c
c
G Analistas
G Equipo de Arquitectura
c
/
$

* c
c
El objetivo de esta tarea es asegurar que los modelos son coherentes entre sí,
comprobando la falta de ambigüedades o duplicación de información. c
c
c
c
c
c
c
c
Las diferentes comprobaciones varían en función del tipo de desarrollo, aunque, en
general, son matrices entre los elementos comunes de los distintos modelos. Estas
comprobaciones forman parte del producto Resultado de Análisis de Consisten cia.c
c
Los análisis de consistencia propuestos en á son:c
c
23

1 92$

Se verifica que:

Cada uno de los almacenes definidos en el modelo de procesos se corresponde
con una parte del modelo lógico de datos normalizado. Es decir, un almacén se
puede corresponder con una entidad, atributos de una entidad o con varias

entidades relacionadas.
Los atributos del modelo lógico de datos normalizado y del modelo de procesos

se ajustan a una misma especificación.
El modelo lógico de datos normalizado satisface las principales consultas de
información. Para comprobar que el modelo lógico de datos normalizado puede soportar
dichas consultas, se proponen, como técnicas opcionales, la determinación de caminos

de acceso lógico en consultas y el cálculo de accesos lógicos.
Todas y cada una de las entidades del modelo lógico normalizado son
accedidas por algún proceso primitivo. Para dicha comprobación, se propone
una matriz de entidades/procesos, donde se especifique que tipo de acceso se
realiza (alta, baja, modificación o consulta).

23

1 9 1"#

En este análisis se comprueba que los atributos relevantes que aparecen en
cada diálogo de la interfaz de usuario forman parte del modelo lógico de datos
normalizado o, en su caso, at ributos derivados de los mismos.

2$9 1"#

Se comprueba que todo proceso en línea tiene asociado al menos un diálogo.
c
El resultado del análisis de consistencia en un análisis estructurado es un producto
que engloba los siguientes elementos: c
c
Matriz de almacenes de datos / entidades del modelo lógico de datos normalizado.
Matriz de atributos de interfaz / atributos de entidades del modelo lógico de datos
normalizado.
Caminos de acceso lógico en consultas.
Cálculo de accesos lógicos.
Matriz de entidades / procesos.
c Matriz de diálogos / procesos.
Los análisis de consistencia propuestos en !
! son los
siguientes:c
c
Considerando que la interfaz de usuario incluye diagramas dinámicos y forma parte
del modelo de clases, los análisis de consistencia con la interfaz pueden solaparse con los
del resto de los modelos. Los análisis de consistencia propuestos son: c
c
2, 9

Se comprueba que:
c
c
c
c c
c c
c
c
Cada mensaje entre objetos se corresponde con una operación de una clase y
c
c
c que todos los mensajes se envían a las clases correctas. c
c
La clase que recibe un mensaje con petición de datos tiene capacidad para
c
c
proporcionar esos datos. c

c
Cada objeto del diagrama de interacción de objetos tiene una correspondencia

en el modelo de clases.
: ( (

4
Se verifica que, para cada uno de ellos, todo evento se corresponde con una
operación de la clase. También se tiene que establecer si las acciones y
actividades de los diagramas de transición de estado se corresponden con

operaciones de la clase.

2 9 1##

Cada clase que requiera una clase de interfaz de usuario, debe tener

asociación con ella en el modelo de clases.
Todas las clases, atributos y operaciones identificados en la interfaz de usuario,
deben tener su correspondencia con algún atributo, operación o clase en el

modelo de clases.

)
1
, "9 1"#

Cada elemento que active la navegación entre pantallas, debe estar asociado
con un mensaje del diagrama de interacción de objetos.
c
Además, se revisa que los subsistemas satisfagan la realización de todos los casos
de uso, e incluyan las clases identificadas hasta el momento. c
c
El resultado del análisis de consistencia en un análisis orientado a objetos es un
producto que engloba los siguientes elementos: c
c
Matriz de mensajes del diagrama de interacción de objetos / operaciones del modelo
de clases.
Matriz de mensajes del diagrama de interacción de objetos / operaciones y atributos
del modelo de clases.
Matriz de objetos del diagrama de interacción de objetos / clases, atributos del
modelo de clases.
Matriz (evento, acción, actividad de clase) / operaciones de clase.
Correspondencia elementos de negocio de interfaz de usuario / modelo de clases.
Correspondencia entre elementos de navegación de interfaz de usuario / mensajes
c del diagrama de interacció n de objetos.
Productos c
c
De entrada c
c
á

á
á

!
!
c
c
c
c
G Análisis de la Reali zación de los Casos de Uso (9.1)
G Descripción Interfaces entre Subsistemas (9.1)
De salida

G Resultado de Análisis de Consistencia
á

á
á

!
!
cG Descripción Interfaces entre Subsistemas
Técnicas c
c
G Matricial

Prácticas

G Cálculo de Accesos Lógicos (CAL)
G Caminos de Accesos Lógicos en Consultas (CALC)
c
Participantes c
c
G Analistas
G Equipo de Arquitectura
c
/%
* c
c
El objetivo de esta tarea es validar los distintos modelos con los requisitos
especificados para el sistema de información, tanto a través del catálogo de requisitos,
mediante la traza de requisitos, como a través de la validación directa del usuario,
especialmente necesaria en el caso de la interfaz de usuario. c
c
Para la validación de la interfaz de usuario se recomienda un prototipo, ya sea
estático o dinámico.c
c
Productos c
c
De entrada c
c
á

á
á

!
!
c
c
c
c
G Modelo de Clases de Análisis (ASI 9.2)
G Descripción de Interfaces entre Subsistemas (9.2)
De salida

á

á
á

!
!
cG Descripción de Interfaces entre Subsistemas
Prácticas c
c
G Prototipado

Participantes

G Analistas
G Usuarios Expertos
c
/á
á

" # 0 1á"2c
c
En esta tarea se aborda la elaboración de la Especificación de Requisitos Software
(ERS), una vez validados los modelos en la tarea anterior. c
c
Este producto incorporará la información necesaria para la aprobación final del
Análisis del Sistema de Información, según el siguiente índice: c
c
Introducción.

Ámbito y alcance.

Participantes.
Requisitos del sistema de información.
Visión general del sistema de información.
Referencia de los productos a entregar.

c Plan de acción.
Productos c
c
De entrada c
c
G Descripción general del entorno tecnológico (1.2)
G Glosario (1.1)
G Catálogo de normas (1.3)
c
c
c
c
G Catálogo de requisitos (2.4)
G Especificación de interfaz de usuario (9.3)
á

G Plan de migración y carga i nicial de datos (6.4)
G Contexto del sistema (1.1)
G Matriz de procesos / localización geográfica (7.1)
G Descripción de interfaz con otros sistemas (7.2)
G Modelo lógico de datos normalizado (9.3)
á

G Modelo de negocio / modelo de dominio (1.1)
G Modelo de casos de uso (9.3)
G Especificación de casos de uso (9.3)
G Descripción de subsistemas de análisis (9.3)
G Descripción de interfaces entre subsistemas (9.3)
G Modelo de clases de análisis (9.3)
G Comportamiento de clases de análisis (9.3)
G Análisis de la realización de los casos de uso (9.3)
De salida

G Especificación de Requisitos Software (ERS)

Participantes

G Analistas
c
c
c
c
ACTIVIDAD : ESPECIICACIÓN DEL PLAN DE
PRUEBASc
c
En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía
para la realización de las pruebas, y permite verificar que el sistema de información cumple
las necesidades establecidas por el usuario, con las debidas garantías de calidad. c
c
El plan de pruebas es un producto formal que define los objetivos de la prueba de un
sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para
elaborar una planificación paso a paso de las actividades de prueba. El plan se inicia en e l
proceso Análisis del Sistema de Información (ASI), definiendo el marco general, y
estableciendo los requisitos de prueba de aceptación, relacionados directamente con la
especificación de requisitos. c
c
Dicho plan se va completando y detallando a medida que se avanza en los restantes
procesos del ciclo de vida del software, Diseño del Sistema de Información (DSI), Construcción del
Sistema de Información (CSI) e Implantación y Aceptación del Sistema (IAS).c
c
Se plantean los siguientes niveles de prueba: c
c
Pruebas unitarias.
Pruebas de integración.
Pruebas del sistema.
Pruebas de implantación.
c
c
c
c
c Pruebas de aceptación.c
c
En esta actividad también se avanza en la definición de las pruebas de aceptación del
sistema. Con la información disponible, es posible establecer los criterios de aceptación de
las pruebas incluidas en dicho nivel, al poseer la información sobre los requisitos que debe
cumplir el sistema, recogidos en el catálogo de requisi tos.c
c
Actividad ASI : Especificación del Plan de Pruebas c
c
c
ASI 10.1c Definición delc c
c Plan de Pruebasc
c c
c Sesiones de Trabajoc
c c
c jefe de Proyectoc c
c
c Alcance de lasc c c c c c Analistasc c
c Equipo de Soportec
c c c c c c c
c Pruebasc c c c c
Técnicoc
c
c c c c c c c
c c c c c c c c
c c c c c c c Usuarios Expertos c c
ASI 10.2c Definición dec c Plan de Pruebasc c Sesiones de Trabajoc c jefe de Proyectoc c
c Analistasc
c c c c c c c
c Requisitos delc c c c c c
c c c c c c c
c Entorno dec c c c c
Técnicoc
c
c c c c c c c
c
Pruebasc c c c c c c
c Usuarios Expertosc
c c c c c c
c c c c c c c
ASI 10.3c Definición de lasc c Plan de Pruebasc c Sesiones de Trabajoc c jefe de Proyectoc c
c Analistasc
c c c c c c c
c Pruebas dec c c c c c
c c c c c c c
c Aceptación delc c c c c
Técnicoc
c
c c c c c c c
c
Sistemac c c c c c c
c Usuarios Expertosc
c c c c c c
c c c c c c c
c
3

c
c
En función de la solución adoptada en el desarrollo de un sistema de información, es
posible que determinados niveles de pruebas sean especialmente críticos y otros no sean
necesarios. Por ejemplo, puede haber grandes diferencias en función de una solución de
desarrollo completo o un producto de mercado cerrado integrado con otros sistemas. c
c
En esta tarea se especifican y justifican de los niveles de pruebas a realizar, así como el
marco general de planificación de cada nivel de prueba, según el siguiente esquema:c
c
Definición de los perfiles implicados en los distintos niveles de prueba.
Planificación temporal.
Criterios de verificación y aceptación de cada nivel de prueba.
Definición, generación y mantenimiento de verificaciones y casos de prueba.
Análisis y evaluación de los resultados de cada nivel de prueba.
Productos a entregar como resultado de la ejecu ción de las pruebas.
c
Productos c
c
De entrada c
c
G Catálogo de Requisitos (ASI 1.2)
G Catálogo de Normas (ASI 1.3)
G Descripción General del Entorno Tecnológico (ASI 2.4)
G Especificación de Interfaz de Usuario (ASI 9.3)
á

á
G Contexto del Sistema (ASI 1.1)
G Modelo de Procesos (ASI 9.3)
G Modelo Lógico de Datos Normalizado (ASI 9.3)
á

!
!
G Modelo de Casos de Uso (ASI 9.3)
c
c
c
c
G Especificación de Casos de Uso (ASI 9.3)
G Descripción de Subsistemas de Análisis (ASI 9.3)
G Descripción de Interfaces entre Subsistemas (ASI 9.3)
G Modelo de Clases (ASI 9.3)
G Comportamiento de Clases (ASI 9.3)
G Análisis de la Realización de los Casos de Uso (ASI
9.3) De salida

G Plan de Pruebas:
Especificación de los Niveles de Pruebas
c
Prácticas c
c

Participantes

G jefe de proyecto
G Analistas
G Usuarios Expertos
c
3

" # á

c
c
El objetivo de esta tarea es la definición o recopilación de los requisitos relativos al
entorno de pruebas, completando el plan de pruebas. c
c
La realización de las pruebas aconseja disponer de un ento rno de pruebas separado
del entorno de desarrollo y del entorno de operación, garantizando cierta independencia y
estabilidad en los datos y elementos a probar, de modo que los resultados obtenidos sean
objetivamente representativos, punto especialmente cr ítico en pruebas de rendimiento. c
c
No es objeto de MÉTRICA Versión 3 en general, ni de esta tarea en particular, la
especificación formal de entornos y procedimientos de pruebas en el ámbito de una instalación.c
c
Independientemente de la existencia o no de d ichos entornos, en esta tarea se inicia
la definición de las especificaciones necesarias para la correcta ejecución de las distintas
pruebas del sistema de información. Entre ellas podemos citar las siguientes: c
c
Requisitos básicos de hardware y software base: sistemas operativos, gestores de
bases de datos, monitores de teleproceso, etc.
Requisitos de configuración de entorno: librerías, bases de datos, ficheros, procesos,
comunicaciones, necesidades de almacena miento, configuración de accesos, etc.
Herramientas auxiliares. Por ejemplo, de extracción de juegos de ensayo, análisis de
rendimiento y calidad, etc.
Procedimientos para la realización de pruebas y migración de elementos entre entornos.
c
Productos c
c
De entradac
c
G Catálogo de Requisitos (ASI 2.4)
G Descripción General del Entorno Tecnológico (ASI 1.2)
G Plan de pruebas (ASI 10.1)
c
c
c
c
De salidac
c
G Plan de pruebas:
Definición de Requisitos del Entorno de Pruebas
c
Prácticas c
c

Participantes

G jefe de proyecto
G Analistas
G Usuarios Expertos
c
3

c
c
En esta tarea se realiza la especificación de las pruebas de aceptación del sistema,
labor fundamental para que el usuario valide el sistema, como último paso, previo a la
puesta en explotación. c
c
Se debe insistir, principalmente, en los criterios de aceptación del sistema que sirven
de base para asegurar que satisface los requisitos exigidos. c
c
Los criterios de aceptación deben ser definidos de forma clara, prestando especial
atención a aspectos como: c
c

Procesos críticos del sistema.

Rendimiento del sistema.

Seguridad.

c Disponibilidad.
Productos c
c
De entrada c
c
G Catálogo de requisitos (ASI 2.4)
G Especificación de Interfaz de Usuario (ASI 9.3)
G Plan de Pruebas (ASI 10.2)
á

á
G Contexto del Sistema (ASI 1.1)
G Descripción de Interfaz con otros Sistemas (ASI 7.2)
G Modelo de Procesos (ASI 9.3)
G Modelo Lógico de Datos Normalizado (ASI 9.3)
á

!
!
G Modelo de Casos de Uso (ASI 9.3)
G Especificación de Casos de Uso (ASI 9.3)
G Descripción de Subsistemas de Análisis (ASI 9.3)
G Descripción de Interfaces entre Subsistemas (ASI 9.3)
G Modelo de Clases (ASI 9.3)
G Comportamiento de Clases (ASI 9.3)
G Análisis de la Realización de los Casos de Uso (ASI 9.3)
c
c
c
c
c
De salidac
c
G Plan de Pruebas

Prácticas


Participantes

G jefe de Proyecto
G Analistas
G Usuarios Expertos
c
c
c
c
ACTIVIDAD ASI : APROBACIÓN DEL ANÁLISIS DEL
SISTEMA DE INORMACIÓNc
c
c
ASI 11.1c Presentación yc c Aprobación del Análisis delc c Presentaciónc c Comité de Direcciónc c
Sistema de Informaciónc c jefe de Proyectoc

c c c c c c
c
c
Aprobación delc c
c c c
c c
c c c
c
c Análisis delc c c c c c c c
c Sistema dec c c c c c c
Informaciónc
c
c c c c c c c c
c
c
c

c
c
En esta tarea se realiza la presentación del análisis del sistema de información al
Comité de Dirección, para la aprobación final del mismo. c
c
Productos c
c
De entrada c
c
G Especificación de Requisitos Software (ERS) (ASI 9.4)
G Plan de pruebas (ASI
10.3) De salida

G Aprobación del Análisis del Sistema de Información

Técnicas

G Presentación
c
Participantes c
c
G Comité de Seguimiento
G jefe de Proyecto
c
c
c
c
c
c
PARTICIPANTES EN LAS ACTIVIDADES DEL PROCESO ASIc
c
ANALISIS DEL c c c c c ACTIVIDADES c c c c c c
SISTEMA DE c
c c c c c c c c c
²
INORMACION c ASI ¯c ASI 2c ASI °c ASI 4c ASI 5c ASI 6c ASI 7 c ASI ±c ASI c ASI ¯³c ASI ¯¯c
c
c
Analistasc c
xc c
xc c
xc c
xc c
xc c
xc c
xc c
xc c
xc xc c
c c
c
c
c
Comité de Direcciónc c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c c
xc c
c
c
Directores Usuariosc c
xc c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
Equipo de Arquitecturac c c c c c c c c xc c c c
Equipo de Soportec
xc xc xc
c c c c c c c c
Técnicoc
c
c c c c c c c c c
c c c c c c c c c c c c
jefe de Proyectoc xc c xc c c c c c c xc xc c
Usuarios expertosc c xc c c c xc c xc xc xc c c
c
c
Actividadesc
c
ASI 1 Definición del Sistema. c
c
ASI 2 Establecimiento de Requisitos. c
c
ASI 3 Identificación de Subsistemas de Análisis.c
c
ASI 4 Análisis de los Casos de Uso. c
c
ASI 5 Análisis de Clases. c
c
ASI 6 Elaboración del Modelo de Datos.c
c
ASI 7 Elaboración del Modelo de Procesos.c
c
ASI 8 Definición de Interfaces de Usuario.c
c
ASI 9 Análisis de Consistencia y Especificación de Requisitos.c
c
ASI 10 Especificación del Plan de Pruebas.c
c
ASI 11 Aprobación del Análisis del Sistema de Información.c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
TÉCNICAS/PRÁCTICAS UTILIZADAS EN LAS ACTIVIDADES DEL PROCESO ASIc
c
ANALISIS DEL c c c c c ACTIVIDADES c c c c c c
SISTEMA DEc
c c c c c c c c c
·
INORMACION c ASI ´c ASI 2c ASI µc ASI 4 c ASI 5c ASI 6c ASI 7c ASI ¶c ASI c ASI ´¸c ASI ´´c
c
Cálculo de Accesosc
xc
c c c c c c c c c c
Lógicosc
c
Caminos de Accesosc
xc
c c c c c c c c c c
Lógicos en Consultasc
c
c
Casos de Usoc c
xc c
xc c
c
c
c
c
c
c
c
c
c c
xc c
c
c
c
c
c
c
c
c
Catalogaciónc c
xc c
xc c
c
c
c
c
c
c
c
c
c c
xc c
c
c
c
c
c
c
c
c
Diagrama de Clasesc c
xc c
c
c
c c
xc c
xc c
c
c
c
c
c
c
c
c
c
c
c
c
c
Diagramac c c c c c c c c c c c c
Descomposiciónc c c c c c c c xc c c c
Funcionalc
c
Diagrama de Flujo dec

xc xc xc
c c c c c c c c
Datos c
c
c c c c c c c c c
Diagrama de Interacciónc c
xc xc
c c c c c c c c
de Objetos c
c
c c c c c c c c c c
Diagrama de Paquetesc c
xc
c c c c c c c c c
(Subsistemas)c
c
c
c
c
c c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
Diagrama dec
xc xc
c c c c c c c c c
Representación c
c
c c c c c c c c c c
Diagrama de Transiciónc c
xc xc
c c c c c c c c
de Estados c
c
c c c c c c c c c c
Matricialc c c c c c c xc xc xc c c c
Modelo Entidad /c
xc xc
c c c c c c c c c c
Relación Extendidoc c
c
c
c
c
c
c
c
c c
c
c
c
c
c
c
c
c
c
c
c
c
Normalizaciónc c
c
c
c
c
c
c
c
c
c c
xc c
c
c
c
c
c
c
c
c
c
c
c
c
Presentaciónc c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c c
xc c
c
c
Prototipadoc c
c
c
c
c
c
c
c
c
c
c
c
c
c c
xc c
xc c
c
c
c
c
c
c
Sesiones de Trabajoc c
xc c
xc c
c
c
c
c
c c
xc c
c c
xc c
c c
xc c
c
c
c
c
c
Actividadesc
c
ASI 1 Definición del Sistema. c
c
ASI 2 Establecimiento de Requisitos. c
c
ASI 3 Identificación de Subsistemas de Análisis.c
c
ASI 4 Análisis de los Casos de Uso. c
c
ASI 5 Análisis de Clases. c
c
ASI 6 Elaboración del Modelo de Datos.c
c
ASI 7 Elaboración del Modelo de Procesos.c
c
ASI 8 Definición de Interfaces de Usuario.c
c
ASI 9 Análisis de Consistencia y Especificación de Requisitos.c
c
ASI 10 Especificación del Plan de Pruebas.c
c
ASI 11 Aprobación del Análisis del Sistema de Información.c
c
c

Analisis de Sistema de 677

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis de Sistema de 677

Enviado por

Direitos autorais:

Formatos disponíveis

c

Análisis del Sistema de Información c

S0,)i )t $*+) ($ A %4li )i )c

A %4li )i ) ($c E)@$&ifi &+&i'% ($l c A @3-,+&i'% A %4li)i )c

6-%)i)t$%&i+c Pl+% ($ P30$,+)c Si) t$*+ ($c

"lograr establecer un sistema en la empresa que permita el correcto funcionamiento de la entidad."

G Mostrar los beneficios que ofrece el diseñar sistemas.

3) Problemas para el control de empleados

c In orm ión c cc ccc c c

Ali i ?lSi tm ?If m i c

c it l i c c c c cc c c c c c cc c c cc c c c c c cc c c c ö Itf  ?  ic c

? t ?l itm c

.2.1c Obtención dec c Catálogo de Requisitosc c Sesiones de Trabajoc

c Modelo de Casos de Usoc c Catalogaciónc c Analistasc

2.2c Especificación dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c

Modelo de Casos de Uso c Catalogaciónc c Analistasc

2.3c Análisis dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c

Modelo de Casos de Uso c Catalogaciónc c Analistasc

2.4c Validación dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c

c Modelo de Casos de Usoc c Catalogaciónc c Analistasc

c ACTIVIDAD : IDENTIICACIÓN DEc

.3.1c Determinación dec á :c  Diagrama de Flujo dec c jefe de Proyectoc c

c Modelo de Procesosc Datosc c Analistasc

c Subsistemas dec á :c c Datosc c Analistasc

.4.1c Identificación dec  c Modelo de Clases dec  c Diagrama de Clasesc  c Analistasc c

4.2c Descripción de lac  c Análisis de la Realizaciónc  c Diagrama de Interacciónc c Analistasc c

de los Casos de Usoc de Objetos (secuencia oc c c

5.1c Identificación dec  c Modelo de Clases dec c Diagrama de Clasesc  c Analistasc c

Análisisc c Diagrama de Transiciónc c

 c Comportamiento de Clasesc c de Estadosc

5.2c Identificación dec  c Modelo de Clases dec c Diagrama de Clasesc  c Analistasc c

6.1c Elaboración delc c Modelo Conceptual dec c Modelo Entidad /c  c Analistasc c

Datosc Relación Extendidoc

6.2c Elaboración delc c Modelo Lógico de Datosc c Modelo Entidad /c  c Analistasc c

6.3c Normalización delc c Modelo Lógico de Datosc c Normalizaciónc  c Analistasc c

Modelo Lógico dec c Normalizadoc

Necesidades dec c Inicial de Datosc c Analistasc

7.1c Obtención delc c Modelo de Procesosc c Diagrama de Flujo dec  c Analistasc c

c Matriz de Procesos /c Datosc

7.2c Especificación dec  c Descripción de Interfaz conc c  c Analistasc c

8.1c Especificación dec  c Especificación de Interfazc  c Sesiones de Trabajoc c Usuarios Expertosc c

Principios Generales dec c c

c Perfiles yc c de Usuario:c c Descomposiciónc c Analistasc c

 Catálogo de Perfiles de c c Funcionalc

8.3c Especificación dec  c Especificación de Interfazc

de Usuario:c Catalogaciónc c Analistasc

8.4c Especificación delc c Especificación de Interfazc c Diagrama de Transiciónc c Usuarios Expertosc c

Comportamientoc c de Usuario:c de Estadosc c Analistasc

 Modelo de Navegaciónc c Prototipadoc

c c c Interactivac c Diagrama de Interacciónc c c c

8.5c Especificación dec c Especificación de Interfazc c Prototipadoc c Usuarios Expertosc c

de Usuario:c c Sesiones de Trabajoc c Analistasc

c Prototipo de Interfaz Interactiva 

9.1c Verificación de losc c Especificación de Interfazc c

c Modelosc c de Usuarioc c c c Equipo dec c

c c c Modelo Lógico de Datosc c c c c c

c c  Modelo de Casos de Usoc c c c c c

c c c Especificación de Casos dec c c c c c

c c  Modelo Clases de Análisisc c c c c c

c c c de los Casos de Usoc c c c c c

9.2c Análisis dec c Resultado de Análisis dec c Matricialc c Analistasc c

Consistenciac Cálculo de Accesosc c Equipo dec

c Especificación de Interfazc c Lógicosc Arquitecturac

c c á :c c Lógicos en Consultasc c c c

Ali i ?lSi tm ?If m i c

c it l i c c c c cc c c c c c cc c c cc c c c c c cc c c c ö Itf ? ic c

? t ?l itm c

.2.1c Obtención dec c Catálogo de Requisitosc c Sesiones de Trabajoc

c Modelo de Casos de Usoc c Catalogaciónc c Analistasc

2.2c Especificación dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c

Modelo de Casos de Uso c Catalogaciónc c Analistasc

2.3c Análisis dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c

Modelo de Casos de Uso c Catalogaciónc c Analistasc

2.4c Validación dec c Catálogo de Requisitosc c Sesiones de Trabajoc c Usuarios Expertosc c

c Modelo de Casos de Usoc c Catalogaciónc c Analistasc

.3.1c Determinación dec á :c Diagrama de Flujo dec c jefe de Proyectoc c

c Modelo de Procesosc Datosc c Analistasc

c Subsistemas dec á :c c Datosc c Analistasc

.4.1c Identificación dec c Modelo de Clases dec c Diagrama de Clasesc c Analistasc c

4.2c Descripción de lac c Análisis de la Realizaciónc c Diagrama de Interacciónc c Analistasc c

5.1c Identificación dec c Modelo de Clases dec c Diagrama de Clasesc c Analistasc c

Análisisc c Diagrama de Transiciónc c

c Comportamiento de Clasesc c de Estadosc

5.2c Identificación dec c Modelo de Clases dec c Diagrama de Clasesc c Analistasc c

6.1c Elaboración delc c Modelo Conceptual dec c Modelo Entidad /c c Analistasc c

6.2c Elaboración delc c Modelo Lógico de Datosc c Modelo Entidad /c c Analistasc c

6.3c Normalización delc c Modelo Lógico de Datosc c Normalizaciónc c Analistasc c

Necesidades dec c Inicial de Datosc c Analistasc

7.1c Obtención delc c Modelo de Procesosc c Diagrama de Flujo dec c Analistasc c

c Matriz de Procesos /c Datosc

7.2c Especificación dec c Descripción de Interfaz conc c c Analistasc c

8.1c Especificación dec c Especificación de Interfazc c Sesiones de Trabajoc c Usuarios Expertosc c

c Perfiles yc c de Usuario:c c Descomposiciónc c Analistasc c

Catálogo de Perfiles de c c Funcionalc

8.3c Especificación dec c Especificación de Interfazc

de Usuario:c Catalogaciónc c Analistasc

8.4c Especificación delc c Especificación de Interfazc c Diagrama de Transiciónc c Usuarios Expertosc c

Comportamientoc c de Usuario:c de Estadosc c Analistasc

Modelo de Navegaciónc c Prototipadoc

c c c Interactivac c Diagrama de Interacciónc c c c

8.5c Especificación dec c Especificación de Interfazc c Prototipadoc c Usuarios Expertosc c

de Usuario:c c Sesiones de Trabajoc c Analistasc

c Prototipo de Interfaz Interactiva

9.1c Verificación de losc c Especificación de Interfazc c

c Modelosc c de Usuarioc c c c Equipo dec c

c c c Modelo Lógico de Datosc c c c c c

c c Modelo de Casos de Usoc c c c c c

c c c Especificación de Casos dec c c c c c

c c Modelo Clases de Análisisc c c c c c

9.2c Análisis dec c Resultado de Análisis dec c Matricialc c Analistasc c

Consistenciac Cálculo de Accesosc c Equipo dec

c Especificación de Interfazc c Lógicosc Arquitecturac

c c á :c c Lógicos en Consultasc c c c

c c c Modelo Lógico de Datosc c c c c c

c c Modelo de Casos de Usoc c c c c c

c c c Especificación de Casos dec c c c c c

c c c Modelo de Clases dec c c c c c

9.3c Validación de losc c Especificación de Interfazc c Prototipadoc c Analistasc c

de Usuarioc c Usuarios Expertos c

c c c Modelo Lógico de Datosc c c c c c

c c Modelo de Casos de Usoc c c c c c

c c c Especificación de Casos dec c c c c c

9.4c Elaboración de lac c Especificación dec c c Analistasc c

2$9 1"#

c Alcance de lasc c c c c c Analistasc c

Sistema de Informaciónc c jefe de Proyectoc