PLANTEAMIENTO DEL PROBLEMA

A travs de la informacin obtenida, cuya actividad se desarrollaba en

un edificio ubicado en las intersecciones de la avenida paragua entre
2do y 3er anillo calle 8 nmero 2410; convirtindose en la actualidad
en su sede central, constituida en una sociedad de responsabilidad,
iniciada aproximadamente a partir del ao 2008, transformndose en
una institucin pequea que actualmente sea extendido al interior de
todo el pas tiene instituciones en Santa cruz(central), La Paz,
Cochabamba, dejando de ser una institucin pequea para incluirse en
la de categora de mediana institucin.
Los rubros con los que la misma realizan sus enseanzas se ha inclinado
notablemente hacer unas de las mejores instituciones de MMA (Artes
Marciales Mixtas).
Una de las necesidades planteadas es conocer en el momento preciso
informacin en cuanto a cada cliente como ser las especializaciones, los
ttulos que podran resultar interesantes, el domicilio actual todo lo
referente a ellos en la medida que al mandar los servicios de novedades
se encuentre con informacin precisa y relevante.
Otra necesidad a resolver se encuentra en la administracin donde el
espacio fsico es reducido en relacin al personal, que se moviliza en el
transcurso de los das. Tambin hemos sugerido un procedimiento en la
parte de depsito para llevar un seguimiento de la actividad
desarrollada y hacer saber a la administracin cada tarea a realizar si
fue concretada con total efectividad, de no ser as dejar asentado todo
en una planilla de informes antes de culminar el da.
PROPUESTA
Desarrollar un sistema web que tenga el uso de una base de datos para
tener informacin precisa y que sea agradable para la empresa y toda la
institucin.
El sistema ser capaz de satisfacer el requerimiento de los usuarios, la
implementacin seguir las indicaciones del proceso unificado,
implementando en N capas, con el paradigma orientado a objeto

Marco Terico
Teora General de Sistemas
Definicin.- Es un conjunto de partes o elementos organizados y
relacionados que interactan entre s para lograr un objetivo.
Los sistemas reciben (entrada) datos, energa o materia del ambiente y
proveen (salida) informacin, energa o materia.

Cada sistema existe dentro de otro ms grande, por lo tanto un sistema

puede estar formado por subsistemas y partes, y a la vez puede ser
parte de un supersistema.

Complejidad

Simple: Se puede identificar partes o elementos. Ej. Software.

Complejo: Constituido de subsistemas donde cada uno puede
estar formado de partes o de otros subsistemas. Ej. Tierra, Ciudad,
etc.

Modo de constitucin o material

Fsico: Los componentes son palpables, se puede tocar a travs

de los sentidos (tacto). Ej. PC, TV, etc.
Abstracto: Constituido por componentes, conceptos, trminos
abstrados de la realidad. Ej. Software, Memoria, Valores, etc.

Movimiento
Estticos: No tienen movimiento. Ej. Paquete.
Dinmicos: Tienen movimiento. Ej. Ecosistema.
Naturaleza
Vivos: Tienen vida.
Inertes: Carecen de vida. No tienen capacidad de cambio por s
solo. Ej. Cordillera de los Andes.
Intercambio con el medio
Abierto: Tienen intercambio con el medio. Ej. Cuerpo Humano,
etc.
Cerrado: No tienen intercambio con el medio. Ej. Universo.
Origen
Natural: Su origen NO depende del hombre. Ej. Sistema Solar.
Artificial: Depende de otro sistema, creado por el hombre. Ej.
Sistema de carreteras.
Dualidad de los sistemas
Excluyente: Una u otra no pueden existir al mismo tiempo. Ej.
Fuente de poder.
Complementaria: Puede existir uno y otro al mismo tiempo. Ej.
Partes de un case.
Sinergia

La suma del todo es mayor que la suma de todas sus partes. El

