Você está na página 1de 159

UNIVERSIDAD SIMÓN BOLÍVAR

DECANATO DE ESTUDIOS PROFESIONALES


COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN

SISTEMA DE REGISTRO DE PARTICIPANTES EN EVENTOS


ACADÉMICOS

Por:
CARLOS GUSTAVO SARMIENTO

Realizado con la asesorı́a de:


LUIS EDUARDO MENDOZA MORALES

PASANTÍA LARGA
Presentado ante la Ilustre Universidad Simón Bolı́var
como requisito parcial para optar al tı́tulo de
Ingeniero en Computación

Sartenejas, 9 de ENERO de 2012


Resumen

La motivación de este proyecto fue apoyar las nuevas estrategias de crecimiento de Orga-
nización de Eventos Lasses 07 C.A. a través del desarrollo de un sistema de información que
pudiera manejar el registro de los asistentes que participan en los eventos organizados por la
compañı́a.
El proyecto se realizó bajo la metodologı́a Open Unified Process (OpenUP) del Eclipse
Process Framework y consistió en la concepción, elaboración, construcción y transición 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 regis-
tro de participantes. Esta herramienta suple las necesidades de la empresa en los procesos
que ocurren antes, durante y después de los eventos. Además ofrece suporte para procesos
auxiliares que esten relacionados con el registro de los participantes.
Además del desarrollo del sistema, objetivo principal de la pasantı́a, se apoyó a la em-
presa en el desarrollo de otras soluciones para atacar necesidades del negocio. Entre las más
significativas se encuentran la instalación de una red Ethernet en las nuevas oficinas de la
empresa junto con varios servicios TI relacionados y el desarrollo de la herramienta de Con-
trol 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 Tı́a Cocó, a quien quiero y todavı́a extraño

2246726565206174206C6173743B2066726565206174206C6173743B207468
616E6B20476F6420416C6D6967687479207765206172652066726565206174
206C6173742E22204D617274696E204C7574686572204B696E672C204A722E

v
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
podrı́an 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 permitı́an convertir
ideas descabelladas en realidad y proyectos arriesgados en éxitos. Por ofrecer un lugar donde
el soñar era recompensado y esforzarse exigido. Por ayudarme a ser quien soy.
Segundo a mi tı́o, quien desde niño me inculcó el valor de entender como funcionan las
cosas. Frente a motores, aires acondicionados, bombas de agua y problemas incomprensibles
a los 7 años, me enseñó 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 guı́a en el mundo que existe dentro de la mente y en
como el entendimiento de uno mismo significa paz.
Quinto a Marı́a Valentina, por ser en estos últimos dos años la fuente de mi alegrı́a y mi
apoyo incondicional. Por escucharme, comprenderme y soportarme cuando ni yo mismo me
soportaba. Por demostrar que el amor es más que un anhelo.
Por último a mi Tı́a Cocó, quien aunque ya tiene tiempo ida, siempre es una fuente de
alegrı́a. Por mostrarme el poder de un abrazo, el calor del cariño y la fuerza de un gesto.
A todos ustedes,
Gracias
Índice general

Índice general VII

Índice de cuadros X

Índice de figuras XI

1. Introducción 1
1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Justificación e Importancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Entorno Empresarial 5
2.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Cultura Corporativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Posición del Pasante en la Empresa . . . . . . . . . . . . . . . . . . . . . . . 7

3. Marco Teórico 8
3.1. Aplicación Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Ventajas de las Aplicaciones Web . . . . . . . . . . . . . . . . . . . . 9
3.1.1.1. Simplicidad de Despliegue . . . . . . . . . . . . . . . . . . . 9
3.1.1.2. Soporte Multi-Plataforma . . . . . . . . . . . . . . . . . . . 10
3.1.1.3. Actualización Automática para los Clientes . . . . . . . . . 10
3.2. Arquitectura por Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Arquitectura 3 capas . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Arquitectura Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . 12
3.3. Herramientas de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. .NET Framework 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Visual Studio Web Developer Express 2010 y CSharp Developer Ex-
press 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. SQL Server Express 2008 R2 . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. ASP.NET MVC 3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.5. .NET Entity Framework 4.2 . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.6. IIS Express 7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. Metodologı́a de Desarrollo 17
4.1. Caracterı́sticas Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Fases de OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Fase de Concepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Fase de Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3. Fase de Construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.4. Fase de Transición . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Disciplinas de OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5. Fase de Concepción 23
5.1. Primera Iteración de Concepción . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Análisis de SRP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.2. Cambios respecto al sistema anterior . . . . . . . . . . . . . . . . . . 25
5.2. Plan de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3. Segunda Iteración de Concepción . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4. Visión del Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. Descripción de la aplicación . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2. Posicionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.3. Usuarios y Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.4. Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

viii
6. Fase de Elaboración 35
6.1. Vista de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Vista Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.1. Modelos de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.2. Elementos arquitectónicamente significativos . . . . . . . . . . . . . . 38
6.2.3. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3. Vista de Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.4. Vista de Implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5. Vista de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7. Fase de Construcción 44
7.1. Iteraciones de Construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.1. Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.2. Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1.3. Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.1.4. Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2. Descripción de la Versión Actual del Sistema . . . . . . . . . . . . . . . . . . 48

8. Fase de Transición 52
8.1. Prueba Piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9. Conclusiones y Recomendaciones 55
9.1. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Bibliografı́a 58

ix
Índice de cuadros

3.1. Explicación de las capas en una Arquitectura de 3 Capas (Fowler, 2003) . . . 11

4.1. Fase de Concepción - Objetivos y Actividades (OpenUP-Wiki, 2011) . . . . . 19


4.2. Fase de Elaboración - Objetivos y Actividades (OpenUP-Wiki, 2011) . . . . 20
4.3. Fase de Construcción - Objetivos y Actividades (OpenUP-Wiki, 2011) . . . . 20
4.4. Fase de Transición - Objetivos y Actividades (OpenUP-Wiki, 2011) . . . . . 21

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


5.2. Planificación de Iteraciones (Elab. Propia). . . . . . . . . . . . . . . . . . . . 27
5.3. Stakeholders en el Sistema (Elab. Propia). . . . . . . . . . . . . . . . . . . . 30
5.4. Caracterı́sticas (Elab. Propia). . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5. Riesgos (Elab. Propia). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.1. Casos de Uso Implementados en la Iteración 1 (Elab. Propia). . . . . . . . . 45


7.2. Casos de Uso Implementados en la Iteración 2 (Elab. Propia). . . . . . . . . 46
7.3. Casos de Uso Implementados en la Iteración 3 (Elab. Propia). . . . . . . . . 47
7.4. Casos de Uso Implementados en la Iteración 3 (Elab. Propia). . . . . . . . . 48

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


Índice de figuras

2.1. Estructura Organizacional de la Compañı́a (Elab. Propia) . . . . . . . . . . 6

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


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

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


6.2. Modelo de Dominio de SRP6 (Elab. Propia). . . . . . . . . . . . . . . . . . . 37
6.3. Diagrama de Clases de SRP6 (Elab. Propia). . . . . . . . . . . . . . . . . . . 39
6.4. Diagrama de Componentes de SRP6 (Elab. Propia). . . . . . . . . . . . . . . 40
6.5. Diagrama de Implantación de SRP6 (Elab. Propia). . . . . . . . . . . . . . . 41
6.6. Diagrama de Entidad-Relación de SRP6 (Elab. Propia). . . . . . . . . . . . . 42
6.7. Diagrama de CU (Elab. Propia). . . . . . . . . . . . . . . . . . . . . . . . . . 43

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


7.2. SRP6 - Generando un Reporte y su Resultado en XML (Elab. Propia). . . . 50
7.3. SRP6 - En la Lista de Imprimibles junto con una Plantilla (Elab. Propia). . 51
Capı́tulo 1

Introducción

1.1. Antecedentes

Organización de Eventos Lasses 07 C.A. es una empresa fundada en el año 2000 dedicada a
la organización de eventos del gremio médico. Durante sus diez años de operación la empresa
ha dedicado atención especial al área de Atención al Participante en los eventos utilizando
las Tecnologı́as de Información como herramienta principal para resolver las necesidades
técnicas del servicio. Desde el año 2005, en la empresa se utiliza una plataforma desarrollada
particularmente para los requerimientos de Atención 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 médico.

El sistema sólo se puede utilizar en el ambiente Windows y requiere de un proceso de


instalación.

Cada cambio al sistema debe ser desplegado a más de quince (15) computadoras.
2

1.2. Planteamiento del Problema

Por esta razón, la empresa decidió desarrollar una nueva plataforma que reemplace por
completo el sistema anterior. Basada en tecnologı́as web (en contraste con el software ac-
tual que funciona únicamente bajo ambiente Windows), el proyecto busca suplir las mismas
necesidades del sistema original mientras agrega funcionalidades adicionales como soporte
multi-plataforma, interfaces más flexibles, privilegios de acceso, etc.

1.3. Objetivos

El Objetivo General de la Pasantı́a es desarrollar un Sistema de Información


para llevar un control de los participantes que se registran en uno o más de los
eventos que organiza la compañı́a.
Especı́ficamente, el sistema deberá 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 personalizándolo a los diseños particulares


de cada evento.

Preparar las estadı́sticas asociadas a las diferentes participaciones existentes en el evento


(por ciudad, profesión, tipo de participante, forma de pago, entre otros).

Proveer un resumen de la participación que se obtuvo en el evento (estado financiero


de inscripción, total participación por casa comercial, por profesión, entre otros).
3

1.4. Justificación e Importancia

En el mundo de la Organización de Eventos académicos, el uso de sistemas de información


ofrece la posibilidad de dar a los clientes y participantes acceso a servicios e información
con una precisión y velocidad anteriormente inaccesible. En particular, en los gremios que
no tienen un contacto frecuente con las herramientas informáticas 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 infor-
mación digital es una importante ventaja competitiva, que es aumentada al tener un sistema
desarrollado para servir sus requerimientos especı́ficos, en vez de utilizar una plataforma
genérica. En ese sentido, el trabajo realizado por el estudiante es el mecanismo principal por
el cual la compañı́a accede a esos beneficios.

1.5. Estructura

Este informe esta estructurado de la siguiente manera:

CAP. I - INTRODUCCIÓN: Provee un contexto general para el entendimiento


del trabajo

CAP. II - ENTORNO EMPRESARIAL: Describe a la compañı́a donde se


realizó la pasantı́a; su historia, estructura y cultura organizacional.

CAP. III - MARCO TEÓRICO: Introduce los conceptos importantes del Dominio
del Problema ası́ como los conceptos técnicos utilizados en el proyecto de pasantı́a.

CAP. IV - METODOLOGÍA DE DESARROLLO: Explica los conceptos y las


estrategias definidas por el Open Unified Process (OpenUP) que es la metodologı́a bajo
la cual se desarrolló el proyecto.
4

CAP. V - FASE DE CONCEPCIÓN: Detalla el proceso de análisis realizado para


determinar los requerimientos del nuevo sistema y sus conclusiones.

CAP. VI - FASE DE ELABORACIÓN: Explica la solución técnica que se planteo


para el desarrollo del sistema.

CAP. VII - FASE DE CONSTRUCCIÓN: Se enfoca en el trabajo de programar


y construir el sistema, mencionando aspectos relevantes del trabajo de programación.

CAP. VIII - FASE DE TRANSICIÓN: Trata del proceso de transición de la


compañı́a al nuevo sistema y de la infraestructura que lo soporta.

