Está en la página 1de 24

6

CAPITULO 1
INTRODUCCION
7
1.1. METODOLOGÍA DE DESARROLLO DE SOFTWARE
1.1.1. DEFINICIÓN
Las metodologías de software son procedimientos, formas, guías para la
documentación 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 elaboración de un producto de software.
Esto incluye la implementación de modelos, gráficos junto con los procedimientos
detallados, donde cada uno de los procedimientos puede ser utilizado en varias
actividades. Se describen los modelos gráficos que deben ser producidos, las reglas o
restricciones que debe cumplir el sistema, las recomendaciones para una buena
práctica de diseño y guías de procesos que se debe seguir para cada actividad.
1.1.2. FASES
La metodología presenta ciertas fases o tareas que se requiere llevar a cabo:
1.1.2.1 ANÁLISIS DE REQUISITOS
En esta etapa se analizan y extraen cada uno de los requisitos que se necesitan para la
elaboración 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 análisis de
requerimientos. Los resultados del análisis de requerimientos se guardan en un
documento ERS (Especificación de Requerimientos del Sistema), se realiza un
diagrama de Entidad/Relación, donde se definen las entidades que participarán en el
desarrollo del software.
8
1.1.2.2. ESPECIFICACIÓN
Es la representación del sistema en un documento más técnico, donde se establecen
las características, materiales y los servicios necesarios para la elaboración del
producto de software. Dentro del documento intervienen los requerimientos
necesarios para la obtención exitosa y medición de calidad del producto.
1.1.2.3. DISEÑO Y ARQUITECTURA
En la fase de diseño se pretende esquematizar un sistema que, satisfaga las
especificaciones, se ajuste a las limitaciones y cumpla con los requerimientos
establecidos.
Dentro del diseño y arquitectura tenemos:
x Diseño de datos:
Modelo de información de la estructuras de datos.
x Diseño arquitectónico:
Define relaciones entre elementos estructurales del sistema.
x Diseño procedimental:
Se transforman los elementos estructurales del sistema en una
descripción procedimental del software
x Diseño de interfaz:
Describe cómo se comunica el software consigo mismo y con su
entorno.
Es un documento que presenta modelos gráficos como:
x Modelos de caso de uso
x Modelo entidad-relación-atributo
9
x Modelos de objetos
x Modelo de flujo de datos
x Modelo estructural
1.1.2.4. PROGRAMACIÓN
Es traducir el diseño a código fuente. Esta es una actividad personal ya que no existe
una estándar sobre cómo programar; es crear cada uno de los módulos y probarlos.
1.1.2.5. PRUEBAS
En esta fase se realiza pruebas de integración y validación, para la comprobación del
correcto funcionamiento de cada una de las tareas que se indican en las
especificaciones.
Las pruebas del sistema involucran la ejecución del sistema, con casos de prueba
que se derivan de la especificación de los datos reales procesados por el mismo. Con
el proceso de pruebas se eliminan errores y falencias de la solución informática, y lo
que se obtiene a la salida de esta fase es una aplicación completa y lista para usarse.
1.1.2.6. DOCUMENTACIÓN
En esta fase lo que se pretende, es la realización de manuales de usuario, manuales
técnicos, y documentación de código fuente, con el propósito de mantener y
evolucionar del sistema.
1.1.2.7. MANTENIMIENTO
En esta fase se realiza un proceso de mejoramiento y optimización 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 adición 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 finalización de la etapa anterior.
El modelo en cascada se divide en las siguientes etapas:
x Análisis de Requisitos
x Diseño del Sistema
x Diseño del Programa
x Codificación
x Pruebas
x Implantación
x Mantenimiento
De tal forma que si un error es detectado en cualquier etapa obliga a un rediseño y
una nueva programación 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
construcción de prototipos con los aspectos controlados y sistemáticos 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.
- Identificación de riesgos y estrategias para evitarlos en el proyecto.
- Planificación inicial o previa.
x Análisis 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 corrección.
- Después de la evaluación de los riesgos, se elige un modelo para el
desarrollo.
- Se revisa lo realizado, se evalúa, y se decide si se continúa 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 más definición.
Se basa en la construcción rápida de un prototipo del sistema. Éste se evalúa por el
usuario final y se identifican nuevos requerimientos o corrección de errores. Este
proceso permite obtener una retroalimentación que gracias a ésta se refinan los
requisitos del software que se desarrollará.
12
1.1.3.1.4. MÉTODO EN V
Se describe las actividades y los resultados en el proceso de desarrollo del software.
El Método-V representa gráficamente el ciclo de vida del desarrollo del sistema (ver
Figura 1.1).
Resume los pasos principales que hay que tomar en conjunción con las
correspondientes entregas de los sistemas de validación.
Requerimientos
Diseño del
Sistema
Diseño del
Software
Código
Verificación del
Software
Verificación del
Sistema
Validación del
Sistema
Validación de
Requerimientos
Verificación del
Diseño
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 intersección de la
V, representa la corriente de desarrollo.
La definición de especificación consiste en:
x Especificaciones de requerimientos de usuario
x Especificaciones funcionales
x Especificaciones de diseño
La fase de pruebas consiste en:
x Calificación de instalación
x Calificación operacional
x Calificación de rendimiento
13
La fase de desarrollo puede consistir en personalización, configuración o
codificación.
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 definición de especificaciones no
se las realiza al inicio del proyecto, sino que se va desarrollando simultáneamente
con las diversas versiones del código.
Pueden distinguirse las siguientes fases:
x Especificación conceptual
x Análisis de requerimientos
x Diseño inicial
x Diseño detallado, codificación, depuración y liberación
Estas diferentes fases se van repitiendo en cada etapa del diseño.
1.1.3.2. METODOLOGÍAS ÁGILES
Se basa en procesos ágiles para el desarrollo de software. Los procesos ágiles son
metodologías livianas que pretenden evitar las metodologías tradicionales.
En esta metodología el usuario es el factor principal del éxito del software.
Propone que exista una interrelación entre el usuario y el equipo de desarrollo, donde
la colaboración será lo que marque el éxito del proyecto.
Las metodologías á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 metodología, van a aumentar la productividad
y rentabilidad del proceso de producción de software y son los siguientes:
14
x Eliminar desperdicios
x Ampliar el aprendizaje
x Decidir lo más tarde posible
x Entregar lo más rápido posible
x Potenciar al equipo de trabajo
x Construir pensando en la integridad del software
x Ver el todo
1.1.3.2.1. PROGRAMACIÓN EXTREMA (XP)
La metodología XP se basa en la interrelación entre el usuario y el equipo de
desarrollo, para una realimentación continua, se mantiene una comunicación 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 más
realista que intentar definir todos los requisitos al comienzo del proyecto y después
invertir esfuerzos en controlar los cambios en los requisitos.
1.1.3.2.2. SCRUM
Es una metodología que se adapta a proyectos que requieren cambios de requisitos
rápidos, se basa en iteraciones denominadas sprints cada una con duración de 30
días, la culminación de cada sprint se muestra al cliente y es un incremento
ejecutable. La característica es una reunión diaria de 15 minutos del equipo para
coordinación e integración.
1.1.3.2.3. CRISTAL
La metodología cristal se centra en la importancia de las personas, las cuales
componen el equipo de desarrollo del proyecto, se considera como un juego de
cooperación, invención y comunicación, donde se establecen políticas de trabajo en
equipo.
15
1.1.3.2.4. FEATURE DRIVEN DEVELOPMENT (FDD)
Esta metodología 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 diseño e
implementación partiendo de las características que debe cumplir el software.
1.1.3.2.5. ADAPTIVE SOFTWARE DEVELOPMENT(ASD)
Esta metodología 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 Especulación: se planifica y especifican las características del software.
x Colaboración: se desarrollan las características.
x Aprendizaje: se realiza la validación y verificación de calidad y se entrega al
cliente.
1.1.3.2.6. LEAN DEVELOPMENT (LD)
Es un conjunto de herramientas para la administración 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 metodología de desarrollo de software que,
junto a UML(Unified Modeling Language), colabora para el desarrollo del análisis,
diseño, implementación y documentación de sistemas orientados a objetos.
La metodología RUP se adapta a la necesidad que presente la Organización 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 diseñadores de esta metodología se enfocaron en los fallos o
errores cometidos en diferentes proyectos de software y se enfocaron en la raíz de las
causas de dichos problemas.
A continuación se presentan algunos de los errores más comunes en el desarrollo de
software:
x Administración Ad-Hoc de requerimientos
x Comunicación ambigua e imprecisa.
x Arquitectura inestable
x Inconsistencia indetectable en requerimientos, diseño e implementación
x Pruebas del Sistema incompletas
x Evaluación subjetiva del estado del proyecto
x Fallos en eliminación de riesgos
La combinación de estos errores es común en proyectos que no siguen una
metodología enfocada en buenas prácticas, 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 organización debe adaptar el tamaño del
proceso a su necesidad. También 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 Colaboración por medio de equipos: Existe una creciente demanda de
desarrollo de software distribuido, con las actuales herramientas de
comunicación. La colaboración incluye en necesidades, pruebas, cifras, etc.
x Demostrar valor iterativamente: Los proyectos se deben presentar en cada
iteración, así sea dentro del equipo de desarrollo, para refinarlo y comenzar
una nueva iteración.
x Elevar el nivel de abstracción: Se motiva a la reutilización 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 iteración.
1.2.2. CICLO DE VIDA
RUP es una implementación del modelo en espiral, es decir que utiliza iteraciones y
cada una de estas debe ser el inicio de una nueva iteración, hasta que el proyecto
haya concluido satisfactoriamente o se haya cancelado.
Cada iteración debe contener las siguientes fases:
18
x Concepción
x Elaboración
x Construcción
x Transición
A continuación 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, concepción,
elaboración, construcción y transición. A continuación se presenta con más detalle el
alcance de cada fase y sus actividades.
FASE DE INICIACIÓN
Durante la fase de iniciación se definirá el alcance del proyecto y el modelo del
negocio, se diseñan los principales casos de uso y se identifican actores. Además se
determinan los recursos que deben ser asignados al proyecto.
19
Objetivos:
x Establecer el ámbito del proyecto
x Casos de uso crítico del Sistema.
x Definir al menos una arquitectura candidata.
x Estimar costo en recursos y tiempo de elaboración.
x Definir riesgos.
Al finalizar esta fase se debe alcanzar los siguientes resultados:
x Un documento preliminar con los requerimientos, características
principales y restricciones.
x Un 10% de los casos de uso
x Descripción del negocio
x Riegos del negocio
x Planificación del proyecto
x Modelado del negocio
En esta fase además se debe evaluar los siguientes criterios, que deberán ser
aprobatorios o reprobatorios a la continuidad del proyecto.
x Se debe coincidir en el ámbito del Sistema y la estimación de tiempos
para el desarrollo del proyecto.
x Comprensión de los requerimientos.
x Los gastos son similares o difieren en muy poco con los propuestos.
FASE DE ELABORACIÓN
La fase de elaboración 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 Descripción de la arquitectura de software
x Un prototipo ejecutable de la arquitectura
Los criterios de evaluación de esta fase son los siguientes:
x La visión del producto es estable.
x La arquitectura es estable.
x Se ha demostrado mediante la ejecución del prototipo que los principales
elementos de riesgo han sido abordados y resueltos.
x El plan para la fase de construcción es detallado y preciso. Las
estimaciones son creíbles.
FASE DE CONSTRUCCIÓN
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto
de forma incremental a través de las sucesivas iteraciones.
Objetivos:
x Conseguir una calidad adecuada tan rápido como sea práctico.
21
x Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
Los resultados de la fase de construcción deben ser:
x Modelos Completos
x Arquitectura íntegra
x Riesgos Presentados Mitigados
x Plan del Proyecto para la fase de Transición.
x Manual Inicial de Usuario
x Prototipo Operacional – beta
x Caso del Negocio Actualizado
Los criterios de evaluación 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 TRANSICIÓN
Con la fase de transición se pretende colocar el sistema en uso, completar la
documentación y realizar tareas de ajuste y configuración 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 transición son:
x Prototipo Operacional
x Documentos Legales
x Línea de Base del Producto completa y corregida que incluye todos los
modelos del sistema
x Descripción de la Arquitectura completa y corregida
x Las iteraciones de esta fase irán dirigidas normalmente a conseguir una
nueva versión.
Los criterios de evaluación de esta fase son los siguientes:
x El usuario se encuentra satisfecho.
1.2.3.2. DISCIPLINAS
En RUP, las disciplinas son el corazón, estas deben alternarse en cada iteración.
Se identifican las siguientes disciplinas:
Modelado del negocio:
Esta disciplina pretende entender el negocio de la organización 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 reingeniería 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
Análisis y Diseño:
Tomando en cuenta los requerimientos y restricciones se diseña la solución a ser
implementada. En esta disciplina se establece y valida la arquitectura, se comprenden
los requerimientos, se diseñan los módulos, la base de datos, interfaz de usuario.
Implementación:
Se pasa el diseño a código ejecutable con un nivel primario de pruebas para entender
y evolucionar el diseño. Así mismo se escribe el código fuente, se implementa los
módulos y se integra el código en subsistemas.
Verificación:
Se detecta fallos en el sistema, se valida el diseño, se comprueba que el sistema
satisfaga los requerimientos.
En esta disciplina se ejecuta pruebas y reporta defectos para una futura iteración.
Puesta en marcha:
Se da la liberación del sistema y se entrena a los usuarios.
Configuración y gestión del cambio:
Se gestiona las peticiones de cambio, se planea el control y reportes de la
configuración, y se administra la versión base del sistema.
Administración del proyecto:
El objetivo es dirigir las actividades que toman lugar en el proyecto como gestión del
riesgo, dirección del equipo de trabajo, coordinación externa, planeación y
culminación del proyecto.
Entorno:
24
El objetivo es asegurar que se pueda ejecutar el proceso por medio de la
identificación, evaluación, instalación y configuración de las herramientas para el
equipo del proyecto.
1.2.3.3 ITERACIONES
Un proceso iterativo permite crear una visión 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 más
pronto posible.
Para que las iteraciones sean de provecho, se necesita una constante interacción 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 términos 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. ELECCIÓN DEL SISTEMA OPERATIVO
Un sistema operativo es un conjunto de aplicaciones que permiten interactuar al
usuario con el Hardware, como también 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
características que otros. La familia Windows presenta características como soporte
y extensiones, así también como una gran variedad de Software y compatibilidad con
los mismos. La familia de GNU/Linux presenta una gran característica como poseer
licencia GNU¹, en la mayoría de sus distribuciones, donde cada una pretende cubrir
las necesidades de los usuarios.
La elección del sistema operativo se fundamenta en que el Oratorio Don Bosco de
Cuenca, presenta la instalación de Windows XP y no es necesario la instalación de
otro sistema operativo, además que los usuario están 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. ELECCIÓN DE LA BASE DE DATOS
Una base de datos es un conjunto de datos almacenados sistemáticamente, que
mediante un Sistema Gestor de Base de Datos (SGBD) permite la recuperación de
los mismos para obtener información para la toma de decisiones.
________________________________________________________________________________
“¹ GNU es un acrónimo 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 características 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 mayoría 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 programación en el que se esta
desarrollando la aplicación
x Procesa rápidamente los datos vía WEB.
1.3.3. ELECCIÓN 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 características similares unos con
licencia gratuita y otros con licencia de pago.
El Servidor Web que se ha escogido para la implementación es Apache Tomcat,
primero por su licencia de libre distribución, a más que soporta la tecnología Servlets
y JSP (Java Server Pages), es de fácil instalación, tiene compatibilidad con diversos
Sistemas Operativos, y con MySQL.
_________________________________________________________________
“¹ GPL: GNU General Public License, licencia orientada principalmente a los términos de
distribución, modificación y uso de software.” Ref. http://www.definicion.org/diccionario/200
27
1.3.4. ELECCIÓN DEL LENGUAJE DE PROGRAMACION
Lenguaje de Programación 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 Programación como JAVA, C++, Visual Basic, entre
otros, cada uno sirve para controlar el comportamiento de la computadora, mediante
un conjunto de símbolos y reglas sintácticas y semánticas que definen la estructura y
su comportamiento.
El lenguaje de Programación 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 ningún 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 código, un
compilador, un depurador y un constructor de interfaz gráfica GUI. Presenta un
entorno amigable que le sirve al programador para el desarrollo, pruebas y corrección
de errores de aplicaciones.
Existen varios IDEs en el mercado como Eclipse, Netbeans, JBuilder, JDeveloper,
etc, cada uno con distintas características 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 creación y generación de código.
x Integra varias tecnologías como Hibernate, Struts, que son las necesarias
para el desarrollo de la aplicación.
1.4. DESCRIPCION GENERAL DEL SISTEMA DE
INSCRIPCIONES
El Sistema a desarrollarse tiene como base un módulo de inscripciones que además
debe interactuar con otros módulos 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 módulos
involucrados en el Sistema y su interacción.
Figura 1.4
Módulo usuarios:
Este módulo controlará el acceso al Sistema por medio de usuarios y contraseñas que
deben ser digitados por los usuarios para poder acceder al resto de módulos. Esto
evitará el acceso no permitido y asignará responsabilidades a los usuarios del
Sistema por las acciones realizadas.
29
Módulo Administrativo
El módulo administrativo servirá para el mantenimiento de información auxiliar del
sistema como puede ser el ABM (Alta, Baja y Modificación) de usuarios e
información que los usuarios comunes del sistema no tengan acceso.
Módulo de Inscripciones
Es el módulo base del sistema, en el cual se realizará todas las tareas de inscripción
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
módulo el usuario debe estar activo y poseer los permisos necesarios.
Módulo de Reportes
Los reportes son siempre necesarios en los sistemas, es por eso que la creación de un
módulo de reportes es fundamental. En éste módulo se encargará de la creación de:
listados de alumnos según el curso, ficha personal, y comprobante de inscripción.