comportamiento de un elemento no representa el comportamiento del
todo.
Todo sistema es sinrgico en tanto el examen de sus partes en forma
aislada no puede explicar o predecir su comportamiento.
La sinergia es, en consecuencia, un fenmeno que surge de las
interacciones entre las partes o componentes de un sistema
(conglomerado). Ej. H2O.
Homeostasis
Es la propiedad de un sistema que define su nivel de respuesta y de
adaptacin al contexto.
Es el nivel de adaptacin permanente del sistema o su tendencia a la
supervivencia dinmica.
Los sistemas altamente homeostticos sufren transformaciones
estructurales en igual medida que el contexto sufre transformaciones,
ambos actan como condicionales del nivel evolucin.
Entropa(s)
Es el grado de desorden de una organizacin.
Es la perdida permanente de vida til.
Es el degaste que el sistema presenta por el transcurso del tiempo por el
funcionamiento del mismo.
Los sistemas altamente entrpicos tienden a desapareces por el
desgaste generado por su proceso sistmico. Ej. Sistema Utepsa.
Neguentropa
Se refiere a la energa que el sistema importa del ambiente para
mantener su organizacin y sobrevivir.
Luego de la aplicacin de mecanismos neguentrpicos, si persiste el
problema, se activan los mecanismos homeostticos.
Son mecanismos encargados de corregir el problema no resuelto por la
neguentropa, llevando la conducta o los resultados a los valores
normales.

Sistema de informacin

Es un conjunto de elementos orientados al tratamiento y administracin

de datos e informacin, organizados y listos para su uso posterior,
generados para cubrir una necesidad u objetivo.
Forman parte de:

Dato.- Representacin formal de hechos, conceptos para su:

comunicacin, interpretacin y procesamiento por seres humanos
o medios automticos.
Informacin.- el significado que un ser humano le asigna a los
datos.

Ciclo de vida de un Sistema de Informacin

Conocimiento de la Organizacin
Identificacin de problemas y oportunidades
Determinar las necesidades
Diagnostico
Propuesta
Diseo del sistema
Codificacin
Implementacin
Mantenimiento

Proceso Unificado de Desarrollo de Software (PUD)

Dirigido por caso de uso
Un caso de uso es una pequea funcionalidad del sistema que
devuelve al usuario un resultado importante.
Representa la unidad atmica funcional a travs del cual se
realizar todas las actividades necesarias para solucionar un
problema.
El conjunto de casos de uso de un sistema representa la
funcionalidad total del producto.
Los casos de uso no solo inician el proceso de desarrollo sino que
brindan un hilo constructor a traces de todo el proceso, los casos
se analizan, disean se implementan y se construyen los modelos
de prueba.

Centrado en la arquitectura
Solo los casos de usos, NO son suficientes. Es necesario la
Arquitectura.
Por qu?, ejemplo:
o Para construir un edificio se requiere:
Equipo Arquitectos.
Los miembros del equipo deben estar informados del
progreso.
Tendrn registrar su trabajo de forma compresible
parea los otros miembros.
Tambin presentar a otros no expertos de forman
comprensible (propietario, usuarios y otros).
Deben informar de la arquitectura al constructor,
proveedores, etc. mediante planos.

La arquitectura es la visin comn en la que todos los empleados

(desarrolladores y otros usuarios) deben estar de acuerdo.
La arquitectura nos da una clara perspectiva del sistema
completo, necesaria para controlar el desarrollo.

Iterativo e Incremental

Es prctico dividir al proyecto en pequeos mini proyectos.

Estos mini proyectos o iteraciones Incrementan la funcionalidad
del sistema para cada mini proyecto se realizan cinco flujos de
trabajo: requisitos, anlisis, diseo, implementacin y prueba.
Por supuesto una iteracin no necesariamente es aditiva puede ser
que se necesite reemplazar iteraciones en las primeras fases por
otras mucho mas robustas.

Reduce el costo de los incrementos a una sola iteracin.

Reduce el riesgo de no sacar al mercado el producto en un tiempo
calendario.
Resultados claros a corto plazo.
Los clientes rara vez definen los requisitos a un inicio.
Fase de Inicio