CAP. IX - CONCLUSIONES Y RECOMENDACIONES: Menciona las con-


clusiones más importantes del proyecto y posibles recomendaciones para su posterior
continuación.

Para poder entender todo el proceso de desarrollo del sistema, empezaremos primero con
un breve resumen del Entorno Empresarial en el cual se desarrolló la pasantı́a.
Capı́tulo 2

Entorno Empresarial

Organización de Eventos Lasses 07 C.A. es una PYME1 fundada en el año 2000 dedicada
a la organización de Eventos académicos que durante la última década se ha dedicado prin-
cipalmente a suplir las necesidades de actualización académica continua del gremio médico
en Venezuela. Esto está cambiando actualmente, con la empresa interesada en expandir sus
servicios a otros mercados a través de una reorganización interna que le permita servir más
clientes y organizar más eventos al mismo tiempo2 .

2.1. Estructura

La empresa está 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 Área. Los Gerentes de Área supervisan a los Asistentes de Área quienes se
encuentran en el nivel inicial de la jerarquı́a organizacional.

1
Pequeña o Mediana Empresa
2
Entrevista con Tutor Académico
6

Figura 2.1: Estructura Organizacional de la Compañı́a (Elab. Propia)

Las responsabilidades de cada Unidad de Negocio son las siguientes:

2.1.1. Eventos

Se enfoca en proveer el servicio de Organización de Eventos a los clientes, desde la concep-


tualización de un Evento hasta su finalización y cierre. En esta unidad los Gerentes de Área
son conocidos como Gerentes de Eventos y cada uno organiza una serie de eventos de forma
independiente de los otros gerentes. Actualmente, la compañı́a cuenta con dos Gerentes de
Eventos a dedicación exclusiva.

2.1.2. Productos

Esta unidad se dedica a proveer productos y servicios auxiliares para la organización de un


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

2.1.3. Operaciones

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

2.2. Cultura Corporativa

Organización de Eventos Lasses se define a sı́ misma como una empresa de servicios y su
enfoque principal es en resolver cualquier situación en la cual el cliente pueda beneficiarse de
la intervención de los empleados de la empresa.

2.3. Posición del Pasante en la Empresa

El autor fue contratado por la compañı́a para empezar labores el 18 de Julio de 2011 en
Operaciones, como el primer desarrollador de una naciente área 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 área) que a su vez reporta al Vicepresidente de Productos.
En la práctica, reporta directamente al Vicepresidente de Productos ya que este ú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 ejecución del proyecto.
Capı́tulo 3

Marco Teórico

Para el desarrollo del sistema propuesto por la empresa, el principal problema fue enten-
der las caracterı́sticas particulares de las tecnologı́as que se deseaban utilizar. Una ventaja
importante a la hora de desarrollar el proyecto es que muchos de los conceptos básicos fue-
ron claramente explicados en el Pensum de la carrera, por lo que solamente fue necesario
desarrollar algunos conceptos especı́ficos que eran relevantes para la tarea a realizar.
La única excepción a este criterio fue el concepto de la Aplicación Web. Este se incluyó en
el Marco Teórico del proyecto, ya que a pesar de ser un concepto de uso muy común en el
mundo del desarrollo de software, es necesario para que el lector que desconozca del tema
tenga un contexto mı́nimo para entender el resto del proyecto.
Los otros temas del Marco Teórico son las Arquitecturas por Capas (especialmente el caso
particular de la arquitectura de 3 capas), la Arquitectura Modelo-Vista-Controlador.

3.1. Aplicación Web

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


una de los trabajos más importantes de los grupos de TI. Pero un problema constante es
9

definir de forma precisa a que nos referimos al hablar de una Aplicación Web.
La primera mención del término aplicación web, ocurrió en la Especificación de Servlets
de Java v2.2 donde se definı́a como Una colección de servlets, páginas JavaServer, documen-
tos HTML y otros recursos web que pueden incluir imágenes, archivos comprimidos y otra
información(Davidson, 1999). El problema con esta definición es que es especı́fica al contexto
de Java y no representa el uso actual que se le da al término Aplicación Web.
En este sentido, (Jazayeri, 2007) propone una definición un poco más clara cuando dice
Una Aplicación Web una aplicación que se accede a través de Internet con un Explorador .

3.1.1. Ventajas de las Aplicaciones Web

La razón por la cual las Aplicaciones Web han tenido un auge importante en los últimos
años 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 más 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 automa-
tizar el proceso de instalación de una o más 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 aplicación de escritorio.
Por otro lado, las aplicaciones web no sufren de estos problemas. En primer lugar, no re-
quieren ninguna instalación especial en la computadora cliente, solamente la disponibilidad de
un Explorador Web y una conexión de red, dos caracterı́sticas que se consiguen ampliamente
10

en computadoras recientes y dispositivos móviles (Shklar, 2003)

3.1.1.2. Soporte Multi-Plataforma

Otra caracterı́stica de las Aplicaciones Web es que se encuentran basadas en protocolos


y formatos estandarizados1 (Shklar, 2003). Estos estándares2 son soportados por una gran
cantidad de plataformas3 lo cual le permite a una aplicación web soportar una amplia gama
de métodos de acceso sin requerir cambios significativos o la construcción de una aplicación
paralela que ofrezca la misma funcionalidad para otra plataforma.

3.1.1.3. Actualización Automática para los Clientes

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


clientes, el realizar una actualización del software requiere solamente el despliegue de nuevos
archivos en los servidores (Shklar, 2003). La próxima vez que un cliente utilice la aplicación,
recibirá del servidor los archivos actualizados, por lo que, sin ninguna interacción particular
en el cliente, la aplicación será actualizada. Esto cambia la dinámica de actualización de
una aplicación 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 construcción de software en Capas es una de las técnicas más comunes para reducir
la complejidad de una aplicación. 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 estandarización, cada fabricante lleva a cabo pequeñas interpretaciones
del significado del estándar. Esto puede causar comportamientos ligeramente distintos en una Aplicación 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 aplicación para estos pequeños detalles.
3
De hecho es difı́cil pensar en una plataforma que ofrezca acceso a la Web sin cumplir con estos estándares
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 más común es la arquitectu-
ra de 3 capas. (Fowler, 2003). Esta consiste en tres capas que juntas ofrecen la funcionalidad
total del sistema. Estas capas son llamadas respectivamente Presentación, Dominio y Datos
(Brown, 2003).

Provee todos los servicios necesarios para desplegar la información


al usuario (Ventanas o código HTML, manejo de interacciones del
Presentación
usuario, protocolos para cargar data, operaciones de terminal, etc.).
No realiza ninguna clase de manejo de la lógica del dominio.

Maneja toda la lógica que produce la verdadera funcionalidad del sis-


4
Dominio tema. Verifica que las operaciones que se realizan cumplen con las
reglas del dominio.

Maneja la conexión con el almacenamiento de la información. No in-


cluye una comprensión semántica de la data que se maneja, sino úni-
Datos camente realiza las transacciones necesarias para mover la data entre
la capa de Dominio y los recursos de almacenamiento y transmisión
de data.

Cuadro 3.1: Explicación de las capas en una Arquitectura de 3 Capas (Fowler, 2003)

4
También conocida como Aplicación
12

3.2.2. Arquitectura Modelo-Vista-Controlador

En contraste con la arquitectura de 3 capas, se encuentra la arquitectura Modelo-Vista-


Controlador, 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 Model–View–Controller (Burbeck, 1987).
Burbeck (1987) describe la arquitectura MVC como un paradigma en el que las interac-
ciones del usuario, las respuestas del sistema y el modelo del dominio son manejadas expli-
citamente por objectos distintos y especializados para cada tarea.
El modelo maneja el comportamiento y la data del dominio de la aplicación, respondiendo
a solicitudes de información y de cambios de estado (generalmente provenientes de las Vistas).
Las vistas, por otro lado, manejan la representación visual de las operaciones que realiza el
sistema y son los únicos objetos capaces de manipular dicha representación. Por último, los
controladores interpretan las interacciones del usuario y remiten instrucciones al modelo o
las vistas para que realicen las operaciones apropiadas.
Una caracterı́stica 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 comunicación 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 vı́nculo 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 están, por su misma naturaleza,
fuertemente vinculados.
Por último, la Arquitectura Modelo-Vista-Controlador, permite la creación de jerarquı́as
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 complejización del código del
sistema.

3.3. Herramientas de Desarrollo

Para la construcción del proyecto, se decidió utilizar el grupo de herramientas ofrecidas


por Microsoft para desarrollo de aplicaciones. Las razones se explican a continuación.

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,
Recolleción de basura y Compilación al momento (entre muchos otros) para la plataforma
Windows (Haack, 2011).
La elección de desarrollar el sistema en el lenguaje CSharp del .NET Framework se basó en
los siguientes criterios:

Fuerte Integración 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 técnicos.

3.3.2. Visual Studio Web Developer Express 2010 y CSharp De-

veloper Express 2010

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

la tecnologı́a ASP.NET. Ofrece capacidades para el desarrollo de código HTML, CSS, Ja-
vaScript, CSharp y VB.NET (con la limitante de solo permitir aplicaciones web) (Haack,
2011).
La caracterı́stica más atractiva para utilizar esta herramienta es su fuerte integración 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 versión más 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 versión del lenguaje SQL que implementa Microsoft (T-SQL) que es a su
ves compatible con el estándar 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 aplicación contra SQL Server
Express con la seguridad de que, en el momento que las necesidades de almacenamiento
y manipulación de datos superen las capacidades de esta versión, se puede transicionar a
versiones más 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 Código 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 aplicación web, lo que
le permite al desarrollador dedicarse a la lógica de negocio y las funcionalidades especı́ficas
de la aplicación.
15

3.3.5. .NET Entity Framework 4.2

Las librerı́as que conforman el .NET Entity Framework 4.2 ofrecen funcionalidad diri-
gida a simplificar el acceso a bases de datos relacionales. La librerı́a permite abstraer las
instrucciones de acceso de datos (Generalmente código SQL) del código de la aplicación.
Estas capacidades están a su vez construı́das siguiendo las reglas y patrones de diseño y
programación recomendadas para evitar ataques contra la capa de datos (Lerman, 2011).
En particular, el sistema utiliza la librerı́a Code First, que permite crear las entidades
del modelo de datos como clases de .NET, describiendo sus caracterı́sticas y relaciones en el
mismo código. Estas a su vez son convertidas automáticamente6 en un esquema de base de
datos que puede ser ejecutado directamente contra el Manejador de Bases de Datos.
Además la librerı́a Code First permite generar automáticamente las consultas SQL a la
Base de Datos a partir de consultas escritas en código .NET78 y convertir el resultado de las
mismas en objetos de .NET (Lerman, 2011).
Por último, la librerı́a 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 versión 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 versión 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ón es automática, la librerı́a permite configurar el proceso para obtener modificar el
esquema resultante.
7
Para esto se utiliza una librerı́a incluı́da con .NET desde la versión 3.0 llamada LINQ.
8
Estas consultas son fuertemente optimizadas por la librerı́a, y para los casos en los cuales el resultado
del proceso sea sub-óptimo existe las posibilidades de escribir una consulta en SQL y que esta sea ejecutada
por la librerı́a sin perder el uso del resto de la funcionalidad
16

trivial aplicaciones web desarrolladas con .NET a la vez que ofrece caracterı́sticas avanzadas
como transacciones con SSL/TLS en un paquete sin costo.
Para el próximo capı́tulo, realizaremos un breve resumen de la metodologı́a OpenUP
utilizada durante el desarrollo del proyecto.
Capı́tulo 4

