BOLIVAR

UNIVERSIDAD SIMON
DECANATO DE ESTUDIOS PROFESIONALES
DE INGENIERIA DE LA COMPUTACION

COORDINACION

SISTEMA DE REGISTRO DE PARTICIPANTES EN EVENTOS

ACADEMICOS

Por:
CARLOS GUSTAVO SARMIENTO

Realizado con la asesora de:

LUIS EDUARDO MENDOZA MORALES

PASANTIA LARGA
Presentado ante la Ilustre Universidad Simon Bolvar
como requisito parcial para optar al ttulo de
Ingeniero en Computacion

Sartenejas, 9 de ENERO de 2012

Resumen
La motivacion de este proyecto fue apoyar las nuevas estrategias de crecimiento de Organizacion de Eventos Lasses 07 C.A. a traves del desarrollo de un sistema de informacion que
pudiera manejar el registro de los asistentes que participan en los eventos organizados por la
compa
na.
El proyecto se realizo bajo la metodologa Open Unified Process (OpenUP) del Eclipse
Process Framework y consistio en la concepcion, elaboracion, construccion y transicion de
una plataforma web utilizando ASP.NET MVC 3 y jQuery.
El resultado del proyecto fue una herramienta web capaz de manejar el proceso de registro de participantes. Esta herramienta suple las necesidades de la empresa en los procesos
que ocurren antes, durante y despues de los eventos. Ademas ofrece suporte para procesos
auxiliares que esten relacionados con el registro de los participantes.
Ademas del desarrollo del sistema, objetivo principal de la pasanta, se apoyo a la empresa en el desarrollo de otras soluciones para atacar necesidades del negocio. Entre las mas
significativas se encuentran la instalacion de una red Ethernet en las nuevas oficinas de la
empresa junto con varios servicios TI relacionados y el desarrollo de la herramienta de Control de Puertas que se ejecuta en dipositivos iPod Touch (utilizada para llevar un control de
que participantes entran a una determinada conferencia).

iv

En memoria de mi Ta Coco, a quien quiero y todava extra

no

2246726565206174206C6173743B2066726565206174206C6173743B207468
616E6B20476F6420416C6D6967687479207765206172652066726565206174
206C6173742E22204D617274696E204C7574686572204B696E672C204A722E

Agradecimientos
No se puede celebrar el camino recorrido hasta ahora sin incluir a muchas personas que
lo hicieron posible.
Primero a mis padres por confiar en mis ideas locas y apoyarme incluso sabiendo que
podran no salir muy bien; de los errores se crece. Por ofrecerme oportunidades para hacer
incluso antes de saber como hacerlo. Por darme las herramientas que permitan convertir
ideas descabelladas en realidad y proyectos arriesgados en exitos. Por ofrecer un lugar donde
el so
nar era recompensado y esforzarse exigido. Por ayudarme a ser quien soy.
Segundo a mi to, quien desde ni
no me inculco el valor de entender como funcionan las
cosas. Frente a motores, aires acondicionados, bombas de agua y problemas incomprensibles
a los 7 a
nos, me ense
no a preguntar, analizar y responder.
Tercero a mis hermanos por creer en m y que no existe un techo. Son como el aire que
sostiene a un ave en vuelo.
Cuarto a Pedro, quien ha sido mi gua en el mundo que existe dentro de la mente y en
como el entendimiento de uno mismo significa paz.
Quinto a Mara Valentina, por ser en estos u
ltimos dos a
nos la fuente de mi alegra y mi
apoyo incondicional. Por escucharme, comprenderme y soportarme cuando ni yo mismo me
soportaba. Por demostrar que el amor es mas que un anhelo.
Por u
ltimo a mi Ta Coco, quien aunque ya tiene tiempo ida, siempre es una fuente de
alegra. Por mostrarme el poder de un abrazo, el calor del cari
no y la fuerza de un gesto.
A todos ustedes,
Gracias

Indice general
Indice general

VII

Indice de cuadros

Indice de figuras

XI

1. Introducci
on
1.1. Antecedentes . . . . . . . .
1.2. Planteamiento del Problema
1.3. Objetivos . . . . . . . . . .
1.4. Justificacion e Importancia .
1.5. Estructura . . . . . . . . . .
2. Entorno Empresarial
2.1. Estructura . . . . . . .
2.1.1. Eventos . . . .
2.1.2. Productos . . .
2.1.3. Operaciones . .
2.2. Cultura Corporativa .
2.3. Posicion del Pasante en
3. Marco Te
orico
3.1. Aplicacion Web
3.1.1. Ventajas
3.1.1.1.
3.1.1.2.
3.1.1.3.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
la Empresa

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

. . . . . . . . . . . . . . . . . . . . . . . . .
de las Aplicaciones Web . . . . . . . . . . .
Simplicidad de Despliegue . . . . . . . . . .
Soporte Multi-Plataforma . . . . . . . . . .
Actualizacion Automatica para los Clientes

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

1
1
2
2
3
3

.
.
.
.
.
.

5
5
6
6
7
7
7

.
.
.
.
.

8
8
9
9
10
10

3.2. Arquitectura por Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1. Arquitectura 3 capas . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2. Arquitectura Modelo-Vista-Controlador . . . . . . . . . . . . . . . . .
3.3. Herramientas de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. .NET Framework 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Visual Studio Web Developer Express 2010 y CSharp Developer Express 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3. SQL Server Express 2008 R2 . . . . . . . . . . . . . . . . . . . . . . .
3.3.4. ASP.NET MVC 3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5. .NET Entity Framework 4.2 . . . . . . . . . . . . . . . . . . . . . . .
3.3.6. IIS Express 7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Metodologa de Desarrollo
4.1. Caractersticas Generales . .
4.2. Fases de OpenUP . . . . . .
4.2.1. Fase de Concepcion .
4.2.2. Fase de Elaboracion
4.2.3. Fase de Construccion
4.2.4. Fase de Transicion .
4.3. Disciplinas de OpenUP . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

5. Fase de Concepci
on
5.1. Primera Iteracion de Concepcion . . . . . .
5.1.1. Analisis de SRP4 . . . . . . . . . . .
5.1.2. Cambios respecto al sistema anterior
5.2. Plan de Proyecto . . . . . . . . . . . . . . .
5.3. Segunda Iteracion de Concepcion . . . . . .
5.4. Vision del Producto . . . . . . . . . . . . . .
5.4.1. Descripcion de la aplicacion . . . . .
5.4.2. Posicionamiento . . . . . . . . . . . .
5.4.3. Usuarios y Stakeholders . . . . . . .
5.4.4. Caractersticas . . . . . . . . . . . .
5.5. Riesgos . . . . . . . . . . . . . . . . . . . . .

viii

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

10
11
12
13
13
13
14
14
15
15

.
.
.
.
.
.
.

17
17
18
18
19
20
21
21

.
.
.
.
.
.
.
.
.
.
.

23
23
24
25
27
28
28
28
28
29
30
32

6. Fase de Elaboraci
on
6.1. Vista de Casos de Uso . . . . . . . . . . . . . . . .
6.2. Vista Logica . . . . . . . . . . . . . . . . . . . . . .
6.2.1. Modelos de Dominio . . . . . . . . . . . . .
6.2.2. Elementos arquitectonicamente significativos
6.2.3. Diagrama de Clases . . . . . . . . . . . . . .
6.3. Vista de Implementacion . . . . . . . . . . . . . . .
6.4. Vista de Implantacion . . . . . . . . . . . . . . . .
6.5. Vista de Datos . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

35
35
37
37
38
38
38
39
40

.
.
.
.
.
.

44
44
44
45
46
47
48

8. Fase de Transici
on
8.1. Prueba Piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52
52

9. Conclusiones y Recomendaciones
9.1. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55
56

Bibliografa

58

7. Fase de Construcci
on
7.1. Iteraciones de Construccion . . . . . . . . .
7.1.1. Iteracion 1 . . . . . . . . . . . . . . .
7.1.2. Iteracion 2 . . . . . . . . . . . . . . .
7.1.3. Iteracion 3 . . . . . . . . . . . . . . .
7.1.4. Iteracion 4 . . . . . . . . . . . . . . .
7.2. Descripcion de la Version Actual del Sistema

ix

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

Indice de cuadros
3.1. Explicacion de las capas en una Arquitectura de 3 Capas (Fowler, 2003) . . .

11

4.1.
4.2.
4.3.
4.4.

Fase
Fase
Fase
Fase

5.1.
5.2.
5.3.
5.4.
5.5.

Cambios en requisitos entre SRP4 y SRP6 (Elab. Propia).

Planificacion de Iteraciones (Elab. Propia). . . . . . . . . .
Stakeholders en el Sistema (Elab. Propia). . . . . . . . . .
Caractersticas (Elab. Propia). . . . . . . . . . . . . . . . .
Riesgos (Elab. Propia). . . . . . . . . . . . . . . . . . . . .

7.1.
7.2.
7.3.
7.4.

Casos
Casos
Casos
Casos

de
de
de
de

Concepcion - Objetivos y Actividades (OpenUP-Wiki, 2011) .

Elaboracion - Objetivos y Actividades (OpenUP-Wiki, 2011)
Construccion - Objetivos y Actividades (OpenUP-Wiki, 2011)
Transicion - Objetivos y Actividades (OpenUP-Wiki, 2011) .

.
.
.
.

.
.
.
.

19
20
20
21

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

26
27
30
31
34

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

45
46
47
48

8.1. Errores Descubiertos durante la Prueba Piloto (Elab. Propia). . . . . . . . .

54

Uso
Uso
Uso
Uso

Implementados
Implementados
Implementados
Implementados

en
en
en
en

la
la
la
la

Iteracion
Iteracion
Iteracion
Iteracion

1
2
3
3

(Elab.
(Elab.
(Elab.
(Elab.

Propia).
Propia).
Propia).
Propia).

.
.
.
.
.

.
.
.
.

.
.
.
.
.

de
de
de
de

.
.
.
.
.

.
.
.
.

Indice de figuras
2.1. Estructura Organizacional de la Compa
na (Elab. Propia)

. . . . . . . . . .

5.1. Casos de Uso de SRP4 (Elab. Propia). . . . . . . . . . . . . . . . . . . . . .

5.2. Modelo de Casos de Uso Inicial de SRP6 (Elab. Propia). . . . . . . . . . . .

25
32

6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.

.
.
.
.
.
.
.

36
37
39
40
41
42
43

7.1. SRP6 - Modificando a un Participante (Elab. Propia). . . . . . . . . . . . . .

7.2. SRP6 - Generando un Reporte y su Resultado en XML (Elab. Propia). . . .
7.3. SRP6 - En la Lista de Imprimibles junto con una Plantilla (Elab. Propia). .

49
50
51

Diagrama de Secuencia. CU Crear Ciudad (Elab. Propia).

Modelo de Dominio de SRP6 (Elab. Propia). . . . . . . . .
Diagrama de Clases de SRP6 (Elab. Propia). . . . . . . . .
Diagrama de Componentes de SRP6 (Elab. Propia). . . . .
Diagrama de Implantacion de SRP6 (Elab. Propia). . . . .
Diagrama de Entidad-Relacion de SRP6 (Elab. Propia). . .
Diagrama de CU (Elab. Propia). . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

Captulo 1
Introducci
on
1.1.

Antecedentes

Organizacion de Eventos Lasses 07 C.A. es una empresa fundada en el a

no 2000 dedicada a
la organizacion de eventos del gremio medico. Durante sus diez a
nos de operacion la empresa
ha dedicado atencion especial al area de Atencion al Participante en los eventos utilizando
las Tecnologas de Informacion como herramienta principal para resolver las necesidades
tecnicas del servicio. Desde el a
no 2005, en la empresa se utiliza una plataforma desarrollada
particularmente para los requerimientos de Atencion al Participante pero esta ha comenzado
a mostrar limitaciones importantes. Entre estas se encuentran:
Incapacidad de registrar participantes con profesiones distintas a las del gremio medico.
El sistema solo se puede utilizar en el ambiente Windows y requiere de un proceso de
instalacion.
Cada cambio al sistema debe ser desplegado a mas de quince (15) computadoras.

1.2.

Planteamiento del Problema

Por esta razon, la empresa decidio desarrollar una nueva plataforma que reemplace por
completo el sistema anterior. Basada en tecnologas web (en contraste con el software actual que funciona u
nicamente bajo ambiente Windows), el proyecto busca suplir las mismas
necesidades del sistema original mientras agrega funcionalidades adicionales como soporte
multi-plataforma, interfaces mas flexibles, privilegios de acceso, etc.

1.3.

Objetivos

El Objetivo General de la Pasanta es desarrollar un Sistema de Informaci

on
para llevar un control de los participantes que se registran en uno o m
as de los
eventos que organiza la compa
na.
Especficamente, el sistema debera ser capaz de
Registrar los datos concernientes a los asistentes a un evento y los ingresos relacionados
con las inscripciones a un evento.
Procesar las listas de pre-inscritos que provean las casas comerciales que participan en
el evento.
Generar el material impreso de los asistentes personalizandolo a los dise
nos particulares
de cada evento.
Preparar las estadsticas asociadas a las diferentes participaciones existentes en el evento
(por ciudad, profesion, tipo de participante, forma de pago, entre otros).
Proveer un resumen de la participacion que se obtuvo en el evento (estado financiero
de inscripcion, total participacion por casa comercial, por profesion, entre otros).

1.4.

Justificaci
on e Importancia

En el mundo de la Organizacion de Eventos academicos, el uso de sistemas de informacion

ofrece la posibilidad de dar a los clientes y participantes acceso a servicios e informacion
con una precision y velocidad anteriormente inaccesible. En particular, en los gremios que
no tienen un contacto frecuente con las herramientas informaticas estas herramientas han
tomado un gran tiempo en estar disponible.
Para la empresa, el acceder a las capacidades que ofrece un sistema de manejo de informacion digital es una importante ventaja competitiva, que es aumentada al tener un sistema
desarrollado para servir sus requerimientos especficos, en vez de utilizar una plataforma
generica. En ese sentido, el trabajo realizado por el estudiante es el mecanismo principal por
el cual la compa
na accede a esos beneficios.

1.5.

Estructura

Este informe esta estructurado de la siguiente manera:

CAP. I - INTRODUCCION:
Provee un contexto general para el entendimiento
del trabajo
CAP. II - ENTORNO EMPRESARIAL: Describe a la compa
na donde se
realizo la pasanta; su historia, estructura y cultura organizacional.

CAP. III - MARCO TEORICO:

Introduce los conceptos importantes del Dominio
del Problema as como los conceptos tecnicos utilizados en el proyecto de pasanta.
CAP. IV - METODOLOGIA DE DESARROLLO: Explica los conceptos y las
estrategias definidas por el Open Unified Process (OpenUP) que es la metodologa bajo
la cual se desarrollo el proyecto.

CAP. V - FASE DE CONCEPCION:

Detalla el proceso de analisis realizado para
determinar los requerimientos del nuevo sistema y sus conclusiones.

CAP. VI - FASE DE ELABORACION:

Explica la solucion tecnica que se planteo
para el desarrollo del sistema.

CAP. VII - FASE DE CONSTRUCCION:

Se enfoca en el trabajo de programar
y construir el sistema, mencionando aspectos relevantes del trabajo de programacion.

CAP. VIII - FASE DE TRANSICION:

Trata del proceso de transicion de la
compa
na al nuevo sistema y de la infraestructura que lo soporta.
CAP. IX - CONCLUSIONES Y RECOMENDACIONES: Menciona las conclusiones mas importantes del proyecto y posibles recomendaciones para su posterior
continuacion.
Para poder entender todo el proceso de desarrollo del sistema, empezaremos primero con
un breve resumen del Entorno Empresarial en el cual se desarrollo la pasanta.