La fase de inicio responde a:

o La pregunta cunto va a costar el producto y en qu tiempo
estimado tendremos una primera versin del software?

o Cules son los casos de uso esenciales para los usuarios

ms importantes?
o Cul ser esbozo o la arquitectura o del producto?
Se presenta un modelo de caso uso simplificado contenga los
casos de uso ms crtico en una arquitectura provisional que
muestra los subsistemas ms importantes.

Fase de Elaboracin

En esta fase se identifican la mayora de los casos de uso y se

especfica en detalle se disea la arquitectura del sistema a travs
de modelos que representan al sistema entero esto implica que
hay una vista arquitectnica del modelo del caso de uso, del
modelo anlisis del modelo de diseo de implementacin y de
despliegue.
Al finalizar esta fase el director del proyecto est en condiciones
de planificar las actividades y estimar los recursos necesarios para
terminar el proyecto.

Fase de Construccin
El producto crece hasta convertirse en un sistema completo
preparado para ser utilizado por la comunidad de usuarios,
puede que no est completamente libre de defectos.
Muchos de esos defectos se descubrirn y solucionaran durante
la fase de transicin.

Fase de Transicin
Esta fase cubre el periodo de entrega del producto a la comunidad
de usuarios.
Se capacita al personal o usuario finales de la aplicacin, se crean
los manuales o ayudas del sistema.

MODELO DE NEGOCIO
IDENTIFICACIN DE PROCESOS DE NEGOCIOS
P.N.1.- Registrar a los patrocinadores
P.N.2.- Registrar a los profesores
P.N.3.- Registrar a los peleadores
P.N.4.- Registrar los pagos
P.N.5.- Registrar los usuarios del sistema
P.N.6.- Registrar a los cursos
P.N.7.- Registrar las categoras por peso
P.N.8.- Registrar los trabajadores
P.N.9.- Registrar los alumnos
P.N.10.- Registrar los datos de eventos
P.N.11.- Listar las fechas de los eventos y peladores
P.N.12.- Listar todos los peleadores con su peso
P.N.13.- Listar

a todos los cursos con su profesor

P.N.14.- Listar los usuarios del sistema

P.N.15.- Mostrar los pagos

CLASIFICACION DE ACTORES
ACTORES
Administrador
sistema

FUNCION
del Es

Encargado de sistema

el encargado de
otorgar permisos a los
dems
usuarios
del
sistema,
con
sus
respectivos accesos
Es el encargado de firmar
contrato
de
los

TIPO DE ACTOR
PRIMARIO

SECUNDARIO

patrocinadores
y
contratar los profesores

Cajera

Cobrar la mensualidad,
registrara
a
los
profesores y alumnos con
su respectivo horario de
clase

PRIMARIO

REQUISITOS PREVIOS
-

TENER REGISTRADOS LOS PROFESORES QUE ENSEARAN LOS

CURSOS
TENER REGISTRADOS LOS HORARIOS DISPONIBLES PARA LOS
CURSOS
TENER SELECCIONADOS LOS ESTUDIANTES POR PESO
TENER REGISTRADAS LAS ESPECIALES DE LOS PROFESORES

REGLAS DE NEGOCIOS

La administradora es la encargada de registrar a cada peleador

nuevo
El horario de atencin es de 08:00 am 10:45 pm (cinco das a la
semana)
El pago de mensualidad del peleador debe ser el mismo da que
empiece a entrenar
Todo peleador se tiene que realizar la revisin mdica una vez por
mes
Todo peleador tiene que tener el equipo adecuado para realizar el
entrenamiento
Cada profesor debe rendir un informe de cada peleador

DIAGRAMA DE ACTIVIDADES

act Business Process Model

USUARIO

SISTEMA

ingresa al sitio w eb
INICIO

se introduce usuario e
inicia secion
usuario
correcto

busca el id del profesor

que v a dar el curso

incorrecto

muestra w eb para
registrar cursos

se busca el nombre y
especialidad del profesor

