6

CAPITULO 1
INTRODUCCION
7
1.1. METODOLOGA DE DESARROLLO DE SOFTWARE
1.1.1. DEFINICIN
Las metodologas de software son procedimientos, formas, guas para la
documentacin y desarrollo del software, aqu se describen los pasos, tareas y
procedimientos de una forma detallada; que se deben seguir para cada una de las
actividades para la elaboracin de un producto de software.
Esto incluye la implementacin de modelos, grficos junto con los procedimientos
detallados, donde cada uno de los procedimientos puede ser utilizado en varias
actividades. Se describen los modelos grficos que deben ser producidos, las reglas o
restricciones que debe cumplir el sistema, las recomendaciones para una buena
prctica de diseo y guas de procesos que se debe seguir para cada actividad.
1.1.2. FASES
La metodologa presenta ciertas fases o tareas que se requiere llevar a cabo:
1.1.2.1 ANLISIS DE REQUISITOS
En esta etapa se analizan y extraen cada uno de los requisitos que se necesitan para la
elaboracin del producto de software, aqu se establece los servicios y restricciones
que el usuario requiere del sistema.
Todos lo requerimientos son generados durante el proceso de anlisis de
requerimientos. Los resultados del anlisis de requerimientos se guardan en un
documento ERS (Especificacin de Requerimientos del Sistema), se realiza un
diagrama de Entidad/Relacin, donde se definen las entidades que participarn en el
desarrollo del software.
8
1.1.2.2. ESPECIFICACIN
Es la representacin del sistema en un documento ms tcnico, donde se establecen
las caractersticas, materiales y los servicios necesarios para la elaboracin del
producto de software. Dentro del documento intervienen los requerimientos
necesarios para la obtencin exitosa y medicin de calidad del producto.
1.1.2.3. DISEO Y ARQUITECTURA
En la fase de diseo se pretende esquematizar un sistema que, satisfaga las
especificaciones, se ajuste a las limitaciones y cumpla con los requerimientos
establecidos.
Dentro del diseo y arquitectura tenemos:
x Diseo de datos:
Modelo de informacin de la estructuras de datos.
x Diseo arquitectnico:
Define relaciones entre elementos estructurales del sistema.
x Diseo procedimental:
Se transforman los elementos estructurales del sistema en una
descripcin procedimental del software
x Diseo de interfaz:
Describe cmo se comunica el software consigo mismo y con su
entorno.
Es un documento que presenta modelos grficos como:
x Modelos de caso de uso
x Modelo entidad-relacin-atributo
9
x Modelos de objetos
x Modelo de flujo de datos
x Modelo estructural
1.1.2.4. PROGRAMACIN
Es traducir el diseo a cdigo fuente. Esta es una actividad personal ya que no existe
una estndar sobre cmo programar; es crear cada uno de los mdulos y probarlos.
1.1.2.5. PRUEBAS
En esta fase se realiza pruebas de integracin y validacin, para la comprobacin del
correcto funcionamiento de cada una de las tareas que se indican en las
especificaciones.
Las pruebas del sistema involucran la ejecucin del sistema, con casos de prueba
que se derivan de la especificacin de los datos reales procesados por el mismo. Con
el proceso de pruebas se eliminan errores y falencias de la solucin informtica, y lo
que se obtiene a la salida de esta fase es una aplicacin completa y lista para usarse.
1.1.2.6. DOCUMENTACIN
En esta fase lo que se pretende, es la realizacin de manuales de usuario, manuales
tcnicos, y documentacin de cdigo fuente, con el propsito de mantener y
evolucionar del sistema.
1.1.2.7. MANTENIMIENTO
En esta fase se realiza un proceso de mejoramiento y optimizacin del software, con
descubrimientos de errores y nuevos requisitos.
La fase de mantenimiento de software involucra cambios al software en orden de
corregir defectos y dependencias encontradas durante su uso, como la adicin de
nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software.
10
1.1.3. CLASIFICACION
1.1.3.1. MODELOS O PARADIGMAS DE DESARROLLO
1.1.3.1.1. MODELO EN CASCADA
Este modelo divide en etapas al ciclo de vida del software, de forma que para iniciar
la siguiente etapa se debe esperar la finalizacin de la etapa anterior.
El modelo en cascada se divide en las siguientes etapas:
x Anlisis de Requisitos
x Diseo del Sistema
x Diseo del Programa
x Codificacin
x Pruebas
x Implantacin
x Mantenimiento
De tal forma que si un error es detectado en cualquier etapa obliga a un rediseo y
una nueva programacin de las actividades, aumentado los costes del desarrollo.
1.1.3.1.2. MODELO EN ESPIRAL
Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de
construccin de prototipos con los aspectos controlados y sistemticos del modelo
lineal y secuencial.
Durante este proceso se implementan varias versiones incrementales. Durante las
ltimas iteraciones se producen versiones mas completas del sistema, se reduce los
riesgos, se incorporan objetivos de calidad, y pueden aparecer nuevos
requerimientos.
El modelo en espiral se divide en cuatro tareas las cuales deben cumplir cada una de
las siguientes actividades:
11
x Determinar objetivos
- Obtener requerimientos, especificaciones, manual de usuario.
- Fijar las restricciones.
- Identificacin de riesgos y estrategias para evitarlos en el proyecto.
- Planificacin inicial o previa.
x Anlisis del riesgo
- Se establecen los riesgos potenciales y las alternativas propuestas para
reducir o eliminar los riesgos.
x Desarrollar, verificar y validar
- Pruebas del sistema y correccin.
- Despus de la evaluacin de los riesgos, se elige un modelo para el
desarrollo.
- Se revisa lo realizado, se evala, y se decide si se contina con la
siguiente actividad.
1.1.3.1.3. MODELO DE PROTOTIPOS
Se definen los objetivos, se identifican los requisitos y el esquema donde sea
necesaria ms definicin.
Se basa en la construccin rpida de un prototipo del sistema. ste se evala por el
usuario final y se identifican nuevos requerimientos o correccin de errores. Este
proceso permite obtener una retroalimentacin que gracias a sta se refinan los
requisitos del software que se desarrollar.
12
1.1.3.1.4. MTODO EN V
Se describe las actividades y los resultados en el proceso de desarrollo del software.
El Mtodo-V representa grficamente el ciclo de vida del desarrollo del sistema (ver
Figura 1.1).
Resume los pasos principales que hay que tomar en conjuncin con las
correspondientes entregas de los sistemas de validacin.
Requerimientos
Diseo del
Sistema
Diseo del
Software
Cdigo
Verificacin del
Software
Verificacin del
Sistema
Validacin del
Sistema
Validacin de
Requerimientos
Verificacin del
Diseo
Figura 1.1
La parte izquierda de la V definen las especificaciones del sistema. La parte derecha
de la V define las validaciones y comprobaciones del sistema. La interseccin de la
V, representa la corriente de desarrollo.
La definicin de especificacin consiste en:
x Especificaciones de requerimientos de usuario
x Especificaciones funcionales
x Especificaciones de diseo
La fase de pruebas consiste en:
x Calificacin de instalacin
x Calificacin operacional
x Calificacin de rendimiento
13
La fase de desarrollo puede consistir en personalizacin, configuracin o
codificacin.
1.1.3.1.5. DESARROLLO POR ETAPAS
El Desarrollo en Etapas es similar al modelo de prototipos ya que presenta al usuario
una serie de estados de prototipos de desarrollo, la definicin de especificaciones no
se las realiza al inicio del proyecto, sino que se va desarrollando simultneamente
con las diversas versiones del cdigo.
Pueden distinguirse las siguientes fases:
x Especificacin conceptual
x Anlisis de requerimientos
x Diseo inicial
x Diseo detallado, codificacin, depuracin y liberacin
Estas diferentes fases se van repitiendo en cada etapa del diseo.
1.1.3.2. METODOLOGAS GILES
Se basa en procesos giles para el desarrollo de software. Los procesos giles son
metodologas livianas que pretenden evitar las metodologas tradicionales.
En esta metodologa el usuario es el factor principal del xito del software.
Propone que exista una interrelacin entre el usuario y el equipo de desarrollo, donde
la colaboracin ser lo que marque el xito del proyecto.
Las metodologas giles tratan de responder a los cambios que surjan a largo del
proyecto mas que seguir un plan estricto, por lo tanto los planes deben ser flexibles y
abiertos.
Los principios que se aplican en esta metodologa, van a aumentar la productividad
y rentabilidad del proceso de produccin de software y son los siguientes:
14
x Eliminar desperdicios
x Ampliar el aprendizaje
x Decidir lo ms tarde posible
x Entregar lo ms rpido posible
x Potenciar al equipo de trabajo
x Construir pensando en la integridad del software
x Ver el todo
1.1.3.2.1. PROGRAMACIN EXTREMA (XP)
La metodologa XP se basa en la interrelacin entre el usuario y el equipo de
desarrollo, para una realimentacin continua, se mantiene una comunicacin fluida
entre todos los participantes, se presta para enfrentar los cambios e implementar de
soluciones continuas.
Se cree que, adaptarse a los cambios de requisitos del sistema, es mejor y ms
realista que intentar definir todos los requisitos al comienzo del proyecto y despus
invertir esfuerzos en controlar los cambios en los requisitos.
1.1.3.2.2. SCRUM
Es una metodologa que se adapta a proyectos que requieren cambios de requisitos
rpidos, se basa en iteraciones denominadas sprints cada una con duracin de 30
das, la culminacin de cada sprint se muestra al cliente y es un incremento
ejecutable. La caracterstica es una reunin diaria de 15 minutos del equipo para
coordinacin e integracin.
1.1.3.2.3. CRISTAL
La metodologa cristal se centra en la importancia de las personas, las cuales
componen el equipo de desarrollo del proyecto, se considera como un juego de
cooperacin, invencin y comunicacin, donde se establecen polticas de trabajo en
equipo.
15
1.1.3.2.4. FEATURE DRIVEN DEVELOPMENT (FDD)
Esta metodologa se define como un proceso de 5 pasos en iteraciones, donde cada
una de las iteraciones culmina en 2 semanas. Se centra en las fases de diseo e
implementacin partiendo de las caractersticas que debe cumplir el software.
1.1.3.2.5. ADAPTIVE SOFTWARE DEVELOPMENT(ASD)
Esta metodologa se basa en iteraciones, orientada a los componentes de software y
es capaz de adoptar los cambios. El ciclo de vida se divide en tres fases:
x Especulacin: se planifica y especifican las caractersticas del software.
x Colaboracin: se desarrollan las caractersticas.
x Aprendizaje: se realiza la validacin y verificacin de calidad y se entrega al
cliente.
1.1.3.2.6. LEAN DEVELOPMENT (LD)
Es un conjunto de herramientas para la administracin de desarrollo de software,
donde los cambios se consideran como mejoras y se pueden transformar en
oportunidades para mejorar la productividad del usuario, Lean Development se
caracteriza por implementar mecanismos para dichos cambios.
16
1.2. METODOLOGIA DE DESARROLLO DE SOFTWARE RUP
1.2.1. DEFINICION
RUP (Rational Unified Process), es un metodologa de desarrollo de software que,
junto a UML(Unified Modeling Language), colabora para el desarrollo del anlisis,
diseo, implementacin y documentacin de sistemas orientados a objetos.
La metodologa RUP se adapta a la necesidad que presente la Organizacin y es un
proceso que define las actividades, roles, responsabilidades, productos de trabajo y
herramientas para organizar las tareas y sus ejecuciones as como el momento en
que se realizan.
RUP fue creado por Rational Software Corporation que desde el 2003 pertenece a
IBM. Los creadores y diseadores de esta metodologa se enfocaron en los fallos o
errores cometidos en diferentes proyectos de software y se enfocaron en la raz de las
causas de dichos problemas.
A continuacin se presentan algunos de los errores ms comunes en el desarrollo de
software:
x Administracin Ad-Hoc de requerimientos
x Comunicacin ambigua e imprecisa.
x Arquitectura inestable
x Inconsistencia indetectable en requerimientos, diseo e implementacin
x Pruebas del Sistema incompletas
x Evaluacin subjetiva del estado del proyecto
x Fallos en eliminacin de riesgos
La combinacin de estos errores es comn en proyectos que no siguen una
metodologa enfocada en buenas prcticas, como lo es RUP.
17
Principios
RUP se basa en un conjunto de 6 principios de desarrollo, que son los siguientes:
x Adaptar el proceso: Un proyecto u organizacin debe adaptar el tamao del
proceso a su necesidad. Tambin influye el alcance del proyecto y sus
regulaciones.
x Balancear prioridades: Se debe ver en que medida se toma los objetivos del
negocio, las necesidades de los interesados y llegar a un balance entre las
partes involucradas.
x Colaboracin por medio de equipos: Existe una creciente demanda de
desarrollo de software distribuido, con las actuales herramientas de
comunicacin. La colaboracin incluye en necesidades, pruebas, cifras, etc.
x Demostrar valor iterativamente: Los proyectos se deben presentar en cada
iteracin, as sea dentro del equipo de desarrollo, para refinarlo y comenzar
una nueva iteracin.
x Elevar el nivel de abstraccin: Se motiva a la reutilizacin de conceptos
como patrones de software.
x Enfocarse en la calidad: La calidad se controla en cada actividad del
desarrollo de software y no solamente al final de cada iteracin.
1.2.2. CICLO DE VIDA
RUP es una implementacin del modelo en espiral, es decir que utiliza iteraciones y
cada una de estas debe ser el inicio de una nueva iteracin, hasta que el proyecto
haya concluido satisfactoriamente o se haya cancelado.
Cada iteracin debe contener las siguientes fases:
18
x Concepcin
x Elaboracin
x Construccin
x Transicin
A continuacin se presenta un estimado de tiempo relativo y recursos ocupado por
las cuatro fases (Figura 1.2) .
Figura 1.2.
1.2.3. FASES, DISCIPLINAS E ITERACIONES
1.2.3.1. FASES
Como se mencion en el punto anterior, las fases son cuatro, concepcin,
elaboracin, construccin y transicin. A continuacin se presenta con ms detalle el
alcance de cada fase y sus actividades.
FASE DE INICIACIN
Durante la fase de iniciacin se definir el alcance del proyecto y el modelo del
negocio, se disean los principales casos de uso y se identifican actores. Adems se
determinan los recursos que deben ser asignados al proyecto.
19
Objetivos:
x Establecer el mbito del proyecto
x Casos de uso crtico del Sistema.
x Definir al menos una arquitectura candidata.
x Estimar costo en recursos y tiempo de elaboracin.
x Definir riesgos.
Al finalizar esta fase se debe alcanzar los siguientes resultados:
x Un documento preliminar con los requerimientos, caractersticas
principales y restricciones.
x Un 10% de los casos de uso
x Descripcin del negocio
x Riegos del negocio
x Planificacin del proyecto
x Modelado del negocio
En esta fase adems se debe evaluar los siguientes criterios, que debern ser
aprobatorios o reprobatorios a la continuidad del proyecto.
x Se debe coincidir en el mbito del Sistema y la estimacin de tiempos
para el desarrollo del proyecto.
x Comprensin de los requerimientos.
x Los gastos son similares o difieren en muy poco con los propuestos.
FASE DE ELABORACIN
La fase de elaboracin pretende analizar el dominio del problema, establecer los
cimientos de la arquitectura, desarrollar el plan del proyecto, y eliminar riesgos
mayores.
20
En esta fase se construye un prototipo del sistema, constituyendo ste, la base para el
sistema final, el cual evolucionar en las iteraciones.
Objetivos:
x Definir, validar y cimentar la arquitectura
x Especificar los requerimientos con mayor detalle
x Implementar un caso de uso de alto riesgo
Al finalizar esta fase se debe alcanzar los siguientes resultados:
x Un 80% de los casos de uso del sistema y sus actores
x Requisitos adicionales como los no funcionales
x Descripcin de la arquitectura de software
x Un prototipo ejecutable de la arquitectura
Los criterios de evaluacin de esta fase son los siguientes:
x La visin del producto es estable.
x La arquitectura es estable.
x Se ha demostrado mediante la ejecucin del prototipo que los principales
elementos de riesgo han sido abordados y resueltos.
x El plan para la fase de construccin es detallado y preciso. Las
estimaciones son crebles.
FASE DE CONSTRUCCIN
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto
de forma incremental a travs de las sucesivas iteraciones.
Objetivos:
x Conseguir una calidad adecuada tan rpido como sea prctico.
21
x Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rpido como sea prctico.
Los resultados de la fase de construccin deben ser:
x Modelos Completos
x Arquitectura ntegra
x Riesgos Presentados Mitigados
x Plan del Proyecto para la fase de Transicin.
x Manual Inicial de Usuario
x Prototipo Operacional beta
x Caso del Negocio Actualizado
Los criterios de evaluacin de esta fase son los siguientes:
x El producto es estable y maduro como para ser entregado a la comunidad
de usuarios para ser probado.
FASE DE TRANSICIN
Con la fase de transicin se pretende colocar el sistema en uso, completar la
documentacin y realizar tareas de ajuste y configuracin necesarias para el uso del
producto.
Objetivos:
x Conseguir que el usuario se valga por si mismo.
x Un producto final que cumpla los requisitos esperados, que funcione y
satisfaga suficientemente al usuario.
22
Los resultados de la fase de transicin son:
x Prototipo Operacional
x Documentos Legales
x Lnea de Base del Producto completa y corregida que incluye todos los
modelos del sistema
x Descripcin de la Arquitectura completa y corregida
x Las iteraciones de esta fase irn dirigidas normalmente a conseguir una
nueva versin.
Los criterios de evaluacin de esta fase son los siguientes:
x El usuario se encuentra satisfecho.
1.2.3.2. DISCIPLINAS
En RUP, las disciplinas son el corazn, estas deben alternarse en cada iteracin.
Se identifican las siguientes disciplinas:
Modelado del negocio:
Esta disciplina pretende entender el negocio de la organizacin referente al Sistema.
Para esto se analiza los cambios que se produzcan con el Sistema, se verifica el
procedimiento actual y de ser necesario se busca una posible reingeniera en los
procedimientos actuales.
Requerimientos:
Se genera un documento de acuerdo al alcance del proyecto y se define las partes del
negocio que se construyen con el proyecto y que partes no.
23
Anlisis y Diseo:
Tomando en cuenta los requerimientos y restricciones se disea la solucin a ser
implementada. En esta disciplina se establece y valida la arquitectura, se comprenden
los requerimientos, se disean los mdulos, la base de datos, interfaz de usuario.
Implementacin:
Se pasa el diseo a cdigo ejecutable con un nivel primario de pruebas para entender
y evolucionar el diseo. As mismo se escribe el cdigo fuente, se implementa los
mdulos y se integra el cdigo en subsistemas.
Verificacin:
Se detecta fallos en el sistema, se valida el diseo, se comprueba que el sistema
satisfaga los requerimientos.
En esta disciplina se ejecuta pruebas y reporta defectos para una futura iteracin.
Puesta en marcha:
Se da la liberacin del sistema y se entrena a los usuarios.
Configuracin y gestin del cambio:
Se gestiona las peticiones de cambio, se planea el control y reportes de la
configuracin, y se administra la versin base del sistema.
Administracin del proyecto:
El objetivo es dirigir las actividades que toman lugar en el proyecto como gestin del
riesgo, direccin del equipo de trabajo, coordinacin externa, planeacin y
culminacin del proyecto.
Entorno:
24
El objetivo es asegurar que se pueda ejecutar el proceso por medio de la
identificacin, evaluacin, instalacin y configuracin de las herramientas para el
equipo del proyecto.
1.2.3.3 ITERACIONES
Un proceso iterativo permite crear una visin mas clara de los requerimientos del
sistema al mismo tiempo que ste crece. RUP sigue el modelo iterativo, con lo que
se logra minimizar los riesgos del proyecto y presentar un sistema ejecutable lo ms
pronto posible.
Para que las iteraciones sean de provecho, se necesita una constante interaccin con
los usuarios involucrados en el sistema, con eso se logra un refinamiento del
proyecto hasta que llegue a su etapa final.
1.2.4. ESTIMACION DE TIEMPOS DE DESARROLLO
En general RUP establece un aproximado a los tiempos de desarrollo de un proyecto,
en el cual se puede apreciar las fases y su cantidad de esfuerzo en trminos de
porcentaje.
En nuestro caso hemos establecido el siguiente aproximado en porcentaje (Figura
1.3):
ESTIMADO DE TIEMPOS
INICIACION
15%
ELABORACION
20%
CONSTRUCCION
60%
TRANSICION
5%
Figura 1.3.
25
1.3. SOFTWARE DE APOYO
1.3.1. ELECCIN DEL SISTEMA OPERATIVO
Un sistema operativo es un conjunto de aplicaciones que permiten interactuar al
usuario con el Hardware, como tambin controlar los recursos eficazmente.
Existen varios Sistema Operativos en el mercado, como son la Familia de Microsoft
Windows, la familia de GNU/Linux entre otros. Cada uno de estos con mejores
caractersticas que otros. La familia Windows presenta caractersticas como soporte
y extensiones, as tambin como una gran variedad de Software y compatibilidad con
los mismos. La familia de GNU/Linux presenta una gran caracterstica como poseer
licencia GNU, en la mayora de sus distribuciones, donde cada una pretende cubrir
las necesidades de los usuarios.
La eleccin del sistema operativo se fundamenta en que el Oratorio Don Bosco de
Cuenca, presenta la instalacin de Windows XP y no es necesario la instalacin de
otro sistema operativo, adems que los usuario estn familiarizados con el mismo.
En nuestro caso, el proyecto de software que se esta desarrollando, es compatible con
cualquier Sistema Operativo, ya que las herramientas para su desarrollo son
multiplataforma.
1.3.2. ELECCIN DE LA BASE DE DATOS
Una base de datos es un conjunto de datos almacenados sistemticamente, que
mediante un Sistema Gestor de Base de Datos (SGBD) permite la recuperacin de
los mismos para obtener informacin para la toma de decisiones.
________________________________________________________________________________
GNU es un acrnimo recursivo que significa GNU No es Unix (GNU is Not Unix) Ref.
http://es.wikipedia.org/wiki/GNU
26