Captulo 2
Entorno Empresarial
Organizacion de Eventos Lasses 07 C.A. es una PYME1 fundada en el a
no 2000 dedicada
a la organizacion de Eventos academicos que durante la u
ltima decada se ha dedicado principalmente a suplir las necesidades de actualizacion academica continua del gremio medico
en Venezuela. Esto esta cambiando actualmente, con la empresa interesada en expandir sus
servicios a otros mercados a traves de una reorganizacion interna que le permita servir mas
clientes y organizar mas eventos al mismo tiempo2 .

2.1.

Estructura

La empresa esta separada en tres unidades de negocio (Eventos, Productos y Operaciones),

las cuales son dirigidas por un Vicepresidente de Unidad a los que a su vez reportan los

Gerentes de Area.
Los Gerentes de Area
supervisan a los Asistentes de Area
quienes se
encuentran en el nivel inicial de la jerarqua organizacional.

1
2

Peque
na o Mediana Empresa
Entrevista con Tutor Academico

Figura 2.1: Estructura Organizacional de la Compa

na (Elab. Propia)
Las responsabilidades de cada Unidad de Negocio son las siguientes:

2.1.1.

Eventos

Se enfoca en proveer el servicio de Organizacion de Eventos a los clientes, desde la concep

tualizacion de un Evento hasta su finalizacion y cierre. En esta unidad los Gerentes de Area
son conocidos como Gerentes de Eventos y cada uno organiza una serie de eventos de forma
independiente de los otros gerentes. Actualmente, la compa
na cuenta con dos Gerentes de
Eventos a dedicacion exclusiva.

2.1.2.

Productos

Esta unidad se dedica a proveer productos y servicios auxiliares para la organizacion de un

Evento. La intencion de la empresa es que estos ofrecimientos puedan ser utilizados tanto por
clientes internos como clientes externos que no desean el servicio de organizacion de eventos.
Productos como Aparatos Interactivos (Audience-Polling) y servicios como Inscripcion y
Registro son manejados por el personal de Producto.

2.1.3.

Operaciones

Se dedica al manejo de todos los procesos que soportan las actividades de las otras unidades de negocio. Actividades como Contabilidad y Recursos Humanos se encuentran en
Operaciones.

2.2.

Cultura Corporativa

Organizacion de Eventos Lasses se define a s misma como una empresa de servicios y su

enfoque principal es en resolver cualquier situacion en la cual el cliente pueda beneficiarse de
la intervencion de los empleados de la empresa.

2.3.

Posici
on del Pasante en la Empresa

El autor fue contratado por la compa

na para empezar labores el 18 de Julio de 2011 en
Operaciones, como el primer desarrollador de una naciente area enfocada en el desarrollo de
software para uso exclusivo de la empresa.
Formalmente, el autor reporta al Gerente de Inscripciones (ya que el software a desarrollar
se relaciona principalmente con esta area) que a su vez reporta al Vicepresidente de Productos.
En la practica, reporta directamente al Vicepresidente de Productos ya que este u
ltimo
cumple actualmente con las actividades del Gerente de Inscripciones.
Ahora que esta claro el entorno en el cual se desarrolla el proyecto, nos moveremos a
explicar los conceptos principales que rigieron la ejecucion del proyecto.

Captulo 3
Marco Te
orico
Para el desarrollo del sistema propuesto por la empresa, el principal problema fue entender las caractersticas particulares de las tecnologas que se deseaban utilizar. Una ventaja
importante a la hora de desarrollar el proyecto es que muchos de los conceptos basicos fueron claramente explicados en el Pensum de la carrera, por lo que solamente fue necesario
desarrollar algunos conceptos especficos que eran relevantes para la tarea a realizar.
La u
nica excepcion a este criterio fue el concepto de la Aplicacion Web. Este se incluyo en
el Marco Teorico del proyecto, ya que a pesar de ser un concepto de uso muy com
un en el
mundo del desarrollo de software, es necesario para que el lector que desconozca del tema
tenga un contexto mnimo para entender el resto del proyecto.
Los otros temas del Marco Teorico son las Arquitecturas por Capas (especialmente el caso
particular de la arquitectura de 3 capas), la Arquitectura Modelo-Vista-Controlador.

3.1.

Aplicaci
on Web

En el mundo empresarial moderno, el desarrollo de aplicaciones web se ha convertido en

una de los trabajos mas importantes de los grupos de TI. Pero un problema constante es

definir de forma precisa a que nos referimos al hablar de una Aplicacion Web.
La primera mencion del termino aplicacion web, ocurrio en la Especificacion de Servlets
de Java v2.2 donde se defina como Una colecci
on de servlets, p
aginas JavaServer, documentos HTML y otros recursos web que pueden incluir im
agenes, archivos comprimidos y otra
informacion(Davidson, 1999). El problema con esta definicion es que es especfica al contexto
de Java y no representa el uso actual que se le da al termino Aplicacion Web.
En este sentido, (Jazayeri, 2007) propone una definicion un poco mas clara cuando dice
Una Aplicacion Web una aplicaci
on que se accede a traves de Internet con un Explorador .

3.1.1.

Ventajas de las Aplicaciones Web

La razon por la cual las Aplicaciones Web han tenido un auge importante en los u
ltimos
a
nos se puede observar por las ventajas que ofrecen versus las aplicaciones tradicionales de
escritorio. De las muchas ventajas que pueden ser enumeradas, nos enfocaremos aqu en 3
que son generalmente consideradas de las mas importantes.

3.1.1.1.

Simplicidad de Despliegue

De acuerdo con Shklar (2003), las aplicaciones tradicionales (aplicaciones de escritorio)

requieren ser desplegadas en cada computador en el que se desea utilizar. Para poder cumplir
este requisito, se han desarrollado una gran variedad de aplicaciones que permiten automatizar el proceso de instalacion de una o mas aplicaciones. Este proceso tiene importantes
limitaciones, ya que se vuelve imposible configurar un computador al que no se tiene acceso
para que este instale una aplicacion de escritorio.
Por otro lado, las aplicaciones web no sufren de estos problemas. En primer lugar, no requieren ninguna instalacion especial en la computadora cliente, solamente la disponibilidad de
un Explorador Web y una conexion de red, dos caractersticas que se consiguen ampliamente

10

en computadoras recientes y dispositivos moviles (Shklar, 2003)

3.1.1.2.

Soporte Multi-Plataforma

Otra caracterstica de las Aplicaciones Web es que se encuentran basadas en protocolos

y formatos estandarizados1 (Shklar, 2003). Estos estandares2 son soportados por una gran
cantidad de plataformas3 lo cual le permite a una aplicacion web soportar una amplia gama
de metodos de acceso sin requerir cambios significativos o la construccion de una aplicacion
paralela que ofrezca la misma funcionalidad para otra plataforma.

3.1.1.3.

Actualizaci
on Autom
atica para los Clientes

Como las aplicaciones web son almacenadas en Servidores y no en las computadoras

clientes, el realizar una actualizacion del software requiere solamente el despliegue de nuevos
archivos en los servidores (Shklar, 2003). La proxima vez que un cliente utilice la aplicacion,
recibira del servidor los archivos actualizados, por lo que, sin ninguna interaccion particular
en el cliente, la aplicacion sera actualizada. Esto cambia la dinamica de actualizacion de
una aplicacion ya que solamente es necesario planificar el proceso de actualizaciones en los
servidores y no en las maquinas clientes.

3.2.

Arquitectura por Capas

La construccion de software en Capas es una de las tecnicas mas comunes para reducir
la complejidad de una aplicacion. Las capas sirven para compartimentar la funcionalidad del
1

Hypertext Transfer Protocol (HTTP), HyperText Markup Language (HTML), Cascading Style Sheets
(CSS), JavaScript, etc.
2
Lamentablemente, a pesar de la estandarizacion, cada fabricante lleva a cabo peque
nas interpretaciones
del significado del est
andar. Esto puede causar comportamientos ligeramente distintos en una Aplicacion Web
dependiendo de la plataforma en la que se utiliza. Por suerte, las diferencias son generalmente menores, lo
que le permite a un equipo de desarrollo adaptar la aplicacion para estos peque
nos detalles.
3
De hecho es difcil pensar en una plataforma que ofrezca acceso a la Web sin cumplir con estos estandares

11

sistema en distintos niveles, donde uno se construye sobre la funcionalidad que ofrece el nivel
directamente inferior (Fowler, 2003).

3.2.1.

Arquitectura 3 capas

De todas las arquitecturas que utilizan el modelo de Capas, la mas com

un es la arquitectura de 3 capas. (Fowler, 2003). Esta consiste en tres capas que juntas ofrecen la funcionalidad
total del sistema. Estas capas son llamadas respectivamente Presentacion, Dominio y Datos
(Brown, 2003).
Provee todos los servicios necesarios para desplegar la informacion
al usuario (Ventanas o codigo HTML, manejo de interacciones del
Presentacion
usuario, protocolos para cargar data, operaciones de terminal, etc.).
No realiza ninguna clase de manejo de la logica del dominio.
Maneja toda la logica que produce la verdadera funcionalidad del sisDominio

tema. Verifica que las operaciones que se realizan cumplen con las
reglas del dominio.
Maneja la conexion con el almacenamiento de la informacion. No incluye una comprension semantica de la data que se maneja, sino u
ni-

Datos

camente realiza las transacciones necesarias para mover la data entre

la capa de Dominio y los recursos de almacenamiento y transmision
de data.

Cuadro 3.1: Explicacion de las capas en una Arquitectura de 3 Capas (Fowler, 2003)
4

Tambien conocida como Aplicaci

on

12

3.2.2.

Arquitectura Modelo-Vista-Controlador

En contraste con la arquitectura de 3 capas, se encuentra la arquitectura Modelo-VistaControlador, descrita por primera vez en 1978 por Trygve Reenskaug mientras trabajaba con
Smalltalk (Reenskaug, 2011) e implementada por primera vez en Applications Programming
in Smalltalk-80: How to use ModelViewController (Burbeck, 1987).
Burbeck (1987) describe la arquitectura MVC como un paradigma en el que las interacciones del usuario, las respuestas del sistema y el modelo del dominio son manejadas explicitamente por objectos distintos y especializados para cada tarea.
El modelo maneja el comportamiento y la data del dominio de la aplicacion, respondiendo
a solicitudes de informacion y de cambios de estado (generalmente provenientes de las Vistas).
Las vistas, por otro lado, manejan la representacion visual de las operaciones que realiza el
sistema y son los u
nicos objetos capaces de manipular dicha representacion. Por u
ltimo, los
controladores interpretan las interacciones del usuario y remiten instrucciones al modelo o
las vistas para que realicen las operaciones apropiadas.
Una caracterstica relevante que debe mencionarse es que a diferencia de la arquitectura
de 3 capas, en los cuales las interacciones son estrictamente lineales5 , en la arquitectura MVC
la comunicacion es triangular Burbeck (1987), el modelo se comunica tanto con las vista como
los controladores y las vistas con los controladores. Esto no debe ser interpretado como la
existencia de un vnculo fuerte entre las tres partes. De hecho, Burbeck (1987) menciona
que el Modelo no tiene porque estar fuertemente vinculado con las otras dos partes de la
arquitectura, mientras que las Vistas y los Controladores estan, por su misma naturaleza,
fuertemente vinculados.
Por u
ltimo, la Arquitectura Modelo-Vista-Controlador, permite la creacion de jerarquas
donde un Controlador o una Vista delega el manejo de un subconjunto de su funcionalidad
5

Una capa se comunica solamente con la inmediatamente superior y la inmediatamente inferior

13

a un Controlador o Vista inferior. De esta manera se evita la complejizacion del codigo del
sistema.

3.3.

Herramientas de Desarrollo

Para la construccion del proyecto, se decidio utilizar el grupo de herramientas ofrecidas

por Microsoft para desarrollo de aplicaciones. Las razones se explican a continuacion.

3.3.1.

.NET Framework 4

El .NET Framework es un conjunto de APIs desarrolladas por Microsoft a partir de 1999

para el desarrollo de aplicaciones utilizando conceptos de Desarrollo Orientado a Objectos,
Recollecion de basura y Compilacion al momento (entre muchos otros) para la plataforma
Windows (Haack, 2011).
La eleccion de desarrollar el sistema en el lenguaje CSharp del .NET Framework se baso en
los siguientes criterios:
Fuerte Integracion con otras herramientas de desarrollo (desarrolladas por Microsoft o
terceras personas).
Manejo del lenguaje por parte del desarrollador y su supervisor.
Amplia comunidad en Internet puede ofrecer apoyo con problemas tecnicos.

3.3.2.

Visual Studio Web Developer Express 2010 y CSharp Developer Express 2010

Una herramienta desarrollada por Microsoft para servir como Ambiente de Desarrollo
Integrado (IDE - Integrated Development Environment) para aplicaciones Web utilizando

14

la tecnologa ASP.NET. Ofrece capacidades para el desarrollo de codigo HTML, CSS, JavaScript, CSharp y VB.NET (con la limitante de solo permitir aplicaciones web) (Haack,
2011).
La caracterstica mas atractiva para utilizar esta herramienta es su fuerte integracion con
el resto del stack Microsoft y su disponibilidad sin costo para el desarrollo de aplicaciones
comerciales.

3.3.3.

SQL Server Express 2008 R2

Es una version mas compacta y ligera del manejador de base de datos empresarial SQL
Server 2008 R2. Tiene capacidad para manejar bases de datos de hasta 2GB y ofrece soporte
completo para la version del lenguaje SQL que implementa Microsoft (T-SQL) que es a su
ves compatible con el estandar SQL-98 (Rankins, 2010).
La principal ventaja de esta herramienta es su similaridad con las versiones empresariales
de SQL Server. Esto permite a la empresa desarrollar una aplicacion contra SQL Server
Express con la seguridad de que, en el momento que las necesidades de almacenamiento
y manipulacion de datos superen las capacidades de esta version, se puede transicionar a
versiones mas capacitadas sin necesidad de realizar cambios en las aplicaciones desarrolladas
contra SQL Server Express (Rankins, 2010).

3.3.4.

ASP.NET MVC 3.5

De acuerdo con Haack (2011), ASP.NET MVC es un proyecto de Codigo de Abierto

para el desarrollo de aplicaciones web bajo el principio de Modelo-Vista-Controlador. La
herramienta ofrece las cacacidades necesarias para el manejo de una aplicacion web, lo que
le permite al desarrollador dedicarse a la logica de negocio y las funcionalidades especficas
de la aplicacion.

15

3.3.5.

.NET Entity Framework 4.2

Las libreras que conforman el .NET Entity Framework 4.2 ofrecen funcionalidad dirigida a simplificar el acceso a bases de datos relacionales. La librera permite abstraer las
instrucciones de acceso de datos (Generalmente codigo SQL) del codigo de la aplicacion.
Estas capacidades estan a su vez construdas siguiendo las reglas y patrones de dise
no y
programacion recomendadas para evitar ataques contra la capa de datos (Lerman, 2011).
En particular, el sistema utiliza la librera Code First, que permite crear las entidades
del modelo de datos como clases de .NET, describiendo sus caractersticas y relaciones en el
mismo codigo. Estas a su vez son convertidas automaticamente6 en un esquema de base de
datos que puede ser ejecutado directamente contra el Manejador de Bases de Datos.
Ademas la librera Code First permite generar automaticamente las consultas SQL a la
Base de Datos a partir de consultas escritas en codigo .NET78 y convertir el resultado de las
mismas en objetos de .NET (Lerman, 2011).
Por u
ltimo, la librera tambien ofrece la capacidad de guardar los cambios que se le realizan
a los objetos .NET en la base de datos que los mismos representan.

3.3.6.

IIS Express 7.5

Una version compacta del servidor HTTP Internet Information Server 7.5 que puede ser
utilizada en computadoras que no tiene Windows Server como sistema operativo. Ofrece las
mismas funcionalidades de IIS 7.5 en su version completa con la diferencia de que no es capaz
de manejar altos niveles de transacciones concurrentes (Haack, 2011).
El sistema utiliza este programa como Servidor HTTP ya que permite ejecutar de forma
6