da el nombre, la
capacidad, el horario y
arte marcial para el
curso

confirma el curso

se accede al horario y
arte marcial desde la
base de datos para
mostrarlos

manda los datos a la

base de datos
final

act Business Process Model

USUARIO

SISTEMA

el usuario se loguea
INICIO

el usuario entra al
sistema

se solicita el pago

se muestra interfaz de
usuario

se v erifica la solicitud
del usuario

se muestra v entana de
cobros

se da el dato del monto

que se desea cancelar

el usuario decide si
desea cancelar o no

se muestra si el usuario
tiene deudas pendientes o
no

Si se tiene deudas
muestra un mensaj e si
desea cancelar

se confirma el pago

se v erifica si todo esta

correcto

imprime la factura

finaliza la transaccion
FINAL

act Business Process Model

ACTOR

SISTEMA

el usuario se loguea
INICIO

el usuario accede al
sistema

el usuario selecciona la
opcion de ev entos

el usuario selecciona los

peleadores

se mustra interfaz de
usuario

se muestra interfaz de
ev entos

se carga una v entana con la

lista de peleadores y
horarios para dicho ev ento

organiza los horarios

para dichos ev entos

una v es todo organizado

el usuario carga todo al
sistema

el usuario confirma todos

los ev entos

se muestra mensaj e
para confirmar dichos
ev entos

se muestra mensaj e de
registros guardados
FINAL

MODELO DE REQUISITOS
REQUISITOS FUNCIONALES
NRO
RF1
RF2
RF3
RF4
RF5

RF6
RF7

RF8
RF9
RF10

REQUERIMIENT
O
Registrar
patrocinadores
Registrar a los
profesores
Registrar a los
peleadores
Registrar
los
pagos
Registrar
los
usuarios
del
sistema
Registrar
los
cursos
Registrar
las
categoras
por
peso
Registrar
los
trabajadores
Registrar
los
alumnos
Registrar
las
fechas
de
eventos

PRIORIDAD

COMPLEJIDAD

Baja

Baja

Alta

Media

Alta

Media

Ata

Alta

Alta

Baja

Alta

Alta

Media

Baja

Alta

Media

Alta

Alta

Media

Media

REQUISITOS NO FUNCIONALES
NRO
RNF1
RNF2
RNF3
RNF4
RNF5

REQUERIMIENTOS
La contrasea debe estar encriptada
La contrasea debe tener 8 caracteres como
mnimo
Debe ser programado usando el lenguaje C# y
HTML
Utilizar SQL versin 2008 como mnimo como
motor de la base de datos
Tener una opcin para realizar el BACKUP

peridicamente

MODELO DE ANALISIS
class Business Process Model

Alumnos
Categorias
-

idCategoria: int
PesoLibras: char
TipoPeso: char

1..* -

Correo: char
Dirrecion: char
FechaNacimiento: long
1
idAlumno: int
idCategoria: int
Nombre: char
Telefono: char

Pagos
* -

ArteMarcial

Fecha: long
idAlumno: int
idArteMarcial: int
idPago: int

idArteMarcial: int
Monto: int
Nombre: char
1

*
*

Peleadores
-

Correo: char
Direccion: char
FechaNacimiento: long *
idCategoria: int
idPeleador: int
Nombre: char
Telefono: char

* -

Direccion: char
Especiali dad: char
FechaNacimiento: long 1
idProfesor: int
Nombre: char
Telefono: char

*
-

1
Horarios

Capacidad: int
idArteMarcial: int
idCurso: int
1
idHorario: int
idProfesor: int
Nombre: char

* -

Horario: char
idHorarios: int

* -

Ev entos
-

Cursos

Profesores

Fecha: long
idEvento: int
*
idPeleador: int
*
Nombre: char

Trabaj adores
*

Correo: char
Direccion: char
idEvento: char
1
idTrabajador: int
Nombre: char

Patrocinadores
Correo: char
Direccion: char
idEvento: int
idPatrocinador: int
idPeleador: int
NombreEmpresa: char
Telefono: char
UsuariosSistema

