Escolar Documentos
Profissional Documentos
Cultura Documentos
Por:
CARLOS GUSTAVO SARMIENTO
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
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 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
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.
Cada cambio al sistema debe ser desplegado a más de quince (15) computadoras.
2
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
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.
1.5. Estructura
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.
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
1
Pequeña o Mediana Empresa
2
Entrevista con Tutor Académico
6
2.1.1. Eventos
2.1.2. Productos
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.
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.
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.
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 .
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.
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).
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).
Cuadro 3.1: Explicación de las capas en una Arquitectura de 3 Capas (Fowler, 2003)
4
También conocida como Aplicación
12
a un Controlador o Vista inferior. De esta manera se evita la complejización del código del
sistema.
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.
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).
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.
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
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.
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
2
Cuyo principal entregable es el Documento de Arquitectura de Software (DAS).
20
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
Requerimientos
Arquitectura
Desarrollo
Pruebas
Manejo de Proyectos
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:
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.
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
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.
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
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
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.
1ra Iteración de
10 dı́as Programar la funcionalidad mı́nima para ejecutar el sistema.
Construcción
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
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.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 de forma masiva o en lote las listas de participantes provistas por las empresas
patrocinantes
Llevar un control monetario de los ingresos que se generan por la inscripción de parti-
cipantes en el evento.
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.
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
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.
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.
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.
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.
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.
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.
Servidor HTTP y HTTPS que transmite las páginas web que componen el sistema.
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.
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.
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
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.1. Iteración 1
3 Cambiar Clave
7.1.2. Iteración 2
68 Ver Profesiones
7.1.3. Iteración 3
ID Nombre del CU
7.1.4. Iteración 4
ID Nombre del CU
13 Imprimir Material
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.
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.
Conclusiones y Recomendaciones
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
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.
Brown, L. (2003). Enterprise Java programming with IBM WebSphere. Boston, Mass:
Addison-Wesley.
Davidson, D., James D.; Cowards (1999). Java Servlet Specification, v2.2 . Palo Alto, Cali-
fornia: Sun Microsystems.
Gustafsson, B. (2008). Openup - the best of two worlds. Methods and Tools, 16 , 21–32.
Jazayeri, M. (2007). Some trends in web application development. In FOSE’07 , (pp. 199–
213).
Lerman, J. (2011). Programming Entity Framework: Code First. Sebastopol, CA, USA:
O’Reilly Media.
59
Rankins, R. (2010). Microsoft SQL Server 2008 R2 Unleashed . Boston, MA, USA: Pearson
Education, Inc.
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
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
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. 2 Posicionamiento
3
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6
4
Documento de Visión Fecha: 17/08/2011
Sistema de Registro de Participantes 6 Siglas de la Aplicación:
SRP6
Comentarios / otros
aspectos
Tabla de Necesidades
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.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
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
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
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
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
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
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
33
Apéndice C
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
• 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.
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
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
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
45