Aunque la conversi
on es autom
atica, la librera permite configurar el proceso para obtener modificar el
esquema resultante.
7
Para esto se utiliza una librera includa con .NET desde la version 3.0 llamada LINQ.
8
Estas consultas son fuertemente optimizadas por la librera, y para los casos en los cuales el resultado
del proceso sea sub-
optimo existe las posibilidades de escribir una consulta en SQL y que esta sea ejecutada
por la librera sin perder el uso del resto de la funcionalidad

16

trivial aplicaciones web desarrolladas con .NET a la vez que ofrece caractersticas avanzadas
como transacciones con SSL/TLS en un paquete sin costo.
Para el proximo captulo, realizaremos un breve resumen de la metodologa OpenUP
utilizada durante el desarrollo del proyecto.

Captulo 4
Metodologa de Desarrollo
Para el desarrollo de este proyecto se utilizo la metodologa OpenUP (Open Unified
Process) desarrollada bajo el marco del Eclipse Process Framework, un proyecto de software
libre de la Fundacion Eclipse
La metodologa OpenUP empezo como una donacion de IBM al mundo del software libre
de su metodologa Basic Unified Process (BUP) que a su vez es una simplificacion de la
metodologa Rational Unified Process (RUP) en el a
no 2005. Esta donacion la recibio la
Fundacion Eclipse como una propuesta para un nuevo proyecto (Kroll, 2007).
De acuerdo con Kroll (2006), la metodologa OpenUP se define en funcion del Proceso
Unificado, con cambios trados al incluir principios de las metodologas agiles como Scrum y

eXtreme Programming as como el Manifiesto Agil.

4.1.

Caractersticas Generales

OpenUP, a pesar de estar fuertemente relacionado con RUP y el Proceso Unificado en

general, presenta dos cambios importantes que buscan simplificar la manera en la cual se
trabaja con la metodologa. El primero de ellos es el manejo del proceso como a partir de

18

incrementos discretos. En vez de dedicar los recursos de un proyecto a completar de forma

completa una tarea particular, o un area del sistema particular, OpenUP propone dedicar los
recursos por espacios de tiempo mas cortos y producir resultados mas modestos que puedan
ser refinados en periodos de tiempo futuros hasta llegar a una solucion que cumpla con la
funcionalidad completa (Kroll, 2007).
Por otro lado, OpenUP tambien propone que el proceso de construccion del software se
realice en Micro-Incrementos (Gustafsson, 2008). Estos micro incrementos son paquetes que
desarrollan un peque
no componente de la funcionalidad total del sistema de forma completa,
tal que cada vez que se termine una iteracion, el equipo de desarrollo tiene un producto en
un estado funcional (Kroll, 2007).

4.2.

Fases de OpenUP

Algo que si no ha cambiado en comparacion con el proceso unificado son las fases de
desarrollo1 . OpenUP todava divide el proceso de desarrollo en 4 fases concretas, por las que
se mueve el equipo de desarrollo de forma lineal. Estas fases son: Concepcion, Elaboracion,
Construccion y Transicicion.

4.2.1.

Fase de Concepci
on

El objetivo principal de la Fase de Concepcion es el adquirir un conocimiento claro de las

caractersticas del sistema que se desea desarrollar. En el OpenUP-Wiki (2011) se definen los
siguientes objetivos y actividades:

Esta afirmaci
on no debe confundirse con otra que afirme que la forma en la que se realizan las fases es
la misma que en RUP. De hecho en la seccion anterior se muestra que esto no es cierto.

19

Objetivos de la Fase

Actividades

Entender que se desea construir

Identificar y refinar los requerimientos

Definir la funcionalidad clave del siste-

Iniciar el Proyecto. Identificar y refinar

ma.

los requerimientos

Determinar al menos una posible soluAceptar una estrategica tecnica.

cion.
Entender los costos, cronogramas y

Iniciar el Proyecto. Planificar y Geren-

riesgos asociados con el proyecto.

ciar la Iteracion.

Cuadro 4.1: Fase de Concepcion - Objetivos y Actividades (OpenUP-Wiki, 2011)

4.2.2.

Fase de Elaboraci
on

El objetivo principal de la Fase de Elaboracion consiste en construir una arquitectura

sobre la cual puedan soportarse el resto de la funcionalidad del sistema2 . Un punto crtico
es que la arquitectura debe ser implementada y validada, no simplemente dise
nada en papel
para poder proseguir a la siguiente fase. En el OpenUP-Wiki (2011) se definen los siguientes
objetivos y actividades:
Objetivos de la Fase

Actividades

Obtener una comprension de los requeIdentificar y refinar los requerimientos

rimientos mas detallada
Desarrollar la arquitectura. Desarrollar
Dise
nar, implementar y validar la arincrementos de la solucion.Probar la soquitectura
lucion

Cuyo principal entregable es el Documento de Arquitectura de Software (DAS).

20

Mitigar los riesgos esenciales, producir

Planificar y Manejar la Iteracion
un cronograma preciso y estimar costos
Cuadro 4.2: Fase de Elaboracion - Objetivos y Actividades (OpenUP-Wiki, 2011)

4.2.3.

Fase de Construcci
on

El objetivo principal de la Fase de Construccion es la de desarrollar una aplicacion que,

basdada en la arquitectura desarrollada en la Fase de Elaboracion, cumpla con los requerimientos planteados para el sistema. La parte mas importante de este proceso es que todas las
iteraciones de esta fase deben producir un producto completo, que puede ser potencialmente
distribudo a los usuarios. En el OpenUP-Wiki (2011) se definen los siguientes objetivos y
actividades:
Objetivos de la Fase

Actividades

Desarrollar de forma iterativa un proIdentificar y refinar los requerimientos.

ducto completo que esta listo para poDesarrollar un incremento de la solutencialmente ser transicionado a los
cion. Probar la Solucion
usuarios.
Planificar y Gerencias la Iteracion.
Minimizar los costos de desarrollo y alDesarollar un incremento de la solucanzar un nivel de paralelismo.
cion. Probar la Solucion.
Cuadro 4.3: Fase de Construccion - Objetivos y Actividades (OpenUP-Wiki, 2011)

21

4.2.4.

Fase de Transici
on

El objetivo de la u
ltima Fase, Transicion es el de preparar el software para ser transicionado de forma definitiva a la comunidad de usuarios. Esta preparacion se logra puliendo y
optimizando las funcionalidades desarrolladas en la Fase de Construccion. En el OpenUPWiki (2011) se definen los siguientes objetivos y actividades para esta fase:
Objetivos de la Fase

Actividades
Continuar las tareas en curso. Desarro-

Prueba Beta para validar que se cumllar un incremento de la solucion. Proplen las expectativas de los usuarios.
bar la Solucion.
Alcanzar el acuerdo de los participantes
del proyecto que el despliegue esta com- Planificar y Gerenciar la iteracion. Propleto. Achieve stakeholder concurrence

bar la solucion

that deployment is complete

Mejorar el desempe
no de proyectos futuros a traves de las lecciones aprendi-

Planificar y Gerenciar la iteracion

das
Cuadro 4.4: Fase de Transicion - Objetivos y Actividades (OpenUP-Wiki, 2011)

4.3.

Disciplinas de OpenUP

Para las disciplinas en OpenUP, se realizo una simplificacion de las disciplinas establecidas
en RUP. El objetivo fue eliminar actividades que no eran crticas para el desarrollo de software
en grupos peque
nos y/o actividades que fuesen ejecutadas por grupos externos al equipo de
desarrollo.

22

De acuerdo con BLAH las disciplinas resultantes en OpenUP son:

Requerimientos
Arquitectura
Desarrollo
Pruebas
Manejo de Proyectos
Manejo de Configuraci
on y Cambios
Para iniciar la descripcion del proceso de Desarrollo del sistema, empezaremos con la
primera de las etapas de la metodologa OpenUP, la Fase de Concepcion.

Captulo 5
Fase de Concepci
on
Este captulo se dedica a explicar el proceso por el cual se determinaron los caractersticas principales del sistema y como estas deban ser representadas ante el usuario. En la
metodologa OpenUP, a esta fase se le conoce como Fase de Concepci
on (Inception Phase).
En el proyecto, se realizaron dos iteraciones formales durante la fase de concepcion del
Sistema. Durante estas dos iteraciones se alcanzaron los siguientes objetivos de la metodologa:
Definir que se desea construir.
Identificar las funcionalidades clave del sistema.
Determinar una solucion tecnica.
Entender los costos, cronograma y riesgos del proyecto.

5.1.

Primera Iteraci
on de Concepci
on

Como se menciono anteriormente, la empresa ya contaba con un sistema para las necesidades que presentaba el negocio y su interes principal era en migrar la plataforma de un

24

aplicacion local a una plataforma web. En vista de esto, para definir los requerimientos del
sistema se llevaron a cabo tres analisis por separado. El primero se enfoco en la funcionalidad cumpla el sistema actual de la empresa, como mecanismo para entender el dominio del
sistema y muchos de los requerimientos que se plantearon. El segundo busco entender que
caractersticas se deseaban modificar en comparacion con el sistema original. Por u
ltimo, el
tercero fue determinar que caractersticas eran totalmente nuevas.

5.1.1.

An
alisis de SRP4

Para realizar el analisis del sistema actual, el autor participo en varios eventos de la
compa
na como Operador, utilizando el mismo en el entorno en el que se utiliza realmente.
A partir de esta experiencia y de conversaciones con los usuarios, se determinaron los Casos
de Uso (CU) del sistema. Como resultado de una ingeniera de reversa el resultado final fue
un Modelo de Casos de Uso (MCU) (ver Figura 5.2) que refleja los CU que ofrece el sistema
actual (SRP4).
Como se puede observar, la funcionalidad ofrecida en SRP4 parece ser bastante limitada.
CU como la posibilidad de manejar los registro de las entidades auxiliares del sistema no
existen, as como sistemas de generacion de reportes complejos1 .
Aunque esta observacion es cierta en el sentido tecnico, sera un error pensar que el sistema
es inadecuado para la compa
na. El mismo esta construdo alrededor de las necesidades
particulares de la empresa, por lo que cumple de forma clara con los requisitos de manejo
de informacion y flujo de procesos del negocio. Esto es relevante para el proyecto porque nos
permite utilizar los CU de SRP4 como una base en la cual basar la funcionalidad para el
nuevo sistema y asegurar que SRP6 ofrezca las caractersticas necesarias de SRP4.
Vale la pena aclarar que la afirmacion anterior es valida en la medida en la que nuevos
1

Existe una herramienta que es capaz de extraer la informacion del sistema pero no es parte del sistema
sino una herramienta desarrollada por un particular

25

Figura 5.1: Casos de Uso de SRP4 (Elab. Propia).

requisitos no entren en conflicto con las caractersticas del sistema anterior. En estos casos
la poltica del proyecto es modificar las caractersticas heredadas de SRP4 de forma que
cumplan con los requisitos de SRP6.

5.1.2.

Cambios respecto al sistema anterior

Para cumplir con los requerimientos de las nuevas iniciativas de negocio que se desean
realizar en la empresa, se identificaron un grupo de caractersticas que deban cambiar entre
SRP4 y SRP6. Para describir estos cambios, se construyo el cuadro 5.1.

26

Categora

SRP4

SRP6

Tipo de Sistema

Cliente - Servidor

Web

Validacion de Usuarios

Interna

A traves de LDAP

Almacenamiento de Datos

Centralizado

Distribuido

Dos (2)

Ilimitadas

Uno (1)

Ilimitadas

No. de Especialidades por

Participante
No. de Tipos de Participacion por Participante y
Evento
Tipo de Documento de
Cedula de Identidad

Identidad

Cedula de Identidad, Pasaporte3 , ID temporal

Todas las transacciones de-

No existe ninguna bitacora

ben ser registradas en una

de las transacciones.

bitacora con Usuario, Fecha

Registro de Transacciones
y Operacion.
Manejo de conceptos, paEl sistema solamente manegos y la relacion entre ellos
ja registros de Pagos, peControl de Ingresos

(Transacciones) cuando un
ro no los asocia con ning
un
concepto4

participante cancela mas de

uno.

Cuadro 5.1: Cambios en requisitos entre SRP4 y SRP6 (Elab. Propia).

2

Para casos en los cuales no se tena la C.I. del participante, la empresa utilizaba un texto que empezaba
por P(por ejemplo P123456789), pero esto no fue una caracterstica dise
nada en el sistema sino una solucion
temporal al problema.
3
Para poder registrar los conferencistas internacionales.
4
Esto causaba muchos problemas cuando un participante pagaba mas de un concepto, ya que no se poda
determinar que conceptos componan el total.

27

5.2.

Plan de Proyecto

En esta iteracion se planifico ademas la distribucion del resto del tiempo disponible para
el proyecto. El resultado de ese trabajo de planificacion se encuentra en el cuadro 5.2.
Iteracion

Duracion Objetivos

1ra Iteracion de

Realizar un analisis de las herramientas que existen actual5 das

Concepcion

mente en la empresa.

2da Iteracion de

Determinar el posicionamiento del sistema y desarrollar el Do5 das

Concepcion

cumento Vision.

1ra Iteracion de

Desarrollar los requerimientos del sistema y realizar la Espe10 das

Elaboracion

cificacion de Requerimientos

2da Iteracion de

Preparar la arquitectura del sistema y el Documento de Ar10 das

Elaboracion

quitectura de Software

1ra Iteracion de
10 das

Programar la funcionalidad mnima para ejecutar el sistema.

Construccion
2da Iteracion de

Programar los CU que manejan la entrada, modificacion y

15 das

Construccion

eliminacion de data del sistema.

3ra Iteracion de
15 das

Programar la funcionalidad de reportes.

10 das

Programar toda la funcionalidad adicional restante.

Construccion
4ta Iteracion de
Construccion
1ra Iteracion de

Preparar y ejecutar el piloto de la aplicacion en un evento

10 das

Transicion

organizado por la compa

na.
Cuadro 5.2: Planificacion de Iteraciones (Elab. Propia).

28

5.3.

Segunda Iteraci
on de Concepci
on

En la segunda iteracion de Concepcion, se desarrollo la vision del sistema. Esto consistio en

detallar el Posicionamiento del Sistema, sus usuarios y stakeholders, las necesidades que
resuelve el sistema. Estas ideas sirvieron para guiar el resto del proceso de desarrollo de la
aplicacion.

5.4.

Visi
on del Producto

Despues del desarrollo de la vision del proyecto esta quedo planteada finalmente en el
Documento de Vision (Disponible completo en el Apendice A). Los elementos mas relevantes
de la vision del proyecto son los siguientes.

5.4.1.

Descripci
on de la aplicaci
on

La aplicacion es un sistema de informacion Web que va a ser utilizado en computadoras

con ambiente Windows para la realizacion del registro de participantes en un evento organizado por la Compa
na. La aplicacion debe permitir el registro de participantes, la generacion de
material imprimible personalizado, la generacion de reportes. Aunque actualmente la aplicacion no interact
ua con ning
un otro sistema de la empresa, esta posibilidad debe considerarse
en la ejecucion del proyecto.

5.4.2.

Posicionamiento

El sistema fue concebido para resolver varios problemas a los cuales se enfrentaba la
compa
na y para los cuales la aplicacion anterior (SRP4) era insuficiente. A traves del analisis
de la Fase de Concepcion se determinaron los siguientes problemas:
Registrar a los participantes en los Eventos Medicos organizados por la Compa
na.

29

Registrar de forma masiva o en lote las listas de participantes provistas por las empresas
patrocinantes
Ofrecer informacion agregada acerca de los participantes en un Evento.
Llevar un control monetario de los ingresos que se generan por la inscripcion de participantes en el evento.

5.4.3.

Usuarios y Stakeholders