Existen varios SGBD en el mercado, unos con licencias de pago como ORACLE,
DB2, etc. Y otras con Licencias GPL como HSQL, MySQL, PostgreSQL. Cada una
con diferentes caractersticas pero que cumplen su objetivo.
La Base de Datos que se ha escogido es MySQL, primordialmente por:
x Su licencia que es GNU GPL
x La mayora de servidores soportan la arquitectura de MySQL
x Ocupa pocos recursos de la PC
x Tiene soporte de la comunidad MySQL
x Compatible con el lenguaje de programacin en el que se esta
desarrollando la aplicacin
x Procesa rpidamente los datos va WEB.
1.3.3. ELECCIN DEL SERVIDOR WEB
Un Servidor Web es el encargado de receptar las peticiones del protocolo HTTP
(Hypertext Transfer Protocol) y responder con el contenido solicitado a las peticiones
que realiza el cliente mediante un navegador Web.
Tenemos varios Servidores Web en el mercado como Apache Tomcat, JBoss, Jetty,
GlassFish, Sun Application Server, cada uno con caractersticas similares unos con
licencia gratuita y otros con licencia de pago.
El Servidor Web que se ha escogido para la implementacin es Apache Tomcat,
primero por su licencia de libre distribucin, a ms que soporta la tecnologa Servlets
y JSP (Java Server Pages), es de fcil instalacin, tiene compatibilidad con diversos
Sistemas Operativos, y con MySQL.
_________________________________________________________________
GPL: GNU General Public License, licencia orientada principalmente a los trminos de
distribucin, modificacin y uso de software. Ref. http://www.definicion.org/diccionario/200
27
1.3.4. ELECCIN DEL LENGUAJE DE PROGRAMACION
Lenguaje de Programacin es un lenguaje con el cual se puede controlar funciones de
una computadora y crear aplicaciones que controlen ciertas funciones o que cumplan
con ciertas tareas que requiere el usuario.
Existen varios Lenguajes de Programacin como JAVA, C++, Visual Basic, entre
otros, cada uno sirve para controlar el comportamiento de la computadora, mediante
un conjunto de smbolos y reglas sintcticas y semnticas que definen la estructura y
su comportamiento.
El lenguaje de Programacin que se ha escogido es el Lenguaje JAVA:
x Por su licencia es gratuita GPL.
x Es un lenguaje orientado a objetos.
x Es multiplataforma es decir no depende de ningn Sistema Operativo.
x Es un lenguaje de alto nivel.
x Compatible con el SGBD MYSQL.
1.3.5. ELECCION DEL IDE DE DESARROLLO
Un IDE es un conjunto de herramientas, es decir, consiste en un editor de cdigo, un
compilador, un depurador y un constructor de interfaz grfica GUI. Presenta un
entorno amigable que le sirve al programador para el desarrollo, pruebas y correccin
de errores de aplicaciones.
Existen varios IDEs en el mercado como Eclipse, Netbeans, JBuilder, JDeveloper,
etc, cada uno con distintas caractersticas y diferentes licencias.
El IDE que usaremos para el desarrollo del sistema de inscripciones es Eclipse:
x Por su licencia ya que es gratuita.
x Presenta un entorno amigable.
28
x Facilidad para la creacin y generacin de cdigo.
x Integra varias tecnologas como Hibernate, Struts, que son las necesarias
para el desarrollo de la aplicacin.
1.4. DESCRIPCION GENERAL DEL SISTEMA DE
INSCRIPCIONES
El Sistema a desarrollarse tiene como base un mdulo de inscripciones que adems
debe interactuar con otros mdulos como el de usuarios, el administrativo y reportes.
1.4.1. DIAGRAMA MODULAR
El siguiente diagrama (Figura 1.4) nos presenta una vista general de los mdulos
involucrados en el Sistema y su interaccin.
Figura 1.4
Mdulo usuarios:
Este mdulo controlar el acceso al Sistema por medio de usuarios y contraseas que
deben ser digitados por los usuarios para poder acceder al resto de mdulos. Esto
evitar el acceso no permitido y asignar responsabilidades a los usuarios del
Sistema por las acciones realizadas.
29
Mdulo Administrativo
El mdulo administrativo servir para el mantenimiento de informacin auxiliar del
sistema como puede ser el ABM (Alta, Baja y Modificacin) de usuarios e
informacin que los usuarios comunes del sistema no tengan acceso.
Mdulo de Inscripciones
Es el mdulo base del sistema, en el cual se realizar todas las tareas de inscripcin
en el Oratorio, como el mantenimiento de alumnos, mantenimiento de cursos y
animadores y las inscripciones de los alumnos en los cursos. Para el acceso a este
mdulo el usuario debe estar activo y poseer los permisos necesarios.
Mdulo de Reportes
Los reportes son siempre necesarios en los sistemas, es por eso que la creacin de un
mdulo de reportes es fundamental. En ste mdulo se encargar de la creacin de:
listados de alumnos segn el curso, ficha personal, y comprobante de inscripcin.