Metodologı́a de Desarrollo

Para el desarrollo de este proyecto se utilizó la metodologı́a OpenUP (Open Unified


Process) desarrollada bajo el marco del Eclipse Process Framework, un proyecto de software
libre de la Fundación Eclipse
La metodologı́a OpenUP empezó como una donación de IBM al mundo del software libre
de su metodologı́a Basic Unified Process (BUP) que a su vez es una simplificación de la
metodologı́a Rational Unified Process (RUP) en el año 2005. Esta donación la recibió la
Fundación Eclipse como una propuesta para un nuevo proyecto (Kroll, 2007).
De acuerdo con Kroll (2006), la metodologı́a OpenUP se define en función del Proceso
Unificado, con cambios traı́dos al incluir principios de las metodologı́as ágiles como Scrum y
eXtreme Programming ası́ como el Manifiesto Ágil.

4.1. Caracterı́sticas 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 metodologı́a. 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 área del sistema particular, OpenUP propone dedicar los
recursos por espacios de tiempo más cortos y producir resultados más modestos que puedan
ser refinados en periodos de tiempo futuros hasta llegar a una solución que cumpla con la
funcionalidad completa (Kroll, 2007).
Por otro lado, OpenUP también propone que el proceso de construcción del software se
realice en Micro-Incrementos (Gustafsson, 2008). Estos micro incrementos son paquetes que
desarrollan un pequeño componente de la funcionalidad total del sistema de forma completa,
tal que cada vez que se termine una iteración, 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 comparación con el proceso unificado son las fases de
desarrollo1 . OpenUP todavı́a divide el proceso de desarrollo en 4 fases concretas, por las que
se mueve el equipo de desarrollo de forma lineal. Estas fases son: Concepción, Elaboración,
Construcción y Transicición.

4.2.1. Fase de Concepción

El objetivo principal de la Fase de Concepción es el adquirir un conocimiento claro de las


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

1
Esta afirmación 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 sección 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 solu-


Aceptar una estratégica técnica.
ción.

Entender los costos, cronogramas y Iniciar el Proyecto. Planificar y Geren-


riesgos asociados con el proyecto. ciar la Iteración.

Cuadro 4.1: Fase de Concepción - Objetivos y Actividades (OpenUP-Wiki, 2011)

4.2.2. Fase de Elaboración

El objetivo principal de la Fase de Elaboración consiste en construir una arquitectura


sobre la cual puedan soportarse el resto de la funcionalidad del sistema2 . Un punto crı́tico
es que la arquitectura debe ser implementada y validada, no simplemente diseñada 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 comprensión de los reque-


Identificar y refinar los requerimientos
rimientos más detallada

Desarrollar la arquitectura. Desarrollar


Diseñar, implementar y validar la ar-
incrementos de la solución.Probar la so-
quitectura
lución

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

Mitigar los riesgos esenciales, producir


Planificar y Manejar la Iteración
un cronograma preciso y estimar costos

Cuadro 4.2: Fase de Elaboración - Objetivos y Actividades (OpenUP-Wiki, 2011)

4.2.3. Fase de Construcción

El objetivo principal de la Fase de Construcción es la de desarrollar una aplicación que,


basdada en la arquitectura desarrollada en la Fase de Elaboración, cumpla con los requeri-
mientos planteados para el sistema. La parte más importante de este proceso es que todas las
iteraciones de esta fase deben producir un producto completo, que puede ser potencialmente
distribuı́do 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 pro-


Identificar y refinar los requerimientos.
ducto completo que está listo para po-
Desarrollar un incremento de la solu-
tencialmente ser transicionado a los
ción. Probar la Solución
usuarios.

Planificar y Gerencias la Iteración.


Minimizar los costos de desarrollo y al-
Desarollar un incremento de la solu-
canzar un nivel de paralelismo.
ción. Probar la Solución.

Cuadro 4.3: Fase de Construcción - Objetivos y Actividades (OpenUP-Wiki, 2011)


21

4.2.4. Fase de Transición

El objetivo de la última Fase, Transición es el de preparar el software para ser transicio-