El proyecto se realizo con el apoyo de tres personas que tuvieron la posicion dual de
Usuarios y Stakeholers. Como el sistema fue concebido para uso estrictamente interno, no
hay ninguna persona externa a la empresa como Stakeholder. El posicionamiento completo
de los stakeholders y usuarios se encuentran en el Documento Vision en el Anexo A.
Categora

Responsabilidad

Nombre

Determina los requerimienPromotor del Proyecto, Adtos de la aplicacion y deterministrador del Sistema y

Nelliana Acu
na
mina el cumplimiento de los

Gur
u de Negocios
requisitos
Apoyar en el desarrollo de
la solucion tecnica para los
Gur
u de Negocio, Experproblemas planteados en los
to Tecnico y Administrador

Isbhet Mu
noz
requerimientos. Ayudar a

del Sistema
convertir los requerimientos
en soluciones tecnicas

30

Proveer feedback en relacion al funcionamiento del

Operador del Sistema

sistema y su facilidad de uso Marco Calabrese

por parte de los operadores
en un Evento.

Cuadro 5.3: Stakeholders en el Sistema (Elab. Propia).

5.4.4.

Caractersticas

En la metodologa utilizada a este nivel del proyecto los requerimientos del sistema son
las caractersticas de alto nivel que debe cumplir el mismo. En el Documento Vision (ver
Apendice A) se plantearon los requerimientos principales del sistema y la solucion que deba
proponer la aplicacion.
Necesidad

Solucion Actual

Propuesta

Se requiere registrar los da-

El sistema SRP4 ofrece

tos concernientes a los asis-

una funcionalidad similar.

tentes a un evento y los in-

Cuando

gresos relacionados con las

esta operativo se utiliza

inscripciones a un evento.

Excel

La aplicacion debe ofrecer

una Interfaz Web para registrar los datos concernientes
el

sistema

no
a los asistentes a un evento y generar los imprimibles
necesarios.

31

La aplicacion debe ofrecer

Se requiere procesar las lis-

La carga de la informa-

tas de pre-inscritos que pro-

cion se realiza manualmen-

vean las casas comerciales

te, participante por partici-

que participan en el evento.

pante, en SRP4

una Interfaz Web a la cual

se suban archivos en formato CSV que sean procesados
automaticamente.
Se requiere preparar las
SRP4 ofrece una herramienestadsticas asociadas a las

La aplicacion debe ofreta que exporta la informa-

diferentes

participaciones

cer una Interfaz Web la

cion del evento a Excel. La

existentes

en

el

evento

cual permita generar reporagregacion y el analisis de la

(por ciudad, profesion, tipo

tes agregando la informainformacion se realizan ma-

de participante, forma de

cion deseada.
nualmente.

pago, entre otros).

Se requiere proveer un resuSe utilizan los mecanismos
men de la participacion que
existentes en SRP4 para

La aplicacion debe ofrecer

se obtuvo en el evento (estael manejo de los Pagos y la capacidad de generar Redo financiero de inscripcion,
otra informacion relaciona- portes de Caja, de Ingresos
total participacion por casa
da, aunque son insuficien-

y Balances del evento.

comercial, por profesion, entes.

tre otros).
El sistema SRP4 ofrece La aplicacion debe seguir
Se requiere que las actividauna funcionalidad insufi-

los estandares webs mni-

des que realice la aplicacion

ciente de seguridad y confia- mos de seguridad y confiasean seguras y confiables.
bilidad

bilidad.

Cuadro 5.4: Caractersticas (Elab. Propia).

32

Figura 5.2: Modelo de Casos de Uso Inicial de SRP6 (Elab. Propia).

5.5.

Riesgos

Para el desarrollo del proyecto se determinaron los siguientes riesgos junto con ciertas
estrategicas para mitigarlos y controlarlos. Estos riesgos se encuentran en la tabla 5.5.
ID

Nombre

Prioridad Descripcion
Existe la posibilidad que los usuarios no
acepten el nuevo sistema y prefiera seguir uti-

Rechazo del Proyecto por

1

lizando SRP4. Para contrarrestar este riesgo,

4

parte de los usuarios

es necesario incluir a los usuarios durante el

proceso de desarrollo del sistema y obtener
buy-in.

33

El no conseguir los equipos apropiados para la ejecucion del sistema en los eventos es
un riesgo, particularmente considerando los
No se pueden obtener los
cambios de arquitectura de procesadores a
2

equipos necesarios para el

1
x64. Contrarrestar este riesgo no es complejo

proyecto
ya que existen gran cantidad de computadores a bajo costo que cumplen con los requisitos sugeridos para ejecutar el software.
La perdida de informacion (codigo, documentacion, etc.) es un riesgo significativo del proyecto. Para contrarrestar este riesgo se estaPerdida de informacion o
3

blecio un mecanismo de control de versiones

data
(SVN) almacenado en un arreglo de discos
con RAID Tipo 1 para asegurar la integridad logica y fsica de la informacion.

El uso de las nuevas tecnologas que ofrece Microsoft (ASP.NET MVC, Entity Framework) supone un riesgo de aprendizaje
4

Uso de tecnologa nueva

durante el proyecto. Para contrarrestar este riesgo, se adquirieron varios libros y documentacion sobre el uso de estos sistemas
antes de arrancar el proyecto.

34

Un crecimiento desmedido de los requerimientos del sistema (Scope Creep) puede ser
destructivo para el proyecto. Para contrarresDemasiados requerimientos
5

tar este riesgo, se limito el ambito del proyec-

para el tiempo del proyecto

to a las necesidades basicas de la empresa en
el area de registro y se excluyo cualquier otra
area de negocios.

Cuadro 5.5: Riesgos (Elab. Propia).

Con la vision del sistema claramente establecida, la cual puede revisarse con detalle en
el Anexo A, el siguiente paso del proyecto consistio en detallar los requerimientos de la
aplicacion y obtener de esa forma un documento claro de lo que se deba construir. Este fue
el objetivo de la siguiente fase del proyecto, la Fase de Elaboracion, a la que se refiere el
proximo captulo.

Captulo 6
Fase de Elaboraci
on
En este captulo se detallan los resultados del proceso de Elaboracion de la arquitectura del
sistema SRP6. En la metodologa OpenUP, a esta fase se le conoce como Fase de Elaboracion
(Elaboration Phase).
La fase de elaboracion se desarrollo en una sola iteracion enfocada en el dise
no de una
arquitectura capaz de sostener las necesidades del sistema identificadas durante la Fase de
Concepcion. Con este objetivo en mente se desarrollaron tres diagramas que describen las
capacidades del sistema.

6.1.

Vista de Casos de Uso

La Vista de Casos de Uso transforma los requerimientos determinados durante el desarrollo del ERS en un conjunto de Casos de Uso que permiten dividir la funcionalidad del
sistema en pedazos manejables para un esfuerzo de programacion estructurado. La vista de
casos de uso se compone del Diagrama de Casos de uso (Figura 6.7), las narrativas de casos de uso (Disponibles completas en el Apendice B - Especificacion de Requerimientos), y
los diagramas de secuencia (disponibles en el Apendice C - Documento de Arquitectura de

36

Software).
El diagrama de secuencia (Figura 6.1)muestra el flujo de los mensajes para realizar un CU
entre los distintos actores del sistema. En este caso en particular, se muestra el proceso para
Agregar un nuevo registro de Ciudad al sistema. Este diagrama permite apreciar claramente
la forma en la cual una capa del sistema solamente se comunica con su Dispatcher o entre
dispatchers, lo cual es una caracterstica relevante de la arquitectura.

Figura 6.1: Diagrama de Secuencia. CU Crear Ciudad (Elab. Propia).

37

6.2.

Vista L
ogica

La vista logica se enfoca en los aspectos abstractos del sistema que se desea construir.
En particular, permite describir el entorno de negocios en el cual se desarrolla y funciona el
software. Esta vista se encuentra disponible completa en el Apendice C y consiste del Modelo
de Dominio, los Elementos Arquitectonicamente significativos y el Diagrama de Clases.

6.2.1.

Modelos de Dominio

El modelo de dominio describe los elementos mas relevantes del entorno en el cual se
desarrolla la aplicacion. Para SRP6, estos elementos forman parte del area de organizacion
de eventos de la empresa y se centra en el Evento como elemento interconector de las demas
areas del negocio.

Figura 6.2: Modelo de Dominio de SRP6 (Elab. Propia).

38

6.2.2.

Elementos arquitect
onicamente significativos

Para la construccion de la aplicacion, se tomaron los siguientes elementos como aquellos

arquitectonicamente significativos:
Sistema de Base de Datos que contiene la informacion del sistema.
Servidor HTTP y HTTPS que transmite las paginas web que componen el sistema.

6.2.3.

Diagrama de Clases

El diagrama (Figura 6.3) muestra en el centro las tres clases principales para la intercomunicacion del sistema (ControllerDispatcher, ViewDispatcher y SrpDatabaseConnection).
Estos tres componentes se encargan del flujo completo de la informacion desde la Base de
Datos hasta el explorador del usuario y sirven como entes coordinadores particulares entre
cada una de las clases adicionales que aparecen en el diagrama. Ademas se puede observar
que todas las clases se comunican unicamente con su Dispatcher asociado el cual media las
interacciones y de esa forma abstraer de los controladores y las vistas la comunicacion con el
Cliente.

6.3.

Vista de Implementaci
on

La vista de implementacion describe las estructura que componen el software a construir.

Para esta vista existe un u
nico diagrama: el diagrama de componentes (ver Figura 6.4) que
representa la forma en la que las distintas partes del codigo son agrupadas en elementos
discretos (componentes). Toda la informacion de la Vista de Implementacion y los diagramas
se pueden revisar en el Apendice C.
Como se puede observar en el diagrama (Figura 6.4), la solucion fue dividida siguiente
la arquitectura elegida para el sistema (MVC). El u
nico punto resaltante del diagrama es

39

Figura 6.3: Diagrama de Clases de SRP6 (Elab. Propia).

la separacion de las clases de Reporte en un componente adicional. Esto se hizo para dar
flexibilidad a futuros proyectos que requieran utilizar la capacidad de generar reportes de
forma separada del resto del sistema.

6.4.

Vista de Implantaci
on

La vista de implantacion muestra las caractersticas relevantes del entorno en el cual se

va a ejecutar el software una vez finalizado el proceso de desarrollo. En el caso particular de
SRP6, las caractersticas del sistema permiten un entorno de implantacion extremadamente
sencillo por lo que solo hay un diagrama (Figura 6.5). Ademas, las caractersticas de la

40

Figura 6.4: Diagrama de Componentes de SRP6 (Elab. Propia).

plataforma en la que se ejecutara el software permite responder a los dos requerimientos no
funcionales de la aplicacion: Seguridad y Confiabilidad. El primero lo maneja la funcionalidad
de IIS 7 de ofrecer el protocolo seguro HTTPS. El segundo es la combinacion de IIS 7 junto
con SQL Server 2008 R2, la cual ha demostrado ser efectiva en mantener en funcionamiento
sistemas de informacion complejos1 . La documentacion completa de la Vista de Implantacion
se encuentra completa en el Apendice C.

6.5.

Vista de Datos

La vista de datos del DAS (disponible completo en el Apendice C) describe la estructura

de la informacion de negocios que maneja y almacena el sistema. Gracias a las caractersticas
del paquete utilizado para manejar las interacciones con la Base de Datos (Entity-Framework
1

Toda la infraestructura de informacion de Microsoft funciona en estos dos sistemas. Una infraestructura
que soporta cientos de miles de empleados en mas de 100 pases.

41

Figura 6.5: Diagrama de Implantacion de SRP6 (Elab. Propia).

4.2), el proyecto solo requirio el desarrollo de un Modelo Entidad Relacion (Figura 6.6) el cual
fue despues incorporado como elementos de las clases descritas en el Diagrama de Clases.
Ahora que se ha definido claramente lo que se desea construir, podemos pasar a revisar
el camino por el cual se convirtieron este grupo de especificaciones en una aplicacion de
software que se poda ejecutar y utilizar en la empresa. Nuestro proximo captulo se refiere
directamente a la Fase de Construccion en el proceso de OpenUP.

42

Figura 6.6: Diagrama de Entidad-Relacion de SRP6 (Elab. Propia).

43

Figura 6.7: Diagrama de CU (Elab. Propia).

Captulo 7
Fase de Construcci
on
Dividido en dos grandes partes, este captulo detalla las herramientas que se utilizaron
para la construccion de SRP6 junto con unas rese
nas de las actividades desarrolladas durante
cada una de las 4 iteraciones del proceso de construccion. En la metodologa OpenUP, a esta
fase se le conoce como Fase de Construcci
on (Construction Phase).

7.1.
7.1.1.

Iteraciones de Construcci
on
Iteraci
on 1

La primera iteracion de desarrollo se enfoco en la construccion de toda la capa de datos

que permitira al resto del sistema interactuar con la Base de Datos donde se almacenaran
los datos. Los principales productos de esta iteracion fueron la implementacion de las clases
que accesaran la base de datos y la programacion de las reglas de Mapeo definidas en la Fase
de Elaboracion para cada una de las clases del modelo ORM.
Los casos de Uso implementados en esta iteracion fueron:
ID

Nombre del CU

ID

Nombre del CU

45

Iniciar Sesion

Cambiar Clave

Cerrar Sesion

Cuadro 7.1: Casos de Uso Implementados en la Iteracion 1 (Elab. Propia).

7.1.2.

Iteraci
on 2

En la segunda iteracion, el trabajo se enfoco en programar los CU de la tabla 7.2. Para

esto, se construyeron varios controladores, cada uno enfocado en un area tematica del sistema.
De estos temas, los mas importantes fueron la configuracion inicial del sistema , manejo de
eventos, manejo de Participantes, manejo de Participaciones y manejo de transacciones. En
esta iteracion se construyeron otros controladores auxiliares al resto del sistema.
ID

Nombre del CU

ID

Nombre del CU

Crear Participante

Modificar Participante

Eliminar Participante

Asignar Especialidad a Participante

Eliminar Especialidad de Partici8

Buscar Por Nombre Participante

pante
10

Buscar Por Cedula Participante

11

Modificar Participacion

12

Eliminar Participacion

28

Crear Pas

29

Modificar Pas

30

Eliminar Pas

31

Ver Pas

32

Crear Estados

33

Modificar Estados

34

Eliminar Estados

35

Ver Estados

36

Crear Ciudades

37

Modificar Ciudades

38

Eliminar Ciudades

46

39

Ver Ciudades

49

Crear Eventos

50

Modificar Eventos

51

Eliminar Eventos

52

Ver Eventos

53

Crear Tipos de Participantes

54

Modificar Tipos de Participantes

55

Eliminar Tipos de Participantes

56

Ver Tipos de Participantes

57

Crear Conceptos

58

Modificar Conceptos

59

Eliminar Conceptos

60

Ver Conceptos

61

Crear Especialidades

62

Modificar Especialidades

63

Eliminar Especialidades

64

Ver Especialidades

65

Crear Profesiones

66

Modificar Profesiones

67

Eliminar Profesiones

68

Ver Profesiones
Cuadro 7.2: Casos de Uso Implementados en la Iteracion 2 (Elab. Propia).

7.1.3.

Iteraci
on 3

El objetivo de la tercera iteracion fue el desarrollar la capacidad de generar reportes con

el sistema. Para esto se construyo un u
nico controlador que maneja el proceso de creacion de
los reportes y se utilizo una librera para la creacion de archivos compatibles con Microsoft
Excel para la transformacion de los resultados de los reportes en representaciones que fueran
facilmente manipulables por los usuarios.
Los casos de Uso implementados en esta iteracion estan listados en el cuadro 7.3:
ID

Nombre del CU

14

Crear Transaccion

15

Agregar Concepto a Transaccion

47

Eliminar Concepto de Transac16

17

Agregar Pago a Transaccion

cion
18

Eliminar Pago de Transaccion

