0
“José Simeón Cañas”
Facultad de Ingeniería y Arquitectura
Práctica de Especialidad II
Fase de Construcción (final):
Administración de Cursos de Postgrado UCA - MINED
Gema System
Catedrático:
Lic. Mauricio Quevedo
Presentado por:
Fátima Haydeé Hernández Brito Tanya Angélica Nóchez Perdomo
Mónica Beatriz Palacios Torres Donnina Beatriz Paz Rivera
Fecha de entrega:
1 ÍNDICE
1. CORRECCIONES - FASE DE ELABORACIÓN
Diagramas de casos de uso 2
Diseño de pantallas 4
Diseño de base de datos 5
Arquitectura de software 5
ITERACIONES 6
CONCLUSIONES 8
Número total de líneas de código 9
2 CORRECCIONES - FASE DE ELABORACIÓN
1. Diagramas de casos de uso
Los casos de uso específicos que se realizaron en la fase de elaboración, representaban las funcionalidades que iba a poseer cada módulo de la aplicación, pero no se habían considerado algunas administraciones que son necesarias para llevar al software en desarrollo a alcanzar un alto nivel de calidad y eficiencia.
Inicio
Los casos de uso que se ampliaron desde la fase de inicio, representaban los siguientes módulos de la aplicación: ingreso al sistema, administración de datos del curso, administración de sedes, administración de especialistas y participantes, administración de reproducción y distribución de material, administración de transportistas y administración de notas. Sin embargo, no se contaba con el caso de uso que representara el módulo de administración de usuarios, secciones y cursos.
Caso de uso: Administración de datos del curso
Corrección
3
Caso de uso: Administración de datos del curso
4
Administración de usuarios
2. Diseño de pantallas
Se realizó ciertos cambios en el diseño de las pantallas, ya que al ser presentadas tanto al cliente como al catedrático de la materia, solicitaron algunas modificaciones que ayudarían a tener una mejor visualización y manipulación de la información que se administra dentro de la aplicación. Asimismo, se agregaron nuevas funcionalidades a las pantallas para la comodidad del cliente y se diseñó nuevas pantallas para completar toda la navegabilidad del software.
Inicio
En la fase de elaboración se diseñó y presentó únicamente las pantallas más básicas de la aplicación, las cuales se realizaron con un tamaño de fuente que dificultaba la lectura de la información, la funcionalidad de estas estaba limitada, lo que dificultaba la navegabilidad al usuario y además no se había considerado el diseño para el módulo de administración de usuario y la de los cursos.
5
El diseño del sistema, ya contiene una fuente que satisface al usuario, un estándar definido en toda la aplicación y la realización de las nuevas pantallas, permitió completar todos los módulos necesarios para poder llevar a cabo la codificación que requiere la fase de construcción.
3. Base de datos
El diseño de la base de datos se elaboró con mucha presión y exactitud conforme a la información que el cliente deseaba manejar y automatizar, la cual se encuentra plasmada en los requerimientos solicitados en la fase de inicio. La base de datos al igual que las otras partes del proyecto, también se le hizo algunos cambios que se necesitaba para mejorar el rendimiento de la codificación de cada módulo.
Inicio
El diseño de la base de datos que se había presentado en la fase de elaboración no contenía la tabla que admitiera la creación de los usuarios con sus respectivos permisos de accesos. Al mismo tiempo, este diseño no permitía saber la sección de la materia a la que pertenece un docente, ya que no existía una relación directa entre la tabla docente y sección, por lo que implicó modificar el diseño actual.
Corrección
Las correcciones que se le hizo a la base de datos, implicó agregar la relación directa entre la tabla docente y sección, para permitir el fácil acceso a la información que contienen estas tablas en la codificación de los módulos que lo requieren. También, se agregó la tabla de tipo de usuario, la cual contiene la información de los usuarios que tienen acceso a la aplicación según los permisos asignados en la creación de sus cuentas.
Además, se realizó una mínima modificación de los nombres de algunas tablas, simplemente para seguir la costumbre de unir los nombres compuestos de las tablas. Los cambios fueron para la tabla especialidad material y material didáctico por especialidad_material y material_didactico respectivamente.
4. Arquitectura de software
La arquitectura de software se seleccionó y se diseñó en base a los objetivos y restricciones de aplicación. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, sino también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar el sistema de información.
6
La arquitectura que se consideró en la fase de elaboración fue MVC, a la cual se consideraba como un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos: modelo, vista y controlador. Además, porque es comúnmente empleada en aplicaciones web.
Corrección
La confusión que hubo al seleccionar la arquitectura, hizo efectiva la modificación de la arquitectura, la cual fue cambiada por la Arquitectura de tres niveles o capas con patrón MVC que se acoplaba a las características y necesidades de la aplicación que se desarrolló. La arquitectura de tres niveles o capas consiste en una especialización de la arquitectura cliente-servidor, donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente.
ITERACIONES
Desde el inicio de la fase de elaboración, hasta la realización de la tercera fase (construcción), se han identificado cinco iteraciones las cuales son:
Primera iteración
Diseño preliminar de la interfaz del sistema y diagrama preliminar de la base de datos:
Definición de módulos en los que deberá estar compuesta la aplicación, para poder cumplir con todos los requerimientos.
Definición de tipos de datos, entidades y atributos necesarios, así como las relaciones entre ellos.
Segunda iteración
Diseño inicial de la interfaz del sistema y diagramas de base de datos más completos. Correcciones a la forma de ingreso a la aplicación.
Primer modelado de la composición física de la interfaz principal.
Definición de un modelo de diagrama Entidad-Relación preliminar.
7
Tercera iteración
Diseño final de la GUI y diagramas de base de datos definidos
Los cambios que se obtuvieron al realizar la tercera iteración fueron en el caso de uso de Participantes, ya que se integrará la Administración de las notas al Módulo de participantes.
Cuarta iteración
Diseño final de los módulos
Al realizar una cuarta iteración se hizo una revisión general de los módulos. Es por ello, que se agregaron dos módulos, aparte de los que ya existían, los cuales son: Módulo de administración de usuarios y el Módulo de cursos.
Quinta iteración
Obtención final de la base de datos
8 CONCLUSIONES
La elección de integrantes para formar el equipo, fue la mejor opción que se tuvo para desarrollar el sistema de Administración de cursos de postgrados UCA_MINED para la Unidad de Proyectos de la universidad; ya que entre las integrantes, se contaba con una de las personas que interactúan directamente con la información de los datos de los cursos, lo que facilitó el análisis de la aplicación para poder llevar a cabo su desarrollo.
El desarrollo de la aplicación utilizando la Metodología RUP, le permitió al equipo desarrollador conocer y aprender sobre la forma de trabajo que la metodología aplica para la implementación de sistemas de información. Las características de RUP proporcionan un proceso de desarrollo de software, que constituye la metodología estándar más utilizada para el análisis, implementación y documentación de aplicaciones orientadas a objetos. Además, RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
La experiencia vivida al desarrollar un sistema para un cliente real, permitió saber los requerimientos que un usuario solicita para la implementación de una aplicación al querer y necesitar automatizar su trabajo. Sin embargo, el cliente al cual se visitó tiene conocimientos informáticos, lo que proporcionó un mayor entendimiento con el equipo de trabajo al momento de explicar el proceso actual que se realiza en la Unidad de Proyectos y poder pasarlo a un sistema de información.
La culminación del desarrollo de la aplicación web (Administración de cursos de Postgrados), ayudará a los usuarios a automatizar el proceso actual y centralizar la información, para lograr la eficiencia en el acceso de la misma; auxiliándose del manual de usuario para el manejo del sistema.
9
CRONOGRAMA DEL PROYECTO DE LA FASE DE CONSTRUCCIÓN(Estimado)
Id. Acitividad Encargado Comienzo Fin Duración Numero de Horas
24 Oct 2010 31 Oct 2010 7 Nov 2010
23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 2 3 4 360 h 21d 14/11/2010 25/10/2010 Todas Software del Sistema
10 h 3d
17/11/2010 15/11/2010
Por definir Manual de Usuario
50 h 4d
26/10/2010 23/10/2010
Por definir Correcciones de etapa anterior
1d 18/11/2010
18/11/2010 Actualización del Cronograma
14 Nov 2010
17 18
10
CRONOGRAMA DEL PROYECTO DE LA FASE DE CONSTRUCCION (Real)
A continuación se muestra el cronograma de trabajo que seguimos durante esta fase cada una de las integrantes, al final se hace una consolidación de
total de horas reales que como grupo usamos para el desarrollo del sistema.
Horas reales
104 h 87 H
TOTAL
18/11/2010 3 h 5h
Manual de usuario 17/11/2010-19/11/2010 20 h 24 h
07/11/2010-11/11/2010 18 h 22 h
fase de elaboración
Módulo de secciones 08/11/2010-12/11/2010 40 h 45 h Cronograma individual de la fase de construcción: Fatima Hernandez
Actividades realizadas Fecha de elaboración Horas estimadas
Querys 05/11/2010-06/11/2010 6 h 8 h
11
Horas reales
101.5 h 4.5 h
Total 116 h
Validaciones 05/11/2010 - 18/11/2010 6 h
Modulo de Usuarios 16/11/2010-18/11/2010 13 h 8 h
Modulo de Reportes 17/11/2010 - 19/11/2010 25 h 18 h
Módulo de Reproducción de Material 12/11/2010-13/11/2010 18 h 17 h
Modulo de Distribución de Material 14/11/2010 - 15/11/2010 18 h 18 h
18 h 19 h
Modulo de Transportistas 08/11/2010-11/11/2010 18h 17 h
Cronograma individual de la fase de construcción: Donnina Paz
Actividades realizadas Fecha de elaboración Horas estimadas
Módulo de Especialistas 05/11/2010-08/11/2010
Actividad Fechas Horas estimadas Horas reales
Creación de la plantilla de tablas usadas en cada módulo 31/10/2010 -03/11/2010 12 8 Funcionalidad de la tabla base usada en los módulos 04/11/2010 - 06/11/2010 10 5
Creación del módulo de Participantes 07/11/2010 - 13/11/2011 13 20
Creación del módulo para la administración de cursos 13/11/2010 - 15/11/2012 10 8 Creación del módulo para la selección del cambio de nivel y cursos16/11/2010 - 18/11/2013 10 8
Total 55 h 49 h
12
Horas reales
102.5
TOTAL 99 h
4 h Validación del logeo de usuario y la contraseña 13/11/2010 - 14/11/2010 6 h
Unión de todas las pantallas del proyecto 16/11/2010 - 18/11/2010 24 h 24 h
Redireccionamiento de los dos Usuarios que contiene el proyecto 17/11/2010-19/11/2010 1 h 1 h
07/11/2010 - 11/11/2010 50 h 60 h
Diseño final de Pantallas de Usuario y Cursos 13/11/2010 3 h 3.5 h
Modificaciones al diseño de las pantallas
Cronograma individual de la fase de construcción: Tania Nochez
Actividades realizadas Fecha de elaboración Horas estimadas
13
El siguiente gráfico explica el comportamiento de las Horas Estimadas VRS lasHoras Reales
utilizadas en la Fase de Construcción por integrante.
Integrantes Horas Estimadas Horas Reales
Tania Nochez 99 102
Monica Palacios 55 49
Fatima Hernandez 87 104
Donnina Paz 116 101.5
Total 357 356.5
0 20 40 60 80 100 120 140
Tania Nochez Monica Palacios Fatima Hernandez Donnina Paz Horas Estimadas Horas Reales
Horas Reales vrs Estimadas Totales