nado de forma definitiva a la comunidad de usuarios. Esta preparación se logra puliendo y
optimizando las funcionalidades desarrolladas en la Fase de Construcción. En el OpenUP-
Wiki (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 cum-
llar un incremento de la solución. Pro-
plen las expectativas de los usuarios.
bar la Solución.

Alcanzar el acuerdo de los participantes


del proyecto que el despliegue esta com- Planificar y Gerenciar la iteración. Pro-
pleto. Achieve stakeholder concurrence bar la solución
that deployment is complete

Mejorar el desempeño de proyectos fu-


turos a través de las lecciones aprendi- Planificar y Gerenciar la iteración
das

Cuadro 4.4: Fase de Transición - Objetivos y Actividades (OpenUP-Wiki, 2011)

4.3. Disciplinas de OpenUP

Para las disciplinas en OpenUP, se realizó una simplificación de las disciplinas establecidas
en RUP. El objetivo fue eliminar actividades que no eran crı́ticas para el desarrollo de software
en grupos pequeños 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ón y Cambios

Para iniciar la descripción del proceso de Desarrollo del sistema, empezaremos con la
primera de las etapas de la metodologı́a OpenUP, la Fase de Concepción.
Capı́tulo 5

Fase de Concepción

Este capı́tulo se dedica a explicar el proceso por el cual se determinaron los caracterı́sti-
cas principales del sistema y cómo éstas debı́an ser representadas ante el usuario. En la
metodologı́a OpenUP, a esta fase se le conoce como Fase de Concepción (Inception Phase).
En el proyecto, se realizaron dos iteraciones formales durante la fase de concepción del
Sistema. Durante estas dos iteraciones se alcanzaron los siguientes objetivos de la metodo-
logı́a:

Definir que se desea construir.

Identificar las funcionalidades clave del sistema.

Determinar una solución técnica.

Entender los costos, cronograma y riesgos del proyecto.

5.1. Primera Iteración de Concepción

Como se mencionó anteriormente, la empresa ya contaba con un sistema para las nece-
sidades que presentaba el negocio y su interés principal era en migrar la plataforma de un
24

aplicación local a una plataforma web. En vista de esto, para definir los requerimientos del
sistema se llevaron a cabo tres análisis por separado. El primero se enfocó en la funcionali-
dad cumplı́a el sistema actual de la empresa, como mecanismo para entender el dominio del
sistema y muchos de los requerimientos que se plantearon. El segundo buscó entender que
caracterı́sticas se deseaban modificar en comparación con el sistema original. Por último, el
tercero fue determinar que caracterı́sticas eran totalmente nuevas.

5.1.1. Análisis de SRP4

Para realizar el análisis del sistema actual, el autor participó en varios eventos de la
compañı́a 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 ingenierı́a 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 generación de reportes complejos1 .
Aunque esta observación es cierta en el sentido técnico, serı́a un error pensar que el sistema
es inadecuado para la compañı́a. El mismo está construı́do alrededor de las necesidades
particulares de la empresa, por lo que cumple de forma clara con los requisitos de manejo
de información 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 caracterı́sticas necesarias de SRP4.
Vale la pena aclarar que la afirmación anterior es válida en la medida en la que nuevos
1
Existe una herramienta que es capaz de extraer la información 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 caracterı́sticas del sistema anterior. En estos casos
la polı́tica del proyecto es modificar las caracterı́sticas 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 caracterı́sticas que debı́an cambiar entre
SRP4 y SRP6. Para describir estos cambios, se construyó el cuadro 5.1.
26

Categorı́a SRP4 SRP6

Tipo de Sistema Cliente - Servidor Web

Validación de Usuarios Interna A través de LDAP

Almacenamiento de Datos Centralizado Distribuido

No. de Especialidades por


Dos (2) Ilimitadas
Participante

No. de Tipos de Partici-


pación por Participante y Uno (1) Ilimitadas
Evento

Tipo de Documento de Cédula de Identidad, Pasa-


2
Cédula de Identidad
Identidad porte3 , ID temporal

Todas las transacciones de-


No existe ninguna bitácora ben ser registradas en una
Registro de Transacciones
de las transacciones. bitácora con Usuario, Fecha
y Operación.

Manejo de conceptos, pa-


El sistema solamente mane-
gos y la relación entre ellos
ja registros de Pagos, pe-
Control de Ingresos (Transacciones) cuando un
ro no los asocia con ningún
participante cancela más de
concepto4
uno.

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

2
Para casos en los cuales no se tenı́a la C.I. del participante, la empresa utilizaba un texto que empezaba
por ”P”(por ejemplo P123456789), pero esto no fue una caracterı́stica diseñada en el sistema sino una solución
temporal al problema.
3
Para poder registrar los conferencistas internacionales.
4
Esto causaba muchos problemas cuando un participante pagaba más de un concepto, ya que no se podı́a
determinar que conceptos componı́an el total.
27

5.2. Plan de Proyecto

En esta iteración se planificó además la distribución del resto del tiempo disponible para
el proyecto. El resultado de ese trabajo de planificación se encuentra en el cuadro 5.2.

Iteración Duración Objetivos

1ra Iteración de Realizar un análisis de las herramientas que existen actual-


5 dı́as
Concepción mente en la empresa.

2da Iteración de Determinar el posicionamiento del sistema y desarrollar el Do-


5 dı́as
Concepción cumento Visión.

1ra Iteración de Desarrollar los requerimientos del sistema y realizar la Espe-


10 dı́as
Elaboración cificación de Requerimientos

2da Iteración de Preparar la arquitectura del sistema y el Documento de Ar-


10 dı́as
Elaboración quitectura de Software

1ra Iteración de
10 dı́as Programar la funcionalidad mı́nima para ejecutar el sistema.
Construcción

2da Iteración de Programar los CU que manejan la entrada, modificación y


15 dı́as
Construcción eliminación de data del sistema.

3ra Iteración de
15 dı́as Programar la funcionalidad de reportes.
Construcción

4ta Iteración de
10 dı́as Programar toda la funcionalidad adicional restante.
Construcción

1ra Iteración de Preparar y ejecutar el piloto de la aplicación en un evento


10 dı́as
Transición organizado por la compañı́a.

Cuadro 5.2: Planificación de Iteraciones (Elab. Propia).


28

5.3. Segunda Iteración de Concepción

En la segunda iteración de Concepción, se desarrolló la visión del sistema. Esto consistió 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ón del Producto

Después del desarrollo de la visión del proyecto esta quedó planteada finalmente en el
Documento de Visión (Disponible completo en el Apéndice A). Los elementos más relevantes
de la visión del proyecto son los siguientes.

5.4.1. Descripción de la aplicación

La aplicación es un sistema de información Web que va a ser utilizado en computadoras


con ambiente Windows para la realización del registro de participantes en un evento organiza-
do por la Compañı́a. La aplicación debe permitir el registro de participantes, la generación de
material imprimible personalizado, la generación de reportes. Aunque actualmente la aplica-
ción no interactúa con ningún otro sistema de la empresa, esta posibilidad debe considerarse
en la ejecución del proyecto.

5.4.2. Posicionamiento

El sistema fue concebido para resolver varios problemas a los cuales se enfrentaba la
compañı́a y para los cuales la aplicación anterior (SRP4) era insuficiente. A través del análisis
de la Fase de Concepción se determinaron los siguientes problemas:

Registrar a los participantes en los Eventos Médicos organizados por la Compañı́a.


29

Registrar de forma masiva o en lote las listas de participantes provistas por las empresas
patrocinantes

Ofrecer información agregada acerca de los participantes en un Evento.

Llevar un control monetario de los ingresos que se generan por la inscripción de parti-
cipantes en el evento.

5.4.3. Usuarios y Stakeholders

El proyecto se realizó con el apoyo de tres personas que tuvieron la posición 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 Visión en el Anexo A.

Categorı́a Responsabilidad Nombre

Determina los requerimien-


Promotor del Proyecto, Ad-
tos de la aplicación y deter-
ministrador del Sistema y Nelliana Acuña
mina el cumplimiento de los
Gurú de Negocios
requisitos

Apoyar en el desarrollo de
la solución técnica para los
Gurú de Negocio, Exper-
problemas planteados en los
to Técnico y Administrador Isbhet Muñoz
requerimientos. Ayudar a
del Sistema
convertir los requerimientos
en soluciones técnicas
30

Proveer feedback en rela-


ción 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. Caracterı́sticas

En la metodologı́a utilizada a este nivel del proyecto los requerimientos del sistema son
las caracterı́sticas de alto nivel que debe cumplir el mismo. En el Documento Visión (ver
Apéndice A) se plantearon los requerimientos principales del sistema y la solución que debı́a
proponer la aplicación.

Necesidad Solución Actual Propuesta

La aplicación debe ofrecer


Se requiere registrar los da- El sistema SRP4 ofrece
una Interfaz Web para regis-
tos concernientes a los asis- una funcionalidad similar.
trar los datos concernientes
tentes a un evento y los in- Cuando el sistema no
a los asistentes a un even-
gresos relacionados con las está operativo se utiliza
to y generar los imprimibles
inscripciones a un evento. Excel
necesarios.
31

La aplicación debe ofrecer


Se requiere procesar las lis- La carga de la informa-
una Interfaz Web a la cual
tas de pre-inscritos que pro- ción se realiza manualmen-
se suban archivos en forma-
vean las casas comerciales te, participante por partici-
to CSV que sean procesados
que participan en el evento. pante, en SRP4
automáticamente.

Se requiere preparar las


SRP4 ofrece una herramien-
estadı́sticas asociadas a las La aplicación debe ofre-
ta que exporta la informa-
diferentes participaciones cer una Interfaz Web la
ción del evento a Excel. La
existentes en el evento cual permita generar repor-
agregación y el análisis de la
(por ciudad, profesión, tipo tes agregando la informa-
información se realizan ma-
de participante, forma de ción deseada.
nualmente.
pago, entre otros).

Se requiere proveer un resu-


Se utilizan los mecanismos
men de la participación que
existentes en SRP4 para La aplicación debe ofrecer
se obtuvo en el evento (esta-
el manejo de los Pagos y la capacidad de generar Re-
do financiero de inscripción,
otra información relaciona- portes de Caja, de Ingresos
total participación por casa
da, aunque son insuficien- y Balances del evento.
comercial, por profesión, en-
tes.
tre otros).

El sistema SRP4 ofrece La aplicación debe seguir


Se requiere que las activida-
una funcionalidad insufi- los estándares webs mı́ni-
des que realice la aplicación
ciente de seguridad y confia- mos de seguridad y confia-
sean seguras y confiables.
bilidad bilidad.

Cuadro 5.4: Caracterı́sticas (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
estratégicas para mitigarlos y controlarlos. Estos riesgos se encuentran en la tabla 5.5.

ID Nombre Prioridad Descripción

Existe la posibilidad que los usuarios no


acepten el nuevo sistema y prefiera seguir uti-
Rechazo del Proyecto por lizando SRP4. Para contrarrestar este riesgo,
1 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 pa-


ra la ejecución 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 computado-
res a bajo costo que cumplen con los requisi-
tos sugeridos para ejecutar el software.

La pérdida de información (código, documen-


tación, etc.) es un riesgo significativo del pro-
yecto. Para contrarrestar este riesgo se esta-
Pérdida de información o
3 5 bleció un mecanismo de control de versiones
data
(SVN) almacenado en un arreglo de discos
con RAID Tipo 1 para asegurar la integri-
dad lógica y fı́sica de la información.

El uso de las nuevas tecnologı́as que ofre-


ce Microsoft (ASP.NET MVC, Entity Fra-
mework) supone un riesgo de aprendizaje
4 Uso de tecnologı́a nueva 4 durante el proyecto. Para contrarrestar es-
te riesgo, se adquirieron varios libros y do-
cumentación sobre el uso de estos sistemas
antes de arrancar el proyecto.
34

Un crecimiento desmedido de los requeri-


mientos del sistema (Scope Creep) puede ser
destructivo para el proyecto. Para contrarres-
Demasiados requerimientos
5 3 tar este riesgo, se limitó el ámbito del proyec-
para el tiempo del proyecto
to a las necesidades básicas de la empresa en
el área de registro y se excluyó cualquier otra
área de negocios.

Cuadro 5.5: Riesgos (Elab. Propia).

Con la visión del sistema claramente establecida, la cual puede revisarse con detalle en
el Anexo A, el siguiente paso del proyecto consistió en detallar los requerimientos de la
aplicación y obtener de esa forma un documento claro de lo que se debı́a construir. Este fue
el objetivo de la siguiente fase del proyecto, la Fase de Elaboración, a la que se refiere el
próximo capı́tulo.
Capı́tulo 6

Fase de Elaboración

En este capı́tulo se detallan los resultados del proceso de Elaboración de la arquitectura del
sistema SRP6. En la metodologı́a OpenUP, a esta fase se le conoce como Fase de Elaboración
(Elaboration Phase).
La fase de elaboración se desarrolló en una sola iteración enfocada en el diseño de una
arquitectura capaz de sostener las necesidades del sistema identificadas durante la Fase de
Concepción. 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 desa-


rrollo del ERS en un conjunto de Casos de Uso que permiten dividir la funcionalidad del
sistema en pedazos manejables para un esfuerzo de programación estructurado. La vista de
casos de uso se compone del Diagrama de Casos de uso (Figura 6.7), las narrativas de ca-
sos de uso (Disponibles completas en el Apéndice B - Especificación de Requerimientos), y
los diagramas de secuencia (disponibles en el Apéndice 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 caracterı́stica relevante de la arquitectura.

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


37

6.2. Vista Lógica

La vista lógica 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 Apéndice C y consiste del Modelo
de Dominio, los Elementos Arquitectónicamente significativos y el Diagrama de Clases.

6.2.1. Modelos de Dominio

El modelo de dominio describe los elementos más relevantes del entorno en el cual se
desarrolla la aplicación. Para SRP6, estos elementos forman parte del área de organización
de eventos de la empresa y se centra en el Evento como elemento interconector de las demás
áreas del negocio.

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


38

6.2.2. Elementos arquitectónicamente significativos

Para la construcción de la aplicación, se tomaron los siguientes elementos como aquellos


arquitectónicamente significativos:

Sistema de Base de Datos que contiene la información del sistema.

Servidor HTTP y HTTPS que transmite las páginas 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 interco-
municación del sistema (ControllerDispatcher, ViewDispatcher y SrpDatabaseConnection).
Estos tres componentes se encargan del flujo completo de la información 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. Además 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 comunicación con el
Cliente.

6.3. Vista de Implementación

La vista de implementación describe las estructura que componen el software a construir.


Para esta vista existe un único diagrama: el diagrama de componentes (ver Figura 6.4) que
representa la forma en la que las distintas partes del código son agrupadas en elementos
discretos (componentes). Toda la información de la Vista de Implementación y los diagramas
se pueden revisar en el Apéndice C.
Como se puede observar en el diagrama (Figura 6.4), la solución fue dividida siguiente
la arquitectura elegida para el sistema (MVC). El único punto resaltante del diagrama es
39

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

la separación 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ón

La vista de implantación muestra las caracterı́sticas 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 caracterı́sticas del sistema permiten un entorno de implantación extremadamente
sencillo por lo que solo hay un diagrama (Figura 6.5). Además, las caracterı́sticas de la
40

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

plataforma en la que se ejecutará el software permite responder a los dos requerimientos no


funcionales de la aplicación: Seguridad y Confiabilidad. El primero lo maneja la funcionalidad
de IIS 7 de ofrecer el protocolo seguro HTTPS. El segundo es la combinación de IIS 7 junto
con SQL Server 2008 R2, la cual ha demostrado ser efectiva en mantener en funcionamiento
sistemas de informacion complejos1 . La documentación completa de la Vista de Implantación
se encuentra completa en el Apéndice C.

6.5. Vista de Datos

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


de la información de negocios que maneja y almacena el sistema. Gracias a las caracterı́sticas
del paquete utilizado para manejar las interacciones con la Base de Datos (Entity-Framework
1
Toda la infraestructura de información de Microsoft funciona en estos dos sistemas. Una infraestructura
que soporta cientos de miles de empleados en más de 100 paı́ses.
41

Figura 6.5: Diagrama de Implantación de SRP6 (Elab. Propia).

4.2), el proyecto solo requirió el desarrollo de un Modelo Entidad Relación (Figura 6.6) el cual
fue después 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 aplicación de
software que se podı́a ejecutar y utilizar en la empresa. Nuestro próximo capı́tulo se refiere
directamente a la Fase de Construcción en el proceso de OpenUP.
42

Figura 6.6: Diagrama de Entidad-Relación de SRP6 (Elab. Propia).


43

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


Capı́tulo 7

Fase de Construcción

Dividido en dos grandes partes, este capı́tulo detalla las herramientas que se utilizaron
para la construcción de SRP6 junto con unas reseñas de las actividades desarrolladas durante
cada una de las 4 iteraciones del proceso de construcción. En la metodologı́a OpenUP, a esta
fase se le conoce como Fase de Construcción (Construction Phase).

7.1. Iteraciones de Construcción

7.1.1. Iteración 1

La primera iteración de desarrollo se enfocó en la construcción de toda la capa de datos


que permitirı́a al resto del sistema interactuar con la Base de Datos donde se almacenarı́an
los datos. Los principales productos de esta iteración fueron la implementación de las clases
que accesarı́an la base de datos y la programación de las reglas de Mapeo definidas en la Fase
de Elaboración para cada una de las clases del modelo ORM.
Los casos de Uso implementados en esta iteración fueron:

ID Nombre del CU ID Nombre del CU


45

1 Iniciar Sesión 2 Cerrar Sesión

3 Cambiar Clave

Cuadro 7.1: Casos de Uso Implementados en la Iteración 1 (Elab. Propia).

7.1.2. Iteración 2

En la segunda iteración, el trabajo se enfocó en programar los CU de la tabla 7.2. Para


esto, se construyeron varios controladores, cada uno enfocado en un área temática del sistema.
De estos temas, los más importantes fueron la configuración inicial del sistema , manejo de
eventos, manejo de Participantes, manejo de Participaciones y manejo de transacciones. En
esta iteración se construyeron otros controladores auxiliares al resto del sistema.

ID Nombre del CU ID Nombre del CU

4 Crear Participante 5 Modificar Participante

Asignar Especialidad a Partici-


6 Eliminar Participante 7
pante

Eliminar Especialidad de Partici-


8 9 Buscar Por Nombre Participante
pante

10 Buscar Por Cédula Participante 11 Modificar Participación

12 Eliminar Participación 28 Crear Paı́s

29 Modificar Paı́s 30 Eliminar Paı́s

31 Ver Paı́s 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 Iteración 2 (Elab. Propia).

7.1.3. Iteración 3

El objetivo de la tercera iteración fue el desarrollar la capacidad de generar reportes con


el sistema. Para esto se construyó un único controlador que maneja el proceso de creación de
los reportes y se utilizó una librerı́a para la creación de archivos compatibles con Microsoft
Excel para la transformación de los resultados de los reportes en representaciones que fueran
fácilmente manipulables por los usuarios.
Los casos de Uso implementados en esta iteración estan listados en el cuadro 7.3:

ID Nombre del CU

14 Crear Transacción 15 Agregar Concepto a Transacción


47

Eliminar Concepto de Transac-


16 17 Agregar Pago a Transacción
ción

18 Eliminar Pago de Transacción 19 Modificar Pago de Transacción

20 Cerrar Transacción 21 Anular Transacción

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 Iteración 3 (Elab. Propia).

7.1.4. Iteración 4

La última iteración de construcción del sistema consisitió en desarrollar los mecanismos


para la generación de material impreso basado en plantillas. Desde el comienzo del proceso
de elaboración 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 más de 6
meses. Durante el proceso de búsqueda de una librerı́a capaz de generar archivos de Excel1 se
descubrió que la librerı́a OfficeOpenXML ofrecı́a además de la capacidad de generar archivos
1
Durante la iteración 3
48

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


PowerPoint.
Esta fue la solución ideal al problema, ya que PowerPoint ofrecı́a las caracterı́sticas de
diseño de las plantillas2 y la librerı́a OfficeOpenXML ofrecı́a la capacidad de modificarlas a
través de la Aplicación Web.
Los casos de Uso implementados en esta iteración estan en el cuadro 7.4:

ID Nombre del CU

13 Imprimir Material

Cuadro 7.4: Casos de Uso Implementados en la Iteración 3 (Elab. Propia).

7.2. Descripción de la Versión Actual del Sistema

Al finalizar la Fase de Construcción, el sistema permitı́a a la compañı́a registrar eficien-


temente a los participantes de los eventos, a través de una interfaz web (ver Figura 7.1),
llevando un control claro de los ingresos y egresos de dinero, además de toda la información
adicional asociada al proceso.
Otra caracterı́stica del software es permitir manipular rápidamente, a través de reportes
(ver Figura 7.2), la información que se maneja dentro del sistema, ofreciendo un control de
las operaciones que realizan los empleados al registrar participantes y sirviendo como un
repositorio histórico de los eventos que organiza la empresa.
Además, al finalizar la Cuarta Iteración de Construcción, el software permite a los opera-
dores 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 impresión de materiales desde que
se fundó en el año 2000
49

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

Una vez cumplido el trabajo de la construcción de la aplicación, el proyecto se dedicó a


preparar la infraestructura necesaria para iniciar un despliegue piloto del sistema en un evento
organizado por la compañı́a. En la metodologı́a OpenUP, este proceso es conocido como la
Fase de Transición, y se detalla en el próximo capı́tulo.
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).
Capı́tulo 8

Fase de Transición

Para la Fase de Transición del sistema se realizaron dos tareas importantes. La primera,
una prueba piloto de la funcionalidad del sistema. Esta se realizó en la 1era Jornada de
Actualización en Cirugı́a Buco Maxilofacial, un evento organizado por la compañı́a 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.
Quizás el error más importante durante el desarrollo, y que causarı́a problemas durante el
piloto, fue el no diseñar un plan de pruebas y seguirlo a pesar de que la metodologı́a llamaba
para el uso de uno. La ejecución de la prueba piloto sin pruebas anteriores significó, como se
verá a continuación, que ocurrieron problemas que se debieron haber previsto anteriormente.
La empresa tomó esta situación como un punto de aprendizaje para cualquier desarrollo
futuro.

8.1. Prueba Piloto

Uno de los requisitos de la fase de transición en OpenUP es la realización de una prueba


piloto en la cual se validen la correcta implementación de los requerimientos del sistema.
53

Dicha prueba se realizó en la 1era Jornada de Actualización en Cirugı́a Buco Maxilofacial,


un evento organizado por la compañı́a para la Sociedad Venezolana de Cirugı́a Buco-Máxilo
Facial (http://www.svcbmf.org).
La razón por la que se realizó la prueba en un evento1 es que era muy complejo simular
la realidad de un evento para una prueba. Los eventos más grandes de la empresa pueden
llegar a tener más de 2.500 participantes, de los cuales la mayorı́a llega durante el primer
dı́a. En eventos más pequeños (como la Jornada donde se realizó la prueba) los más de 300
participantes llegan prácticamente juntos en las primeras 3 horas de la mañana del primer
dı́a2 . Era imposible para la empresa conseguir alrededor de las 16 personas que se necesitarı́an
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 inscripción y registro. Por esta razón, para la realización de la prueba
piloto se prepararon los dos sistemas de la compañı́a, SRP4 y SPR6. Como primario se
utilizarı́a SRP6, para de esta forma realizar la prueba piloto. En caso de que ocurriera una
falla catastrófica en ese sistema, se tenı́a preparada una copia de SRP4 lista para servir de
backup. Afortunadamente, no ocurrió 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 implementa-
ción de los requerimientos. Esto no deberı́a ser una sorpresa, ya que SRP6 busca construir
y mejorar sobre la funcionalidad de SRP4, un sistema que ha sido utilizado y refinado por
más de 5 años en la empresa. Lo que la prueba piloto si trajo a relieve fueron errores de
programación que no fueron descubiertos durante el desarrollo del sistema. Como se men-
1
Que para los procesos de la empresa puede ser considerado Producción
2
Este comportamiento es común en los eventos. Los participantes pagan para poder asistir, y no desean
perderse ninguna de las sesiones, por lo que llegan temprano el primer dı́a
3
4 operadores y 12 personas sirviendo de participantes que pasan por la cola una y otra vez.
54

cionó anteriormente, estos problemas debieron haber sido descubiertos a través de un Plan
de Pruebas, la empresa a partir de ese momento tomo la polı́tica de requerir el diseño y
ejecución de pruebas en todos los desarrollos subsecuentes.

Error Estado Actual

Al imprimir, la integración con Power-


Point impredeciblemente lanza un COM Corregido
Exception.

Al buscar participantes, el sistema distin-


gue entre una vocal acentuada y una no Corregido
acentuada.

Al guardar la información de un partici-


Corregido
pante, no se activa la notificación visual.

Al imprimir el material de un participan-


Corregido
te, no se registra el material impreso.

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


Capı́tulo 9

Conclusiones y Recomendaciones

Después del perı́odo de pasantı́a, entendiendo los requerimientos, diseñando arquitecturas


y escribiendo código, podemos decir que el proyecto de desarrollo del Sistema de Registro de
Participantes fue un éxito importante para la compañı́a. El principal logro fue resolver los
problemas más importantes que ocurrı́an con la v4 del sistema, sin perder la funcionalidad
altamente refinada que ofrecı́a.
El software resultante de la pasantı́a permite a la compañı́a registrar eficientemente a
los participantes de los eventos que ésta organiza, a través de una interfaz web, llevando un
control claro de los ingresos-egresos de dinero y de la información asociada al proceso. Otras
caracterı́sticas del software son permitir manipular rápidamente, a través de reportes, la
información que se maneja dentro del sistema, ofrecer control de las operaciones que realizan
los empleados al registrar participantes y servir como un repositorio histórico de los eventos
que organiza la empresa. Por último la aplicación ofrece a la empresa una plataforma con la
cual ofrecer servicios agregados más valiosos para sus clientes.
Esta última caracterı́stica permite cambios como eliminar completamente el uso de
computadoras en los eventos y reemplazarlos con dispositivos móviles como iPads. A la
misma vez, como la aplicación fue construida desde el comienzo sin reciclar código de la
56

versión 4, este programa no sufre de los problemas de una aplicación que fue construida sin
seguir ningún requisito formal, sino más bien fue un proyecto cuyo objetivo fue cumplir con
los requisitos a la medida que se iban descubriendo sin planificación ni metodologı́a.
Por otro lado, el uso de la metodologı́a 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ñı́a pequeña, 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 situación tan
particular en la que se encuentra la empresa. Para el tamaño de la empresa, metodologı́as
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ñı́a desarrollando software para
uso en los procesos reales de una compañı́a ha sido una experiencia muy enriquecedora. El
poder interactuar con personas altamente capacitadas en sus áreas de experticia y que ven
en las aplicaciones de software oportunidades nuevas de mejorar la empresa fue un motivador
importante durante la realización de la pasantı́a.

9.1. Recomendaciones

Después de todo el proceso de desarrollo, se decidió recomendar a la empresa los siguientes


cambios para mejorar sus procesos y sus capacidades:

Cambiar su metodologı́a de desarrollo a opciones más ágiles para tomar ventaja de su


pequeño tamaño y evitar la producción de documentación que puede ser innecesaria en
equipos de desarrollo muy pequeños.
1
Que es necesario a medida que el tamaño del equipo de desarrollo crece
57

Considerar la posibilidad de establecer un pequeño 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 través de Internet, realizando el pago en lı́nea con tarjetas
de débito o crédito.

Expandir el alcance del proyecto para incluir la capacidad de interactuar directamente


con usuarios externos que provean y carguen las listas de pre-inscritos automáticamente
por Internet y de esta manera eliminar la necesidad de procesar listas de pre-inscritos
internamente.

Desarrollar la funcionalidad necesaria para que la aplicación pueda manejar el Hos-


pedaje de los participante del Evento, ya que en la empresa es un proceso altamente
interconectado al de registro.
Bibliografı́a

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-view-


controller (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, Cali-
fornia: 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 , 21–32.

Haack, P. (2011). Professional ASP.NET MVC 3 . Indianapolis, IN, USA: Wrox.

Jazayeri, M. (2007). Some trends in web application development. In FOSE’07 , (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:
O’Reilly 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 Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Apéndice A

Aplicación Sistema de Registro de Participantes 6 (SRP6)


Visión de la Aplicación

Versión 1.1
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Historia de Revisión

Fecha Versión Descripción Autor(es)


14/08/2011 1.0 Versión Inicial Carlos Gustavo Sarmiento
17/08/2011 1.1 Eliminación de renglones de información superfluos en el Carlos Gustavo Sarmiento
documento (stakeholders repetidos, requerimientos
modificados)
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Propósito: 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
aplicación, las necesidades de cada uno de ellos así como las razones que justifican dichas necesidades. Adicionalmente,
contiene las características de la aplicación, incluyendo restricciones y criterios de aceptación aplicables al caso.

VS. 1 Nombre de la Aplicación


Sistema de Registro de Participantes 6

VS. 2 Posicionamiento

El problema de El alto volumen de participantes a


registrar en los Eventos Médicos
organizados por la Compañía.
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 solución exitosa Registría los datos concernientes a
los asistentes a un evento y los
ingresos relacionados con las
inscripciones a un evento.
Generaría el material impreso de los
asistentes personalizándolo a los
diseños particulares de cada evento.

El problema de La carga manual de la información


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 Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Los participantes en el evento.


Cuyo impacto es Las empresas patrocinantes pueden
llegar a registrar a más del 70% de
los participantes en un evento.
Una solución exitosa Procesaría las listas de pre-inscritos
que provean las casas comerciales
que participan en el evento.

El problema de No poder ofrecer información


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.
Cuyo impacto es Si no es posible realizar reportes con
información agregada de la
participación en el evento, se limita
significativamente la utilidad de
llevar un registro de los participantes
que asisten al evento.
Una solución exitosa Prepararía las estadísticas asociadas
a las diferentes participaciones
existentes en el evento (por ciudad,
profesión, tipo de participante,
forma de pago, entre otros).

El problema de No tener control monetario de los


ingresos que se generan por la
inscripción 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.
Cuyo impacto es Un registro financiero claro y
detallado es necesario para ofrecer
resultados económicos claros del
evento a los clientes
Una solución exitosa Proveería un resumen de la
participación que se obtuvo en el
evento (estado financiero de
2
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

inscripción, total participación por


casa comercial, por profesión, entre
otros).

Para El personal de Organización de


Eventos, la Gerencia de Productos y
los Operadores en el área de
Inscripciones.
Quién(es) Requieren mecanismos para
automatizar el registro de los
participantes en los eventos de la
Compañía
SRP6 Es la Aplicación 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 personalizándolo a los
diseños particulares de cada evento.
Preparar las estadísticas asociadas a
las diferentes participaciones
existentes en el evento (por ciudad,
profesión, tipo de participante,
forma de pago, entre otros).
Proveer un resumen de la
participación que se obtuvo en el
evento (estado financiero de
inscripción, total participación por
casa comercial, por profesión, entre
otros).
Se diferencia de SRP4
Nuestra Aplicación Ofrece una infraestructura web
capaz de soportar las operaciones
en cualquier plataforma con acceso
a Internet.
Esta construido utilizando
tecnologías modernas que lo hacen
más mantenible y eficiente.
Se adapta a las nuevas necesidades
de la empresa y sus planes de
crecimiento.

3
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

VS. 3 Descripción de los Stakeholders y Usuarios

Representatividad Carlos Sarmiento – Pasante


Categoría Desarrollador
Tipo Desarrollador de Software
Responsabilidad Diseñar, Construir y Probar el sistema.
Criterios de Éxito El sistema cumple con todas las especificaciones
definidas para el proyecto.
Nivel de Desarrolla el software. Realiza mantenimiento del
participación sistema.
Entregables Software y Documentación
Comentarios / otros
aspectos

Representatividad Nelliana Acuña – VP de Productos


Categoría Promotor
Tipo Gurú de Negocio
Responsabilidad Determina los requerimientos de la aplicación y
determina el cumplimiento de los requisitos
Criterios de Éxito La aplicación permite llevar a cabo un registro eficiente
de los participantes en el Evento.
La aplicación ofrece mecanismos para realizar reportes
sobre la información almacenada en el mismo.
Nivel de Revisa los requerimientos del sistema. Ofrece
participación información acerca de la realidad del negocio.
Entregables Ninguno
Comentarios / otros
aspectos

Representatividad Isbhet Muñoz – Gerente de Eventos


Categoría Administrador
Tipo Gurú de Negocio y Experto Técnico
Responsabilidad Apoyar en el desarrollo de la solución técnica para los
problemas planteados en los requerimientos. Ayudar a
convertir los requerimientos en soluciones técnicas
Criterios de Éxito No Aplica
Nivel de Soporte en el desarrollo de las soluciones técnicas del
participación sistema. Proveer experiencia en el uso de las
herramientas de desarrollo.
Entregables Ninguno

4
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Comentarios / otros
aspectos

Representatividad Marco Calabrese


Categoría Usuario
Tipo Operador del Sistema
Responsabilidad Proveer feedback en relación al funcionamiento del
sistema y su facilidad de uso por parte de los operadores
en un Evento.
Criterios de Éxito La aplicación permite llevar a cabo un registro eficiente
de los participantes en el Evento.
La aplicación ofrece mecanismos para realizar reportes
sobre la información almacenada en el mismo.
La aplicación es Fácil de Usar y Eficiente.
Nivel de Revisa los requerimientos del sistema. Ofrece
participación información acerca de la realidad del negocio.
Entregables Ninguno
Comentarios / otros
aspectos

Tabla de Necesidades

Necesidad Prioridad del Problema que Solución Actual Soluciones


Negocio origina la Propuestas
necesidad
Se requiere registrar los 1 Registrar a los El sistema SRP4 La aplicación debe
datos concernientes a participantes ofrece una ofrecer una Interfaz
los asistentes a un en los Eventos funcionalidad similar. Web para registrar
evento y los ingresos Médicos Cuando el sistema no los datos
relacionados con las organizados está operativo se concernientes a los
inscripciones a un por la utiliza Excel asistentes a un
evento. Compañía. evento y generar los
imprimibles
necesarios.
Se requiere que las 5 El proceso al El sistema SRP4 La aplicación debe
actividades que realice que la ofrece una seguir los estándares
la aplicación sean aplicación funcionalidad webs mínimos de
seguras y confiables soporta es un insuficiente de seguridad y
proceso crítico seguridad y confiabilidad.
del negocio. confiabilidad
Se requiere procesar las 4 Registrar de La carga de la La aplicación debe
listas de pre-inscritos forma masiva o información se ofrecer una Interfaz
que provean las casas en lote las listas realiza manualmente, Web a la cual se
comerciales que de participante por suban archivos en
participan en el evento. participantes participante, en SRP4 formato CSV que
provistas por sean procesados
las empresas automáticamente.
5
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

patrocinantes
Se requiere preparar las 2 Ofrecer SRP4 ofrece una La aplicación debe
estadísticas asociadas a información herramienta que ofrecer una Interfaz
las diferentes agregada exporta la Web la cual permita
participaciones acerca de los información del generar reportes
existentes en el evento participantes evento a Excel. La agregando la
(por ciudad, profesión, en un Evento. agregación y el información
tipo de participante, análisis de la deseada.
forma de pago, entre información se
otros). realizan
manualmente.
Se requiere proveer un 3 Llevar un Se utilizan los La aplicación debe
resumen de la control mecanismos ofrecer la capacidad
participación que se monetario de existentes en SRP4 de generar Reportes
obtuvo en el evento los ingresos para el manejo de los de Caja, de Ingresos
(estado financiero de que se generan Pagos y otra y Balances del
inscripción, total por la información evento.
participación por casa inscripción de relacionada, aunque
comercial, por participantes son insuficientes.
profesión, entre otros). en el evento.
VS.4 Descripción de la Aplicación
La aplicación es un sistema de información Web, que va a ser utilizado en computadoras con ambiente Windows para la
realización del registro de participantes en un evento organizado por la Compañía. La aplicación debe permitir el registro
de participantes, la generación de material imprimible personalizado, la generación de reportes. Actualmente la
aplicación no se intercomunica con ningún otro sistema de la empresa, aunque la posibilidad debe considerarse en la
ejecución 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 aplicación debe ser una computadora portátil comercial u otra computadora de tamaño
y peso pequeño.
VS.6 Requerimientos de Documentación.
Se deberá desarrollar un manual de usuario para el entrenamiento de los nuevos usuarios.
Un manual del procedimiento de instalación del sistema en el computador servidor.
VS.7 Glosario de la Aplicación.

Término Definición
SRP6 Sistema de Registro de Participantes 6.
Versión actualmente utilizada por la empresa para el registro de los
SRP4
participantes. El objetivo del proyecto es reemplazar esta aplicación.
Una persona que se registra parar asistir a un evento organizado por
Participante
la Empresa.
Empleado de la compañía que se encarga de cargar la información
Operador
de uno o más participantes en el sistema.
Cliente La organización que contrata a la empresa para organizar el Evento.
La persona de la compañía responsable de la organización completa
Organizador
del evento.

6
Apéndice B

Aplicación Sistema de Registro de Participantes 6


Especificación de Requerimientos de la Aplicación

Versión 1.0
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Historia de Revisión

Fecha Versión Descripción Autor(es)


07/09/2011 1.0 Versión Inicial Carlos Gustavo Sarmiento
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Propósito: Este documento detalla los requerimientos de software para la aplicación Sistema de Registro de Participantes 6,
según 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 información establece los lineamientos y las
restricciones que debe considerar el equipo de desarrollo del proyecto para el desarrollo de la aplicación.

ERS. 1 Nombre de la Aplicación.

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 Nombre del Caso de Uso Actor(es)
1 Iniciar Sesión Operador
2 Cerrar Sesión Operador
3 Cambiar Clave Operador
4 Crear Participante Operador
5 Modificar Participante Operador
6 Eliminar Participante Operador
7 Asignar Especialidad a Participante Operador
8 Eliminar Especialidad de Participante Operador
9 Buscar Por Nombre Participante Operador
10 Buscar Por Cedula Participante Operador
11 Modificar Participación Operador
12 Eliminar Participación Operador
13 Imprimir Material Operador
14 Crear Transacción Operador
15 Agregar Concepto a Transacción Operador
16 Eliminar Concepto de Transacción Operador
17 Agregar Pago a Transacción Operador
18 Eliminar Pago de Transacción Operador
19 Modificar Pago de Transacción Operador
20 Cerrar Transacción Operador
21 Anular Transacción Operador
22 Crear Forma de Pago Administrador
23 Modificar Forma de Pago Administrador
24 Eliminar Forma de Pago Administrador
25 Ver Forma de Pago Administrador
26 Agregar Detalle Administrador
27 Eliminar Detalle Administrador
28 Crear País Administrador
29 Modificar País Administrador
30 Eliminar País Administrador
31 Ver País Administrador
32 Crear Estados Administrador
33 Modificar Estados Administrador
34 Eliminar Estados Administrador
35 Ver Estados Administrador
36 Crear Ciudades Administrador
37 Modificar Ciudades Administrador

1
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

38 Eliminar Ciudades Administrador


39 Ver Ciudades Administrador
40 Generar Reporte Caja XML Administrador
41 Generar Reporte Caja xlsx Administrador
42 Generar Reporte Caja csv Administrador
43 Generar Reporte Inscritos XML Administrador
44 Generar Reporte Inscritos xlsx Administrador
45 Generar Reporte Inscritos csv Administrador
46 Generar Reporte Ingresos XML Administrador
47 Generar Reporte Ingresos xlsx Administrador
48 Generar Reporte Ingresos csv Administrador
49 Crear Eventos Administrador
50 Modificar Eventos Administrador
51 Eliminar Eventos Administrador
52 Ver Eventos Administrador
53 Crear Tipos de Participantes Administrador
54 Modificar Tipos de Participantes Administrador
55 Eliminar Tipos de Participantes Administrador
56 Ver Tipos de Participantes Administrador
57 Crear Conceptos Administrador
58 Modificar Conceptos Administrador
59 Eliminar Conceptos Administrador
60 Ver Conceptos Administrador
61 Crear Especialidades Administrador
62 Modificar Especialidades Administrador
63 Eliminar Especialidades Administrador
64 Ver Especialidades Administrador
65 Crear Profesiones Administrador
66 Modificar Profesiones Administrador
67 Eliminar Profesiones Administrador
68 Ver Profesiones Administrador

2
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ERS.2.2. Diagrama de Caso de Uso

3
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ERS.2.3. Especificaciones de Casos de Uso


ID del Caso de uso Nombre del Caso de Uso:
1 Iniciar Sesión
Descripción
El actor inicia sesión en el sistema
Pre-condición
El actor no se encuentra logeado al sistema
Flujo
1. El actor accesa a la dirección web del sistema
2. El actor introduce su usuario, su clave y presiona el botón de "Entrar"
3. La aplicación valida el usuario y la clave provistas.
4a. Si la validación es exitosa: El actor es transferido a la página de inicio del sistema
4b. Si la validación falla: El actor es transferido de vuelta a la página de login del sistema.
Post-condición
El actor se encuentra logeado al sistema

ID del Caso de uso Nombre del Caso de Uso:


2 Cerrar Sesión
Descripción
El actor cierra su sesión en el sistema
Pre-condición
El actor se encuentra logeado al sistema
Flujo
1. El actor presiona el link de "Cerrar Sesión"
2. El sistema destruye la información de sesión del actor.
3. El actor es transferido a la página de login del sistema
Post-condición
El actor no se encuentra logeado al sistema

ID del Caso de uso Nombre del Caso de Uso:


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

4
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ID del Caso de uso Nombre del Caso de Uso:


4 Crear Participante
Descripción
El actor desea agregar un nuevo participante al sistema
Pre-condición
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-condición
El Participante nuevo existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


5 Modificar Participante
Descripción
El actor desea modificar un participante
Pre-condición
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-condición
El Participante tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


6 Eliminar Participante
Descripción
El actor desea eliminar un participante
Pre-condición
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-condición
El Participante no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:

5
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

7 Asignar Especialidad a Participante


Descripción
El actor desea agregar una especialidad a un Participante
Pre-condición
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 botón "Agregar"
3. El sistema agrega al participante la especialidad en la Base de Datos.
4. La información de las especialidades es actualizada en la interfaz del usuario
Post-condición
El participante tiene la especialidad asociada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


8 Eliminar Especialidad de Participante
Descripción
El actor desea eliminar una especialidad de un Participante
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista del Participante
Flujo
1. El actor presiona el botón eliminar Especialidad
2. El sistema elimina la especialidad del participante en la Base de Datos.
3. La información de las especialidades es actualizada en la interfaz del usuario
Post-condición
El participante no tiene la especialidad asociada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


9 Buscar Por Nombre Participante
Descripción
El actor desea Buscar un Participante utilizando su nombre como criterio de búsqueda
Pre-condición
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 botón Buscar
3. El sistema consulta en la base de datos todos los nombres que cumplan con el criterio de búsqueda.
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-condición

6
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ID del Caso de uso Nombre del Caso de Uso:


10 Buscar Por Cedula Participante
Descripción
El actor desea Buscar un Participante utilizando su Cedula como criterio de búsqueda
Pre-condición
El actor se encuentra logeado al sistema
Flujo
1. El actor introduce la Cédula del Participante en el Campo "Buscar"
2. El actor presiona el botón Buscar
3. El sistema consulta en la base de datos todas los cédulas que cumplan con el criterio de búsqueda.
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-condición

ID del Caso de uso Nombre del Caso de Uso:


11 Modificar Participacion
Descripción
El actor desea modificar un participante
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Participación
Flujo
1. El actor modifica los campos que desea de la Participación
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro de la participación en la Base de Datos.
Post-condición
El Participación tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


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

7
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ID del Caso de uso Nombre del Caso de Uso:


13 Imprimir Material
Descripción
El actor desea imprimir el material de un Participante en el Evento
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Participación
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 automáticamente
Post-condición
El material se encuentra impreso

ID del Caso de uso Nombre del Caso de Uso:


14 Crear Transacción
Descripción
El actor desea agregar una nueva transacción al sistema
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
Flujo
1. El actor presiona el link de "Agregar Transacción"
3. El sistema crea el registro de la transacción en la Base de Datos.
4. La vista de Transacción se actualiza para mostrar la nueva transacción
Post-condición
La nueva transacción es creada en el sistema con el Estatus de Abierta

ID del Caso de uso Nombre del Caso de Uso:


15 Agregar Concepto a Transacción
Descripción
El actor desea agregar un Concepto a la Transacción
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
La Transacción 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 botón "Agregar"
3. El sistema agrega el concepto a la transacción en la Base de Datos.
4. La información de la transacción es actualizada en la interfaz del usuario
Post-condición
La Transacción tiene el concepto agregado en el sistema

8
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ID del Caso de uso Nombre del Caso de Uso:


16 Eliminar Concepto de Transacción
Descripción
El actor desea eliminar un Concepto de la Transacción
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
La Transacción no esta cerrada
Flujo
1. El actor presiona el botón "Eliminar Concepto"
2. El sistema elimina el concepto de la transacción en la Base de Datos.
3. La información de la transacción es actualizada en la interfaz del usuario
Post-condición
La Transacción no tiene el concepto en el sistema

ID del Caso de uso Nombre del Caso de Uso:


17 Agregar Pago a Transacción
Descripción
El actor desea agregar un Pago a la Transacción
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
La Transacción 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 botón "Agregar"
3. El actor introduce los detalles de la forma de pago (varían según la Forma de Pago)
3. El sistema agrega el pago junto con los detalles a la transacción en la Base de Datos.
4. La información de la transacción es actualizada en la interfaz del usuario
Post-condición
La Transacción tiene el pago agregado en el sistema

ID del Caso de uso Nombre del Caso de Uso:


18 Eliminar Pago de Transacción
Descripción
El actor desea eliminar un Pago de la Transacción
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
La Transacción no esta cerrada
Flujo

9
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

1. El actor presiona el botón "Eliminar Pago"


2. El sistema elimina el pago y todos los detalles asociados de la transacción en la Base de Datos.
3. La información de la transacción es actualizada en la interfaz del usuario
Post-condición
La Transacción no tiene el pago en el sistema

ID del Caso de uso Nombre del Caso de Uso:


19 Modificar Pago de Transacción
Descripción
El actor desea Modificar un Concepto a la Transacción
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
La Transacción no esta cerrada
Flujo
1. El actor modifica los detalles del pago que desea actualizar
2. El actor presiona el botón "Guardar"
3. El sistema modifica los detalles del pago en la Base de Datos.
4. La información de la transacción es actualizada en la interfaz del usuario
Post-condición
El pago contiene la nueva información provista por el actor

ID del Caso de uso Nombre del Caso de Uso:


20 Cerrar Transacción
Descripción
El actor desea cerrar la transacción
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Transacción
La Transacción no esta cerrada
Flujo
1. El actor presiona el Botón Cerrar Transacción
2. El sistema modifica la información de la trasacción en la Base de Datos para indicar que esta cerrada.
3. Se actualiza la interfaz de usuario para indicar que la trasacción esta cerrada.
Post-condición
La transacción esta cerrada en el sistema y es inmodificable (excepto por anulación)

ID del Caso de uso Nombre del Caso de Uso:


21 Anular Transacción
Descripción
El actor desea anular la transacción
Pre-condición

10
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

El actor se encuentra logeado al sistema


El actor esta el la vista de Transacción
Flujo
1. El actor presiona el Botón "Anular Transacción"
2. El sistema modifica la información de la trasacción en la Base de Datos para indicar que esta anulada.
3. Se actualiza la interfaz de usuario para indicar que la trasacción esta anulada.
Post-condición
La transacción esta anulada en el sistema y es inmodificable

ID del Caso de uso Nombre del Caso de Uso:


22 Crear Forma de Pago
Descripción
El actor desea agregar una nueva Forma de Pago al sistema
Pre-condición
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-condición
La nueva Forma de Pago existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


23 Modificar Forma de Pago
Descripción
El actor desea modificar una Forma de Pago
Pre-condición
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-condición
La Forma de Pago tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


24 Eliminar Forma de Pago
Descripción
El actor desea eliminar una Forma de Pago
Pre-condición

11
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
La Forma de Pago no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


25 Ver Forma de Pago
Descripción
El actor desea ver una Forma de Pago
Pre-condición
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-condición

ID del Caso de uso Nombre del Caso de Uso:


26 Agregar Detalle
Descripción
El actor desea agregar un nuevo detalle a la Forma de Pago
Pre-condición
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 expresión regular para su validación
3. El sistema crea el registro del Detalle en la Base de Datos.
4. La interfaz de usuario se actualiza con la nueva información
Post-condición
El nuevo detalle se encuentra agregado a la Forma de Pago

ID del Caso de uso Nombre del Caso de Uso:


27 Eliminar Detalle
Descripción
El actor desea agregar eliminar un detalle de la Forma de Pago
Pre-condición

12
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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 información
Post-condición
El detalle ya no esta incluido en la Forma de Pago

ID del Caso de uso Nombre del Caso de Uso:


28 Crear Pais
Descripción
El actor desea agregar un nuevo País al sistema
Pre-condición
El actor se encuentra logeado al sistema
El actor esta en la Lista de Países
Flujo
1. El actor presiona el link de "Agregar País"
2. El actor introduce el Nombre del País y el código ISO del país
3. El sistema crea el registro del País en la Base de Datos.
4. El actor es transferido a la Vista del País
Post-condición
El País nuevo existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


29 Modificar Pais
Descripción
El actor desea modificar un País
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista del País
Flujo
1. El actor modifica los campos que desea del País
2. El actor presiona el link de "Guardar"
3. El sistema Modifica el registro del País en la Base de Datos.
Post-condición
El País tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


30 Eliminar Pais
Descripción
El actor desea eliminar un País
Pre-condición

13
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

El actor se encuentra logeado al sistema


El actor esta el la vista del País
Flujo
1. El actor presiona el link de "Eliminar País"
2. El sistema Elimina el registro del país en la Base de Datos.
3. El actor es transferido a la Lista de Países
Post-condición
El País no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


31 Ver Pais
Descripción
El actor desea ver un País
Pre-condición
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 Países
3. El actor hace click en el Nombre del País que desea ver
4. El actor es transferido a la Vista de País
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


32 Crear Estados
Descripción
El actor desea agregar un nuevo Estado al sistema
Pre-condición
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 País 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-condición
El Estado nuevo existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


33 Modificar Estados
Descripción
El actor desea modificar un Estado
Pre-condición

14
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
El Estado tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


34 Eliminar Estados
Descripción
El actor desea eliminar un Estado
Pre-condición
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-condición
El Estado no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


35 Ver Estados
Descripción
El actor desea ver un Estado
Pre-condición
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-condición

ID del Caso de uso Nombre del Caso de Uso:


36 Crear Ciudades
Descripción
El actor desea agregar una nueva Ciudad al sistema
Pre-condición

15
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
La nueva Ciudad existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


37 Modificar Ciudades
Descripción
El actor desea modificar una Ciudad
Pre-condición
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-condición
La Ciudad tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


38 Eliminar Ciudades
Descripción
El actor desea eliminar una Ciudad
Pre-condición
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-condición
La Ciudad no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


39 Ver Ciudades
Descripción
El actor desea ver una Ciudad
Pre-condición

16
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición

ID del Caso de uso Nombre del Caso de Uso:


40 Generar Reporte Caja xml
Descripción
El actor desea generar un reporte de la caja de un Operador en un Evento
Pre-condición
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 envía al usuario a través del explorador en formato XML
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


41 Generar Reporte Caja xlsx
Descripción
El actor desea generar un reporte de la caja de un Operador en un Evento
Pre-condición
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 envía al usuario a través del explorador en formato XLSX
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


42 Generar Reporte Caja csv
Descripción
El actor desea generar un reporte de la caja de un Operador en un Evento
Pre-condición
El actor se encuentra logeado al sistema
Flujo

17
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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 envía al usuario a través del explorador en formato CSV
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


43 Generar Reporte Inscritos xml
Descripción
El actor desea generar un reporte de todos los participantes inscritos en un evento
Pre-condición
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 envía al usuario a través del explorador en formato XML
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


44 Generar Reporte Inscritos xlsx
Descripción
El actor desea generar un reporte de todos los participantes inscritos en un evento
Pre-condición
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 envía al usuario a través del explorador en formato XLSX
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


45 Generar Reporte Inscritos csv
Descripción
El actor desea generar un reporte de todos los participantes inscritos en un evento
Pre-condición
El actor se encuentra logeado al sistema
Flujo

18
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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 envía al usuario a través del explorador en formato CSV
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


46 Generar Reporte Ingresos xml
Descripción
El actor desea generar un reporte de todos los pagos realizados en un Evento
Pre-condición
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 envía al usuario a través del explorador en formato XML
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


47 Generar Reporte Ingresos xlsx
Descripción
El actor desea generar un reporte de todos los pagos realizados en un Evento
Pre-condición
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 envía al usuario a través del explorador en formato XLSX
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


48 Generar Reporte Ingresos csv
Descripción
El actor desea generar un reporte de todos los pagos realizados en un Evento
Pre-condición
El actor se encuentra logeado al sistema
Flujo

19
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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 envía al usuario a través del explorador en formato CSV
Post-condición

ID del Caso de uso Nombre del Caso de Uso:


49 Crear Eventos
Descripción
El actor desea agregar un nuevo Evento al sistema
Pre-condición
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 País 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-condición
El Evento nuevo existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


50 Modificar Eventos
Descripción
El actor desea modificar un Evento
Pre-condición
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-condición
El Evento tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


51 Eliminar Eventos
Descripción
El actor desea eliminar un Evento
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista del Evento
Flujo
20
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
El Evento no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


52 Ver Eventos
Descripción
El actor desea ver un Evento
Pre-condición
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-condición

ID del Caso de uso Nombre del Caso de Uso:


53 Crear Tipos de Participantes
Descripción
El actor desea agregar un nuevo Tipo de Participante al sistema
Pre-condición
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 País 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-condición
El Tipo de Participante nuevo existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


54 Modificar Tipos de Participantes
Descripción
El actor desea modificar un Tipo de Participante
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista del Tipo de Participante
Flujo

21
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
El Tipo de Participante tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


55 Eliminar Tipos de Participantes
Descripción
El actor desea eliminar un Tipo de Participante
Pre-condición
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-condición
El Tipo de Participante no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


56 Ver Tipos de Participantes
Descripción
El actor desea ver un Tipo de Participante
Pre-condición
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-condición

ID del Caso de uso Nombre del Caso de Uso:


57 Crear Conceptos
Descripción
El actor desea agregar un nuevo Concepto al sistema
Pre-condición
El actor se encuentra logeado al sistema
El actor esta en la Lista de Conceptos
Flujo

22
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

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


2. El actor introduce el Nombre del Concepto y el País 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-condición
El Concepto nuevo existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


58 Modificar Conceptos
Descripción
El actor desea modificar un Concepto
Pre-condición
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-condición
El Concepto tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


59 Eliminar Conceptos
Descripción
El actor desea eliminar un Concepto
Pre-condición
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-condición
El Concepto no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


60 Ver Conceptos
Descripción
El actor desea ver un Concepto
Pre-condición
El actor se encuentra logeado al sistema
Flujo

23
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición

ID del Caso de uso Nombre del Caso de Uso:


61 Crear Especialidades
Descripción
El actor desea agregar una nueva Especialidad al sistema
Pre-condición
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-condición
La nueva Especialidad existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


62 Modificar Especialidades
Descripción
El actor desea modificar una Especialidad
Pre-condición
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-condición
La Especialidad tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


63 Eliminar Especialidades
Descripción
El actor desea eliminar una Especialidad
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Especialidad
Flujo
24
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
La Especialidad no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


64 Ver Especialidades
Descripción
El actor desea ver una Especialidad
Pre-condición
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-condición

ID del Caso de uso Nombre del Caso de Uso:


65 Crear Profesiones
Descripción
El actor desea agregar una nueva Profesion al sistema
Pre-condición
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-condición
La nueva Profesion existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


66 Modificar Profesiones
Descripción
El actor desea modificar una Profesion
Pre-condición
El actor se encuentra logeado al sistema
El actor esta el la vista de Profesion
Flujo

25
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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-condición
La Profesion tiene la nueva información almacenada en el sistema

ID del Caso de uso Nombre del Caso de Uso:


67 Eliminar Profesiones
Descripción
El actor desea eliminar una Profesion
Pre-condición
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-condición
La Profesion no existe en el sistema

ID del Caso de uso Nombre del Caso de Uso:


68 Ver Profesiones
Descripción
El actor desea ver una Profesion
Pre-condición
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-condición

ERS.3 Especificaciones Suplementarias


ERS.3.1. Usabilidad

ERS.4.1.1. Cumplimiento de las Expectativas de Aplicaciones Web


La aplicación debe cumplir con las expectativas de los usuarios al usar aplicaciones web. Esto incluye el acceso exclusivo a
través de un explorador, uso de Links como mecanismo de navegación, botones como mecanismo de ejecución de
acciones.
ERS.4.1.2. Tiempo de Aprendizaje
El sistema debe ser de fácil aprendizaje para cualquier persona con conocimiento superficial del flujo de trabajo de la
compañía. Además debe permitir a los usuarios la navegación simple a través de las opciones a la cual tienen acceso.

26
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ERS.4.2. Confiabilidad (Los requerimientos de confiabilidad de la aplicación se deben especificar aquí).

ERS.4.2.1 Integridad de la Información


El sistema debe asegurar que en todo momento la información 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 información 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 código 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 aplicación debe permitir solamente a los usuarios autenticados la realización de cualquier acción en el sistema excepto
la de Iniciar Sesión. El sistema debe además validar los credenciales presentados por los usuarios al momento de realizar
una operación.
ERS.4.5.2. Acceso a través de HTTPS
El sistema debe resguardar la seguridad de la información mientras es transferida entre el Servidor y el Cliente. Para esto,
el sistema debe utilizar la tecnología de encriptación de comunicaciones HTTPS.

ERS.4.6. Restricciones de Diseño

ERS.4.6.1. Tipo de Aplicación


La aplicación debe ser desarrollada como una aplicación web accesible a través de un explorador web usando tecnologías
web estándar (HTTP, HTML, CSS, etc.)
ERS.4.6.2. Lenguaje de Programación
El sistema debe ser programado utilizando Microsoft C# 4 con .NET 4 debido a la experiencia acumulada en la compañía
con el sistema.
ERS.4.6.2. Librería de Desarrollo Web
La aplicación 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 programación escogido.
ERS.4.6.4. Librería de Acceso a la Base de Datos
La librería de acceso al manejador de base de datos será .NET Entity Framework 4.2. No se permitirán conexiones directas
a la base de datos.
ERS.4.6.5. Entorno de Ejecución
El entorno de ejecución debe ser Windows 7 con IIS 7.5. La compañía 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 aplicación no utiliza ningún componente comprado específicamente para la misma. Los componentes comprados son
licencias adquiridas por la empresa para el desarrollo general de sus tareas.

27
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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 ningún participante”
ERS.4.9.1.5 Vista de Participación

28
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ERS.4.9.1.6 Vista de Transacción

ERS.4.9.1.7 Vista de Forma de Pago

ERS.4.9.1.8 Lista de Formas de Pago

29
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
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
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ERS.4.9.1.18 Vista de Profesión

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 aplicación de la empresa, el software no interactúa con ningún componente externo a este ERS.
En el caso de la conexión con los sistemas de base de datos, la interfaz es manejada por la librería .NET Entity Framework
4.2, por lo cual la especificación de la interfaz esta fuera del alcance de este ERS.

32
Especificación de Requerimientos de la Aplicación Fecha: 07/09/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

ERS.4.9.4. Interfaces de Comunicaciones


Todas las interfaces de comunicaciones usadas por el Sistema son implementadas por la librería de desarrollo web (ASP.NET
MVC 3.5), el entorno de ejecución (.NET 4) y el sistema operativo (Windows 7)

33
Apéndice C

Aplicación Sistema de Registro de Participantes 6


Documento de Arquitectura de la Aplicación

Versión 1.0
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Historia de Revisión

Fecha Versión Descripción Autor(es)


13/09/2011 1.0 Versión Inicial Carlos Gustavo Sarmiento
19/09/2011 2.0 Cambios a los diagramas Casos de Uso, Entidad- Carlos Gustavo Sarmiento
Relación y Despliegue
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Propósito: Este documento proporciona una descripción arquitectónica de la aplicación Sistema de Registro de Participantes 6,
usando un número de diversas vistas para representar diferentes aspectos de la aplicación, el cual esta destinado para las
personas que se encargaran de implementar la arquitectura que se plantea en este documento, mostrándose de forma
comprensible para los lectores.
DAS. 1 Nombre de la Aplicación.
Sistema de Registro de Participantes V.6
DAS. 2 Representación 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 Lógica
DAS.4.1. Modelos de Dominio.
DAS.4.2. Elementos arquitectónicamente significativos
DAS.5.1. Diagrama de Clases
DAS.5 Vista de Implementación
DAS.5.2. Diagrama de Componentes
DAS.6 Visa de Implantación
DAS.6.1. Diagrama de Implantación
DAS.7 Vista de Datos
DAS.7.1. Modelo Entidad-Relación.

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

1
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

DAS.3.3 Diagrama de Secuencia por Caso de Uso


Ver Forma de Pago

Ver País

2
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Ver Profesión

Ver Tipo de Participante

3
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Agregar Concepto

4
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Agregar Detalle a Forma de Pago

5
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Agregar Pago

Anular Transacción

6
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Agregar Especialidad

7
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Buscar Participante por Cédula

Buscar Participante por Nombre

8
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Cambiar Clave

Cerrar Sesión

9
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Cerrar Transacción

Iniciar Sesión

10
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Ciudad

11
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Concepto

12
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Especialidad

13
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Estado

14
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Evento

15
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Forma de Pago

16
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear País

17
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Participante

18
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Ciudad

19
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Tipo de Participante

20
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Crear Transacción

Eliminar Ciudad

21
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Concepto de Transacción

Eliminar Concepto

22
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Detalle

Eliminar Especialidad de Participante

23
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Especialidad

Eliminar Estado

24
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Evento

Eliminar Forma de Pago

25
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Pago de Transacción

Eliminar País

26
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Participación

Eliminar Participante

27
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Eliminar Profesión

Generar Reporte de Caja en CSV

28
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Generar Reporte de Caja en XML

Generar Reporte de Ingresos en XML

29
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Generar Reporte de Ingresos en XLSX

Generar Reporte de Inscritos en XLSX

30
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Ciudad

31
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Concepto

32
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Especialidad

33
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Estado

34
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Evento

35
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Forma de Pago

36
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar País

37
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Participante

38
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Ciudad

39
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Modificar Tipo de Participante

Ver Ciudad

40
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Ver Concepto

Ver Especialidad

41
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

Ver Estado

Ver Evento

42
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

DAS.4 Vista Lógica

DAS.4.1 Modelo de Dominio

DAS.4.2 Elementos arquitectónicamente significativos


Los elementos significativos en el desarrollo de la aplicación 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 Implementación

43
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

DAS.5.1. Diagrama de Clases

DAS.5.2 Diagrama de Componentes

44
Documento de Arquitectura de la Aplicación (Forma DAS) Fecha: 13/09/2011
Nombre de la Aplicación: Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6

DAS. 6 Vista de Implantación.

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 estándar de la
industria para comunicaciones seguras. En el aspecto de confiabilidad, la combinación 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-Relación

45

Você também pode gostar