19

Modificar Pago de Transaccion

20

Cerrar Transaccion

21

Anular Transaccion

22

Crear Forma de Pago

23

Modificar Forma de Pago

24

Eliminar Forma de Pago

25

Ver Forma de Pago

26

Agregar Detalle

27

Eliminar Detalle

40

Generar Reporte Caja xml

41

Generar Reporte Caja xlsx

42

Generar Reporte Caja csv

43

Generar Reporte Inscritos xml

44

Generar Reporte Inscritos xlsx

45

Generar Reporte Inscritos csv

46

Generar Reporte Ingresos xml

47

Generar Reporte Ingresos xlsx

48

Generar Reporte Ingresos csv

Cuadro 7.3: Casos de Uso Implementados en la Iteracion 3 (Elab. Propia).

7.1.4.

Iteraci
on 4

La u
ltima iteracion de construccion del sistema consisitio en desarrollar los mecanismos
para la generacion de material impreso basado en plantillas. Desde el comienzo del proceso
de elaboracion del sistema, se estaba claro que era necesario conseguir una herramienta que
fuera capaz de servir como generador de plantillas, ya que el desarrollar la funcionalidad
necesaria para ofrecer los servicios que la empresa requiere hubiese tomado mucho mas de 6
meses. Durante el proceso de b
usqueda de una librera capaz de generar archivos de Excel1 se
descubrio que la librera OfficeOpenXML ofreca ademas de la capacidad de generar archivos
1

Durante la iteraci
on 3

48

compatibles con Microsoft Excel, la capacidad de modificar archivos en formato de Microsoft

PowerPoint.
Esta fue la solucion ideal al problema, ya que PowerPoint ofreca las caractersticas de
dise
no de las plantillas2 y la librera OfficeOpenXML ofreca la capacidad de modificarlas a
traves de la Aplicacion Web.
Los casos de Uso implementados en esta iteracion estan en el cuadro 7.4:
ID

Nombre del CU

13

Imprimir Material
Cuadro 7.4: Casos de Uso Implementados en la Iteracion 3 (Elab. Propia).

7.2.

Descripci
on de la Versi
on Actual del Sistema

Al finalizar la Fase de Construccion, el sistema permita a la compa

na registrar eficientemente a los participantes de los eventos, a traves de una interfaz web (ver Figura 7.1),
llevando un control claro de los ingresos y egresos de dinero, ademas de toda la informacion
adicional asociada al proceso.
Otra caracterstica del software es permitir manipular rapidamente, a traves de reportes
(ver Figura 7.2), la informacion que se maneja dentro del sistema, ofreciendo un control de
las operaciones que realizan los empleados al registrar participantes y sirviendo como un
repositorio historico de los eventos que organiza la empresa.
Ademas, al finalizar la Cuarta Iteracion de Construccion, el software permite a los operadores imprimir material personalizado para el participante (ver Figura 7.3), utilizando como
plantilla archivos de MS PowerPoint.
2

De hecho, la empresa a utilizado PowerPoint como su herramienta de impresion de materiales desde que
se fundo en el a
no 2000

49

Figura 7.1: SRP6 - Modificando a un Participante (Elab. Propia).

Una vez cumplido el trabajo de la construccion de la aplicacion, el proyecto se dedico a
preparar la infraestructura necesaria para iniciar un despliegue piloto del sistema en un evento
organizado por la compa
na. En la metodologa OpenUP, este proceso es conocido como la
Fase de Transicion, y se detalla en el proximo captulo.

50

Figura 7.2: SRP6 - Generando un Reporte y su Resultado en XML (Elab. Propia).

51

Figura 7.3: SRP6 - En la Lista de Imprimibles junto con una Plantilla (Elab. Propia).

Captulo 8
Fase de Transici
on
Para la Fase de Transicion del sistema se realizaron dos tareas importantes. La primera,
una prueba piloto de la funcionalidad del sistema. Esta se realizo en la 1era Jornada de
Actualizacion en Ciruga Buco Maxilofacial, un evento organizado por la compa
na del 2 al 3
de diciembre de 2011. En este evento se descubrieron ciertas deficiencias en el sistema. Varias
fueron solventadas durante la prueba piloto. El resto se arreglaron al regresar del evento.
Quizas el error mas importante durante el desarrollo, y que causara problemas durante el
piloto, fue el no dise
nar un plan de pruebas y seguirlo a pesar de que la metodologa llamaba
para el uso de uno. La ejecucion de la prueba piloto sin pruebas anteriores significo, como se
vera a continuacion, que ocurrieron problemas que se debieron haber previsto anteriormente.
La empresa tomo esta situacion como un punto de aprendizaje para cualquier desarrollo
futuro.

8.1.

Prueba Piloto

Uno de los requisitos de la fase de transicion en OpenUP es la realizacion de una prueba

piloto en la cual se validen la correcta implementacion de los requerimientos del sistema.

53

Dicha prueba se realizo en la 1era Jornada de Actualizacion en Ciruga Buco Maxilofacial,