Contrasea: char
idTrabajador: int
idUsuario: int
Usuario: char

DIAGRAMA DE CASOS DE USO

ADMINISTRATIVOS
FUNCIONALES
RF1.Registrar RF7.- Registrar
Patrocinadores
cursos

RF2.- Registrar
Profesores

los RF8.- Registrar las

categoras por peso

RF3.- Registrar los

peleadores
RF4.- Registrar los
usuarios del sistema
RF5.- Registrar
trabajadores
RF6.- Registrar
alumnos

los

los
los

Diagrama de caso de uso

RF9.- Registrar
pagos
RF10.- Registrar
datos de eventos

los
los

INFORMATIVOS
RF11.Listar
las
fechas de los eventos
y
peleadores
que
participaran de dicho
evento
RF12.- Listar todos los
peleadores con sus
respectivo peso
RF13.Listar
los
usuarios del sistema
RF14.Mostrar
el
profesor
con
su
respectivas clases
RF15.- Mostrar los
ingresos econmicos

uc Bussines Process Model

DIAGRAMA DE CASO DE USO

registrar los alumnos

operador

registrar
patrocinadores

registrar los
profesores

registrar peleadores

administrador del
sistema
registrar los
trabaj adores

registrar los
usuarios del sistema

Diagrama de caso de uso

uc Business Process Model

DIAGRAMA DE CASO DE USO

registrar los cursos

registrar las
categorias por peso

operador

registrar los pagos

registrar los datos de

ev ento

uc Business Process Model

DIAGRAMA DE CASO DE USO
mostrar el profesor
con sus respectiv as
clases

operador
listar fechas de los ev entos
y peleadores que participan
de dicho ev ento

mostrar los ingresos

economicos

administrador de sistema

listar los usuarios

del sistema

listar todos los

peleadores con su
respectiv o peso

N de caso de uso

C.U.1

Nombre

Registrar patrocinadores

Actor

Administrador del sistema

Tipo

nivel bajo

Referencia
Descripcin

Se hace un registro de todos

los patrocinadores que
aportan a la escuela como
tambien a los peleadores

N de caso de uso

C.U.2

Nombre

Registrar a los profesores

Actor

Administrador del sistema

Tipo

Nivel alto

Referencia
Descripcin

Se tiene que tener un registro

de todos los profesores a los
cuales se les asignara un
curso y un horario

N de caso de uso

C.U.3

Nombre

Registrar a los peleadores

Actor

Administrador del sistema

Tipo

Nivel alto

Referencia
Descripcin

Se debe tener un registro de

todos peleadores para asi
tener un control de las peleas
a realizarce.

N de caso de uso

C.U.4

Nombre

Registrar los pagos

Actor

Operador

Tipo

Nivel alto

Referencia
Descripcin

Es muy importante registrar

los pagos para que as las
personas que hacen sus
respectivos pagos empiecen a
entrenar

N de caso de uso

C.U.5

Nombre

Registrar los usuarios del

sistema

Actor

Administrador del sistema

Tipo

Nivel alto

Referencia
Descripcin

Se debe registrar los usuarios

del sistema para que asi estos
tengan acceso para asi poder
trabajar.

N de caso de uso

C.U.6

Nombre

Registrar los Cursos

Actor

Operador

Tipo

Nivel Alto Primario

Referencia
Descripcin

Es el encargado de registrar a
los alumnos por curso

N de caso de uso

C.U.7

Nombre

Registrar las categoras por

peso

Actor

Operador

Tipo

Nivel Medio Secundario

Referencia
Descripcin

Este se encarga de registrar el

peso de cada una de las
categoras

N de caso de uso

C.U.8

Nombre

Registrar los trabajadores

Actor

Operador

Tipo

Nivel Medio Secundario

Referencia
Descripcin

Es el encargado de registrar a
todos los
Trabajadores

N de caso de uso

C.U.9

Nombre

Registrar los alumnos

Actor

Operador

Tipo

Nivel Alto Primario