un evento organizado por la compa
na para la Sociedad Venezolana de Ciruga Buco-Maxilo
Facial (http://www.svcbmf.org).
La razon por la que se realizo la prueba en un evento1 es que era muy complejo simular
la realidad de un evento para una prueba. Los eventos mas grandes de la empresa pueden
llegar a tener mas de 2.500 participantes, de los cuales la mayora llega durante el primer
da. En eventos mas peque
nos (como la Jornada donde se realizo la prueba) los mas de 300
participantes llegan practicamente juntos en las primeras 3 horas de la ma
nana del primer
da2 . Era imposible para la empresa conseguir alrededor de las 16 personas que se necesitaran
para simular este procedimiento3 , as como los incidentes no planificados que ocurren en el
mundo real.
Como la prueba iba a ser realizada durante un evento en vivo, era inaceptable una falla
total del proceso de inscripcion y registro. Por esta razon, para la realizacion de la prueba
piloto se prepararon los dos sistemas de la compa
na, SRP4 y SPR6. Como primario se
utilizara SRP6, para de esta forma realizar la prueba piloto. En caso de que ocurriera una
falla catastrofica en ese sistema, se tena preparada una copia de SRP4 lista para servir de
backup. Afortunadamente, no ocurrio ninguna falla de este tipo y el piloto se pudo realizar
de forma satisfactoria.
Los resultados de la prueba piloto validaron de forma bastante completa la implementacion de los requerimientos. Esto no debera ser una sorpresa, ya que SRP6 busca construir
y mejorar sobre la funcionalidad de SRP4, un sistema que ha sido utilizado y refinado por
mas de 5 a
nos en la empresa. Lo que la prueba piloto si trajo a relieve fueron errores de
programacion que no fueron descubiertos durante el desarrollo del sistema. Como se men1

Que para los procesos de la empresa puede ser considerado Produccion

Este comportamiento es com
un en los eventos. Los participantes pagan para poder asistir, y no desean
perderse ninguna de las sesiones, por lo que llegan temprano el primer da
3
4 operadores y 12 personas sirviendo de participantes que pasan por la cola una y otra vez.
2

54

ciono anteriormente, estos problemas debieron haber sido descubiertos a traves de un Plan
de Pruebas, la empresa a partir de ese momento tomo la poltica de requerir el dise
no y
ejecucion de pruebas en todos los desarrollos subsecuentes.
Error

Estado Actual

Al imprimir, la integracion con PowerPoint impredeciblemente lanza un COM

Corregido

Exception.
Al buscar participantes, el sistema distingue entre una vocal acentuada y una no

Corregido

acentuada.
Al guardar la informacion de un particiCorregido
pante, no se activa la notificacion visual.
Al imprimir el material de un participanCorregido
te, no se registra el material impreso.
Cuadro 8.1: Errores Descubiertos durante la Prueba Piloto (Elab. Propia).

Captulo 9
Conclusiones y Recomendaciones
Despues del perodo de pasanta, entendiendo los requerimientos, dise
nando arquitecturas
y escribiendo codigo, podemos decir que el proyecto de desarrollo del Sistema de Registro de
Participantes fue un exito importante para la compa
na. El principal logro fue resolver los
problemas mas importantes que ocurran con la v4 del sistema, sin perder la funcionalidad
altamente refinada que ofreca.
El software resultante de la pasanta permite a la compa
na registrar eficientemente a
los participantes de los eventos que esta organiza, a traves de una interfaz web, llevando un
control claro de los ingresos-egresos de dinero y de la informacion asociada al proceso. Otras
caractersticas del software son permitir manipular rapidamente, a traves de reportes, la
informacion que se maneja dentro del sistema, ofrecer control de las operaciones que realizan
los empleados al registrar participantes y servir como un repositorio historico de los eventos
que organiza la empresa. Por u
ltimo la aplicacion ofrece a la empresa una plataforma con la
cual ofrecer servicios agregados mas valiosos para sus clientes.
Esta u
ltima caracterstica permite cambios como eliminar completamente el uso de
computadoras en los eventos y reemplazarlos con dispositivos moviles como iPads. A la
misma vez, como la aplicacion fue construida desde el comienzo sin reciclar codigo de la

56

version 4, este programa no sufre de los problemas de una aplicacion que fue construida sin
seguir ning
un requisito formal, sino mas bien fue un proyecto cuyo objetivo fue cumplir con
los requisitos a la medida que se iban descubriendo sin planificacion ni metodologa.
Por otro lado, el uso de la metodologa de desarrollo OpenUP en el proyecto fue una causa
de problemas en el proyecto. OpenUP establece un proceso bien estructurado y maduro para
el desarrollo de software en equipos. Pero en el caso de una compa
na peque
na, en la cual
un solo desarrollador trabaja en el proyecto, mucha de la estructura que ofrece OpenUP
es excesiva, ya que impide aprovechar las ventajas que se desgranan de la situacion tan
particular en la que se encuentra la empresa. Para el tama
no de la empresa, metodologas
como Scrum o Kanban ofrecen beneficios similares sin necesitar el proceso estructurado que
ofrece OpenUP1 .
Para el pasante, la experiencia de trabajar en una compa
na desarrollando software para
uso en los procesos reales de una compa
na ha sido una experiencia muy enriquecedora. El
poder interactuar con personas altamente capacitadas en sus areas de experticia y que ven
en las aplicaciones de software oportunidades nuevas de mejorar la empresa fue un motivador
importante durante la realizacion de la pasanta.

9.1.

Recomendaciones

Despues de todo el proceso de desarrollo, se decidio recomendar a la empresa los siguientes

cambios para mejorar sus procesos y sus capacidades:
Cambiar su metodologa de desarrollo a opciones mas agiles para tomar ventaja de su
peque
no tama
no y evitar la produccion de documentacion que puede ser innecesaria en
equipos de desarrollo muy peque
nos.
1

Que es necesario a medida que el tama

no del equipo de desarrollo crece

57

Considerar la posibilidad de establecer un peque

no grupo de proyecto que se encargue
de desarrollar aplicaciones especializadas para las tareas y servicios de la empresa.
Integrar el sistema desarrollado con otra plataforma que permita a los participantes
inscribirse para un evento a traves de Internet, realizando el pago en lnea con tarjetas
de debito o credito.
Expandir el alcance del proyecto para incluir la capacidad de interactuar directamente
con usuarios externos que provean y carguen las listas de pre-inscritos automaticamente
por Internet y de esta manera eliminar la necesidad de procesar listas de pre-inscritos
internamente.
Desarrollar la funcionalidad necesaria para que la aplicacion pueda manejar el Hospedaje de los participante del Evento, ya que en la empresa es un proceso altamente
interconectado al de registro.

Bibliografa
Brown, L. (2003). Enterprise Java programming with IBM WebSphere. Boston, Mass:
Addison-Wesley.
Burbeck, S. (1987). Applications programming in smalltalk-80(tm): How to use model-viewcontroller (mvc). http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html.
Davidson, D., James D.; Cowards (1999). Java Servlet Specification, v2.2 . Palo Alto, California: Sun Microsystems.
Fowler, M. (2003). Patterns of enterprise application architecture. Boston: Addison-Wesley.
Gustafsson, B. (2008). Openup - the best of two worlds. Methods and Tools, 16 , 2132.
Haack, P. (2011). Professional ASP.NET MVC 3 . Indianapolis, IN, USA: Wrox.
Jazayeri, M. (2007). Some trends in web application development. In FOSE07 , (pp. 199
213).
Kroll, P. (2006). Agility and Discipline Made Easy. Boston: Addison-Wesley.
Kroll, P. (2007). Openup in a nutshell. http://www.ibm.com/developerworks/rational/
library/sep07/kroll/.
Lerman, J. (2011). Programming Entity Framework: Code First. Sebastopol, CA, USA:
OReilly Media.

59

OpenUP-Wiki (2011). Openup wiki. http://epf.eclipse.org/wikis/openup/.

Rankins, R. (2010). Microsoft SQL Server 2008 R2 Unleashed . Boston, MA, USA: Pearson
Education, Inc.
Reenskaug, T. (2011).

Mvc xerox parc 1978-79.

http://heim.ifi.uio.no/~trygver/

themes/mvc/mvc-index.html.
Shklar, K. (2003). Web Applications Architecture: Principles, Protocols and Practices. West
Sussex, England: John Wiley and Sons, Ltd.

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

Apndice A

Aplicacin Sistema de Registro de Participantes 6 (SRP6)

Visin de la Aplicacin

Versin 1.1

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

Historia de Revisin
Fecha

Versin

Descripcin

Autor(es)

14/08/2011

1.0

Versin Inicial

Carlos Gustavo Sarmiento

17/08/2011

1.1

Eliminacin de renglones de informacin superfluos en el

documento (stakeholders repetidos, requerimientos
modificados)

Carlos Gustavo Sarmiento

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

Propsito: Este documento tiene por objetivo recolectar, analizar y definir las necesidades a un alto nivel y aspectos
relevantes del Sistema de Registro de Participantes 6. Se especifican los stakeholders y los usuarios principales de la
aplicacin, las necesidades de cada uno de ellos as como las razones que justifican dichas necesidades. Adicionalmente,
contiene las caractersticas de la aplicacin, incluyendo restricciones y criterios de aceptacin aplicables al caso.
VS. 1 Nombre de la Aplicacin
Sistema de Registro de Participantes 6
VS. 2 Posicionamiento
El problema de

El alto volumen de participantes a

registrar en los Eventos Mdicos
organizados por la Compaa.

Afecta a

El Gerente Organizador del Evento.

El cliente al que se le organiza al
evento.
La Unidad de Productos y su
personal que registra a los
participantes.
Los participantes en el evento.

Cuyo impacto es

El no llevar un registro automatizado

de los participantes en un Evento,
significa grandes retrasos a la hora
de atender a un participante
individual en el proceso de registro y
limitaciones importantes en la
entrega de los resultados finales al
cliente.

Una solucin exitosa

Registra los datos concernientes a

los asistentes a un evento y los
ingresos relacionados con las
inscripciones a un evento.
Generara el material impreso de los
asistentes personalizndolo a los
diseos particulares de cada evento.

El problema de

La carga manual de la informacin

de cada participante en el sistema
tiene un costo en tiempo
significativo.

Afecta a

El Gerente Organizador del Evento.

El cliente al que se le organiza al
evento.
La Unidad de Productos y su
personal que registra a los
participantes.
1

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

Los participantes en el evento.

Cuyo impacto es

Las empresas patrocinantes pueden

llegar a registrar a ms del 70% de
los participantes en un evento.

Una solucin exitosa

Procesara las listas de pre-inscritos

que provean las casas comerciales
que participan en el evento.

El problema de

No poder ofrecer informacin

agregada acerca de los participantes
en un Evento.

Afecta a

El Gerente Organizador del Evento.

El cliente al que se le organiza al
evento.
La Unidad de Productos y su
personal que registra a los
participantes.
Los participantes en el evento.
Si no es posible realizar reportes con
informacin agregada de la
participacin en el evento, se limita
significativamente la utilidad de
llevar un registro de los participantes
que asisten al evento.

Cuyo impacto es

Una solucin exitosa

Preparara las estadsticas asociadas

a las diferentes participaciones
existentes en el evento (por ciudad,
profesin, tipo de participante,
forma de pago, entre otros).

El problema de

No tener control monetario de los

ingresos que se generan por la
inscripcin de participantes en el
evento.

Afecta a

El Gerente Organizador del Evento.

El cliente al que se le organiza al
evento.
La Unidad de Productos y su
personal que registra a los
participantes.
Un registro financiero claro y
detallado es necesario para ofrecer
resultados econmicos claros del
evento a los clientes

Cuyo impacto es

Una solucin exitosa

Proveera un resumen de la
participacin que se obtuvo en el
evento (estado financiero de
2

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

inscripcin, total participacin por

casa comercial, por profesin, entre
otros).
Para

El personal de Organizacin de
Eventos, la Gerencia de Productos y
los Operadores en el rea de
Inscripciones.

Quin(es)

Requieren mecanismos para

automatizar el registro de los
participantes en los eventos de la
Compaa

SRP6

Es la Aplicacin Web

Qu

Registrar los datos concernientes a

los asistentes a un evento y los
ingresos relacionados con las
inscripciones a un evento.
Procesar las listas de pre-inscritos
que provean las casas comerciales
que participan en el evento.
Generar el material impreso de los
asistentes personalizndolo a los
diseos particulares de cada evento.
Preparar las estadsticas asociadas a
las diferentes participaciones
existentes en el evento (por ciudad,
profesin, tipo de participante,
forma de pago, entre otros).
Proveer un resumen de la
participacin que se obtuvo en el
evento (estado financiero de
inscripcin, total participacin por
casa comercial, por profesin, entre
otros).

Se diferencia de

SRP4

Nuestra Aplicacin

Ofrece una infraestructura web

capaz de soportar las operaciones
en cualquier plataforma con acceso
a Internet.
Esta construido utilizando
tecnologas modernas que lo hacen
ms mantenible y eficiente.
Se adapta a las nuevas necesidades
de la empresa y sus planes de
crecimiento.
3

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

VS. 3 Descripcin de los Stakeholders y Usuarios

Representatividad

Carlos Sarmiento Pasante

Categora

Desarrollador

Tipo

Desarrollador de Software

Responsabilidad

Disear, Construir y Probar el sistema.

Criterios de xito

El sistema cumple con todas las especificaciones

definidas para el proyecto.

Nivel de
participacin

Desarrolla el software. Realiza mantenimiento del

sistema.

Entregables
Comentarios / otros
aspectos

Software y Documentacin

Representatividad

Nelliana Acua VP de Productos

Categora

Promotor

Tipo

Gur de Negocio

Responsabilidad

Determina los requerimientos de la aplicacin y

determina el cumplimiento de los requisitos

Criterios de xito

La aplicacin permite llevar a cabo un registro eficiente

de los participantes en el Evento.
La aplicacin ofrece mecanismos para realizar reportes
sobre la informacin almacenada en el mismo.

Nivel de
participacin

Revisa los requerimientos del sistema. Ofrece

informacin acerca de la realidad del negocio.

Entregables
Comentarios / otros
aspectos

Ninguno

Representatividad

Isbhet Muoz Gerente de Eventos

Categora

Administrador

Tipo

Gur de Negocio y Experto Tcnico

Responsabilidad

Apoyar en el desarrollo de la solucin tcnica para los

problemas planteados en los requerimientos. Ayudar a
convertir los requerimientos en soluciones tcnicas

Criterios de xito

No Aplica

Nivel de
participacin

Soporte en el desarrollo de las soluciones tcnicas del

sistema. Proveer experiencia en el uso de las
herramientas de desarrollo.

Entregables

Ninguno
4

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

Comentarios / otros
aspectos
Representatividad

Marco Calabrese

Categora

Usuario

Tipo

Operador del Sistema

Responsabilidad

Proveer feedback en relacin al funcionamiento del

sistema y su facilidad de uso por parte de los operadores
en un Evento.

Criterios de xito

La aplicacin permite llevar a cabo un registro eficiente

de los participantes en el Evento.
La aplicacin ofrece mecanismos para realizar reportes
sobre la informacin almacenada en el mismo.
La aplicacin es Fcil de Usar y Eficiente.

Nivel de
participacin

Revisa los requerimientos del sistema. Ofrece

informacin acerca de la realidad del negocio.

Entregables

Ninguno

Comentarios / otros
aspectos
Tabla de Necesidades
Necesidad

Prioridad del
Negocio

Se requiere registrar los

datos concernientes a
los asistentes a un
evento y los ingresos
relacionados con las
inscripciones a un
evento.

Se requiere que las

actividades que realice
la aplicacin sean
seguras y confiables

Se requiere procesar las

listas de pre-inscritos
que provean las casas
comerciales que
participan en el evento.

Problema que
origina la
necesidad
Registrar a los
participantes
en los Eventos
Mdicos
organizados
por la
Compaa.

El proceso al
que la
aplicacin
soporta es un
proceso crtico
del negocio.
Registrar de
forma masiva o
en lote las listas
de
participantes
provistas por
las empresas

Solucin Actual

Soluciones
Propuestas

El sistema SRP4
ofrece una
funcionalidad similar.
Cuando el sistema no
est operativo se
utiliza Excel

La aplicacin debe
ofrecer una Interfaz
Web para registrar
los datos
concernientes a los
asistentes a un
evento y generar los
imprimibles
necesarios.
La aplicacin debe
seguir los estndares
webs mnimos de
seguridad y
confiabilidad.

El sistema SRP4
ofrece una
funcionalidad
insuficiente de
seguridad y
confiabilidad
La carga de la
informacin se
realiza manualmente,
participante por
participante, en SRP4

La aplicacin debe
ofrecer una Interfaz
Web a la cual se
suban archivos en
formato CSV que
sean procesados
automticamente.
5

Documento de Visin
Sistema de Registro de Participantes 6

Fecha: 17/08/2011
Siglas de la Aplicacin:
SRP6

patrocinantes
Se requiere preparar las
estadsticas asociadas a
las diferentes
participaciones
existentes en el evento
(por ciudad, profesin,
tipo de participante,
forma de pago, entre
otros).

Ofrecer
informacin
agregada
acerca de los
participantes
en un Evento.

Se requiere proveer un
resumen de la
participacin que se
obtuvo en el evento
(estado financiero de
inscripcin, total
participacin por casa
comercial, por
profesin, entre otros).

Llevar un
control
monetario de
los ingresos
que se generan
por la
inscripcin de
participantes
en el evento.

SRP4 ofrece una

herramienta que
exporta la
informacin del
evento a Excel. La
agregacin y el
anlisis de la
informacin se
realizan
manualmente.
Se utilizan los
mecanismos
existentes en SRP4
para el manejo de los
Pagos y otra
informacin
relacionada, aunque
son insuficientes.

La aplicacin debe
ofrecer una Interfaz
Web la cual permita
generar reportes
agregando la
informacin
deseada.

La aplicacin debe
ofrecer la capacidad
de generar Reportes
de Caja, de Ingresos
y Balances del
evento.

VS.4 Descripcin de la Aplicacin

La aplicacin es un sistema de informacin Web, que va a ser utilizado en computadoras con ambiente Windows para la
realizacin del registro de participantes en un evento organizado por la Compaa. La aplicacin debe permitir el registro
de participantes, la generacin de material imprimible personalizado, la generacin de reportes. Actualmente la
aplicacin no se intercomunica con ningn otro sistema de la empresa, aunque la posibilidad debe considerarse en la
ejecucin del proyecto.
VS.5 Restricciones.
El sistema debe ser capaz de ejecutarse en un ambiente Windows 7 con IIS 7.5 y SQL Server Express 2008 R2 como
servidor de Base de Datos.
El equipo en el cual se ejecute la aplicacin debe ser una computadora porttil comercial u otra computadora de tamao
y peso pequeo.
VS.6 Requerimientos de Documentacin.
Se deber desarrollar un manual de usuario para el entrenamiento de los nuevos usuarios.
Un manual del procedimiento de instalacin del sistema en el computador servidor.
VS.7 Glosario de la Aplicacin.
Trmino
SRP6
SRP4
Participante
Operador
Cliente
Organizador

Definicin
Sistema de Registro de Participantes 6.
Versin actualmente utilizada por la empresa para el registro de los
participantes. El objetivo del proyecto es reemplazar esta aplicacin.
Una persona que se registra parar asistir a un evento organizado por
la Empresa.
Empleado de la compaa que se encarga de cargar la informacin
de uno o ms participantes en el sistema.
La organizacin que contrata a la empresa para organizar el Evento.
La persona de la compaa responsable de la organizacin completa
del evento.

Apndice B

Aplicacin Sistema de Registro de Participantes 6

Especificacin de Requerimientos de la Aplicacin

Versin 1.0

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

Historia de Revisin
Fecha
07/09/2011

Versin
1.0

Descripcin
Versin Inicial

Autor(es)
Carlos Gustavo Sarmiento

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

Propsito: Este documento detalla los requerimientos de software para la aplicacin Sistema de Registro de Participantes 6,
segn tres grandes aspectos claves para su desarrollo: las Especificaciones Funcionales, el modelo de los Casos de Uso, tanto en
diagrama como en narrativa, y las Especificaciones suplementarias. Toda esta informacin establece los lineamientos y las
restricciones que debe considerar el equipo de desarrollo del proyecto para el desarrollo de la aplicacin.
ERS. 1 Nombre de la Aplicacin.
Sistema de Registro de Participantes 6
ERS.2 Casos de Uso (CU)
ERS.2.1. Resumen de Casos de Uso y Actores
ID del Caso de uso
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

Nombre del Caso de Uso

Iniciar Sesin
Cerrar Sesin
Cambiar Clave
Crear Participante
Modificar Participante
Eliminar Participante
Asignar Especialidad a Participante
Eliminar Especialidad de Participante
Buscar Por Nombre Participante
Buscar Por Cedula Participante
Modificar Participacin
Eliminar Participacin
Imprimir Material
Crear Transaccin
Agregar Concepto a Transaccin
Eliminar Concepto de Transaccin
Agregar Pago a Transaccin
Eliminar Pago de Transaccin
Modificar Pago de Transaccin
Cerrar Transaccin
Anular Transaccin
Crear Forma de Pago
Modificar Forma de Pago
Eliminar Forma de Pago
Ver Forma de Pago
Agregar Detalle
Eliminar Detalle
Crear Pas
Modificar Pas
Eliminar Pas
Ver Pas
Crear Estados
Modificar Estados
Eliminar Estados
Ver Estados
Crear Ciudades
Modificar Ciudades

Actor(es)
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Operador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
1

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

Eliminar Ciudades
Ver Ciudades
Generar Reporte Caja XML
Generar Reporte Caja xlsx
Generar Reporte Caja csv
Generar Reporte Inscritos XML
Generar Reporte Inscritos xlsx
Generar Reporte Inscritos csv
Generar Reporte Ingresos XML
Generar Reporte Ingresos xlsx
Generar Reporte Ingresos csv
Crear Eventos
Modificar Eventos
Eliminar Eventos
Ver Eventos
Crear Tipos de Participantes
Modificar Tipos de Participantes
Eliminar Tipos de Participantes
Ver Tipos de Participantes
Crear Conceptos
Modificar Conceptos
Eliminar Conceptos
Ver Conceptos
Crear Especialidades
Modificar Especialidades
Eliminar Especialidades
Ver Especialidades
Crear Profesiones
Modificar Profesiones
Eliminar Profesiones
Ver Profesiones

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador
Administrador

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.2.2. Diagrama de Caso de Uso

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.2.3. Especificaciones de Casos de Uso

ID del Caso de uso

Nombre del Caso de Uso:

Iniciar Sesin

Descripcin
El actor inicia sesin en el sistema
Pre-condicin
El actor no se encuentra logeado al sistema
Flujo
1. El actor accesa a la direccin web del sistema
2. El actor introduce su usuario, su clave y presiona el botn de "Entrar"
3. La aplicacin valida el usuario y la clave provistas.
4a. Si la validacin es exitosa: El actor es transferido a la pgina de inicio del sistema
4b. Si la validacin falla: El actor es transferido de vuelta a la pgina de login del sistema.
Post-condicin
El actor se encuentra logeado al sistema
ID del Caso de uso

Nombre del Caso de Uso:

Cerrar Sesin

Descripcin
El actor cierra su sesin en el sistema
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Cerrar Sesin"
2. El sistema destruye la informacin de sesin del actor.
3. El actor es transferido a la pgina de login del sistema
Post-condicin
El actor no se encuentra logeado al sistema
ID del Caso de uso

Nombre del Caso de Uso:

Cambiar Clave

Descripcin
El actor desea cambiar su clave de acceso.
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Cambiar Clave"
2. El actor es transferido a la pgina de cambio de clave.
3. El actor introduce su clave actual, su nueva clave dos veces y presiona el botn "Cambiar Clave"
3. El sistema actualiza la clave del actor en la base de datos.
4. El actor es transferido a la pgina de inicio del sistema.
Post-condicin
El actor entra al sistema utilizando su nueva clave

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ID del Caso de uso

Nombre del Caso de Uso:

Crear Participante

Descripcin
El actor desea agregar un nuevo participante al sistema
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Agregar Participante"
2. El actor introduce el Documento de Identidad, Nombre y Apellidos del Participante.
3. El sistema crea el registro del participante en la Base de Datos.
4. El actor es transferido a la Vista del Participante
Post-condicin
El Participante nuevo existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

Modificar Participante

Descripcin
El actor desea modificar un participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Participante
Flujo
1. El actor modifica los campos que desea del Participante
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del participante en la Base de Datos.
Post-condicin
El Participante tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

Eliminar Participante

Descripcin
El actor desea eliminar un participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Participante
Flujo
1. El actor presiona el link de "Eliminar Participante"
2. El sistema Elimina el registro del participante en la Base de Datos.
3. El actor es transferido a la Vista Limpia de Participantes
Post-condicin
El Participante no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

5

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

Asignar Especialidad a Participante

Descripcin
El actor desea agregar una especialidad a un Participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Participante
Flujo
1. El actor introduce el nombre de la especialidad que desea agregar en el Campo "Agregar Especialidad"
2. El actor presiona el botn "Agregar"
3. El sistema agrega al participante la especialidad en la Base de Datos.
4. La informacin de las especialidades es actualizada en la interfaz del usuario
Post-condicin
El participante tiene la especialidad asociada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

Eliminar Especialidad de Participante

Descripcin
El actor desea eliminar una especialidad de un Participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Participante
Flujo
1. El actor presiona el botn eliminar Especialidad
2. El sistema elimina la especialidad del participante en la Base de Datos.
3. La informacin de las especialidades es actualizada en la interfaz del usuario
Post-condicin
El participante no tiene la especialidad asociada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

Buscar Por Nombre Participante

Descripcin
El actor desea Buscar un Participante utilizando su nombre como criterio de bsqueda
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor introduce el nombre del participante en el Campo "Buscar"
2. El actor presiona el botn Buscar
3. El sistema consulta en la base de datos todos los nombres que cumplan con el criterio de bsqueda.
4. El sistema muestra todos los resultados en la interfaz del usuario.
5. Si el participante buscado esta en los resultados: El usuario presiona el Nombre del Participante y es
transferido a la Vista del Participante
Post-condicin

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ID del Caso de uso

Nombre del Caso de Uso:

10

Buscar Por Cedula Participante

Descripcin
El actor desea Buscar un Participante utilizando su Cedula como criterio de bsqueda
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor introduce la Cdula del Participante en el Campo "Buscar"
2. El actor presiona el botn Buscar
3. El sistema consulta en la base de datos todas los cdulas que cumplan con el criterio de bsqueda.
4. El sistema muestra todos los resultados en la interfaz del usuario.
5. Si el participante buscado esta en los resultados: El usuario presiona el Nombre del Participante y es
transferido a la Vista del Participante
Post-condicin

ID del Caso de uso

11

Nombre del Caso de Uso:

Modificar Participacion

Descripcin
El actor desea modificar un participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Participacin
Flujo
1. El actor modifica los campos que desea de la Participacin
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro de la participacin en la Base de Datos.
Post-condicin
El Participacin tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

12

Eliminar Participacion

Descripcin
El actor desea eliminar una Participacin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Participacin
Flujo
1. El actor presiona el link de "Eliminar Participacin"
2. El sistema Elimina el registro de la Participacin en la Base de Datos.
3. El actor es transferido a la Vista Limpia de Participacin
Post-condicin
La Participacin no existe en el sistema

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ID del Caso de uso

Nombre del Caso de Uso:

13

Imprimir Material

Descripcin
El actor desea imprimir el material de un Participante en el Evento
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Participacin
Flujo
1. El actor presiona el link de "Imprimir" asociado con el Material que desea imprimir
2. El sistema genera el imprimible y lo imprime automticamente
Post-condicin
El material se encuentra impreso
ID del Caso de uso

Nombre del Caso de Uso:

14

Crear Transaccin

Descripcin
El actor desea agregar una nueva transaccin al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
Flujo
1. El actor presiona el link de "Agregar Transaccin"
3. El sistema crea el registro de la transaccin en la Base de Datos.
4. La vista de Transaccin se actualiza para mostrar la nueva transaccin
Post-condicin
La nueva transaccin es creada en el sistema con el Estatus de Abierta
ID del Caso de uso
15

Nombre del Caso de Uso:

Agregar Concepto a Transaccin

Descripcin
El actor desea agregar un Concepto a la Transaccin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
La Transaccin no esta cerrada
Flujo
1. El actor introduce el nombre del concepto que desea agregar en el Campo "Agregar Concepto"
2. El actor presiona el botn "Agregar"
3. El sistema agrega el concepto a la transaccin en la Base de Datos.
4. La informacin de la transaccin es actualizada en la interfaz del usuario
Post-condicin
La Transaccin tiene el concepto agregado en el sistema

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ID del Caso de uso

Nombre del Caso de Uso:

16

Eliminar Concepto de Transaccin

Descripcin
El actor desea eliminar un Concepto de la Transaccin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
La Transaccin no esta cerrada
Flujo
1. El actor presiona el botn "Eliminar Concepto"
2. El sistema elimina el concepto de la transaccin en la Base de Datos.
3. La informacin de la transaccin es actualizada en la interfaz del usuario
Post-condicin
La Transaccin no tiene el concepto en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

17

Agregar Pago a Transaccin

Descripcin
El actor desea agregar un Pago a la Transaccin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
La Transaccin no esta cerrada
Flujo
1. El actor introduce el nombre de la Forma de Pago que desea agregar en el Campo "Agregar Pago"
2. El actor presiona el botn "Agregar"
3. El actor introduce los detalles de la forma de pago (varan segn la Forma de Pago)
3. El sistema agrega el pago junto con los detalles a la transaccin en la Base de Datos.
4. La informacin de la transaccin es actualizada en la interfaz del usuario
Post-condicin
La Transaccin tiene el pago agregado en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

18

Eliminar Pago de Transaccin

Descripcin
El actor desea eliminar un Pago de la Transaccin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
La Transaccin no esta cerrada
Flujo

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el botn "Eliminar Pago"

2. El sistema elimina el pago y todos los detalles asociados de la transaccin en la Base de Datos.
3. La informacin de la transaccin es actualizada en la interfaz del usuario
Post-condicin
La Transaccin no tiene el pago en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

19

Modificar Pago de Transaccin

Descripcin
El actor desea Modificar un Concepto a la Transaccin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
La Transaccin no esta cerrada
Flujo
1. El actor modifica los detalles del pago que desea actualizar
2. El actor presiona el botn "Guardar"
3. El sistema modifica los detalles del pago en la Base de Datos.
4. La informacin de la transaccin es actualizada en la interfaz del usuario
Post-condicin
El pago contiene la nueva informacin provista por el actor
ID del Caso de uso

Nombre del Caso de Uso:

20

Cerrar Transaccin

Descripcin
El actor desea cerrar la transaccin
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Transaccin
La Transaccin no esta cerrada
Flujo
1. El actor presiona el Botn Cerrar Transaccin
2. El sistema modifica la informacin de la trasaccin en la Base de Datos para indicar que esta cerrada.
3. Se actualiza la interfaz de usuario para indicar que la trasaccin esta cerrada.
Post-condicin
La transaccin esta cerrada en el sistema y es inmodificable (excepto por anulacin)
ID del Caso de uso

Nombre del Caso de Uso:

21

Anular Transaccin

Descripcin
El actor desea anular la transaccin
Pre-condicin

10

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

El actor esta el la vista de Transaccin
Flujo
1. El actor presiona el Botn "Anular Transaccin"
2. El sistema modifica la informacin de la trasaccin en la Base de Datos para indicar que esta anulada.
3. Se actualiza la interfaz de usuario para indicar que la trasaccin esta anulada.
Post-condicin
La transaccin esta anulada en el sistema y es inmodificable
ID del Caso de uso

Nombre del Caso de Uso:

22

Crear Forma de Pago

Descripcin
El actor desea agregar una nueva Forma de Pago al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Formas de Pago
Flujo
1. El actor presiona el link de "Agregar Forma de Pago"
2. El actor introduce el Nombre de la Forma de Pago.
3. El sistema crea el registro de la Forma de Pago en la Base de Datos.
4. El actor es transferido a la Vista de la Forma de Pago
Post-condicin
La nueva Forma de Pago existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

23

Modificar Forma de Pago

Descripcin
El actor desea modificar una Forma de Pago
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Forma de Pago
Flujo
1. El actor modifica los campos que desea de la Forma de Pago
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro de la Forma de Pago en la Base de Datos.
Post-condicin
La Forma de Pago tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

24

Eliminar Forma de Pago

Descripcin
El actor desea eliminar una Forma de Pago
Pre-condicin
11

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

El actor esta el la vista de Forma de Pago
Flujo
1. El actor presiona el link de "Eliminar Forma de Pago"
2. El sistema Elimina el registro de la Forma de Pago en la Base de Datos.
3. El actor es transferido a la Lista de Formas de Pago
Post-condicin
La Forma de Pago no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

25

Ver Forma de Pago

Descripcin
El actor desea ver una Forma de Pago
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Formas de Pago"
2. El actor es transferido a la Lista de Formas de Pago
3. El actor hace click en el Nombre de la Forma de Pago que desea ver
4. El actor es transferido a la Vista de Forma de Pago
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

26

Agregar Detalle

Descripcin
El actor desea agregar un nuevo detalle a la Forma de Pago
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Formas de Pago
Flujo
1. El actor presiona el link de "Agregar Detalle de Forma de Pago"
2. El actor introduce el Nombre del Detalle y una expresin regular para su validacin
3. El sistema crea el registro del Detalle en la Base de Datos.
4. La interfaz de usuario se actualiza con la nueva informacin
Post-condicin
El nuevo detalle se encuentra agregado a la Forma de Pago
ID del Caso de uso

Nombre del Caso de Uso:

27

Eliminar Detalle

Descripcin
El actor desea agregar eliminar un detalle de la Forma de Pago
Pre-condicin

12

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

El actor esta el la vista de Formas de Pago
Flujo
1. El actor presiona el link de "Eliminar Detalle de Forma de Pago" asociado al Detalle que se desea eliminar
2. El sistema elimina el registro del Detalle en la Base de Datos.
3. La interfaz de usuario se actualiza con la nueva informacin
Post-condicin
El detalle ya no esta incluido en la Forma de Pago
ID del Caso de uso

Nombre del Caso de Uso:

28

Crear Pais

Descripcin
El actor desea agregar un nuevo Pas al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Pases
Flujo
1. El actor presiona el link de "Agregar Pas"
2. El actor introduce el Nombre del Pas y el cdigo ISO del pas
3. El sistema crea el registro del Pas en la Base de Datos.
4. El actor es transferido a la Vista del Pas
Post-condicin
El Pas nuevo existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

29

Modificar Pais

Descripcin
El actor desea modificar un Pas
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Pas
Flujo
1. El actor modifica los campos que desea del Pas
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del Pas en la Base de Datos.
Post-condicin
El Pas tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

30

Eliminar Pais

Descripcin
El actor desea eliminar un Pas
Pre-condicin
13

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

El actor esta el la vista del Pas
Flujo
1. El actor presiona el link de "Eliminar Pas"
2. El sistema Elimina el registro del pas en la Base de Datos.
3. El actor es transferido a la Lista de Pases
Post-condicin
El Pas no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

31

Ver Pais

Descripcin
El actor desea ver un Pas
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Paises"
2. El actor es transferido a la Lista de Pases
3. El actor hace click en el Nombre del Pas que desea ver
4. El actor es transferido a la Vista de Pas
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

32

Crear Estados

Descripcin
El actor desea agregar un nuevo Estado al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Estados
Flujo
1. El actor presiona el link de "Agregar Estado"
2. El actor introduce el Nombre del Estado y el Pas al cual pertenece
3. El sistema crea el registro del Estado en la Base de Datos.
4. El actor es transferido a la Vista del Estado
Post-condicin
El Estado nuevo existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

33

Modificar Estados

Descripcin
El actor desea modificar un Estado
Pre-condicin

14

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

El actor esta el la vista del Estado
Flujo
1. El actor modifica los campos que desea del Estado
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del Estado en la Base de Datos.
Post-condicin
El Estado tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

34

Eliminar Estados

Descripcin
El actor desea eliminar un Estado
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Estado
Flujo
1. El actor presiona el link de "Eliminar Estado"
2. El sistema Elimina el registro del Estado en la Base de Datos.
3. El actor es transferido a la Lista de Estados
Post-condicin
El Estado no existe en el sistema
ID del Caso de uso
35

Nombre del Caso de Uso:

Ver Estados

Descripcin
El actor desea ver un Estado
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Estados"
2. El actor es transferido a la Lista de Estados
3. El actor hace click en el Nombre del Estado que desea ver
4. El actor es transferido a la Vista de Estado
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

36

Crear Ciudades

Descripcin
El actor desea agregar una nueva Ciudad al sistema
Pre-condicin

15

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

El actor esta en la Lista de Ciudades
Flujo
1. El actor presiona el link de "Agregar Ciudad"
2. El actor introduce el Nombre de la Ciudad.
3. El sistema crea el registro de la Ciudad en la Base de Datos.
4. El actor es transferido a la Vista de la Ciudad
Post-condicin
La nueva Ciudad existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

37

Modificar Ciudades

Descripcin
El actor desea modificar una Ciudad
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Ciudad
Flujo
1. El actor modifica los campos que desea de la Ciudad
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro de la Ciudad en la Base de Datos.
Post-condicin
La Ciudad tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

38

Eliminar Ciudades

Descripcin
El actor desea eliminar una Ciudad
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Ciudad
Flujo
1. El actor presiona el link de "Eliminar Ciudad"
2. El sistema Elimina el registro de la Ciudad en la Base de Datos.
3. El actor es transferido a la Lista de Ciudades
Post-condicin
La Ciudad no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

39

Ver Ciudades

Descripcin
El actor desea ver una Ciudad
Pre-condicin
16

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

El actor se encuentra logeado al sistema

Flujo
1. El actor presiona el link de "Administrar Ciudades"
2. El actor es transferido a la Lista de Ciudades
3. El actor hace click en el Nombre de la Ciudad que desea ver
4. El actor es transferido a la Vista de Ciudad
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

40

Generar Reporte Caja xml

Descripcin
El actor desea generar un reporte de la caja de un Operador en un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Generar Reporte de Caja"
2. El actor es transferido a la Vista de Reporte de Caja
3. El actor selecciona el nombre del evento y del Operador que para los que desea el reporte.
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato XML
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

41

Generar Reporte Caja xlsx

Descripcin
El actor desea generar un reporte de la caja de un Operador en un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Generar Reporte de Caja"
2. El actor es transferido a la Vista de Reporte de Caja
3. El actor selecciona el nombre del evento y del Operador que para los que desea el reporte.
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato XLSX
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

42

Generar Reporte Caja csv

Descripcin
El actor desea generar un reporte de la caja de un Operador en un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
17

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Generar Reporte de Caja"

2. El actor es transferido a la Vista de Reporte de Caja
3. El actor selecciona el nombre del evento y del Operador que para los que desea el reporte.
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato CSV
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

43

Generar Reporte Inscritos xml

Descripcin
El actor desea generar un reporte de todos los participantes inscritos en un evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Generar Reporte de Inscritos"
2. El actor es transferido a la Vista de Reporte de Inscritos
3. El actor selecciona el nombre del evento
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato XML
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

44

Generar Reporte Inscritos xlsx

Descripcin
El actor desea generar un reporte de todos los participantes inscritos en un evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Generar Reporte de Inscritos"
2. El actor es transferido a la Vista de Reporte de Inscritos
3. El actor selecciona el nombre del evento
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato XLSX
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

45

Generar Reporte Inscritos csv

Descripcin
El actor desea generar un reporte de todos los participantes inscritos en un evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo

18

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Generar Reporte de Inscritos"

2. El actor es transferido a la Vista de Reporte de Inscritos
3. El actor selecciona el nombre del evento
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato CSV
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

46

Generar Reporte Ingresos xml

Descripcin
El actor desea generar un reporte de todos los pagos realizados en un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Generar Reporte de Ingresos"
2. El actor es transferido a la Vista de Reporte de Ingresos
3. El actor selecciona el nombre del evento
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato XML
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

47

Generar Reporte Ingresos xlsx

Descripcin
El actor desea generar un reporte de todos los pagos realizados en un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Generar Reporte de Ingresos"
2. El actor es transferido a la Vista de Reporte de Ingresos
3. El actor selecciona el nombre del evento
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato XLSX
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

48

Generar Reporte Ingresos csv

Descripcin
El actor desea generar un reporte de todos los pagos realizados en un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo

19

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Generar Reporte de Ingresos"

2. El actor es transferido a la Vista de Reporte de Ingresos
3. El actor selecciona el nombre del evento
4. El sistema genera el reporte y lo enva al usuario a travs del explorador en formato CSV
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

49

Crear Eventos

Descripcin
El actor desea agregar un nuevo Evento al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Eventos
Flujo
1. El actor presiona el link de "Agregar Evento"
2. El actor introduce el Nombre del Evento y el Pas al cual pertenece
3. El sistema crea el registro del Evento en la Base de Datos.
4. El actor es transferido a la Vista del Evento
Post-condicin
El Evento nuevo existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

50

Modificar Eventos

Descripcin
El actor desea modificar un Evento
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Evento
Flujo
1. El actor modifica los campos que desea del Evento
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del Evento en la Base de Datos.
Post-condicin
El Evento tiene la nueva informacin almacenada en el sistema
ID del Caso de uso
51

Nombre del Caso de Uso:

Eliminar Eventos

Descripcin
El actor desea eliminar un Evento
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Evento
Flujo
20

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Eliminar Evento"

2. El sistema Elimina el registro del Evento en la Base de Datos.
3. El actor es transferido a la Lista de Eventos
Post-condicin
El Evento no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

52

Ver Eventos

Descripcin
El actor desea ver un Evento
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Eventos"
2. El actor es transferido a la Lista de Eventos
3. El actor hace click en el Nombre del Evento que desea ver
4. El actor es transferido a la Vista de Evento
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

53

Crear Tipos de Participantes

Descripcin
El actor desea agregar un nuevo Tipo de Participante al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Tipos de Participantes
Flujo
1. El actor presiona el link de "Agregar Tipo de Participante"
2. El actor introduce el Nombre del Tipo de Participante y el Pas al cual pertenece
3. El sistema crea el registro del Tipo de Participante en la Base de Datos.
4. El actor es transferido a la Vista del Tipo de Participante
Post-condicin
El Tipo de Participante nuevo existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

54

Modificar Tipos de Participantes

Descripcin
El actor desea modificar un Tipo de Participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Tipo de Participante
Flujo

21

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor modifica los campos que desea del Tipo de Participante

2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del Tipo de Participante en la Base de Datos.
Post-condicin
El Tipo de Participante tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

55

Eliminar Tipos de Participantes

Descripcin
El actor desea eliminar un Tipo de Participante
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Tipo de Participante
Flujo
1. El actor presiona el link de "Eliminar Tipo de Participante"
2. El sistema Elimina el registro del Tipo de Participante en la Base de Datos.
3. El actor es transferido a la Lista de Tipos de Participantes
Post-condicin
El Tipo de Participante no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

56

Ver Tipos de Participantes

Descripcin
El actor desea ver un Tipo de Participante
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Tipos de Participantes"
2. El actor es transferido a la Lista de Tipos de Participantes
3. El actor hace click en el Nombre del Tipo de Participante que desea ver
4. El actor es transferido a la Vista de Tipo de Participante
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

57

Crear Conceptos

Descripcin
El actor desea agregar un nuevo Concepto al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Conceptos
Flujo

22

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Agregar Concepto"

2. El actor introduce el Nombre del Concepto y el Pas al cual pertenece
3. El sistema crea el registro del Concepto en la Base de Datos.
4. El actor es transferido a la Vista del Concepto
Post-condicin
El Concepto nuevo existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

58

Modificar Conceptos

Descripcin
El actor desea modificar un Concepto
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Concepto
Flujo
1. El actor modifica los campos que desea del Concepto
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del Concepto en la Base de Datos.
Post-condicin
El Concepto tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

59

Eliminar Conceptos

Descripcin
El actor desea eliminar un Concepto
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista del Concepto
Flujo
1. El actor presiona el link de "Eliminar Concepto"
2. El sistema Elimina el registro del Concepto en la Base de Datos.
3. El actor es transferido a la Lista de Conceptos
Post-condicin
El Concepto no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

60

Ver Conceptos

Descripcin
El actor desea ver un Concepto
Pre-condicin
El actor se encuentra logeado al sistema
Flujo

23

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Administrar Conceptos"

2. El actor es transferido a la Lista de Conceptos
3. El actor hace click en el Nombre del Concepto que desea ver
4. El actor es transferido a la Vista de Concepto
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

61

Crear Especialidades

Descripcin
El actor desea agregar una nueva Especialidad al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Especialidades
Flujo
1. El actor presiona el link de "Agregar Especialidad"
2. El actor introduce el Nombre de la Especialidad.
3. El sistema crea el registro de la Especialidad en la Base de Datos.
4. El actor es transferido a la Vista de la Especialidad
Post-condicin
La nueva Especialidad existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

62

Modificar Especialidades

Descripcin
El actor desea modificar una Especialidad
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Especialidad
Flujo
1. El actor modifica los campos que desea de la Especialidad
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro de la Especialidad en la Base de Datos.
Post-condicin
La Especialidad tiene la nueva informacin almacenada en el sistema
ID del Caso de uso
63

Nombre del Caso de Uso:

Eliminar Especialidades

Descripcin
El actor desea eliminar una Especialidad
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Especialidad
Flujo
24

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor presiona el link de "Eliminar Especialidad"

2. El sistema Elimina el registro de la Especialidad en la Base de Datos.
3. El actor es transferido a la Lista de Especialidades
Post-condicin
La Especialidad no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

64

Ver Especialidades

Descripcin
El actor desea ver una Especialidad
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Especialidades"
2. El actor es transferido a la Lista de Especialidades
3. El actor hace click en el Nombre de la Especialidad que desea ver
4. El actor es transferido a la Vista de Especialidad
Post-condicin

ID del Caso de uso

Nombre del Caso de Uso:

65

Crear Profesiones

Descripcin
El actor desea agregar una nueva Profesion al sistema
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta en la Lista de Profesiones
Flujo
1. El actor presiona el link de "Agregar Profesion"
2. El actor introduce el Nombre de la Profesion.
3. El sistema crea el registro de la Profesion en la Base de Datos.
4. El actor es transferido a la Vista de la Profesion
Post-condicin
La nueva Profesion existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

66

Modificar Profesiones

Descripcin
El actor desea modificar una Profesion
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Profesion
Flujo

25

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

1. El actor modifica los campos que desea de la Profesion

2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro de la Profesion en la Base de Datos.
Post-condicin
La Profesion tiene la nueva informacin almacenada en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

67

Eliminar Profesiones

Descripcin
El actor desea eliminar una Profesion
Pre-condicin
El actor se encuentra logeado al sistema
El actor esta el la vista de Profesion
Flujo
1. El actor presiona el link de "Eliminar Profesion"
2. El sistema Elimina el registro de la Profesion en la Base de Datos.
3. El actor es transferido a la Lista de Profesiones
Post-condicin
La Profesion no existe en el sistema
ID del Caso de uso

Nombre del Caso de Uso:

68

Ver Profesiones

Descripcin
El actor desea ver una Profesion
Pre-condicin
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Administrar Profesiones"
2. El actor es transferido a la Lista de Profesiones
3. El actor hace click en el Nombre de la Profesion que desea ver
4. El actor es transferido a la Vista de Profesion
Post-condicin

ERS.3 Especificaciones Suplementarias

ERS.3.1. Usabilidad
ERS.4.1.1. Cumplimiento de las Expectativas de Aplicaciones Web
La aplicacin debe cumplir con las expectativas de los usuarios al usar aplicaciones web. Esto incluye el acceso exclusivo a
travs de un explorador, uso de Links como mecanismo de navegacin, botones como mecanismo de ejecucin de
acciones.
ERS.4.1.2. Tiempo de Aprendizaje
El sistema debe ser de fcil aprendizaje para cualquier persona con conocimiento superficial del flujo de trabajo de la
compaa. Adems debe permitir a los usuarios la navegacin simple a travs de las opciones a la cual tienen acceso.
26

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.2. Confiabilidad (Los requerimientos de confiabilidad de la aplicacin se deben especificar aqu).

ERS.4.2.1 Integridad de la Informacin
El sistema debe asegurar que en todo momento la informacin se encuentre en un estado consistente.
ERS.4.2.2 Seguimiento de las transacciones
El sistema debe llevar un registro de todas las transacciones que se realizan en l. La informacin debe incluir quien
realiz el cambio y cuando.
ERS.4.4. Mantenibilidad
ERS.4.4.1. Uso de un sistema de control de versiones
Todo el cdigo fuente debe estar almacenado en un repositorio de control de versiones compatible con las herramientas
de desarrollo utilizadas.
ERS.4.5. Seguridad
ERS.4.5.1. Acceso restringido a usuarios autenticados
La aplicacin debe permitir solamente a los usuarios autenticados la realizacin de cualquier accin en el sistema excepto
la de Iniciar Sesin. El sistema debe adems validar los credenciales presentados por los usuarios al momento de realizar
una operacin.
ERS.4.5.2. Acceso a travs de HTTPS
El sistema debe resguardar la seguridad de la informacin mientras es transferida entre el Servidor y el Cliente. Para esto,
el sistema debe utilizar la tecnologa de encriptacin de comunicaciones HTTPS.
ERS.4.6. Restricciones de Diseo
ERS.4.6.1. Tipo de Aplicacin
La aplicacin debe ser desarrollada como una aplicacin web accesible a travs de un explorador web usando tecnologas
web estndar (HTTP, HTML, CSS, etc.)
ERS.4.6.2. Lenguaje de Programacin
El sistema debe ser programado utilizando Microsoft C# 4 con .NET 4 debido a la experiencia acumulada en la compaa
con el sistema.
ERS.4.6.2. Librera de Desarrollo Web
La aplicacin debe desarrollarse utilizando ASP.NET MVC 3.5.
ERS.4.6.3. Plataforma de Base de Datos
El Manejador de Base de Datos debe ser SQL Server 2008 R2 Express debido a su precio (cero) y su amplia compatibilidad
con el lenguaje de programacin escogido.
ERS.4.6.4. Librera de Acceso a la Base de Datos
La librera de acceso al manejador de base de datos ser .NET Entity Framework 4.2. No se permitirn conexiones directas
a la base de datos.
ERS.4.6.5. Entorno de Ejecucin
El entorno de ejecucin debe ser Windows 7 con IIS 7.5. La compaa maneja una licencia de software con Microsoft y
tiene una amplia experiencia manejando equipos ejecutando distintas versiones de Windows. Esta experiencia no existe
con otros sistemas operativos de menor costo (Linux, BSD, etc.)
ERS.4.8. Componentes Comprados
La aplicacin no utiliza ningn componente comprado especficamente para la misma. Los componentes comprados son
licencias adquiridas por la empresa para el desarrollo general de sus tareas.
27

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.9. Interfaces
ERS.4.9.1. Interfaces de Usuario
ERS.4.9.1.1 Login

ERS.4.9.1.2 Cambio de Clave

ERS.4.9.1.3 Vista de Participante

ERS.4.9.1.4 Vista Limpia de Participante

La vista limpia de participante es una pantalla en blanco con la leyenda No se ha abierto ningn participante
ERS.4.9.1.5 Vista de Participacin
28

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.9.1.6 Vista de Transaccin

ERS.4.9.1.7 Vista de Forma de Pago

ERS.4.9.1.8 Lista de Formas de Pago

29

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.9.1.9 Vista de Reportes de Inscritos

ERS.4.9.1.10 Vista de Reportes de Ingresos

ERS.4.9.1.11 Vista de Reportes de Cajas

ERS.4.9.1.12 Vista de Eventos

ERS.4.9.1.13 Lista de Eventos

30

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.9.1.14 Vista de Tipo de Participantes

ERS.4.9.1.15 Lista de Tipos de Participantes

ERS.4.9.1.16 Vista de Concepto

ERS.4.9.1.17 Lista de Conceptos

31

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.9.1.18 Vista de Profesin

ERS.4.9.1.19 Lista de Profesiones

ERS.4.9.2. Interfaces de Hardware

No Aplica
ERS.4.9.3. Interfaces de Software
Al ser la primera aplicacin de la empresa, el software no interacta con ningn componente externo a este ERS.
En el caso de la conexin con los sistemas de base de datos, la interfaz es manejada por la librera .NET Entity Framework
4.2, por lo cual la especificacin de la interfaz esta fuera del alcance de este ERS.

32

Especificacin de Requerimientos de la Aplicacin

Sistema de Registro de Participantes 6

Fecha: 07/09/2011
Siglas de la Aplicacin:
SRP6

ERS.4.9.4. Interfaces de Comunicaciones

Todas las interfaces de comunicaciones usadas por el Sistema son implementadas por la librera de desarrollo web (ASP.NET
MVC 3.5), el entorno de ejecucin (.NET 4) y el sistema operativo (Windows 7)

33

Apndice C

Aplicacin Sistema de Registro de Participantes 6

Documento de Arquitectura de la Aplicacin

Versin 1.0

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Historia de Revisin
Fecha

Versin

Descripcin

Autor(es)

13/09/2011

1.0

Versin Inicial

Carlos Gustavo Sarmiento

19/09/2011

2.0

Cambios a los diagramas Casos de Uso, EntidadRelacin y Despliegue

Carlos Gustavo Sarmiento

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Propsito: Este documento proporciona una descripcin arquitectnica de la aplicacin Sistema de Registro de Participantes 6,
usando un nmero de diversas vistas para representar diferentes aspectos de la aplicacin, el cual esta destinado para las
personas que se encargaran de implementar la arquitectura que se plantea en este documento, mostrndose de forma
comprensible para los lectores.
DAS. 1 Nombre de la Aplicacin.
Sistema de Registro de Participantes V.6
DAS. 2 Representacin de la Arquitectura
DAS.3 Casos de Uso
DAS.3.1. Diagrama de Casos de Uso.
DAS.3.2. Listas de Casos de Uso.
DAS.3.3. Diagramas de Secuencia por Caso de Uso.
DAS.4 Vista Lgica
DAS.4.1. Modelos de Dominio.
DAS.4.2. Elementos arquitectnicamente significativos
DAS.5.1. Diagrama de Clases
DAS.5 Vista de Implementacin
DAS.5.2. Diagrama de Componentes
DAS.6 Visa de Implantacin
DAS.6.1. Diagrama de Implantacin
DAS.7 Vista de Datos
DAS.7.1. Modelo Entidad-Relacin.
DAS.3 Vista Casos de Usos
DAS.3.1 Diagrama de Casos de Uso
Ver Diagrama de Casos de Uso en el ERS.
DAS.3.2 Listas de Casos de Uso
Ver Lista de Casos de Uso en el ERS

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

DAS.3.3 Diagrama de Secuencia por Caso de Uso

Ver Forma de Pago

Ver Pas

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Ver Profesin

Ver Tipo de Participante

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Agregar Concepto

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Agregar Detalle a Forma de Pago

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Agregar Pago

Anular Transaccin

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Agregar Especialidad

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Buscar Participante por Cdula

Buscar Participante por Nombre

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Cambiar Clave

Cerrar Sesin

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Cerrar Transaccin

Iniciar Sesin

10

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Ciudad

11

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Concepto

12

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Especialidad

13

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Estado

14

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Evento

15

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Forma de Pago

16

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Pas

17

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Participante

18

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Ciudad

19

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Tipo de Participante

20

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Crear Transaccin

Eliminar Ciudad

21

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Concepto de Transaccin

Eliminar Concepto

22

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Detalle

Eliminar Especialidad de Participante

23

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Especialidad

Eliminar Estado

24

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Evento

Eliminar Forma de Pago

25

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Pago de Transaccin

Eliminar Pas

26

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Participacin

Eliminar Participante

27

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Eliminar Profesin

Generar Reporte de Caja en CSV

28

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Generar Reporte de Caja en XML

Generar Reporte de Ingresos en XML

29

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Generar Reporte de Ingresos en XLSX

Generar Reporte de Inscritos en XLSX

30

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Ciudad

31

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Concepto

32

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Especialidad

33

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Estado

34

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Evento

35

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Forma de Pago

36

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Pas

37

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Participante

38

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Ciudad

39

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Modificar Tipo de Participante

Ver Ciudad

40

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Ver Concepto

Ver Especialidad

41

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

Ver Estado

Ver Evento

42

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

DAS.4 Vista Lgica

DAS.4.1 Modelo de Dominio

DAS.4.2 Elementos arquitectnicamente significativos

Los elementos significativos en el desarrollo de la aplicacin son las siguientes:
El sistema de BD
La expectativa es que en la funcionalidad para manejar estos 5 elementos y sus interrelaciones se invierta el 80% del
tiempo de desarrollo.

DAS. 5 Vista de Implementacin

43

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

DAS.5.1. Diagrama de Clases

DAS.5.2 Diagrama de Componentes

44

Documento de Arquitectura de la Aplicacin (Forma DAS)

Nombre de la Aplicacin: Sistema de Registro de Participantes 6

Fecha: 13/09/2011
Siglas de la Aplicacin:
SRP6

DAS. 6 Vista de Implantacin.

Los requerimientos no funcionales del sistema (Seguridad y Confiabilidad) son manejados por las herramientas que utiliza
el servidor para soportar el sistema. En el aspecto de seguridad, IIS 7 ofrece el protocolo HTTPS, que es el estndar de la
industria para comunicaciones seguras. En el aspecto de confiabilidad, la combinacin de SQL Server e IIS 7 ofrece una
plataforma confiable y capaz de manejar cargas mucho mayores a las planteadas por este sistema.
DAS. 7 Vista de Datos
DAS.7.1 Modelo Entidad-Relacin

45