Referencia
Descripcin

Funcin ejecutada por

operador para registrar a los
alumnos

N de caso de uso

C.U.10

Nombre

Registrar las fechas de

eventos

Actor

Operador

Tipo

Nivel Alto Primario

Referencia
Descripcin

Esta funcin la ejecuta el

operador que tiene que
registrar las fechas de eventos

N de caso de uso

C.U.11

Nombre

Listar las fechas de los

eventos y peleadores que
participaran de dicho evento

Actor

Administrador del sistema

Tipo

No funcional

Referencia
Descripcin

El administrador del sistema

lista la fecha de eventos de los
peleadores

N de caso de uso

C.U.12

Nombre

Listar todos los peleadores

con sus respectivo peso

Actor

Administrador del sistema

Tipo

No funcional

Referencia
Descripcin

El administrador del sistema

lista los nombres de los
peleadores con su respectivo
peso

N de caso de uso

C.U.13

Nombre

Listar los usuarios del

sistema

Actor

Administrador del sistema

Tipo

No funcional

Referencia
Descripcin

El administrador del sistema

lista los id y contrasea de los
usuarios

N de caso de uso

C.U.14

Nombre

Mostrar el profesor con su

respectivas clases

Actor

Administrador del sistema

Tipo

No funcional

Referencia
Descripcin

El administrador del sistema

selecciona y muestra las clases
de cada profesor

N de caso de uso

C.U.15

Nombre

Mostrar los ingresos

econmicos

Actor

Administrador del sistema

Tipo

No funcional

Referencia
Descripcin

Cada finalizacin de eventos se

muestran todos los ingresos
econmicos

ELEGIR CASOS DE USO

FUNCIONALES
RF7.Registrar
los
cursos
RF8.Registrar
las
categoras por peso
RF9.Registrar
pagos
RF10.- Registrar
datos de eventos

los
los

DESCRIPCION DEL CASO DE USO ELEGIDO

DESCRIPCION DEL CASO DE USO ELEGIDO

CASO DE USO

REGISTRAR CURSOS

REFERENCIA

RF7

PROPOSITO

Registrar los cursos con su nombre,

capacidad, horario, arte marcial y
profesor encargado

FLUJO NORMAL
ACTOR
1.EL
USUARIO
NAVEGADOR WEB

SISTEMA
ENTRA

AL

2-. EL USUARIO ENTRA A LA PAGINA

WEB DE LA EMPRESA
3-. SE MUESTRA
USUARIO

INTERFAZ

DE

4-. EL USUARIO INICIA SECION Y

SOLICITA SERVICIO
5-. SE VERIFICA LA SOLICITUD DEL
USUARIO
6-.
SE
BUSCA
MEDIANTE SU ID

EL

PROFESOR
7-.SE MUESTRA EL NOMBRE
ESPECIALIDAD DEL PROFESOR

8.- SE ACCEDE AL HORARIO Y ARTE

MARCIAL DESDE LA BASE DE DATOS
PARA MOSTRARLOS
9-.MUESTRA EL NOMBRE Y
ESPECIALIDAD DEL PROFESOR
10.- SE INGRESA EL
CAPACIDAD,
HORARIO
MARCIAL
11-.
EL
USUARIO
CONFIRMACION
DEL
SOLICITADO

SU

NOMBRE,
Y
ARTE
ENVIA
LA
REGISTRO
12-.
SE
MUESTRA
CONFIRMANDO
EL
SOLICITADO

DESCRIPCION DEL CASO DE USO ELEGIDO

MENSAJE
REGISTRO

sd Business Process Model

DESCRIPCION DEL CASO DE USO ELEGIDO

CASO DE USO

FMR LOGIN

USUARIO

PAGOS

EL USUARIO
SE LOGUEA()

REFERENCIA
PROPOSITO

COBROS

REGISTRAR PAGOS

BD

RF9
VALIDAR USUARIO()

Registrar los pagos de los alumnos

para que no sean interrumpidos en
EXISTE (CERRAR
el entrenamiento
SECION)

FLUJO NORMAL
ACTOR

SISTEMA

DIRECCIONAR()

1.- EL USUARIO SE LOGUEA

SOLICITUD DE PAGO()
PAGOS PENDIENTES()
SE MUESTRA COBROS()

SE PAGAN LAS DEUDAS()

SE GUARDAN REGISTROS()

SE IMPRIME FACTURA()

2-. EL USUARIO ENTRA AL SISTEMA

3-. SE MUESTRA
USUARIO

INTERFAZ

DE

4-. EL USUARIO SOLICITA PAGO

5-. SE VERIFICA LA SOLICITUD DEL
USUARIO
6-. SE MUESTRA
COBROS

VENTANA

DE

7-. SE DA EL DATO DEL MONTO QUE

SE DESEA CANCELAR
8.- SE MUESTRA SI EL USUARIO
TIENE DEUDA PENDIENTE O NO
9-. EL USUARIO DECIDE SI DESEA
CANCELAR O NO
10-. SI SE TIENE DEUDAS MUESTRA
MENSAJE CONSULTANDO SI DESEA
PAGAR O NO
11-. SE CONFIRMA EL PAGO
12-. SE IMPRIME LA FACTURA
13-. EL USUARIO VERIFICA SI TODO
ESTA CORRECTO
14-. SE CONFIRMA LA TRANSACCION

sd Business Process Model

FMR LOGIN

USUARIO

PAGOS

COBROS

BD

EL USUARIO
SE LOGUEA()

VALIDAR USUARIO()

EXISTE (CERRAR
SECION)

DIRECCIONAR()

SOLICITUD DE PAGO()
PAGOS PENDIENTES()
SE MUESTRA COBROS()

SE PAGAN LAS DEUDAS()

SE GUARDAN REGISTROS()

SE IMPRIME FACTURA()

DESCRIPCION DEL CASO DE USO ELEGIDO

DESCRIPCION DEL CASO DE USO ELEGIDO

CASO DE USO

REGISTRAR DATOS DE EVENTOS

REFERENCIA

RF10

PROPOSITO

Registrar todas las actividades a

realizarce en las fechas planificadas

FLUJO NORMAL
ACTOR

SISTEMA

1.- EL USUARIO SE LOGUEA

2-. EL USUARIO ACCEDE AL SISTEMA

4-. EL USUARIO SELECCIONA

OPCION DE EVENTOS

3-. SE MUESTRA
USUARIO

INTERFAZ

DE

5-. SE MUESTRA
EVENTOS

INTERFAZ

DE

LA

6-. SE CARGA UNA VENTANA CON LA

LISTA DE PELEADORES Y HORARIOS
PARA DICHO EVENTO
7-. EL USUARIO SELECCIONA LOS
PELEADORES
8-. ORGANIZA LOS HORARIOS PARA
DICHOS EVENTOS
9-. UNA VES TODO ORGANIZADO EL
USUARIO CARGA TODO AL SISTEMA
10-. SE MUESTRA MENSAJE PARA
CONFIRMAR DICHOS EVENTOS
11-. EL USUARIO CONFIRMA TODOS
LOS EVENTOS
12-.SE
MUESTRA
MENSAJE
REGISTROS GUARDADOS

DE

sd Business Process Model

FMR LOGIN

USUARIO

EVENTOS

PELEADORES

HORARIOS

EL USUARIO DE LOGUEA()
VALIDAR USUARIO()

EXISTE (CERRAR SECION)

DIRECCIONAR()

REGISTRA EVENTOS()

SE SELECCIONAN PELEADORES()
SE SELECCIONAN HORARIOS()

SE CONFIRMAN PELEADORES ()

SE CONFIRMAN HORARIOS()

SE GUARDAN REGISTROS DE EVENTOS()

Diagrama De Componentes:
TMG

Firewall

BD

Windows
server
SQL Server
2008 R2
Servidor De Base De
Datos

INTERNET
ROUTERS

USUARIO
NAVEGADO
R