UNIVERSIDAD MAYOR DE SAN ANDRS

FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMTICA

PROYECTO DE GRADO
SISTEMA DE GESTIN ACADMICA UNIVERSITARIO CASO: FACULTAD DE CIENCIAS GEOLGICAS
PARA OPTAR AL TTULO DE LICENCIATURA EN INFORMTICA MENCIN: INGENIERA DE SISTEMAS INFORMTICOS POSTULANTE: TUTOR: REVISOR: Copari Yujra Juana Viviana Lic. Nancy Orihuela Sequeiros Lic. Carlos Mullisaca Choque

La Paz Bolivia Julio 2007

DEDICATORIA Dedico mi Proyecto de Grado a: A Diosito lo ms importante en mi vida, a quien debo todos mis logros y todo lo que tengo, y le agradezco tanto, por estar conmigo y guiarme por el buen camino. A mi Mamita Martina y mi Papi Julio a quienes quiero muchsimo y admiro, a mis hermanos Walter, Simo, Juan, Richar, Alfredo y mis hermanas Eli, Vero, Anghi por darme la fuerza para seguir adelante, y mis sobrinitos Ramirito, Magdalena, Gabrielito y Yaneth por lo cariositos que son y por la alegra que nos dan. A mis amigos y amigas, y a todas las personas que confiaron y confan en mi, desde que era una nia.

AGRADECIMIENTOS
A Diosito le doy gracias por todo lo que me dado, por los logros en mi vida, por la linda familia que tengo, por permitirme realizar mi Proyecto de Grado, por darme la satisfaccin de conocer y encontrar en mi camino personas muy buenas y por darme la fuerza para seguir adelante. A mi Familia por todos los consejos, por el apoyo para seguir adelante en cada paso de mi vida, por la alegra que me dan, por las enseanzas y por la confianza que me brindaron y me brinda. A mi revisor el Lic. Carlos Mullisaca Choque, por los consejos sinceros, buenos y por el apoyo que me dio. A mi tutora la Lic. Nancy Orihuela Sequeiros por el estimulo que siempre nos manifest y por el apoyo en la culminacin de mi Proyecto de Grado. Al Programa UMSATIC por darme la oportunidad trabajar y de crecer profesionalmente. A todas las personas que trabajan en la Facultad de Ciencias Geolgicas por el apoyo y la amistad que me brindaron desde el primer el momento en que comenc mi trabajo en la facultad. A todos mis amigos y amigas del Programa UMSATIC, de la Universidad, del Liceo, de la escuelita, y en general a todos mis amigos y amigas que conoc en el transcurso de mi vida, quienes me dieron y me dan la alegra y el impulso para seguir adelante. A todos los docentes de mi carrera de Informtica, por sus lecciones y enseanzas. A mis profesoras Rosario Torres, Adela, Mery F. de Tejada a quienes no olvido y agradezco muchsimo sus enseanzas y consejos. A todas las personas que me dieron y me dan su apoyo y confianza incondicionalmente desde que era una nia.

RESUMEN
Las TIC (Tecnologas de Informacin y Comunicacin) son herramientas potenciales para la administracin y manipulacin de la informacin para una institucin. De esta manera el desarrollo y la implementacin de las TICs en la Facultad de Ciencias Geolgicas de la Universidad Mayor de San Andrs permitirn tener interfaces y una intercomunicacin para lograr un acceso rpido a la informacin acadmica (notas, materias, actas, pre-actas, listados, record acadmico, historial acadmico y otros) de las carreras de Ingeniera Geogrfica e Ingeniera Geolgica y del Medio Ambiente. Las unidades acadmicas de la Facultad de Ciencias Geolgicas cuentan con sistemas diferentes para la administracin y el control de los datos: seguimiento acadmico de estudiantes, materias, actas, pre-actas, listados, datos de docentes, de administrativos, de autoridades; por tal motivo el manejo de la informacin no esta estandarizada ni existen normas de control. Por lo anteriormente mencionado se ha implementado y desarrollado una versin actual del Sistema de Gestin Acadmica en la Facultad de Ciencias Geolgicas, para tal efecto se ha realizado un estudio de reingeniera de software aplicada en cada unidad acadmica y en el Sistema Modelo Informacional al Sistema de Gestin Acadmica. La aplicacin de las nuevas tecnologas en el desarrollo de software y el empleo del modelo propuesto de reingeniera de software al sistema, nos exigi la migracin de datos de la base de batos con la que contaban las carreras de Ingeniera Geogrfica e Ingeniera del Medio Ambiente, a la nueva estructura de base de datos del Sistema de Gestin Acadmica efectundose la depuracin y consistencia de los datos. Se realiz pruebas de funcionamiento de los mdulos del sistema de gestin acadmica y se ajustaron a los requerimientos presentados por los usuarios, los cuales estn satisfechos por el control y mejor administracin de la informacin acadmica. Finalmente el sistema esta en funcionamiento en la actualidad.

NDICE CONTENIDO CAPITULO I. 1. 1.1. 1.2. 1.3. Pg. MARCO CONTEXTUAL............................................................4

INTRODUCCIN.............................................................................................................4 Descripcin Institucional ..............................................................................................4 Antecedentes ..................................................................................................................6 Planteamiento del Problema.........................................................................................7

1.4. Objetivos.........................................................................................................................8 1.4.1. Objetivo principal ........................................................................................................8 1.4.2. Objetivos secundarios.................................................................................................. 8 1.5. Justificacin....................................................................................................................9 1.5.1. Social ...........................................................................................................................9 1.5.2. Tecnolgica .................................................................................................................9 1.5.3. Econmica ...................................................................................................................9 1.6. 1.7. 1.8. 1.9. Aportes............................................................................................................................9 Limites y Alcances .......................................................................................................10 Metodologa ..................................................................................................................10 Tcnicas Y Herramientas............................................................................................11 MARCO TERICO ........................................................12

CAPITULO II. 2. 2.1. 2.2.

MARCO TERICO........................................................................................................12 Introduccin.................................................................................................................12 Mantenimiento de software. .......................................................................................12

2.3. Reingeniera .................................................................................................................14 2.3.1. Reestructuracin ........................................................................................................15 2.3.2. Ingeniera Inversa ......................................................................................................16 2.3.3. Ingeniera Directa ......................................................................................................17 2.3.4. Reingeniera de base de datos....................................................................................17 2.3.5. Reingeniera de interfaces de usuario........................................................................19

2.4. Ingeniera de Software ................................................................................................20 2.4.1. Definicin de ingeniera ............................................................................................20 2.4.2. Ingeniera de software ...............................................................................................20 2.4.3. Modelos de procesos de software ..............................................................................22 2.4.4. Modelo evolutivo incremental...................................................................................22 2.5. Estndar de la IEEE 830-1998 para la Especificacin de Requisitos .....................24 2.5.1. Ingeniera de requerimientos .....................................................................................24 2.5.2. Definicin de requerimientos. ...................................................................................24 2.5.3. Documentacin de los requerimientos ......................................................................25 2.6. Metodologa de Desarrollo de Software ....................................................................26 2.6.1. RUP (RATIONAL UNIFIED PROCESS) ................................................................26 2.6.2. Anlisis y diseo orientado a objetos (AOO y DOO) ...............................................31 2.6.3. UML (Lenguaje Unificado de Modelado) .................................................................33 2.7. Calidad de Sistema ......................................................................................................36 2.7.1. Web-site QEM...........................................................................................................38 2.8. Herramientas de Desarrollo de Software ..................................................................40 2.8.1. Arquitectura modelo vista controlador ......................................................................40 2.8.2. Arquitectura cliente / servidor ...................................................................................41 2.8.3. Estndar Java Enterprice Edicin (J2EE) ..................................................................43 2.8.4. Sistemas operativos bajo Linux .................................................................................43 2.8.5. Sistema manejador de base de datos .........................................................................44 2.8.6. Lenguajes de programacin.......................................................................................44 CAPITULO III. 3. 3.1. MODELO TERICO .............................................................46

MODELO TERICO .....................................................................................................46 Propuesta de Metodologa de Reingeniera de Software .........................................46

3.2. Aplicacin de la Metodologa Propuesta de Reingeniera de Software ..................50 3.2.1. Anlisis del mantenimiento del software...................................................................50 3.2.2. Una visin general del software ................................................................................51 3.2.3. Estudio de costos beneficios de reingeniera ..........................................................51 3.2.4. Decisin ejecutiva......................................................................................................53 3.2.5. Reingeniera:..............................................................................................................53 3.2.6. Tecnologas................................................................................................................63 CAPITULO IV. 4. CONCRECIN DEL MODELO ...........................................65

ANLISIS, DISEO Y DESARROLLO ......................................................................65

4.1. Procesos Acadmicos...................................................................................................65 4.1.1. Carrera Ingeniera Geogrfica: ..................................................................................67 4.1.2. Carrera de Ingeniera Geolgica y del Medio Ambiente:..........................................68 4.2. Fase de Comienzo o Inicio captura de requisitos...................................................70 4.2.1. Modelado del sistema -actores ..................................................................................70 4.2.2. Diagramas de casos de uso........................................................................................71 4.2.3. Ingeniera Geogrfica - migracin de Foxpro a PostgreSQL..................................101 4.2.4. Ingeniera Geolgica y del Medio Ambiente-migracin de Access a PostgreSQL 102 4.3. Fase de Elaboracin Anlisis .................................................................................104 4.3.1. Diagrama conceptual...............................................................................................104 4.4. Fase de Construccin Diseo .................................................................................109 4.4.1. Diagrama de clases ..................................................................................................109 4.4.2. Diseo de interfaces.................................................................................................110 4.5. 4.6. Fase de Transicin Implementacin .....................................................................115 Calidad del sistema....................................................................................................116

CONCLUSIONES .................................................................................................................123 RECOMENDACIONES .......................................................................................................124 REFERENCIAS BIBLIOGRAFICAS ................................................................................125 GLOSARIO............................................................................................................................130

CAPITULO I.
1. INTRODUCCIN

MARCO CONTEXTUAL

La informacin de es uno de los recursos ms importantes para una institucin, si se quiere alcanzar el objetivo propuesto por la entidad. Las TICs (Tecnologas de Informacin y Comunicacin) se consideran como herramientas potenciales para la manipulacin de la informacin para las personas en la sociedad. Con el objetivo de incrementar la eficiencia y confiabilidad de la informacin, se precisa de interfaces que nos permitan tener acceso de forma rpida a la informacin, actualmente las tecnolgicas de informacin y comunicacin (TIC) nos permiten realizar esto. Es as que una universidad sin esta tecnologa (TIC) actualmente no tendra espacio en un mundo educativo, es as que nace el PROGRAMA UMSATIC para encarar el proyecto de desarrollo, implementacin, diseo y configuracin de las TICs en la Universidad Mayor de San Andrs. El desarrollo e implementacin de un Sistema Gestin Acadmico es fundamental para Facultad de Ciencias Geolgicas ya que esto har que muchos de los procesos se vayan estandarizando y controlando como las inscripciones, adicin y/o retiro de materias, convalidaciones, emisin de actas y pre-actas, etc. y en algunos casos se automaticen los procesos que se realizan manualmente. 1.1. Descripcin Institucional En el ao 1965, con aprobacin del Honorable Consejo Universitario y en razn de la documentacin presentada, se aprueba la implementacin de especialidades en la Facultad de Ciencias Geolgicas. A partir de dicho ao, la Facultad de Ciencias Geolgicas, empieza a formar profesionales gelogos, con orientacin en las siguientes menciones o especialidades: Geologa General, Geologa de Minas, Geofsica, Geotecnia, Geografa y Recursos Naturales A la fecha funcionan las Carreras de Ingeniera Geolgica y del Medio Ambiente e Ingeniera Geogrfica. En el Primer y en el Segundo Congreso de la Facultad de Ciencias Geolgicas se

aprueba una nueva estructura de la Facultad y un nuevo plan de estudios para las dos Carreras las cuales estn vigentes hasta la fecha [DOCU1994]. Acreditacin de la Facultad de Ciencias Geolgicas est acreditada y todo el proceso de la Evaluacin Externa fue debidamente coordinado con la Secretara Nacional de Evaluacin y Acreditacin del Comit Ejecutivo de la Universidad Boliviana CEUB, secretara a cargo del Ing. Marcelo Loayza Melgarejo. Los das 6 y 7 de Diciembre del 2004 se llev a afecto este importante evento. ORGANIGRAMA DE LA FACULTAD DE CIENCIAS GEOLGICAS

CONGRESO DE LA FACULTAD DE CIENCIAS GEOLGICAS ASAMBLEA GENERAL DOCENTE-ESTUDIANTIL HONORABLE CONSEJO FACULTATIVO REA DESCONCENTRADA DECANATO

COMISIN ACADMICA FACULTATIVA

VICEDECANATO ADMINISTRACIN BIBLIOTECA

COMPUTACIN

CARRERA DE GEOLOGA

CARRERA DE GEOGRAFA

INSTITUTO DE INVESTIGACIONES GEOLGICAS Y DEL MEDIO AMBIENTE

INSTITUTO DE INVESTIGACIONES GEOGRFICAS

PROYECTOS DE INVESTIGACIN Y DE INTERACCIN SOCIAL

POST-GRADO

Figura 1.1 Organigrama Facultad de Ciencias Geolgicas

1.2. Antecedentes El 18 de marzo 2004 se suscribe el convenio de cooperacin entre el Ministerio de Educacin, Fundacin Autapo y la UMSA, cuyo objetivo es apoyar a la gestin acadmica y la planeacin educativa a travs de la instalacin del Modelo Administrativa.[CONV2004]. En la gestin 2004, se implementa el Modelo Informacional (MI) en las facultades: Ingeniera, Derecho, Humanidades, Arquitectura, Ciencias puras y Naturales. El Modelo Informacional no lleg a satisfacer en su totalidad las necesidades de los usuarios debida a la magnitud de requerimientos por parte de las carreras y la particularidad que tienen las mismas en los procesos acadmicos; por lo que se realiza la reingeniera del sistema con un nuevo planteamiento y visin de los procesos acadmicos que se tienen en la UMSA, ejecutando una reestructuracin de procedimientos y de datos, bajo la misma plataforma de desarrollo. De esta manera se plantea la implementacin y desarrollo de una versin actual del sistema de gestin acadmica para Facultad de Ciencias Geolgicas. La situacin de gestin acadmica en la que se encuentran las dos carreras es: La carrera de Ingeniera Geogrfica de la Facultad de Ciencias Geolgicas cuenta con el Sistema Acadmico del DSIE (Departamento de Sistemas de Informacin y Estadsticas ex CPDI), sistema desarrollado en lenguaje de programacin Foxpro para plataforma DOS, el cual permite inscripciones sin el control de prerrequisitos, reporte de estudiantes por materia, historial acadmico, certificado de notas y actas finales. La carrera de Ingeniera Geolgica y del Medio Ambiente de la Facultad de Ciencias Geolgicas cuenta con una base de datos en Access, donde se tiene una sola tabla donde se registra las notas, cuyos campos son: apellidos, nombres del estudiante, nombre de la Informacional de Gestin Acadmica

materia, nota, turno, semestre, gestin, observacin, plan. Se tiene reportes de record acadmicos de estudiantes, mediante una consulta por apellido y nombre del estudiante. 1.3. Planteamiento del Problema Las carreras de Facultad de Ciencias Geolgicas cuentan con sistemas diferentes para la administracin y el control de los datos, que no controla los problemas que se presentan: En inscripciones: no se tiene un sistema que controle horarios, prerrequisitos, aulas, retiro y adicin. Datos incorrectos en nombres y notas de estudiantes. Record acadmico e historial acadmico: los estudiantes tienen que esperar para verificar sus notas, muchas veces no son atendidos rpidamente debida al trabajo arduo que tienen los kardixtas pues tambin asumen el cargo de secretaria. No se tiene el registro de notas que son modificadas por causas de error al transcribir o por resolucin. No existe un flujo de informacin rpido y preciso (record acadmico, actas, historial acadmico, reportes, listados) pues algunos procesos se realizan manualmente. Registro de notas por los docentes: presentan sus notas en actas impresas para luego ser transcritas, lo cual demora mucho tiempo. Con esto se plantea el siguiente problema: La Facultad de Ciencias Geolgicas no cuenta con un sistema de gestin acadmica.

1.4. Objetivos 1.4.1. Objetivo principal Implementar y desarrollar el Sistema de Gestin Acadmico que automatic los procesos acadmicos de tal manera se logre controlar, administrar y agilizar la informacin acadmica que tiene cada carrera de la Facultad de Ciencias Geolgicas. 1.4.2. Objetivos secundarios Realizar el relevamiento de datos de las 2 carreras (adquisicin de informacin: planes de estudio, matriz de convalidaciones, prerrequisitos, modalidades de

inscripcin, resoluciones, cronogramas, levantamiento de base de datos, entrevistas con autoridades) Migracin de las bases de datos de la Carrera de Ingeniera Geogrfica e Ingeniera Geolgica y del Medio Ambiente al nuevo modelo de base de datos en PostgreSQL. Depuracin de datos. Verificacin de datos. Disminuir tiempos en los procesos acadmicos. Implementar el sistema de gestin acadmico en las 2 carreras de la Facultad de Ciencias Geolgicas. Desarrollar y modificar mdulos de acuerdo a los requerimientos de cada carrera. Plantear un modelo de reingeniera de software y su aplicacin.

1.5. Justificacin 1.5.1. Social El sistema actual no satisface a los requerimientos acadmicos de la carrera, debido al crecimiento poblacin estudiantil y los cambios que van surgiendo, el sistema permitir a las autoridades (directores), kardixtas agilizar procesos acadmicos: la inscripcin; control de prerrequisitos y convalidaciones. Una atencin mejor hacia al estudiante brindndole una informacin rpida. Autoridades que podrn obtener reportes, listados ms rpidamente. 1.5.2. Tecnolgica Como el Sistema de Gestin Acadmica, est bajo la subvencin del Programa UMSATIC y la Cooperacin SUECA organismo que financia el proyecto, se tiene equipos que son necesarios para la implementacin (equipos e infraestructura de red). El desarrollo del sistema ser con las tecnologas actuales, lenguaje de programacin: java; gestor de base de datos: PostgreSQL, en servidores LINUX 1.5.3. Econmica El Sistema de gestin Acadmica, no contraer ningn costo para cada carrera pues est bajo la subvencin del Programa UMSATIC, la Cooperacin SUECA. Las tecnologas utilizadas para el desarrollo son: software libre y de cdigo abierto (licencias libres). 1.6. Aportes Proporcionar una herramienta que brinde informacin veraz, oportuna y confiable a la institucin.

 Se realizar un estudio de la reingeniera de software, del sistema Modelo Informacional al Sistema de Gestin Acadmica, que surge a partir de la necesidad de requerimiento de los usuarios. 1.7. Limites y Alcances El proyecto abarcara la implementacin del sistema y desarrollo para los tipos usuarios: kardixta, estudiante, docente, autoridad. Para tal efecto el sistema soportara los siguientes mdulos: Planificacin acadmica (asignaciones: docentes, paralelos, cupos,

planificacin de horarios) Inscripciones (prerrequisitos, restricciones, habilitaciones de materias, retiro y adicin) Reportes(listados de inscritos, etc) Actas Censo Rectificaciones (notas por resolucin) Seguimiento acadmico (historial acadmico, record acadmico)

1.8. Metodologa La metodologa que se utilizar es la ingeniera de requerimientos de software para la realizacin de documento de especificacin de requisitos de software, se aplica lo que es el IEEE 830-1998 para el anlisis de requerimientos.

10

Metodologa del Proceso Unificado de Desarrollo (RUP) en la que vine juntamente al lenguaje UML (Lenguaje Unificado de Modelado), para el desarrollo del software que lleva consigo el anlisis, diseo, implementacin y prueba del sistema. 1.9. Tcnicas Y Herramientas

Para el desarrollo e implementacin del sistema se utilizara las siguientes herramientas:

Estndar de la IEEE 830-1998 para la especificacin de requisitos. Metodologa del Proceso Unificado de Desarrollo (RUP), representacin del sistema. UML para

Arquitectura Modelo Vista Controlador (MVC que es un paradigma de programacin para el desarrollo de aplicaciones).

Arquitectura Cliente / servidor Estndar Java Enterprice Edicion (J2EE), para proporcionar especificaciones tcnicas que describen el lenguaje y que debe cumplir el servidor de aplicaciones.

Sistemas operativos bajo Linux: Debian, Knoppix 3.x, Suse. Servidor de base de datos: PostrgreSQL Lenguaje de programacin: Java/Spring Framework, JSP, Javascript, AJAX

11

CAPITULO II.
2. MARCO TERICO 2.1. Introduccin

MARCO TERICO

La reingeniera de software surge a medida que los usuarios van realizando peticiones de mantenimiento (requerimientos) y estos no llegan a satisfacerse. Se registra la peticin de mantenimiento, y se determina de quin es la responsabilidad de atenderla. Y analizar la peticin para determinar si es denegada o aceptada. Si es aceptada la peticin se presenta, los pasos a realizar son [ART9]: Se analiza el problema Se estudia la viabilidad del cambio propuesto por el usuario Se analizan las alternativas de solucin Se realizan las tareas necesarias de los procesos de desarrollo ASI, DSI, CSI Es muy importante registrar los cambios que se realizan en la documentacin 2.2. Mantenimiento de software.

La complejidad de los sistemas se incrementa paulatinamente por la realizacin de continuas modificaciones y en muchas ocasiones el mantenimiento se suele realizar bajo presin de tiempo, y poca participacin del usuario durante el desarrollo del sistema. Los tipos de mantenimiento:

12

 Mantenimiento correctivo: es el conjunto de actividades dedicadas a corregir defectos en el Hardware o en l software detectados en la etapa de pruebas. Antes de la entrega del producto de software. Mantenimiento adaptativo: es el conjunto de actividades para adaptar el sistema a los cambios (hardware y software) en su entorno tecnolgico. Mantenimiento perfectivo: conjunto de actividades para mejorar o aadir nuevas funcionalidades requeridas por los usuarios. Despus de la entrega del producto de software. Mantenimiento preventivo: conjunto de actividades para facilitar el mantenimiento futuro del sistema. 2.2.1. Costos del mantenimiento. Cuando el sistema no se llega satisfacer los requerimientos de los usuarios, los costos de mantenimiento son [ART9]: Oportunidades de desarrollo que se pierden. Insatisfaccin del cliente cuando no se puede atender en un tiempo aceptable una peticin de reparacin que parece razonable. Los errores ocultos que se introducen al cambiar el producto software durante el mantenimiento reducen la calidad global del producto. Perjuicio en otros proyectos de desarrollo cuando la plantilla tiene que dejarlos, total o parcialmente, para atender peticiones de mantenimiento.

13

Etapas de Modificacin de Actividades Mdulos Comprensin del software y Estudiar las peticiones de los cambios a realizar Estudiar la documentacin Estudiar el cdigo Modificacin del software Modificar el cdigo Actualizar la documentacin Realizacin de pruebas Disear y realizar pruebas
Figura 2.1. Costos de mantenimiento [ART9]

Tiempo % 18 % 6% 23 % 19 % 6% 28 %

La Figura 2.1 nos muestra cmo la comprensin del software y de los cambios supone casi un 50% del costo total de mantenimiento. 2.2.2. Mtodos de mantenimiento del software: Son los siguientes [ART9]: Reingeniera: examen y modificacin del sistema para reconstruirlo en una nueva forma. Ingeniera inversa: anlisis de un sistema para identificar sus componentes y las relaciones entre ellos, as como para crear representaciones del sistema en otra forma o en un nivel de abstraccin ms elevado. Reestructuracin del software: consiste en la modificacin del software para hacerlo ms fcil de entender y cambiar o menos susceptible de incluir errores en cambios posteriores. 2.3. Reingeniera

Reingeniera: la modificacin de un producto de software, o de ciertos componentes, usando para el anlisis del sistema existente tcnicas de ingeniera inversa y, para la etapa de reconstruccin, herramientas de ingeniera directa [ART9]. La definicin dada por el Reengineering Center del Software Engineering Institute de la Universidad Carnegie Mellon es:

14

Reingeniera es la transformacin sistemtica de un sistema existente a una nueva forma para realizar mejoras de la calidad en operacin, capacidad del sistema, funcionalidad, rendimiento o capacidad de evolucin a bajo costo, con un plan de desarrollo corto y con bajo riesgo para el cliente [ART10]. La reingeniera trabaja todos los niveles de abstraccin (desde la implementacin hasta el diseo) para conseguir realizar cambios ms drsticos preservando los valores de negocio del sistema.

Figura 2.2. Reingeniera [ART13].

2.3.1. Reestructuracin Es la transformacin de una forma de representacin a otra en el mismo nivel de abstraccin relativo, mientras se mantenga el comportamiento externo del sistema (funcionalidad y semntica), Es la modificacin del software para hacerlo ms fcil de entender y cambiar. [ART13]

15

2.3.2. Ingeniera Inversa El objetivo de la ingeniera inversa es obtener informacin tcnica a partir de un producto accesible al pblico, con el fin de determinar de qu est hecho, qu lo hace funcionar y cmo fue fabricado. Los productos ms comunes que son sometidos a la ingeniera inversa son los programas de computadoras y los componentes electrnicos. La ingeniera inversa extrae informacin del cdigo fuente para obtener informacin (elementos, relaciones) de alto nivel del sistema. Trata de reconstruir la lgica de un sistema de forma parcial o total. La Ingeniera Inversa trata de analizar sistemas de software para reconstruir la descripcin de alto nivel a partir de las de bajo nivel. Se denomina ingeniera inversa del software a la actividad que se ocupa de descubrir cmo funciona un programa [ART8]. Ingeniera Inversa de Datos: Extrae relaciones de datos de alto nivel a partir de estructuras de datos. Ingeniera Inversa de Procesos: Extrae especificaciones de alto nivel a partir del cdigo fuente.
Modelos de datos Diseos Modelos de procesos Interrelaciones

Nivel Lgico

Ingeniera Inversa
Nivel Fsico
Cdigo fuente Descripcin de ficheros Descripcin de datos

Figura 2.3. Tcnicas de ingeniera inversa

16

Nivel Lgico

Modelo Antiguo Rediseo

Modelo Nuevo

Ingeniera Inversa
Nivel Fsico Cdigo

Figura 2.4. Tcnicas de ingeniera inversa

Rediseo Nivel Lgico Modelo Antiguo Modelo Nuevo

Ingeniera Inversa
Nivel Fsico Cdigo Cdigo Modificado

Ingeniera hacia delante

(Forward engineering)

Figura 2.5. Tcnicas Ingeniera inversa y directa

2.3.3. Ingeniera Directa Ingeniera directa, depende mucho de la especificaciones obtenidas mediante la ingeniera inversa o de la metodologa de trabajo que se vaya a utilizar. Mediante el cual se obtenga una nueva versin del sistema con nuevas funcionalidades y de mayor calidad. 2.3.4. Reingeniera de base de datos Aplicar ingeniera inversa a un sistema consiste en recuperar o reconstruir las especificaciones funcionales y tcnicas basndose en el cdigo fuente de los programas. Sin embargo esto llega a ser muy dificultosa con las aplicaciones viejas y mal diseadas ya que extraer informacin del cdigo puede ser una tarea muy compleja. La ingeniera inversa de BD puede ayudar a extraer una especificacin conceptual, independiente de la implementacin, que provee una base para la futura evolucin del sistema de informacin [ART7].

17

En los sistemas de informacin, donde el componente central es una base de datos, la tarea de aplicar reingeniera se facilita ya que se puede hacer reingeniera de la BD independientemente de las partes procedurales. Entonces, concentrarse en hacer la ingeniera inversa de los componentes de datos de una aplicacin primero, puede ser mucho ms eficiente que tratar de aplicarlo a todo el sistema [ART7]. Dentro de los mtodos que se tienen para la obtencin de la estructura de datos podemos mencionar: La Propuesta de Andersson La mayora de las metodologas que realizan ingeniera inversa en una BD y hacen una translacin de un modelo relacional a un modelo conceptual, asumen que las dependencias funcionales y de inclusin son dadas como punto de partida. Otras metodologas usan diferentes fuentes para obtener informacin de las claves primarias y forneas. La propuesta de Andersson presta especial inters en los sistemas ms antiguos, donde la nica informacin provista por el DBMS son los nombres de las tablas, nombre de los campos, ndices y probables definiciones de vistas. Se presenta una metodologa que trata de deducir informacin de las dependencias funcionales, claves y las dependencias de inclusin. Andersson propone, a partir de los cabezales de las tablas (sin sus claves) y las consultas, crear un diagrama intermedio, el cual llama diagrama de conexin. Este diagrama inicialmente refleja informacin bsica sobre las tablas, sus relaciones y sus posibles claves. Luego, en base a criterios basados en las consultas, en las instancias de la base de datos y en algunas decisiones que deja en manos del usuario, va puliendo este diagrama hasta llegar a un diagrama de conexin final. Finalmente aplica reglas de traduccin sobre este diagrama para llevarlo a un modelo entidad-relacin [ART7]. Herramientas tecnolgicas como DBvisualizer, E/R/Estudio.

18

2.3.5. Reingeniera de interfaces de usuario Adaptar aplicaciones a las necesidades de los usuarios, respetando su lgica anterior [ART9]: Recopilacin de documentacin, manuales de usuario, etc. Entrevistas a distintos grupos de usuarios, y observacin de sus mtodos de trabajo. Uso del sistema por el propio equipo de mantenimiento, y usuarios y as nos puedan indicar la manera en que mejor trabajaran. Reconstruccin y redocumentacin de la interfaz. Si opta por un reingeniera es necesario tener en cuenta, para un buen resultado los siguientes aspectos: Habilidad para orientar el proceso de reingeniera de acuerdo con una metodologa sistemtica y amplia. Administracin coordinada del cambio para todas las funciones del negocio que se vean afectadas. Habilidad para evaluar, planificar e implementar el cambio. Habilidad para analizar el impacto total de los cambios propuestos Habilidad para visualizar y simular los cambios propuestos. Habilidad para utilizar estos modelos.

19

2.4.

Ingeniera de Software

2.4.1. Definicin de ingeniera Segn DRAE 1 define el termino ingeniara como: conjunto de conocimientos y tcnicas que permiten aplicar el saber cientfico a la reutilizacin de la materia y de las fuentes de energa. 2.4.2. Ingeniera de software La ingeniera de software es una disciplina o rea de la Informtica o Ciencias de Computacin, que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo [PRESS2003]. La ingeniera de software es una tecnologa multicapa:

Herramientas Mtodos Proceso Un enfoque de calidad

Figura 2.6. Capas de la ingeniera de software [PRESS2003]

- El proceso es el fundamento de la ingeniera del software, es la unin que mantiene juntas las capas de tecnologas y qu permite un desarrollo racional y oportuno. - Los mtodos de la ingeniera del software indican cmo construir tcnicamente el software.

DRAE, Diccionario de la Real Acadmica Espaola de la Lengua

20

- Las herramientas de la ingeniera de software proporcionan un enfoque automtico o semi-automtico para el proceso y para los mtodos. - Cualquier enfoque de ingeniera de software debe apoyarse sobre un compromiso de organizacin de calidad. Dando una visin general a la ingeniera de software podemos decir que se tiene tres fases genricas, con independencia del rea de aplicacin, tamao o complejidad del proyecto que son: Fase de definicin se centra sobre el qu, es decir se intenta identificar la informacin que ha de ser procesada, qu funcin y rendimiento se desea, qu comportamiento del sistema, qu interfaces van a ser establecidas, qu restricciones de diseo existen, y qu criterios de validacin se necesitan para definir un sistema correcto. En esta etapa se realizar la ingeniera de sistemas o de informacin, la planificacin del proyecto del software y anlisis requisitos. Fase de desarrollo se centra en el cmo, es decir cmo se han de disearse las estructuras de datos, cmo ha de implementarse la funcin dentro de una arquitectura de software, cmo han de implementarse los detalles procedimentales, cmo han de caracterizarse interfaces, cmo ha de traducirse el diseo en un lenguaje de programacin y cmo ha de realizarse la prueba. En esta etapa se realizan el diseo de software, generacin de cdigo y prueba del software. Fase de mantenimiento se centra en el cambio que se asociado a la correccin de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a la mejoras producidas por los requisitos cambiantes del cliente. Para construir la ingeniera de software adecuadamente, se debe definir un modelo de proceso de desarrollo de software.

21

2.4.3. Modelos de procesos de software Para resolver problemas reales de una empresa, un ingeniero de software o un equipo de ingenieros se deben incorporar una estrategia de desarrollo que acompae al proceso, mtodos, herramientas y las fases genricas. Esta estrategia a menudo se llama modelo del proceso o paradigma de ingeniera de software [PRESS2003]. Los modelos de procesos que existen son : Modelo lineal secuencial. Modelo de construccin de prototipos (modelo DRA). Modelos evolutivos de proceso de software (incremental, espiral). Nos enfatizaremos en el modelo evolutivo incremental, por ser el modelo que ms se ajusta al desarrollo de este proyecto de grado. 2.4.4. Modelo evolutivo incremental El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetitivamente), con la filosofa interactiva de construccin de prototipos, que se muestran a los usuarios y clientes: Se centra en la entrega de un producto operacional con cada incremento. En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes.
2

Segn [PRESSMAN03]

22

Ingeniera de Sistemas/Informacin Anlisis Diseo

Incremento 1 Cdigo Prueba

Entrega del 1er incremento Entrega del do 2 incremento Entrega del er 3 incremento
Prueba

Incremento 2

Anlisis

Diseo

Cdigo

Prueba

Incremento 3

Anlisis

Diseo

Cdigo

Prueba

Incremento 4

Anlisis

Diseo

Cdigo

Entrega del to 4 incremento

Tiempo de calendario

Figura 2.7. El modelo Incremental segn [PRESS2003].

Cada iteracin comprende 3: Planificar la iteracin (estudio de riesgos) Anlisis de los Casos de Uso y escenarios Diseo de opciones arquitectnicas Codificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin Evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) Preparacin de la entrega (documentacin e instalacin del prototipo)

Segn [ART5]

23

2.5.

Estndar de la IEEE 830-1998 para la Especificacin de Requisitos

2.5.1. Ingeniera de requerimientos El IEEE define: Proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definicin del sistema. El proceso de estudio y refinamiento de un sistema. Requisito o Requerimiento como: Condicin o aptitud necesaria para resolver un problema o alcanzar un objetivo. Condicin o facilidad que debe proporcionar un sistema o algunos de sus subsistemas para satisfacer un contrato, norma, especificacin o cualquier otra condicin impuesta formalmente a travs de un documento. Una representacin documentada de una condicin o facilidad. Concepto de requerimiento: existen dos tipos: Funcionales: que describen los servicios o funciones del sistema. No funcionales: describen las restricciones del sistema o del proceso de desarrollo, interfaz, atributos de calidad, y adems estos requisitos son mas difciles de cuantificar. 2.5.2. Definicin de requerimientos. Expresa en lenguaje natural (con diagramas) los servicios y restricciones operacionales del sistema. Se genera con la informacin proporcionada por el cliente. Especificacin de requerimientos Documento estructurado que describe con detalle los servicios del sistema. A veces llamado especificacin funcional. Escrito como contrato con el cliente.

24

 Especificacin Software Escrito para los diseadores. Sirve de base para el diseo y desarrollo del sistema. 2.5.3. Documentacin de los requerimientos El anlisis y desarrollo de requerimientos tiene como producto final: un acuerdo documentado entre el cliente y el grupo de desarrollo acerca del producto a ser construido. El documento es conocido como: Especificacin de Requerimientos del Software, Especificacin Funcional o Especificacin del Sistema. IEEE Std 830 - Caractersticas de un buen documento de especificacin de requerimientos: Correcto Claro, sin ambigedades Completo Consistente Verificable Modificable Trazable El documento ser preparado conjuntamente entre el: Cliente: Conoce, comprende los problemas propios. Proveedor: Conoce, comprende los procesos del desarrollo.

25

2.6.

Metodologa de Desarrollo de Software

En un proyecto de desarrollo de software la metodologa define Quin debe hacer Qu, Cundo y Cmo debe hacerlo. Todas las metodologas y herramientas tienen un nico fin: producir software de gran calidad. Se eligi RUP (Rational Unified Process) ya que es una metodologa que involucra un anlisis de riesgo, cubre todo el ciclo de vida del producto, soporta un enfoque de desarrollo incremental, proporciona iteraciones tempranas que se enfocan en validar y producir una arquitectura de software, y un ciclo de desarrollo inicial que toma la forma de un prototipo ejecutable que gradualmente evoluciona convirtindose en el sistema final y adems tiene implcito en su proceso de desarrollo la evaluacin continua de la calidad con respecto a los requerimientos de calidad deseados Kruchten, 1996 [ART6]. 2.6.1. RUP (RATIONAL UNIFIED PROCESS) Es un proceso de Ingeniera de Software planteado por Kruchten (1996) cuyo objetivo es producir software de alta calidad, es decir que cumpla con los requerimientos de los usuarios dentro de una planificacin y presupuesto establecidos. Cubre el ciclo de vida de desarrollo de software. RUP toma en cuenta las mejores prcticas en el modelo de desarrollo de software en particular las siguientes [ART6]: Desarrollo de software en forma iterativa. Manejo de requerimientos. Utiliza arquitectura basada en componentes. Modela el software visualmente (con UML Unified Modeling Language). Verifica la calidad de software. Controla los cambios.

26

El proceso iterativo de RUP se organiza en fases (Kruchten, 1996), cada fase se concluye con una piedra de milla 4 principal (mile stone). Es importante indicar que la inclusin de piedras de millas o puntos de revisin, es sumamente importante pues en estos puntos se revisan los requerimientos establecidos para cada fase, basados en los controles de calidad [ART6].
Inicio (Inception) Elaboracin (Elaboration) Construccin (Construction) Transicin (Transition)

Objetivos del Ciclos de Vida

Arquitectura del Ciclo de Vida

Capacidad de Operacionalidad Inicial

Producto Final

Figura 2.8. Fases de Racional Unified Process (RUP) - Kruchten (1996)

La inversin de tiempo y esfuerzo que se dedican, a cada una de las fases, se representa en la siguiente grafica, donde se ve que la mayor parte del trabajo (costo y esfuerzo), se realiza cuando se pasada la 2da fase (la segunda piedra milla, la segunda revisin de control de calidad).

1 fase

ra

2 fase

da

3 fase

ra

4 fase

ta

Figura 2.9. Expresin grafica del tiempo y esfuerzo dedicados a cada fase de RUP (Krtuchten, 1996)

FASES DE RUP: Son 4 las fases que se tienen: a) Inicio c) Construccin

4

b) Elaboracin d) Transicin

Piedra de milla o puntos de revisin, representados con el smbolo:

27

Figura 2.10. Fases del Proceso Unificado (RUP), [JACO2000]

a) Fase de Comienzo o Inicio: Est principalmente dirigida al entendimiento de los requerimientos y determinar el alcance del esfuerzo de desarrollo. Se define la idea, la visin y el alcance del proyecto. Esta fase incluye la fase de anlisis y diseo. Se realiza un anlisis de los requerimientos que tienen los kardixtas, esta fase termina con la determinacin de los objetivos del ciclo de vida. Actividades que se realizan en esta fase: Un documento con la visin del proyecto. Un plan del proyecto que muestre las fases y las iteraciones. El modelo de casos de uso con una lista de todos los casos de uso y los actores que puedan ser identificados. Un glosario inicial del proyecto.

28

 Un estudio inicial de riesgos y su evaluacin. Una lista de los requerimientos y restricciones principales del sistema a desarrollar. Los productos que se tienen son: El modelo de dominio en su primera versin. Un esquema de los modelos, modelo de casos de uso, modelo de anlisis, y el modelo de diseo. b) Fase de Elaboracin: Planificar las actividades necesarias y los recursos requeridos, especificando las

caractersticas y el diseo de la arquitectura de software es decir: Comprender un 80% de los casos de uso para alcanzar los objetivos de esta fase. Afrontar los riesgos que interfieren en la consecucin de este objetivo. Actividades que se realizan en esta fase: Actualizacin del plan de iteracin. Generar una lista revisada de riesgos. Realizar la arquitectura del software. Revisar los requerimientos complementarios. Construir un tipo de prototipo de interfaz del usuario. Los productos que se tienen son:

29

 Un modelo de dominio completo. Una nueva versin de los modelos: modelo de casos de uso, modelo de anlisis, y el modelo de diseo. c) Fase de Construccin Desarrollar el producto y evolucionar la visin, la arquitectura y los planes hasta que el producto en su primera versin este listo para ser presentado a los usuarios [ART6]. Actividades que se realizan en esta fase: Actualizar el plan de iteracin. Revisar la lista de riesgos. Gerenciar los recursos (herramientas, base de datos). Actualizar el plan de proyecto d) Fase de Transicin Realizar la transicin del producto a los usuarios, lo cual incluye: manufactura, envo, entrenamiento, soporte y mantenimiento del producto hasta que el cliente est satisfecho. Esta fase culmina con la versin de producto, la cual a su vez concluye el ciclo [ART6]. Actividades que se realizan en esta fase: Realizar la evaluacin del usuario. Implementacin del sistema, realizar los ajustes necesarios.

30

2.6.2. Anlisis y diseo orientado a objetos (AOO y DOO) a) Paradigma Orientado a Objetos Las tecnologas de objetos nos llevan a realizar sistemas complejos de manera ms fcil a partir de la reutilizacin de componentes. El desarrollo de software orientado a objetos llega a ser ms rpido y flexible, es un nuevo enfoque sobre la manera de organizar las diferentes piezas que componen un sistema de informacin. Los sistemas orientados a objetos tienden a evolucionar con el tiempo (modelo evolutivo de proceso acoplado con un enfoque que fomenta la reutilizacin de componentes). Tres principales principios de orientado a objetos. Herencia, este principio es muy importante en Orientado a Objetos, pues es donde se radica la reusabilidad, la extensibilidad y bajo costo de mantenimiento de los informticos basados en objetos. La herencia radica en crear nuevas clases u objetos(instanciar), heredando los atributos de una(herencia simple) o varias clases (herencia mltiple) Polimorfismo: La misma operacin es resuelta de diferente forma segn el objeto que recibe el mensaje. Encapsulamiento: permite ocultar a los usuarios el detalle de la implementacin de un objeto. El objeto oculta sus datos a otros objetos y solo permite acceder a sus datos vas sus propios mtodos mediante mensajes especficos, es decir, se crea una Caja Negra que solo el constructor del objeto conoce, a esto se llama ocultamiento de la informacin. b) Anlisis orientado a objetos (AOO) El proceso de anlisis comienza con la definicin de los casos de uso. La tcnica de modelado de clases-responsabilidades-colaboraciones se aplica para documentar las clases y sus

31

atributos y operaciones. Tambin se proporciona una vista inicial de las colaboraciones que ocurren entre objetos. El siguiente paso es la clasificacin de objetos y la creacin de la jerarqua de clases. El objeto-relacin proporciona informacin sobre las conexiones [PRESS2003]. c) Diseo orientado a objetos (DOO) El diseo orientado a objetos traduce el modelo de anlisis orientado a objetos del mundo real. Para el diseo orientado a objetos existen mtodos, UML y otros mtodos aproximan el proceso de diseo mediante dos niveles de abstraccin: diseo de subsistemas (arquitectura), y el diseo de objetos individuales [PRESS2003]. d) Programacin orientada a objetos (POO) Extiende el modelo de diseo a un dominio de ejecucin. Un lenguaje de programacin orientado a objetos se usa para traducir las clases, atributos, operaciones y mensajes, de manera que puedan ejecutarse por la maquina [PRESS2003].

32

2.6.3. UML (Lenguaje Unificado de Modelado) El UML (Lenguaje Unificado de Modelado) es la creacin de Grady Booch, James Rumbaugh e Ivar Jacobson; en 1994 Rumbaugh ingres a Rational Software Corporation, donde ya trabajaba Booch, Jacobson ingreso un ao despus. UML es una de las herramientas ms emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseos que capturen sus ideas en una forma convencional y fcil de comprender para comunicarlas a otras personas [SCHMULLE]. UML est conformado por diferentes diagramas que nos permitirn realizar la representacin (anlisis) de lo que har el sistema, la finalidad de los diagramas es presentar diversas perspectivas de un sistema a las cuales se les conoce como modelo 6. Adems que permite al analista de sistemas generar un anteproyecto de varias facetas que sean comprensibles para los clientes, desarrolladores y todos aquellos que estn involucrados en el proceso de desarrollo. Los diagramas de UML se pueden dividir en estticos (aportan una visin del sistema) y dinmicos (aportan una visin dinmica del sistema). Diagramas Estticos: Con el nombre de Diagramas Estticos se engloba tanto al Modelo Conceptual de la fase de Anlisis como al Diagrama de Clases de la fase de Diseo. Ambos son distintos conceptualmente, mientras el primero modela elementos del dominio el segundo presenta los elementos de la solucin software. Sin embargo, ambos comparten la misma notacin para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones) [ART3].
5

Diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos. 6 Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito.

33

 Diagramas de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa [ART3]. Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. Actores es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Casos de Uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. Relaciones entre Casos de Uso entre dos casos de uso puede haber las siguientes relaciones: Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad. Usa: Cuando un caso de uso utiliza a otro. Se representan como una lnea que une a los dos casos de uso relacionados, con una flecha en forma de tringulo y con una etiqueta <<extiende>> o <<usa>> segn sea el tipo de relacin. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja

34

del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. Modelo Conceptual nos muestra los conceptos presentes en el dominio del problema. Un concepto para este caso, en trminos de la Programacin Orientada a Objetos, es un objeto del mundo real; es decir, es la representacin de cosas del mundo real y NO de componentes de software. En l no se definen operaciones (o mtodos); en este modelo se pueden mostrar los conceptos, los atributos de los conceptos (opcionalmente) y la relacin o asociacin entre ellos. Informalmente podramos decir que un concepto es una idea, cosa u objeto. Para descubrirlos debemos analizar los sustantivos en las descripciones textuales del dominio del problema, es decir, de la descripcin del sistema, de los requerimientos y de los Casos de Uso [WEB5] Diagrama de clases es el diagrama principal para el anlisis y diseo del sistema. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. Diagramas dinmicos Son aquellos que muestran las interacciones de un usuario con el sistema. Interaccin es una cadena de mensajes enviados entre los objetos en respuesta a un evento generado por el usuario sobre la aplicacin. Los diagramas de interaccin pueden ser Diagramas de Secuencia. Este diagrama conforma la etapa del diseo de la aplicacin, y se crean a partir de los diagramas de Casos de Uso y el Conceptual. [WEB5] Los Diagramas de Secuencia representan una interaccin entre objetos de manera secuencial en el tiempo. Muestra la participacin de objetos en la interaccin entre sus lneas de vida (desde que se instancias) y los mensajes que ellos organizadamente intercambian en el tiempo. El responsable o ACTOR es quien inicia el ciclo interactuando inicialmente con la interfaz de usuario: GUI; en seguida se inician todos los objetos que intervienen en el funcionamiento del aplicativo. En este diagrama se

35

comienza a observar el comportamiento del sistema a partir de los eventos generados por los actores. Aqu se interacta con instancias, no con clases [WEB5] El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML Grady Booch 2.7. Calidad de Sistema

Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad [ART1]. Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta de calidad [ART1]. El aseguramiento (garanta) de calidad del software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad, el aseguramiento de calidad de software se disea al comenzar el proceso de desarrollo y no despus. Y est presente en [ART1]: Mtodos y herramientas de anlisis, diseo, programacin y prueba. Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo de software. Control de la documentacin del software y de los cambios realizados. Procedimientos para ajustarse a los estndares (y dejar claro se esta fuera de ellos). Mecanismo de medidas (Mtricas). Registro de auditorias y realizacin de informes.

36

Las actividades para el aseguramiento de calidad de software son: Mtricas de software para el control del proyecto Verificacin y validacin del software a lo largo del ciclo de vida (incluye las pruebas y los procesos de revisin e inspeccin) [ART1]. Las especificaciones de la calidad de un producto de software han sido objeto de trabajo de varios grupos de los cuales uno de los ms destacados es el modelo de McCall. Este modelo establece tres reas principales que intervienen en la calidad de del software: 1. Calidad en la operacin del producto (software): requiere que el software pueda ser entendido fcilmente que opere eficientemente y que los resultados obtenidos sean los requeridos inicialmente por el usuario. 2. Revisin de la calidad del producto de software: Tiene como objetivo realizar revisiones durante el proceso de desarrollo para detectar los errores que afecten a la operacin del producto. 3. Calidad en el proceso: Requiere de la definicin de estndares y procedimientos que sirvan como base para el desarrollo del software [ART2]. Otro modelo que es importante indicar es el de Boehm, se destaca por ser uno de los mejores definidos. El modelo es de naturaleza jerrquica y los criterios de calidad se presentan en tres grandes divisiones, portabilidad: est acorde a los servicios que el sistema ofrece; Usabilidad: est de acuerdo a la operacin del producto; Mantenibilidad: de acuerdo a la mantenibilidad del producto de software. La calidad de software para sistemas de informacin en Internet ha llegado a ser de gran importancia. Porque la Conferencia Internacional de la Ingeniera de Software del ao 2002(ICSE 2002) se centro en los aspectos de calidad para sistemas en Internet. En esta conferencia se concluyo que los criterios de calidad ms importantes son los siguientes:

37

Fiabilidad Usabilidad Seguridad Disponibilidad Escalabilidad Mantenibilidad

2.7.1. Web-site QEM Web-site Quality Evaluaction Method, o Web-site QEM, propuesto por Luis Antonio Olsina, para la evaluacin, comparacin y anlisis de sistemas de informacin basados en Web, ms o menos complejos. Web-site QEM es una metodologa integral, flexible y robusta y cubre la mayor parte de las actividades del proceso de evaluacin y compararon (con otros sistemas similares para el tipo de usuario elegido para el proceso de evaluacin) de artefactos web [OLSI1999]. Se utilizara el enfoque de modelo de calidad mixto planteado por el Dr. Olsina, que es a la vez, pragmtico y flexible. Se parte de un modelo fijo (en nuestro caso, a partir del modelo de calidad ISO9126) en la que se asume que todas las caractersticas necesarias para monitorear un proyecto de evaluacin de calidad de producto, son un subconjunto de las seis

caractersticas. Por otra parte, a nivel de subcaracteristicas (segundo nivel) se definen por consenso entre evaluadores y dems partes intervinientes. Y en conjunto se define los atributos, criterios de medicin y las relaciones entre atributos, subcaracteristicas y caractersticas.

38

Se selecciona el subconjunto de caractersticas de primer nivel, conforme a las metas y el perfil de usuario seleccionado. Se considera tres tipos de usuarios visitantes (expertos y generales), desarrolladores y gerenciadores. Se selecciona caractersticas de acuerdo al usuario y se evala de acuerdo a una encuesta Donde el valor resultante ser mediante el cociente: Peso_relativo_Caract_n=Prom(Caract_N)/Suma de todos los promedios As una vez realizada el proceso de evaluacin se normaliza los pesos relativos de tal manera que la suma de estos sea 1. El principal objetivo de la metodologa es evaluar y determinar el nivel de cumplimiento de ciertas caractersticas requeridas como la usabilidad, funcionalidad, confiabilidad y efectividad y analizar preferencias o indicadores parciales y globales. Al final del proceso de evaluacin (y eventualmente de comparacin), para cada sitio seleccionado obtendremos un indicador global con valores comprendidos en una escala de 0 a 100%, que puede ser interpretados como el grado de satisfaccin de los requerimientos de calidad conforme a un perfil de usuario. El valor caer en uno de los tres niveles de aceptabilidad o barras de calidad: Satisfactorio desde 60% a 100% Marginal desde 40% a 60% Insatisfactorio desde 0% a 40% La metodologa ha sido empleada en diversos casos de estudio.

39

2.8.

Herramientas de Desarrollo de Software

2.8.1. Arquitectura modelo vista controlador MVC que es un paradigma de programacin para el desarrollo de aplicaciones. La arquitectura Model-View-Controller surgi como patrn arquitectnico para el desarrollo de interfaces grficos de usuario en entornos Smalltalk. Su concepto se basaba en separar el modelo de datos de la aplicacin de su representacin de cara al usuario y de la interaccin de ste con la aplicacin, mediante la divisin de la aplicacin en tres partes fundamentales:

Vista
Muestra al usuario la informacin que ste necesita.

Controlador
R ecibe e interpreta la interaccin del usuario, actuando sobre modelo y vista de manera adecuada para provocar cambios de estado en la representacin interna de los datos, as como en su visualizacin.

Modelo
Contiene la lgica de negocio de la aplicacin, gestiona el comportamiento y los datos de aplicacin

Figura 2.11. La arquitectura Model-View-Controller

Esta arquitectura ha demostrado ser muy apropiada para las aplicaciones web y especialmente adaptarse a las tecnologas proporcionadas por la plataforma J2EE, de manera que: El modelo, conteniendo lgica de negocio, sera modelado por un conjunto de clases Java, existiendo dos claras alternativas de implementacin, utilizando objetos java tradicionales llamados POJOs (Plain Old Java Objects) o bien utilizando EJB (Enterprise JavaBeans) en sistemas con unas mayores necesidades de concurrencia o distribucin. La vista proporcionar una serie de pginas web dinmicamente al cliente, siendo para l simples pginas HTML. Existen mltiples frameworks que generan estas pginas web a partir de distintos formatos, siendo el ms extendido el de pginas JSP (JavaServer Pages), que mediante un conjunto de tags XML proporcionan un interfaz sencillo y adecuado a clases Java y objetos proporcionados por el servidor de

40

aplicaciones. Esto permite que sean sencillas de desarrollar por personas con conocimientos de HTML. Entre estos tags tienen mencin especial la librera estndar JSTL (JavaServer Pages Standard Tag Library) que proporciona una gran funcionalidad y versatilidad. El controlador en la plataforma J2EE se desarrolla mediante servlets, que hacen de intermediarios entre la vista y el modelo, ms verstiles que los JSP para esta funcin al estar escritos como clases Java normales, evitando mezclar cdigo visual (HTML, XML). 2.8.2. Arquitectura cliente / servidor La arquitectura Cliente/Servidor es una relacin entre procesos corriendo en mquinas separadas, que interactuan por un mecanismo de pasaje de mensajes: pedido de servicio y respuesta [WEB6]. El Servidor(s) es un proveedor de servicios. El Cliente(s) es un consumidor de servicios. a) Cliente: Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en mltiples requerimientos de trabajo a travs de redes LAN o WAN. La ubicacin de los datos o de las aplicaciones es totalmente transparente para el cliente. b) Servidor: Es cualquier recurso de cmputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a travs de redes LANs o WANs, para proveer de mltiples servicios a los clientes y ciudadanos tales como impresin, acceso a bases de datos, fax, procesamiento de imgenes, etc. c) Infraestructura de redes: Componentes Hardware y Software que garantizan la conexin fsica y la transferencia de datos entre los distintos equipos de la red.

41

red

Servidor

Clientes
Figura 2.12. Arquitectura cliente/servidor

En el modelo Cliente/Servidor podemos encontrar las siguientes caractersticas [WEB6]: El Cliente y el Servidor pueden actuar como una sola entidad y tambin pueden actuar como entidades separadas, realizando actividades o tareas independientes. Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o en la misma plataforma. Un Servidor da servicio a mltiples clientes en forma concurrente. Cada plataforma puede ser escalable independientemente. Los cambios realizados en las plataformas de los Clientes o de los Servidores, ya sean por actualizacin o por reemplazo tecnolgico, se realizan de una manera transparente para el usuario final. La interrelacin entre el hardware y el software estn basados en una infraestructura poderosa, de tal forma que el acceso a los recursos de la red no muestra la complejidad de los diferentes tipos de formatos de datos y de los protocolos. Un sistema de servidores realiza mltiples funciones al mismo tiempo que presenta una imagen de un solo sistema a las estaciones Clientes. Esto se logra combinando los recursos

42

de cmputo que se encuentran fsicamente separados en un solo sistema lgico, proporcionando de esta manera el servicio ms efectivo para el usuario final. Tambin es importante hacer notar que las funciones Cliente/Servidor pueden ser dinmicas. Ejemplo, un servidor puede convertirse en cliente cuando realiza la solicitud de servicios a otras plataformas dentro de la red. Su capacidad para permitir integrar los equipos ya existentes en una organizacin, dentro de una arquitectura informtica descentralizada y heterognea. Designa un modelo de construccin de sistemas informticos de carcter distribuido. Su representacin tpica es un centro de trabajo (PC), en donde el usuario dispone de sus propias aplicaciones de oficina y sus propias bases de datos, sin dependencia directa del sistema central de informacin de la organizacin, al tiempo que puede acceder a los recursos de este host central y otros sistemas de la organizacin ponen a su servicio. 2.8.3. Estndar Java Enterprice Edicin (J2EE) J2EE (Java 2, Enterprise Edition), versin empresarial de la plataforma aplicaciones Java 2, de Sun Microsystems, que aporta estndares creacin de aplicaciones web (servlets, JSP), el acceso a bases tratamiento de XML (JAXP), servicios de directorio (JNDI). Se denomina plataforma porque proporciona especificaciones tcnicas que describen el lenguaje pero, proporciona las herramientas para implementar productos de software basados en J2EE. 2.8.4. Sistemas operativos bajo Linux Software de base: GNU/Linux Debian v3.0 Woody, Knoppix 3.x (basado en Debian), Suse Enterprice 9.

43

2.8.5. Sistema manejador de base de datos PostgreSQL es un administrador de base de datos relacional, de alta velocidad y es software libre. Para el desarrollo de base de datos se cuenta con PGACCESS que es una herramienta de interfaz grafica. 2.8.6. Lenguajes de programacin J2SDK, es un paquete que contiene el entorno de desarrollo de Java de Sun. Nos permite desarrollar programas java y proporciona el entorno de ejecucin: API de J2SE, la maquina virtual, y herramientas de la plataforma java. Spring Framework, entorno para el desarrollo de aplicaciones fomentando el patrn inversin de control y la integracin entre tecnologas. Spring es un framework de Java/J2EE que ofrece, contenedor ligero, soporta AOP, abstracciones JDBC, metadatos a nivel de cdigo fuente y framework MVC. Apache Ant, es un proyecto de Apache Yakarta. ANT es una herramienta OpenSource utilizada en la compilacin y creacin de programas Java. Yakarta Tomcat, es un contenedor de Servlets con un entorno JSP. El funcionamiento principal de apache desde su creacin fue la de aceptar y responder requisiciones de Pagina en Internet, estas requisiones correspondan a documentos estticos (puro HTML), es por eso que cuando se requera ejecutar algn tipo de contenido dinmico (programas) como JAVA, es necesario coordinar los esfuerzos de Apache con otro ambiente, en el caso de JAVA es precisamente TOMCAT quien ofrece facilidades para ejecutar los dos componentes ms utilizados en ambientes JAVA como es JSPs y SERVLETS. ORM, es un mapeador objeto-relacional que proporciona un puente entre la orientada a objetos y los sistemas de gestin de bases de datos relacionales.

44

 JSP (Java Server Pages) para el desarrollo del interfaz. AJAX Asynchronous JavaScript And XML (JavaScript y XML asncronos), se trata de una plataforma de desarrollo para lo que se ha llamado aplicaciones Web ricas, esto es, pginas Web con una interaccin inmediata con el usuario, sin necesidad de recargar continuamente la pgina para que se produzcan cambios. La funcin principal de Backbase consiste en proporcionar la capa de presentacin para las aplicaciones Web, para ello utiliza una parte desarrollada con JavaScript que se ejecuta en el navegador del cliente, un lenguaje de declaracin de interfaz llamado BXML y una parte servidor que existe para Java y para .NET.

45

CAPITULO III.

MODELO TERICO REINGENIERA DE SOFTWARE

3. MODELO TERICO 3.1. Propuesta de Metodologa de Reingeniera de Software

El objetivo de esta investigacin es crear una versin de software de mayor calidad y una mejor mantenibilidad. A continuacin present las fases del modelo que propongo para la reingeniera de software, en la Figura 3.1:

Figura 3.1 Fases del modelo de la reingeniera de software [Elaboracin propia]

a) Anlisis del mantenimiento del software: En esta etapa se realiza un anlisis del manteniendo que se est realizando actualmente al Sistema de Software, principalmente se realiza un estudio del tiempos en que se modifica un modulo. b) Una visin general del software: En esta etapa se llega ver un enfoque general y su funcionamiento actual del software en tres aspectos: la base de datos, el cdigo fuente y la interfaz de usuario.

46

c) Estudio de costos beneficios de reingeniera: Los costos y beneficios de la reingeniera de software se pude determinar de forma cuantitativa. El costo del statuo quo, esto es, los costos asociados al mantenimiento y soporte que conlleva una aplicacin existente se puede comparar con los costos estimados de la reingeniera y con la reduccin resultante de los costos de mantenimiento. En casi todos los casos en que un programa tiene vida larga y muestra en la actualidad un mantenimiento dificultoso, la reingeniera representa una estrategia de negocios eficiente en relacin con los costos. [PRESS2003]. P1= costo de mantenimiento anual actual para una aplicacin P2= costo de operacin anual de una aplicacin P3= valor de negocios anual actual de una aplicacin P4= costo de mantenimiento anual predicho despus de la reingeniera P5= costo de operaciones anual predicho despus de la reingeniera P6= valor de negocio actual predicho despus de la reingeniera P7=costos de reingeniera estimados P8= fecha estimada de reingeniera P9= factor de riesgo de la reingeniera (p9=1,0 es valor nominal) L= vida esperada del sistema El costo asociado al mantenimiento continuado de una aplicacin se define como: Cmant = [P3-(P1+P2)] * L

47

El costo asociado a la reingeniera de una aplicacin se define como: Creing = [P6 - (P4 + P5)] * [(L - P 8) - (P7 * P9)] Utilizando las ecuaciones anteriores mencionadas los beneficios globales de la reingeniera se pueden calcular de la siguiente manera: Beneficio y costo = C reing - Cmant Aquellas aplicaciones que muestren el mayor beneficio en relacin con los costos podrn destinarse a la reingeniera, mientras que las dems podrn ser propuestas hasta que se dispongan de ms recursos. d) Decisin ejecutiva: A los ejecutivos se debe explicar y fijar metas y prioridades para el proyecto adems de mostrar el estudio realizado de costos-beneficios de reingeniera que les d un panorama general del actual sistema de software. e) Reingeniera: Ingeniera Inversa (de base de datos, cdigo, interfaz de usuario) Rediseo: consiste en modificar los modelos obtenidos, aadiendo nuevas funciones de acuerdo a los requerimientos de usuarios. Ingeniera Directa: corresponde al desarrollo de software. f) Tecnologas: Se considera las nuevas herramientas tecnolgicas como los lenguajes de programacin, gestor de base de datos que se utilizaran para la etapa de desarrollo de la nueva versin de software.

48

El modelo propuesto se realiza en funcin de los autores: Morales Mauri Carla, Reingeniera como mtodo para el mantenimiento del software. Pressman Roger S, Ingeniera del Software, un enfoque prctico.8 Morris Daniel & Brandon Joel,Reingeniera, como aplicarla con xito en los negocios.9 Alfredo Rodrguez, Antonio Mrquez, Miguel Toro, Gestin de la evolucin del software.10 Carmen Hernndez, Flix Prieto, Miguel Laguna, Yania Crespo, La Fase de Abstraccin Conceptual en Reingeniera deBases de Datos mediante Anlisis de Conceptos Formales1.11 Martin Andersson, implementacin de propuesta de DBRE de "Extracting an Entity Relationship Schema from a Relational Database through Reverse Engineering".
12 7

Jos L. Leiva Olivencia, Aplicacin de Tcnicas de Ingeniera Inversa y Reingeniera en Bases de Datos de Sistemas Informticos de Gestin Hotelera. Mantenimiento de software.14 Master Oficial en Sistemas Telemticos e Informticos, Tcnicas y Herramientas de reingeniera Software.15 Fundamentos de Ingeniera del Software -Mantenimiento del software.16
7 8

13

[MORA1997]

[PRESS2003 ] 9 [MOR &BRAN ] 10 [ART10] 11 [ART11] 12 [ART7 ] 13 [ ART12] 14 [ ART13] 15 [ ART8] 16 [ART9]

49

3.2.

Aplicacin de la Metodologa Propuesta de Reingeniera de Software

3.2.1. Anlisis del mantenimiento del software El mantenimiento que se realiza al sistema llega a ser muy moroso y pesado, los usuarios deben solicitar muchos requerimientos, y adaptar los mdulos para satisfacer los requerimientos solicitados. En la Figura 3.2 detallo el esfuerzo del mantenimiento, para un requerimiento, especficamente en el modulo de inscripciones, de acuerdo a la experiencia que personalmente obtuve. Los primeros pasos a efectuar son: Que es lo que hace Como es el proceso Se realiza un anlisis y diseo del requerimiento Codificacin y pruebas Los puntos detallados se engloban en los que es la modificacin del cdigo Los puntos detallados se engloban en los que es la compresin del cdigo

Comprensin del cdigo

60 %

40%

Modificacin del cdigo

Figura 3.2. Grafico del esfuerzo de mantenimiento [Elaboracin propia]

50

Como se puede observar en la Figura 3.2, la compresin del cdigo llego a tener mayor esfuerzo y tiempo que el diseo y la modificacin del codigo. Y es as que los usuarios: autoridades, kardixtas, docentes, y estudiantes en el transcurso del tiempo tienen ms requerimientos, muchos de los mdulos se fueron adaptando realizando parches 17 al sistema para satisfacer los requerimientos de la carrera. 3.2.2. Una visin general del software a) Base de datos: con poca documentacin, identificar las caractersticas de las tablas. b) Cdigo fuente: con demasiados parches debidos a la adaptacin del sistema y los requerimientos de los usuarios, donde cada modificacin llega a ser ms dificultoso. c) Interfaz del usuarios:
-

mediante consultas SQL se llegan a

La interfaz que tiene el sistema son muy repetitivas. La respuesta al usuario es muy lenta, la navegabilidad de pagina a pagina es cansador para el usuario.

Los reportes que se presentan se imprimir con un programa aparte del sistema en Python, lo que representa un soporte al mantenimiento adicional del sistema

3.2.3. Estudio de costos beneficios de reingeniera Los costos de mantenimiento y de la reingeniera son: P1= 57600 - costo de mantenimiento anual actual para una aplicacin P2= 25000

17

Parches: solucin provisional que se da algn problema, a la larga poco satisfactoria.

51

P3= 100000 P4= 19200 P5= 25000 P6= 125000 P7= 153600 P8= 1 ao P9= 0.3 L= 5 aos El costo asociado al mantenimiento continuado de una aplicacin se define como: Cmant = [P3-(57000+25000)] * L Cmant = [100000-(P 1+P 2)] * 5 = 87000 El costo asociado a la reingeniera de una aplicacin se define como: Creing = [P6 - (P4 + P5)] * [(L - P 8) - (P7 * P9)] Creing
=

[[125000 - (19200 + 25000)] * (5 - 1)] [(153600 * 0.3)]

Creing = [ 125000-44200]*5 - [46080] Creing = [ 125000-44200]*5 - [46080] = 404000-46080 = 399392 Beneficio y costo = 399392 87000 = 312392

52

3.2.4. Decisin ejecutiva Basndose en el estudio de costos-beneficios de reingeniera se determina la ejecucin de la nueva versin del Sistema de Gestin Acadmica. 3.2.5. Reingeniera: Se realizar reingeniera para los mdulos del sistema:

Planificacin acadmica (asignaciones: docentes, paralelos, cupos, planificacin de horarios)

Inscripciones (prerrequisitos, restricciones, habilitaciones de materias, retiro y adicin) Actas Rectificaciones (notas por resolucin) Seguimiento acadmico (historial acadmico, record acadmico) Censo (nuevos mdulos) Reportes(listados de inscritos, etc) (nuevos mdulos)

a) Ingeniera inversa: a.1) Base de datos El manejador de base de datos con la que trabaja el Modelo Informacional es PostgreSQL, esto nos permite ms fcilmente ver la estructura de la base de datos y as realizar la ingeniera inversa de la base de datos.

53

Se realizaron archivos con consultas SQL (scripts), para la obtencin de la estructura de las tablas. Estos archivos se ejecutaron a la base de datos PostgreSQL, como se ve en la Figura. Descripcin de la tabla Materias.

Figura 3.3. Descripcin de la tabla materias

Aqu se vieron que los campos de las tablas no son descriptivos en algunos casos. Para obtener el diagrama entidad relacin E/R la herramienta que se utiliz es el programa dbVisualizer, por la magnitud de la Base de Datos se tuvo que realizar algunos detalles manualmente para su mejor entendimiento.

54

Figura 3.4. Diagrama E/R del Modelo Informacional

55

a.2) Cdigo Fuente Los diagramas que se presentan a continuacin se obtuvieron con la poca documentacin y la interaccin con el sistema Modelo Informacional.

56

Figura 3.5. Diagrama de flujo del modulo de asignacin docente

Figura 3.6. Diagrama de flujo del modulo de inscripcin autoridad

57

Figura 3.7. Diagrama de flujo del modulo de inscripcin autoridad

58

MODULO: INSCRIPCIONES ENLACE: Retiro y adicin de materias RESPONSABLE: administrador de sistemas, Director de carrera y Estudiante

Unidad y responsable

Proceso

Observaciones

inicio

Administrador de sistemas
Ingresar la clave del usuario

Director de carrera
Ingresar RU, CI o nombres de estudiante

Estudiante

Seleccionar una de las acciones: retiro y/o adicin de materias o Cambio de paralelo

retiro De la lista de materias inscritas, elegir la materia que quiere retirar

Cambio de paralelo De la lista de materias elegir la materia adicin

De la lista de materias, elegir la materia y paralelo

Revisar los datos elegidos y confirmar

Seleccionar el paralelo al cual quiere cambiar

Guardar

Fin

59

Figura 3.8. Diagrama de flujo del modulo de adicin y/o retiro de materias

Figura 3.9. Diagrama de flujo del modulo Ver inscripcin de materias

60

Figura 3.10. Diagrama de flujo del modulo Inscripcin autoridad

Figura 3.11. Diagrama de flujo del modulo Inscripcin autoridad

61

Figura 3.12. Diagrama de flujo del modulo Estudiantes validados

a.3) Interfaz de usuario Todo el anlisis que se realiza y las abstracciones diagramas que se consigue, nos permitir realizar el re-diseo de la base de datos, del diseo del sistema, y del cdigo. b) Rediseo Re-diseo: consiste en modificar los modelos obtenidos, aadiendo nuevas funciones de acuerdo a los requerimientos de usuarios (autoridades, kardixtas, docentes, estudiantes) De base de datos: Si en algunos caso no llego a modificarse los nombres de los campos, se modifico el tipo de dato por ejemplo: id_persona ahora est compuesto por las inciales del nombre de la persona CYJ4306836, y anteriormente el id_persona estaba conformado por un numero entero por ejemplo: 65235. Ya que los nombres de algunas tablas y incluso los campos no eran tan descriptivas se tena que recurrir al cdigo fuente.

62

Un detalle importante es que se aadi al rediseo de la base de datos es que se coloco a todas las tablas los campos fec_registro, fec_modificacion, ult_usuario, esto para que se controle cuando los datos fueron registrados, modificados o eliminados y quien fue la persona en realizar tal operacin, y id_estado para ver el estado del registro. De interfaz: para esto se utilizara Ajax tecnologa que nos permite que la respuesta de la interfaz al usuario sea ms rpido. Este punto se desarrollar en el CAPTULO IV. c) Ingeniera directa Ingeniera Directa: corresponde al desarrollo de software. Para los mdulos: Planificacin acadmica (asignaciones: docentes, paralelos, cupos,

planificacin de horarios) Inscripciones (prerrequisitos, restricciones, habilitaciones de materias, retiro y adicin) Actas Rectificaciones (notas por resolucin) Seguimiento acadmico (historial acadmico, record acadmico)

Este punto se desarrollar en el CAPTULO IV. 3.2.6. Tecnologas Las herramientas que se utilizarn para el desarrollo son: La arquitectura modelo vista controlador, arquitectura cliente / servidor, Sistemas operativos bajo Linux, Sistema manejador de base de datos: PostgreSQL.

63

Lenguajes de programacin: J2SDK, que es un paquete que contiene el entorno de desarrollo de Java, Spring Framework, Apache Ant, Yakarta Tomcat, ORM, JSP (Java Server Pages) para el desarrollo del interfaz, AJAX Asynchronous JavaScript And XML (JavaScript y XML asncronos).

64

CAPITULO IV.

CONCRECIN DEL MODELO

4. ANLISIS, DISEO Y DESARROLLO Antes de la concrecin del modelo se realizar un anlisis de las actividades, de la situacin actual de las dos carreras de la Facultad de Ciencias Geolgicas. 4.1. Procesos Acadmicos

Las actividades que se realizan en kardex y secretaria de cada carrera las efecta una sola persona, a continuacin se detalla tales actividades: Actividades que realiza una sola persona Actividades de Kardex

Actividades acadmicas de la Secretaria

Revisin de flderes con los requisitos Elaboracin de informes de estudiantes para la emisin de certificados de nota y nuevos y antiguos de conclusin de materias. Informes de inscripcin Emisin de actas de docente con el listado de inscritos por materia Informe de retiro y adicin de materias Recepcin de actas docentes llenas para Informes de matriculacin de nuevos y la trascripcin de notas antiguos Encargado de canje de matriculas Inscripcin de estudiantes nuevos Informes de reporte de actas de notas Informes inscritos de reporte de estudiantes

Inscripcin de estudiantes antiguos por plan de estudios Elaboracin de resoluciones Encargado de recepcin, elaboracin y despacho de certificados de notas Retiro y adicin de materias por plan de estudios

65

 Emisin de listas de inscritos por materia Emisin de listas de inscritos por gestin Emisin de historial acadmico Emisin de record acadmico Encargado de la revisin de notas con actas Reporte de asignaciones Control de prerrequisitos manualmente Revisin de flder de estudiantes nuevos y antiguos Rectificacin de actas Transcripcin de notas Elaboracin de informes ingreso de estudiantes) (fecha de

Actividades acadmicas que realiza el director de carrera y docente: Actividad del Director Pide reporte de estudiantes inscritos Pide reporte de rendimiento Actividades del docente Solicita lista de inscritos por materia Solicita actas docente, un formulario

Designa un docente a una asignatura y a Llena actas de notas un paralelo Registra un docente

66

 Inscripcin de estudiantes antiguos y nuevos por plan de estudios

El estudiante por su parte realiza: Solicita record acadmico Solicita historial acadmico Solicita inscripcin de materias Solicita retiro y adicin de materias Solicita boleta de inscripcin Realiza canje de matricula Matriculacin en ambas carreras: Estudiantes antiguos: el proceso de matriculacin para antiguos se realiza en cada carrera para esto se maneja el sistema de matriculacin JIWASANA de la Divisin de Sistemas de Informacin y Estadstico DSIE. Estudiantes nuevos: el proceso de matriculacin para nuevos se realiza en la Divisin de Gestiones y Admisiones. 4.1.1. Carrera Ingeniera Geogrfica: La carrera de Ingeniera Geogrfica de la Facultad de Ciencias Geolgicas que cuenta con el Sistema Acadmico del DSIE (Departamento de Sistemas de Informacin y Estadsticas ex CPDI), sistema desarrollado en lenguaje de programacin Foxpro para plataforma DOS, el cual permite inscripciones sin el control de prerrequisitos, reporte de estudiantes por materia, historial acadmico, certificado de notas y actas finales.

67

La base de datos de geografa se tiene registros de notas desde la gestin 1994, los planes con los que actualmente trabajan son: plan nuevo de la gestin 1999, y plan de antiguo 1992. Inscripcin: el nmero mximo de siete materias para la inscripcin de los estudiantes de la carrera de Ingeniera Geogrfica, pudiendo inscribirse en materias anuales solamente, materias semestrales en seis solamente, en caso de materias anuales y semestrales, cuidado de no exceder el cupo de siete materias. Se establece la cantidad mnima de cuatro estudiantes legalmente inscritos para la efectivizacin del dictado de una asignatura en la Carrera de Ingeniera Geogrfica si el numero fuere menor al de 4 inscritos. La misma ser dada como TUTORA18. Las asignaturas por la carrera, con especificaciones de paralelos, docentes, aulas y horarios debern estar debidamente claras y fijadas al tiempo de iniciar la inscripcin en la carrera y son ejecutadas por el director de carrera. A los docentes las entregan las actas de notas de los estudiantes a la secretaria. Una vez recepcionadas las actas de notas de los docentes se transcribe las notas a la base de datos 4.1.2. Carrera de Ingeniera Geolgica y del Medio Ambiente: La carrera de Ingeniera Geolgica y del Medio Ambiente de la Facultad de Ciencias Geolgicas cuenta con una base de datos en Access, donde se tiene una sola tabla donde se registra las notas, cuyos campos son: apellidos, nombres del estudiante, nombre de la

materia, nota, turno, semestre, gestin, observacin, plan. Se tiene reportes de record acadmicos de estudiantes, mediante una consulta por apellido y nombre del estudiante. La base de datos de geologa tiene registros de notas desde la gestin 1990. Actualmente existen estudiantes que cursan el plan antiguo y nuevo.

18

Documento de Facultad de Ciencias Geolgicas Segundo Congreso Interno Carrera de Geografa

68

Inscripcin: el nmero mximo de materias en el que podr inscribirse un estudiante en un semestre es de cinco y en un periodo acadmico anual es de seis. En casos excepcionales un estudiante de cuarto ao, podr cursar materias de quinto ao, siempre que no exceda al nmero de materias establecidas para cada gestin. Los requisitos para la inscripcin de estudiantes son: matricula de la gestin, CI, no estar sancionado con la suspensin temporal o definitiva de su condicin de estudiante universitario por el Honorable Consejo Universitario y contar en su kardex con toda la documentacin reglamentaria. Las asignaturas por la carrera, con especificaciones de paralelos, docentes, aulas y horarios debern estar debidamente claras y fijadas al tiempo de iniciar la inscripcin en la carrera y son ejecutadas por el director de carrera. A los docentes les entregan las listas de inscritos con solo los nombres de los estudiantes en el cual no se identifica el CI o RU del estudiante, lo cual trae problemas en el momento de transcribir las notas y a su vez entregan a la secretaria para luego su transcripcin en la base de datos.

69

4.2.

Fase de Comienzo o Inicio captura de requisitos

En esta fase se utilizar los casos de uso para identificar los requisitos funcionales y actores. 4.2.1. Modelado del sistema -actores

Figura 4.1. Modelado del sistema

Actores del sistema: todos los usuarios podrn ingresar al sistema con un id_usuario y contrasea asignados a cada uno de ellos.

Administrador de sistema: es el encargado de dar soporte al sistema (cambios de configuracin, levantar y bajar servicios, asignar enlaces, crear nuevos usuarios).

70

Autoridades de carrera (decano, vicedecano): podrn sacar reportes (lista de inscritos, record acadmicos, historiales acadmicos).

Director de carrera: es responsable de planificar y supervisar todos los aspectos del proceso de inscripcin, adems que podr sacar reportes (lista de inscritos, record acadmicos, historiales acadmicos).

Kardixta: es el responsable de registrar notas, modificar actas, rectificaciones, inscripcin de materias, podr sacar reportes (lista de inscritos, record acadmicos, historiales acadmicos).

Secretaria: podr sacar reportes (lista de inscritos, record acadmicos, historiales acadmicos).

Estudiante: es quien solicita inscripcin, adicin y retiro de materias, de record acadmico e historial acadmico.

4.2.2. Diagramas de casos de uso Los casos de uso nos permitirn representar las funcionalidades el sistema y mostrar la relacin entre los casos de uso y los actores.

DESCRIPCION DE CASO DE USO Nombre Planificacin acadmica Actores Director de carrera

71

Descripcin El director de carrera est encargado de realizar la planificacin acadmica: la asignacin (eliminacin) de docentes, paralelos, aulas y horarios a las materias para la etapa de inscripcin de materias.

DE SCRIPCION DE CASO DE USO Nombre Inscripciones Actores Director de carrera, kardista Descripcin El estudiante solicita la inscripcin, adicin y/o retiro de materias al director de carrera. El director de carrera o kardixta recibe la solicitud de inscripcin del estudiante controlando que tenga matricula de la gestin; realiza la inscripcin, adicin y/o retiro de materias; tambin tiene la posibilidad de habilitar una o varias materias para inscribir al estudiante rompiendo prerrequisitos.

72

DESCRIPCION DE CASO DE USO Nombre Reportes Actores Director de carrera, Decano, Vicedecano, Secretaria, kardixta, Descripcin Director de carrera, Decano, Vicedecano, Secretaria, kardixta podrn sacar reportes de lista de inscritos por materia y por gestin.

DESCRIPCION DE CASO DE USO Nombre Seguimiento acadmico Director de carrera, Decano, Vicedecano, Secretaria, kardixta, Actores estudiante Descripcin El estudiante realiza una solicitud de record y/o historial acadmico. Director de carrera, Decano, Vicedecano, Secretaria, kardixta podrn responder a la solicitud del estudiante emitiendo el record y/o historial acadmico.

73

DESCRIPCION DE CASO DE USO Actas Nombre Actores Kardixta Descripcin El kardixta podr realizar la modificacin de actas en caso de errores en la transcripcin, creacin de nuevas actas para gestin incluso para gestiones anteriores, tendr la posibilidad de ver e imprimir las actas.

DESCRIPCION DE CASO DE USO Censo Nombre Kardixta Actores Descripcin Esto le permitir al kardixta comunicarse con los estudiantes a travs de Internet, respondiendo a las necesidades de los estudiantes con respecto a sus notas y datos personales.

74

DESCRIPCION DE CASO DE USO Nombre Rectificacin de notas Kardixta Actores Descripcin El kardixta tendr la posibilidad de modificar una nota ya registrada en actas y el sistema, siempre y cuando exista un resolucin para la modificacin. Subcasos de uso: Los subcasos de uso son una descripcin ms detallada de cada caso de uso.

Nombre Actores Propsito

Asignar materias - docente Director de carrera Asignar materias que dictaran los docentes en una gestin y periodo.

75

Flujo principal

Eventos Actor 1. El usuario ingresa al sistema. 3. El usuario ingresa el id_usuario y contrasea 5. El usuario ingresa gestin periodo donde quiere realizar la asignacin

Eventos Sistema 2. el sistema solicita el id_usuario y contrasea 4. El sistema verifica el id_usuario y contrasea. 6. El sistema muestra la lista de materias que tiene paralelos (caso de uso asignacin paralelosmaterias)

7. El usuario elige una 8. El sistema muestra la lista materia de la lista de de docentes de la carrera. materias. 9. El usuario elige de la lista 10. El sistema registra la de docentes a uno de ellos asignacin. para la asignacin Flujo alternativo 11. El usuario elige eliminar 12. El sistema verifica la una asignacin. asignacin. 13. El sistema registra la eliminacin. 14. El sistema actualiza la lista de asignacin de materias - docente Se debe realizar la asignacin de paralelos- materia, para que muestre la lista de materias a ser asignadas. El sistema registrar y actualizar la asignacin.

Precondicin Poscondicin

76

Nombre Actores Propsito Flujo principal

Asignar paralelos - materia Directo de carrera Asignar paralelos (A, B, C, D, E, F, etc.) a las materias las cuales se habilitaran para que los estudiantes puedan inscribirse en las mismas. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario debe elegir el 6. El sistema lista las plan de estudios. materias del plan elegido. 7. El usuario elige una 8. El sistema le muestra en materia de la lista a la cual le una ventana nueva los datos asignara paralelos. de la materias y los paralelos que ya tenia asignado si que los tuviera. 9. El usuario crea un nuevo 10. El sistema registra la paralelo con el cupo de asignacin. estudiantes que podrn inscribirse a la materia.

77

Flujo alternativo

Precondicin Poscondicin

11. El usuario elige modificar 12. El sistema habilita el cupo. materia para modificar cupo. 13. El usuario modifica el 14. El sistema actualiza cupo. modificacin. 11. El usuario elige eliminar 12. El sistema actualiza un paralelo. eliminacin. Ninguna El sistema registrar y actualizar la asignacin

la el la la

Nombre Actores Propsito Flujo principal

Asignar aulas y horarios Director de carrera Asignar horarios y aula a los paralelos creados Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica id_usuario y contrasea. id_usuario y contrasea. 5. El usuario debe elegir el 6. El sistema lista plan de estudios. materias del plan elegido. 7. El usuario elige una 8. El sistema le muestra

el el las en

78

materia de la lista.

una ventana nueva los datos de las materias y los paralelos que ya tiene asignados. 9. El usuario elige un 10. El sistema muestra la lista paralelo para asignarle aula. de predios. 11. El usuario elige el predio. 12. El sistema muestra la lista de aulas que tiene el predio elegido. 13. El usuario elige un aula. 14. El sistema registra la asignacin. 15. El usuario ingresa los 16. El sistema registra la horarios. asignacin. Flujo alternativo 17. El usuario modifica el 18. El sistema actualiza la predio y aula modificacin. 19. el usuario modifica el 20. El sistema actualiza la horario. modificacin. Se debe realizar una asignacin de paralelos El sistema registrar y actualizar la asignacin

Precondicin Poscondicin

79

Nombre Actores Propsito Flujo principal

Inscribir materias Director de carrera y estudiante Inscribir a materia a los estudiantes Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa datos de 6. El sistema busca al estudiante. estudiante 7. El sistema verifica su inscripcin y mencin. 8. El sistema controla los prerrequisitos. 9. El sistema nuestra las materias que puede cursar el estudiante. 11. El usuario elige las 12. El sistema controla el materias a las cuales el mximo de materias que

80

estudiante quiere inscribirse.

Flujo alternativo

Precondicin Poscondicin

puede inscribirse un estudiante. 13. El sistema registra una preinscripcin. 14. El usuario confirma la 15. El sistema registra la eleccin de materias. inscripcin. 16. El sistema genera la boleta de inscripcin. 17. El usuario imprime la boleta de inscripcin. 18. El sistema no encuentra al estudiante en la base de datos. 19. El sistema no se encuentra habilitado al estudiante. Asignacin de paralelos El sistema registra la inscripcin

Nombre Actores Propsito

Habilitar materias Director de carrera y estudiante Es el de habilitar materias adicionales al que puede inscribirse un estudiante para su inscripcin o adicin de

81

Flujo principal

materias. Eventos Actor 1. El usuario ingresa al sistema. 3. El usuario ingresa el id_usuario y contrasea. 5. El usuario ingresa datos del estudiante.

Eventos Sistema 2. el sistema solicita el id_usuario y contrasea 4. El sistema verifica el id_usuario y contrasea. 6. El sistema busca al estudiante. 7. El sistema muestra la lista de materias del pensum y paralelamente la lista de materias que puede cursar el estudiante. 8. El usuario elige las 9. El sistema registra la materias que adicionara al adicin. estudiante. 10. El sistema no encuentra al estudiante. 11. El usuario elige de la lista 12. El sistema actualiza la de materias a cursar una eliminacin de la materia. materia para retirarla. Ninguna El sistema actualiza la lista de materias a cursar del estudiante

Flujo alternativo

Precondicin Poscondicin

82

Nombre Actores Propsito

Flujo principal

Habilitar inscripcin y/o adicin y retiro de materias Director de carrera y estudiante Habilitar nuevamente a un estudiante a que pueda volver a inscribirse o realizar su adicin y/o retiro de materias nuevamente en el caso de que ya se haya inscrito o haya realizado su adicin y/o retiro de materias. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa datos 6. El sistema busca al del estudiante. estudiante. 7. El sistema verifica la inscripcin y adicin y/o retiro. 8. El sistema muestra datos del estudiante y estado de inscripcin. 9. El usuario elige el tipo de habilitacin.

83

Flujo alternativo Precondicin Poscondicin

10. El usuario confirma la 11. El sistema actualiza la habilitacin. habilitacin. 12. El sistema no encuentra al estudiante. Ninguna El sistema actualizar la habilitacin

Nombre Actores Propsito Flujo principal

Adicionar y/o retirar materias Director de materias y estudiante Adicionar y/o retirar materias a la inscripcin a un estudiante. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa datos de 6. El sistema busca al estudiante. estudiante 7. El sistema verifica su adicin y/o retiro de materias y mencin. 8. El sistema controla los prerrequisitos.

84

11. El usuario elige las materias a adicionar o retirar.

14. El usuario confirma la eleccin de materias.

17. El usuario imprime la boleta de adicin y/o retiro de materias. Flujo alternativo

9. El sistema nuestra las materias que puede cursar el estudiante y a las que se inscribi. 12. El sistema controla el mximo de materias que puede inscribirse un estudiante. 13. El sistema registra una preinscripcin. 15. El sistema registra la adicin y/o retiro de materias. 16. El sistema genera la boleta de adicin y/o retiro de materias.

Precondicin Poscondicin

18. El sistema no encuentra al estudiante en la base de datos. 19. El sistema no encuentra habilitado al estudiante. El estudiante tiene que haberse inscrito previamente. El sistema registrar su adicin y/o retiro de materias

85

Nombre Actores Propsito Flujo principal

Listar inscritos por materia Director de carrera, kardixta, decano, vicedecano, secretaria El sistema mostrar la lista de estudiantes inscritos en una materia elegida en formato pdf. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El sistema ingresa la 6. El sistema busca la gestin y el periodo. asignacin de paralelos de materias. 7. El sistema busca la asignacin de docentes. 8. El sistema muestra la lista de todas las materias que tienen paralelos. 9. El usuario elige una 10. El sistema muestra la lista

86

materia.

Flujo alternativo Precondicin Poscondicin

de estudiantes inscritos en la materia elegida. 11. El usuario elige ver la 12. El sistema muestra la lista lista en formato pdf. en formato pdf la lista de inscritos. 13. El usuario imprime el documento en pdf. Ninguno Las materias deben tener algn paralelo asignado y que en la materia se hayan inscrito estudiantes. Ninguna

Nombre Actores Propsito Flujo principal

Listar inscritos por gestin Director de carrera, kardixta, decano, vicedecano, secretaria El sistema mostrar la lista de estudiantes inscritos en una gestin y periodo elegidos. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa gestin 6. El sistema genera un y periodo. documento en formato pdf. 7. El sistema muestra la lista

87

de estudiantes inscritos y en las materias que se inscribi cada estudiante. Flujo alternativo Precondicin Poscondicin 8. El usuario imprime el documento en formato pdf. Ninguna Que exista inscritos en la gestin y periodo Ninguna

Nombre Actores Propsito Flujo principal

Ver record acadmico Director de carrera, kardixta, decano, vicedecano, secretaria El sistema mostrar solo las materias aprobadas de un estudiante. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El estudiante ingresa datos 6. El sistema busca al del estudiante. estudiante. 7. El sistema muestra las materias solo aprobadas del estudiante de acuerdo al plan

88

Flujo alternativo

de estudios y a la mencin al cual pertenece el estudiante. 8. El usuario elige generar la 9. El sistema genera la lista lista en formato pdf. en formato pdf. 10. El usuario imprime el record acadmico. 11. El sistema no encuentra al estudiante en la base de datos. Ninguna Ninguna

Precondicin Poscondicin

Nombre Actores Propsito Flujo principal

Ver historial acadmico Director de carrera, kardixta, decano, vicedecano, secretaria El sistema mostrar materias aprobadas y reprobadas de un estudiante. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea

89

3. El usuario ingresa el id_usuario y contrasea. 5. El estudiante ingresa datos del estudiante.

Flujo alternativo

4. El sistema verifica el id_usuario y contrasea. 6. El sistema busca al estudiante. 7. El sistema busca materias regulares. 8. El sistema busca materias optativas. 9. El sistema busca materias rectificadas. 10. El sistema materias convalidadas. 11. El sistema muestra las materias aprobadas y reprobadas del estudiante de acuerdo al plan de estudios y a la mencin al cual pertenece el estudiante. 12. El usuario elige generar 13. El sistema genera la lista la lista en formato pdf. en formato pdf. 14. El usuario imprime el historial acadmico. 15. El sistema no encuentra al estudiante en la base de datos. Ninguna Ninguna

Precondicin Poscondicin

90

Nombre Actores Propsito Flujo principal

Modificar actas Kardixta El kardixta con este modulo podr modificar notas de estudiantes en el caso que haya errores en la transcripcin de notas. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa gestin 6. El sistema busca la y periodo. asignacin de docentes en la gestin y periodo. 7. El sistema busca la asignacin de paralelos. 8. El sistema muestra la lista de las materias existentes en la gestin y periodo. 9. El usuario elige materia de la lista. una 10. El sistema muestra la lista de estudiantes de la materia

91

Flujo alternativo

Precondicin Poscondicin

elegida con la opcin de modificar o eliminar nota en cada registro. 11. El usuario modifica, 13. El sistema actualiza la elimina una nota de modificacin o eliminacin. estudiante. 14. El usuario inserta nueva 15. El sistema verifica la nota nota de un estudiante. del estudiante que no exista en la lista que se muestra. 16. El sistema registra la nota. Que exista actas con notas en la gestin y periodo elegido. El sistema actualiza notas

Nombre Actores Propsito

Ver notas actas Kardixta Es el de imprimir las actas por gestin(general) y por materia

92

Flujo principal

Eventos Actor 1. El usuario ingresa al sistema. 3. El usuario ingresa el id_usuario y contrasea. 5. El usuario ingresa gestin y periodo.

Eventos Sistema 2. el sistema solicita el id_usuario y contrasea 4. El sistema verifica el id_usuario y contrasea. 6. El sistema genera el documento pdf. general de todas las materias. 7. El sistema busca la asignacin de docentes. 8. El sistema busca la asignacin de paralelos. 9. El sistema muestra la lista de materias de la gestin y periodo ingresados. 10. El usuario elige una 11. El sistema muestra la lista materia de la lista. de estudiantes de la materia seccionada. 12. El sistema genera documento pdf. del acta. 13. El usuario imprime el documento pdf. 14. El usuario imprime el documento pdf. general de todas las materias. Es de que exista actas de notas en la gestin y periodo elegidos. Reportes para la impresin de actas

Flujo alternativo Precondicin Poscondicin

93

Nombre Actores Propsito Flujo principal

Flujo alternativo

Crear actas Kardixta Es el de crear actas para gestiones anteriores. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa gestin y periodo. 6. El usuario ingresa plan de 7. El sistema muestra la lista estudios. de materias del plan elegido. 8. El usuario elige una 9. El sistema muestra la lista materia. de paralelos. 10. El usuario elige un 11. El sistema verifica paralelo asignacin paralelos-materias 12. El sistema crea el acta 13. El sistema muestra la lista

94

Precondicin Poscondicin

de docentes de la carrera 14. El usuario elige un docente. Que no exista el acta que se quiera crear El acta creada listo para la insercin de notas.

Nombre Actores Propsito Flujo principal

Actas docentes Kardixta Es el de generar actas docentes para su impresin. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa gestin 6. El sistema busca y periodo. asignacin de docentes. 7. El sistema busca asignacin de paralelos. 8. El sistema muestra la lista de materias de la gestin y periodo elegidos. 9. El usuario elige una 10. El sistema busca los

95

materia de la lista.

estudiantes inscritos en la materia elegida. 11. El sistema genera el documento pdf. del acta

Flujo alternativo Precondicin Poscondicin

12. El usuario imprime el acta. Ninguno Que existan inscritos en las materias de la gestin y periodo elegidos. Actas para la impresin.

Nombre Actores Propsito Flujo principal

Administrar censo Kardixta Habilitar al docentes y/o estudiantes para el censo. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario elige alguno de 6. El sistema verifica si el los usuarios existentes para usuario elegido ya fue habilitarlo para el censo. habilitado para el censo. 7. El usuario ingresa el 8. El sistema lista los tems.

96

intervalo para la fecha en que se realizar el censo. 9. El usuario elige alguno de 10. El sistema registra la los tems para el censo. habilitacin. Flujo alternativo Precondicin Poscondicin 11. El usuario elimina alguno 12. El sistema actualiza la de los tems asignados. habilitacin. Ninguna El usuario(docente y/o estudiantes) habilitados para el censo

Nombre Actores Propsito Flujo principal

Ver reporte observaciones Kardixta Listar las observaciones de los estudiantes Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El sistema busca estudiantes que realizaron alguna observacin. 6. El sistema muestra la lista de estudiantes sin y/o con observaciones revisadas y no revisadas. 7. El usuario elige genera 8. El sistema genera el

97

Flujo alternativo Precondicin Poscondicin

documento pdf. documento pdf. 9. El usuario imprime documento pdf. Ninguno Que exista una habilitacin de censo para alguno de los usuarios Reporte para imprimir de observaciones.

Nombre Actores Propsito Flujo principal

Verificar estudiante Kardixta Es el ingresar como estudiante y de escribir alguna observacin. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. el sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresar datos 6. El sistema busca del estudiante. estudiante. 7. El sistema verifica si esta habilitado el censo para el estudiante. 8. El sistema lista los tems habilitados para el censo. 9. El usuario elige uno de los 10. El sistema registra la tems y escribe alguna observacin. observacin.

98

Flujo alternativo

Precondicin Poscondicin

11. El sistema no encuentra habilitado el censo para estudiante. 12. El sistema no encuentra al estudiante en la base de datos. El censo debe de estar habilitado para el estudiante El sistema registra las observaciones

Nombre Actores Propsito Flujo principal

Revisar observaciones - estudiante Kardixta Es el de responder al estudiante. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. El sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El sistema busca estudiantes que realizaron alguna observacin. 6. El sistema muestra la lista de estudiantes sin y/o con observaciones revisadas y no

99

Flujo alternativo Precondicin Poscondicin

revisadas. 7. El usuario elige de la lista un estudiante. 8. El usuario elige un tem de la lista. 9. El usuario escribe la 10. El sistema registra las respuesta a la observacin del observaciones. estudiante. Ninguno El censo debe de estar habilitado para el estudiante El sistema registra las observaciones

Nombre Actores Propsito Flujo principal

Rectificar notas por resolucin. Kardixta El usuario podr rectificar la(s) nota(s) del estudiante cuando este tenga alguna resolucin para la modificacin de nota. Eventos Actor Eventos Sistema 1. El usuario ingresa al 2. El sistema solicita el sistema. id_usuario y contrasea 3. El usuario ingresa el 4. El sistema verifica el id_usuario y contrasea. id_usuario y contrasea. 5. El usuario ingresa datos 6. El sistema busca al del estudiante. estudiante. 7. El sistema muestra la lista de materias aprobadas y reprobadas del estudiante.

100

Flujo alternativo Precondicin Poscondicin

8. El sistema busca notas rectificadas. 9. El usuario ingresa datos 10. El sistema verifica que no de la resolucin para exista duplicidad de datos modificar nota(s). con respecto a la resolucin. 11. El usuario modifica 12. El sistema registra la nota(s) del estudiante. rectificacin. Ninguna Ninguna El sistema actualiza las nota(s) rectificadas.

4.2.3. Ingeniera Geogrfica - migracin de Foxpro a PostgreSQL La migracin de base de datos es la conversin de una estructura a otro. Los pasos que se seguirn para la migracin de datos a PostgreSQL son: 1. Obtencin de la base de datos. 2. Obtencin de informacin y documentacin acerca de los planes de estudios, convalidaciones, planificacin acadmica, inscripciones. 3. Se realiza un anlisis de los datos a migrar. 4. Los archivos .dbf de Foxpro que contienen los datos de estudiantes, personas, notas se descencriptan. 5. Se generan archivos de textos para exportarlos a PostgreSQL. 6. Se genera un archivo con las instrucciones SQL para la creacin de las tablas auxiliares para la insercin de datos a las tablas originales. 7. Se ejecuta el archivo con las instrucciones SQL.

101

8. Se genera un archivo con instrucciones SQL para la insercin de datos a las tablas originales, efectuando una comparacin de datos de personas y estudiantes con los datos que se tienen en la base de datos de matriculacin. 9. Se genera los cdigos de id_persona, id_estudiante, id_materia de acuerdo a los cdigos que se manejan en matriculacin. 10. Verificacin de personas, estudiantes, materias y notas. 11. Reporte de personas, estudiantes y notas no migradas. En esta etapa de migracin se encontraron datos incorrectos en nombres y notas los cuales se llegaron a solucionar examinado actas de notas y datos de matriculacin. 4.2.4. Ingeniera Geolgica y del Medio Ambiente - migracin de Access a PostgreSQL La migracin de base de datos es la conversin de una estructura a otro. Los pasos que se seguirn para la migracin de datos a PostgreSQL son: 1. Obtencin de la base de datos. 2. Obtencin de informacin y documentacin acerca de los planes de estudios, convalidaciones, planificacin acadmica, inscripciones. 3. Se realiza un anlisis de los datos a migrar. 4. Se importa la nica tabla que tiene la base de datos Access a PostgreSQL. 5. Se genera un archivo con instrucciones SQL para la insercin de datos a las tablas originales, efectuando una comparacin de datos de personas y estudiantes con los datos que se tienen en la base de datos de matriculacin.

102

6. Se genera los cdigos de id_persona, id_estudiante, id_materia de acuerdo a los cdigos que se manejan en matriculacin. 7. Verificacin de personas, estudiantes, materias y notas. 8. Reporte de personas, estudiantes, materias y notas no migradas. 9. Transcripcin de datos no migrados al sistema revisndolos con actas. En esta etapa de migracin se encontraron muchos datos incorrectos de nombres y notas los cuales se llegaron a solucionar examinado actas de notas y datos de matriculacin.

103

4.3.

Fase de Elaboracin Anlisis

4.3.1. Diagrama conceptual El modelo de conceptual lo expresaremos en paquetes, que nos muestra los conceptos presentes en el dominio del problema. En este modelo se muestra los conceptos19, los atributos de los conceptos (solo algunos) y la relacin entre ellos.
planes id_plan plan gestion id_estado * * estudiantes id_estudiante id_persona id_programa id_plan id_estado materias id_materia sigla materia id_estado paralelos id_paralelo paralelo tiene id_estado prerrequisitos id_plan id_materia id_prerrequisito id_estado

Tiene

Se inscribe

inscripciones id_estudiante gestion periodo id_programa id_plan id_materia id_paralelo id_estado

mtr_paralelos id_materia id_paralelo cupo_actual cupo_max id_horario_paralelo id_estado

Figura 4.1. Modelo conceptual paquete de inscripcin

19

Un concepto es una idea, una cosa u objeto

104

Figura 4.2. Modelo conceptual paquete de administracin del usuarios

Figura 4.3. Modelo conceptual paquete censo

105

Figura 4.4. Modelo conceptual paquete asignacin materias-docentes

Figura 4.5. Modelo conceptual paquete asignacin paralelos-materia

106

estudiantes id_estudiante id_persona id_programa id_plan id_estado * personas id_persona dip paterno materno nombres id_sexo id_estado

Tiene

* notas

es

id_estudiante id_materia id_paralelo gestion periodo nota_sf nota_ef nota nota_2t id_tipo_nota id_estado

tipos_notas id_tipo_nota tipo_nota id_estado

es * docente

es de una

id_docente id_persona id_programa id_estado anio_titulacion titulo carga_horaria id_estado

materias * *
Se asigna

paralelos * *
Tiene

id_materia sigla materia id_estado

id_paralelo paralelo id_paralelo id_estado

asg_docentes id_docente id_materia id_paralelo id_estado id_tipo_asignacion gestion periodo id_estado

* * planes id_plan plan gestion id_estado

Figura 4.6. Modelo conceptual paquete asignacin actas

107

Figura 4.7. Modelo conceptual paquete asignacin horarios-aulas

108

4.4.

Fase de Construccin Diseo

4.4.1. Diagrama de clases El diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia.

personas - id_persona - dip - nombre_completo - paterno - materno - id_sexo - ... +get() +set() materias * -id_materia -id_programa -programa -sigla -materia -... +set() +get() -tiene

predios - id_predio - predio - direccion +set() +get()

* *

usuarios -id_usuario -id_tipo_usuario -tipo_usuario -usuario -clave -id_rol -... +set() +get()

aulas -id_aula -aula -id_tipo_aula -capacidad -superficie -piso -bloque +set() +get() planes -id_plan -plan -... +set() +get()

* paralelos -id_paralelo -id_plan -cupo_max -cupo_actual -... +set() +get() * estudiantes se inscribe asignaciones inscripciones -id_estudiante -id_programa -cupo_restante -nivel_academico -paralelos -can_materias -... +set() +get() -id_docente -id_tipo_asignacion -id_docente -nombres -paterno -materno -dip +set() +get()

* administrativos -id_administrativo -cargo +set() +get()

censo -id_censo -id_item -observacion -item -can_censados -nro_item +set() +get()

docentes - id_docente - carga_horaria - anio_titulacion - tipo_docente - id_tipo_docente +set() +get()

-id_estudiante -id_plan -... +set() +get() +TIENE

* notas rectificaciones -nota_rct -observacion_rct +set() +get() -id_estudiante -nota -folio -libro -observacion -... +set() +get()

programaciones -id_estudiante -id_programa -cupo_restante -nivel_academico -paralelos -estado_inscripcion -max_materias -fec_inicio -fec_fin -... +set() +get()

Figura 4.8. Diagrama de clases

109

4.4.2. Diseo de interfaces

110

111

112

113

114

4.5.

Fase de Transicin Implementacin

La etapa de la implementacin para el manejo del sistema por los usuarios se realiza con las siguientes actividades: 1. Se establece el servidor donde funcionara el sistema de gestin acadmica para la Facultad de Ciencias Geolgicas donde se instalan: 2. 3. 4. El sistema operativo para el funcionamiento del sistema (Linux Debian, Knoppix). El manejador de base de datos (PostgreSQL). El lenguaje de programacin y los servidores determinados (JAVA, TOMCAT, ANT, SPRING, IBATIS). 5. 6. 7. Se realiza el cargado del sistema de gestin acadmica. Se establecen los usuarios y contraseas. Coordinacin con el proyecto de redes del programa UMSATIC para la asignacin de puntos de red y de conexin a equipos para la Facultad de Ciencias Geolgicas ver Figura. 8. 9. 10. 11. Se establece los equipos cliente para la utilizacin de los usuarios. Se realiza los manuales de usuario necesarios. Se realiza la capacitacin a autoridades, kardixtas, estudiantes, docentes. Soporte a los usuarios del sistema

115

Internet

Figura 4.9. Diagrama de red para la Facultad de Ciencias Geolgicas

4.6.

Calidad del sistema

Para el proceso de evaluacin se selecciona al usuario kardixta que es un tipo de visitante general segn la clasificacin de Dr. Luis Olsina. A los usuarios se les explico cada caracterstica y subcarateristica de la ISO9126 para luego proporcionarle una encuesta en la que evaluaban en una escala de 0 a 10. El valor resultante se establece mediante el cociente: Peso_relativo_Caract_n=Prom(Caract_N)/Suma de todos los promedios As un a vez realizada el proceso de evaluacin se normaliza los pesos relativos de tal manera que la suma de estos sea 1.

116

De acuerdo a los resultados se vio que la mayor importancia son usabilidad, funcionalidad luego la confiabilidad y eficiencia, y por ltimo la portabilidad y mantenibilidad para usuario con respecto al sistema de gestin acadmica. rbol de requerimientos de calidad: CARACTERSTICAS SUBCARACTERISTICAS ATRIBUTOS 1. USABILIDAD 1.1 Comprensibilidad Global del Sitio 1.2 Mecanismos de Ayuda y Retroalimentacin en lnea 1.2.1 Calidad de la Ayuda 1.2.2 Indicador de ultima actualizacin 1.2.3 Facilidad FAQ 1.2.4 Retroalimentacin 1.2.4.1 Cuestionario 1.2.4.2 Libro de invitados 1.2.4.3 Comentarios/Sugerencias 1.3 Aspectos de Interfaces y Estticos 1.3.1 Cohesividad al Agrupar los Objetos de Control Principales 1.3.2 Permanencia y Estabilidad en la Presentacin de los Controles Principales 1.3.3 Aspectos de estilo 1.3.3.1 Uniformidad en el color de enlaces 1.3.3.2 Uniformidad en el estilo global 1.3.3.3 Gua de estilo global 1.3.4 Preferencia esttica 2. FUNCIONALIDAD 2.1 Aspectos de Bsqueda y Recuperacin 2.2 Aspectos de Navegacin y Exploracin 2.2.1 Navegabilidad 2.2.1.1 Orientacin 2.2.1.1.1 Indicador del camino 2.2.1.1.2 Etiqueta de la posicin actual 2.2.1.2 Promedio de Enlaces por Pgina 2.2.2 Nivel de Desplazamiento 2.2.2.1 Desplazamiento Vertical 2.2.2.2 Desplazamiento Horizontal 2.2.3 Prediccin Navegacional 2.2.3.1 Enlace con Ttulo (enlace con texto explicatorio) 2.2.3.2 Calidad de la Frase del Enlace 2.3 Aspectos del Dominio orientados al kardixta

117

3. CONFIABILIDAD 3.1 No Deficiencia 3.1.1 Errores de Enlaces 3.1.1.1 Enlaces Rotos 3.1.1.2 Enlaces Invlidos 3.1.1.3 Enlaces no Implementados 3.1.2 Errores o Deficiencias Varias 3.1.2.1 Deficiencias o cualidades ausentes debido a diferentes navegadores (browsers) 3.1.2.2 Deficiencias o resultados inesperados independientes de browsers (p.ej. errores de bsqueda imprevistos, deficiencias con marcos (frames), etc.) 3.1.2.3 Nodos Destinos (inesperadamente) en Construccin 3.1.2.4 Nodos Web Muertos (sin enlaces de retorno) 4. EFICIENCIA 4.1 Pginas de Acceso Rpido 4.2 Accesibilidad 4.2.1 Accesibilidad de Informacin 4.2.1.1 Soporte a Versin slo Texto 4.2.1.2 Legibilidad al desactivar la Propiedad Imagen del Browser 4.2.1.2.1 Imagen con Ttulo 4.2.1.2.2 Legibilidad Global 4.2.2 Accesibilidad de Ventanas
Tabla 4.1. rbol de requerimientos de calidad para el caso de estudio sistema de gestin acadmico

Agregacin de preferencias parciales La tabla nos muestra la estructura de agregacin de preferencias parciales para el Sistema de Gestin Acadmica.

118

ESTRUCTURA DE AGREGACIN PARA LA CARACTERSTICA DE ALTO NIVEL CONFIABILIDAD 0.4

ESTRUCTURA DE AGREGACIN PARA LA CARACTERSTICA DE ALTO NIVEL EFICIENCIA 0.6

3.1.1.1 3.1.1.2

0. 3 DA 0.3

3.1.1 0.3

4.1
0.3 A 4.2.1.2 0.7 DA 0.6 4.2 0.4 A C4.2.1 0.7

4.2.1.1
0.4 A

3.1.1.3
0.3

4.2.1.2.1 4.2.1.2.2

3.1.2.1
0.3

3.1.2.2
0.2

3.1.2 0.7 D --

0.3

3.1.2.3
0 .2

4.2.2

3.1.2.4
Figura 4.10. Estructuras de agregacin para las caractersticas de alto nivel: usabilidad, confiabilidad, funcionalidad y eficiencia

119

Figura 4.11. Tabla. Nos permitir definir el valor R

De acuerdo al rbol de requerimientos, para cada atributo Ai cuantificable se debe asociar y determinar la variable Xi, que tomara un valor real a partir de proceso de medicin (criterios elementales de evaluacin).

CARACTERSTICAS SUBCARACTERISTICAS ATRIBUTOS 1. USABILIDAD 1.1 Comprensibilidad Global del Sitio 1.2 Mecanismos de Ayuda y Retroalimentacin en lnea 1.2.1 Calidad de la Ayuda 1.2.2 Indicador de ultima actualizacin 1.2.3 Facilidad FAQ 1.2.4 Retroalimentacin 1.2.4.1 Cuestionario 1.2.4.2 Libro de invitados 1.2.4.3 Comentarios/Sugerencias 1.3 Aspectos de Interfaces y Estticos 1.3.1 Cohesividad al Agrupar los Objetos de Control Principales

IE*100 71.23 100 58 80 100 0 40 0 0 100 40.14 100

IE^R

Peso

Peso*IE

TOTAL

1 1 1 1 1 1 4.45 4.45 4.45 1 27.11

1 0.58 0.80 1 0 0.4 0 0 1

0.4 0.4 0.15 0.3 0.15 0.4 0.3 0.3 0.4

0.4 0.232 0.12 0.3 0 0.16 0 0 0.4 0.0803 0.4

0.7123

0.58

0.4

0.401416 0.2 1 0.4

0.4014

120

1.3.2 Permanencia y Estabilidad en la Presentacin de los Controles Principales 1.3.3 Aspectos de estilo 1.3.3.1 Uniformidad en el color de enlaces 1.3.3.2 Uniformidad en el estilo global 1.3.3.3 Gua de estilo global 1.3.4 Preferencia esttica 2. FUNCIONALIDAD 2.1 Aspectos de Bsqueda y Recuperacin 2.2 Aspectos de Navegacin y Exploracin 2.2.1 Navegabilidad 2.2.1.1 Orientacin 2.2.1.1.1 Indicador del camino 2.2.1.1.2 Etiqueta de la posicin actual 2.2.1.2 Promedio de Enlaces por Pgina 2.2.2 Nivel de Desplazamiento 2.2.2.1 Desplazamiento Vertical 2.2.2.2 Desplazamiento Horizontal 2.2.3 Prediccin Navegacional 2.2.3.1 Enlace con Ttulo (enlace con texto explicatorio) 2.2.3.2 Calidad de la Frase del Enlace 2.3 Aspectos del Dominio orientados al kardixta 3. CONFIABILIDAD 3.1 No Deficiencia 3.1.1 Errores de Enlaces 3.1.1.1 Enlaces Rotos 3.1.1.2 Enlaces Invlidos 3.1.1.3 Enlaces no Implementados 3.1.2 Errores o Deficiencias Varias 3.1.2.1 Deficiencias o cualidades ausentes debido a diferentes navegadores (browsers) 3.1.2.2 Deficiencias o resultados inesperados independientes de browsers (p.ej. errores de bsqueda imprevistos, deficiencias con marcos (frames), etc.) 3.1.2.3 Nodos Destinos (inesperadamente) en Construccin 3.1.2.4 Nodos Web Muertos (sin

80

27.11

0.002359 0.2

0.0005

80 100 100 0 90 79.28 60 84.2591 85 100 100 100 70 83.46 50 50 100 100 100 90 90.46 90.46 0.19 30 5 10 13.55 0

27.11 50 50 50 27.11 1 1 1.519 1 0.261 0.261 1 1.519 0.261 0.261 1.519 2.018 2.018 1

0.002359 0.2 1 0.4 1 0.4

0.0005 0.4 0.4 0 0.0114959 0.18 0.252777 0.390622 0.5 0.5 0.5 0.35 0.151969 0.4173 0.4173 0.3 0.3 0.7 0.36

0.8

0 0.2 0.057479 0.2 0.6 0.842591 0.781245 1 1 1 0.7 0.3 0.3 0.5 0.5 0.5 0.5 0.5

0.792777 0.842591 0.85 1

0.759846 0.2 0.834509 0.5 0.834509 0.5 1 1 1 0.9 0.3 0.3 0.7 0.4

0.8346

1 4.45 4.45 4.45 1 1.565

0.0019 0.004712 1.62E-06 3.55E-05 0.1355 0

0.3 0.4 0.3 0.3 0.7 0.3

0.00057 0.0019 5E-07 1E-05 0.0949 0

0.0954 0.0019

0.1355

30

1.565 0.151948 0.3

0.0456

1.565

0.2

60

1.565

0.44958

0.2

0.0899

121

enlaces de retorno) 4. EFICIENCIA 4.1 Pginas de Acceso Rpido 4.2 Accesibilidad 4.2.1 Accesibilidad de Informacin 4.2.1.1 Soporte a Versin slo Texto 4.2.1.2 Legibilidad al desactivar la Propiedad Imagen del Browser 4.2.1.2.1 Imagen con Ttulo 4.2.1.2.2 Legibilidad Global 4.2.2 Accesibilidad de Ventanas

83.2 90 73 61.42 0 60.6

0.546 1 1 1 0.261 0.261

0.90 0.73 0.6142 0

0.2 0.6 04 0.7 0.3

0.54 0.292 0.43 0 0.6142

0.832 0.73 0.6142

0.877467 0.7

34.38 100 100

3.929 3.929 1

0.015071 0.4 1 1 0.6 0.3

0.006 0.6 0.3

0.606

Tabla 4.2. Resultados parciales de las preferencias de calidad elemental CARACTERSTICAS SUBCARACTERSTICAS ATRIBUTOS 1. USABILIDAD 2. FUNCIONALIDAD 3. CONFIABILIDAD 4. EFICIENCIA 5. PORTABILIDAD 6. MANTENIBILIDAD

IG 71.23 79.28 90.46 83.2 84 87

Tabla 4.3. Caractersticas de la evaluacin global para el sistema de gestin acadmica

Finalmente la valoracin obtenida tras utilizar el modelo QEM para el Sistema de gestin acadmica es de 82 %, y como vemos en la tabla este porcentaje obtenido esta en el rango de satisfactorio conforme a la metodologa QEM.

Figura 4.12 Rango de aceptabilidad de preferencia de calidad

122

CONCLUSIONES El presente Proyecto de Grado tiene como el logro principal la implementacin del Sistema de Gestin Acadmica en la Facultad de Ciencias Geolgicas y la propuesta del modelo de reingeniera de software y su aplicacin. Y los objetivos alcanzados son: Se realiz el relevamiento de datos de los procesos acadmicos, se obtuvieron las bases de datos de la carrera de Ingeniera Geogrfica y de la Carrera de Ingeniera Geolgica y del Medio Ambiente. Se efectu la migracin de las bases de datos de ambas carreras al nuevo modelo de base de datos en PostgreSQL, en la que se encontraron observaciones en los nombres, notas, materias de estudiantes por lo que se hizo una verificacin y depuracin de datos, emitindose informes de las observaciones. Se realiza una migracin los datos de los estudiantes nuevos que ingresan a la facultad del Sistema de Matriculacin de UMSATIC-DSIE. Se redujo el tiempo de procesamiento de informacin de los procesos acadmicos, en la emisin de reportes: listados, record acadmico, historial acadmico, actas. Se implement y est funcionando el sistema de gestin acadmico en las 2 carreras de la Facultad de Ciencias Geolgicas. Se realiz un anlisis diseo y desarrollo mdulos de acuerdo a los requerimientos de los usuarios de ambas carreras. Se ejecutaron las pruebas de funcionamiento para cada uno de los mdulos que actualmente son utilizados por los usuarios del sistema. Se realizaron manuales y capacitaciones a autoridades y kardixtas de la Facultad de Ciencias Geolgicas.

123

 Se coordin con el proyecto de redes del programa UMSATIC para la asignacin de puntos de red y de conexin a equipos para la Facultad de Ciencias Geolgicas. Se estudio y presento un modelo de reingeniera de software y su aplicacin del sistema Modelo Informacional al Sistema de Gestin Acadmica. RECOMENDACIONES Se recomienda: Continuar con el proyecto realizar el desarrollo y la implementacin de mdulos para los docentes, y estudiantes de esta manera se har uso de las tecnologas TIC para el crecimiento acadmico y la facilidad de comunicacin entre usuarios. La integracin del sistema de gestin acadmica con el sistema de matriculacin UMSATIC-DSIE para el caso de estudiantes nuevos. La aplicacin de reingeniera de software a sistemas de informacin de acuerdo a los cambios requeridos en la institucin.

124

REFERENCIAS BIBLIOGRAFICAS [CONV2004] Convenio de Cooperacin entre el Ministerio de Educacin y la Universidad Mayor de San Andrs, Marzo de 2004. [JACO2000] Ivar Jacobson, Graddy Booch, James Rumbaugh, R. 2000, Proceso Unificado de Desarrollo de Software [GAPEGROS] [KEND1999] Garcia Pelayo - Gross, Pequeo Larousse Kendall K. y Kendall J., 1999; Anlisis y Diseo de Sistemas. [LARM1999] [MOR&BRAN] Craing Larman, UML y Patrones Morris Daniel & Brandon Joel, 1994, Reingeniera, como aplicarla con xito en los negocios [PRESS2003] Pressman Roger S. 2003 Ingeniera del Software, un enfoque prctico. Quinta Edicin. [SCHMULLE] [ART1] Joseph Schmuller, Aprendiendo UML en 24 horas. Articulo 1 Calidad de Software, Juan Manuel Cueva

Lovelle; Conferencia, 21 de Octubre de 1999, Grupo GIDIS, Universidad Nacional de la Pampa, cueva@lsi.uniovi.es [ART2] Articulo 2 Evaluacin de la Calidad de software en Sistemas de Informacin en Internet, Leticia Dvila Nicanor, Pedro Meja Alvarez, CINVESTAV-IPN. Seccin de Computacin, Av. I.P.N. 2508, Zacatenco. Mxico, DF. 07300.

125

ldavila@computacion.cs.cinvestav.mx, pmejia@cs.cinvestav.mx [ART3] Articulo 3 Desarrollo Orientado a Objetos con UML,

Xavier Ferr Grau, Mara Isabel Snchez Segura. Facultad de Informtica UPM [ART4] Articulo 4 Desarrollo de Software Orientado a Objeto usando UML, Patricio Letelier Torres, Departamento Sistemas Informticos y Computacin (DSIC), Universidad Politcnica de Valencia (UPV) Espaa, letelier@dsic.upv.es [ART5] Articulo 5 Introduccin a Rational Unified Process (RUP), Patricio Letelier Torres, Departamento Sistemas Informticos y Computacin (DSIC), Universidad Politcnica de Valencia (UPV) Espaa, letelier@dsic.upv.es [ART6] Articulo 6 Propuesta de una metodologa de desarrollo de software educativo bajo un enfoque de calidad sistmica, Mara Gabriela Daz-Antn Mara Anglica Prez Anna C. Grimmn Luis E. Mendoza. Universidad Simn Bolvar (USB), Caracas - Venezuela. www.academia-interactiva.com/ise.pdf [ART7] Instituto de Computacin, Facultad de Ingeniera Universidad de la Repblica Oriental del Uruguay. Tcnicas Avanzadas para Gestin de Sistemas de

Informacin Carrera de Ingeniera en Computacin Edicin 2003. Titulo: Implementacin de propuesta de DBRE de "Extracting an Entity Relationship Schema from a Relational Database through Reverse Engineering" Martin Andersson, 1994.

126

Martin Andersson: Extracting an Entinty Relationship Schema from a Relational Database through Reverse Engineering (http://citeseer.nj.nec.com/andersson94extracting.html). [ART8] Master Oficial en Sistemas Telemticos e Informticos TEMA II - Tcnicas y Herramientas de reingeniera Software [ART9] Fundamentos de Ingeniera del Software Tema 9.

Mantenimiento del software, Departamento de Informtica y Sistemas.Facultad de Informtica, Campus Universitario de Espinardo - Murcia Asignatura: Fundamentos de Ingeniera del Software; Titulacin: Ingeniera Tcnica de Informtica de Gestin; Curso Acadmico: 2004-2005, Curso: 3,Cuatrimetres: Primero. Pgina Web: dis.um.es/~lopezquesada; Profesor: Juan Antonio Lpez Quesada; Departamento: Informtica y Sistemas [ART10] Gestin de la evolucin del software. El eterno problema de los legacy systems. Alfredo Rodrguez, Antonio Mrquez, Miguel Toro. Departamento de Lenguajes y Sistemas Informticos, Escuela Tcnica Superior de Ingeniera Informtica, Universidad de Sevilla. Email:amarser@teleline.es [ART11] La Fase de Abstraccin Conceptual en Reingeniera de Bases de Datos mediante Anlisis de Conceptos Formales1

127

Carmen Hernndez, Flix Prieto, Miguel A. Laguna, Yania Crespo. Dpto. de Informtica, Universidad de Valladolid, Espaa Telfono:+(34)983423670; Fax: +(34)983423671 {chernan, felix, mlaguna, yania}@infor.uva.es [ART12] Aplicacin de Tcnicas de Ingeniera Inversa y Reingeniera en Bases de Datos de Sistemas Informticos de Gestin Hotelera. Jos L. Leiva OlivenciaDepartamento de Lenguajes y Ciencias de la Computacin Universidad de Mlaga. email:jlleivao@lcc.uma.es [ART13] [DOC1] [DOCU1994] Mantenimiento de software, tema 16. Documentacin de kardex de la carrera de Geografa y Geologa Documento recopilado del Boletn "KURMI" del 8 de marzo de 1994, Editado por CEIGEO. [COTA2002] Cotaa Mier Miguel, 2002: Sistema de Informacin de gestin Acadmica Facultativa, Proyecto de Grado, La Paz-Bolivia. [MAMA2006] Mamani Julin Porfirio Agustin, 2006: Sistema Informtico de Tesorera, caso: Tesoro Universitario - UMSA, Proyecto de Grado, La Paz-Bolivia. [MORA1997] Morales Mauri Carla, 1997: Reingeniera como mtodo para el mantenimiento del software, Tesis de Grado, La Paz Bolivia. [OLSI1999] Mag. Luis Antonio Olsina, Tesis Doctoral Metodologa Cuantitativa para la Evaluacin y Comparacin de la

128

Calidad de Sistemas basados en la Web, Facultad de Ciencias Exactas de la UNLP, Argentina. [PEA2004] Peafiel plata, G.A. 2004, Gestin Acadmica va Web Universidad Privada Franz Tamayo [SIRP2005] Sirpa Caceres Rocio de la Azucena, 2005: Sistema de Gestin acadmica Universitaria, caso: Facultad de Ingeniera, Proyecto de Grado, La Paz-Bolivia. [VINC2004] Vicente Sanchez Geysa, 2004: Sistema de Registro de Informacin de Gestin Acadmica de la Carrera de Derecho, Proyecto de Grado, La Paz-Bolivia. [WEB2] [WEB3] [WEB4] http://137.94.177/archive/eee583/2000/papers/IEEE/ http://www.monografias.com ModeloScliente/servidor http://www.ucm.es/info/Psyap/Prieto/alum9798/intranet01/client e.htm [WEB5] MSDN http://www.microsoft.com/latam/ articulo escrito por: Armando Calancha [WEB6] Arquitectura Cliente/Servidor www.monografias.com

129

GLOSARIO Framework Conjunto de APIs y herramientas destinadas a la construccin de un determinado tipo de aplicaciones de manera generalista. HTML Hypertext Markup Language. Lenguage de tags estandarizado para la creacin de documentos para la web. HTTP Hypertext Transfer Protocol. Protocolo de nivel de aplicacin usado extensivamente en Internet para el acceso a documentos. ISO Federacin de alcance mundial integrada por cuerpos de estandarizacin nacionales de gran nmero de pases, que promueve el desarrollo de la estandarizacin. J2EE Java 2, Enterprise Edition. Versin avanzada de la plataforma Java de Sun Microsystems, destinada al desarrollo de aplicaciones empresariales. J2SE Java 2, Standard Edition. Versin bsica del conjunto de herramientas y APIs de Sun Microsystems destinadas a la creacin de aplicaciones en plataforma Java.

130

Java Plataforma para el desarrollo de software creada por Sun Microsystems, ampliamente extendida hoy en da, que otorga independencia de plataforma al software creado en ella y lo provee de una gran cantidad de APIs estandarizados. JavaDoc Documentacin HTML embebida en el cdigo Java de una aplicacin, que mediante la herramienta del mismo nombre puede ser convertida en un rbol de pginas HTML que muestre la documentacin del API de la aplicacin de manera detallada. JDBC Java DataBase Connectivity. API de la plataforma Java para el acceso a sistemas gestores de base de datos. JNDI Java Naming and Directory Interface. Servicio estndar de nombrado y directorio en Java. JSP JavaServer Pages. API de la plataforma J2EE para la creacin de pginas web dinmicas mediante el uso de libreras de tags. Mtodo. 1. (constructor de proceso, procedimiento) modo especfico de realizar una tarea o resolver un proceso. Curso de accin u operaciones y conjunto de estndares y procedimientos de modelado a usar para tratar con algn proceso de un proyecto. 2. implementacin de un servicio u operacin de una clase.

131

Metodologa. Conjunto de mtodos asociados a un enfoque con el fin de cubrir una o ms fases o una parte significativa de una fase de un proyecto. Modelo Es una representacin abstracta (abstraccin) de entes o fenmenos del mundo real en la que se consideran los aspectos relevantes de los mismos y se desechan los menos relevantes sin que por ello deje de representar significativamente a esa realidad. Es una estructura en un dominio usado para representar a entes de otro dominio, con el propsito de comprenderlo y/o controlarlo. Modelo de calidad. Conjunto de caractersticas, subcaractersticas y las relaciones entre ellas que proveen la base para especificar requerimientos de calidad con el fin de realizar un proceso de evaluacin. Modelo de ciclo de vida. Modelo de proceso de software, modelo de proceso de producto. Modelo de proceso de desarrollo de software Modelo de ciclo de vida.- 1. Es una estrategia apropiada para abstraer, organizar, ejecutar y/o controlar a las distintas fases, tareas, recursos y artefactos de un proyecto de software con el objeto de alcanzar las metas establecidas. 2. una descripcin ms o menos formal del proceso de desarrollo de software. Por lo que un modelo de proceso expresa: a) un cierto nivel de abstraccin; b) una perspectiva particular del proceso de desarrollo. Model2

132

Modelo arquitectnico para aplicaciones web acuado por Sun Microsystems consistente en la creacin de una aplicacin segn el patrn MVC y estableciendo un controlador nico o front controller en su capa controlador. MVC Model-View-Controller. Patrn arquitectnico desarrollado para interfaces grcas que resalta la importancia de una separacin clara entre la presentacin de datos y la lgica de negocio de una aplicacin. Open Source Calificacin de software que cumple una serie de requisitos, principalmente aquel que permite una libre redistribucin, distribuye el cdigo fuente, y permite modificaciones y trabajos derivados. OSI Open Source Initiative, http://www.opensource.org. Organizacin sin nimo de lucro dedicada a la gestin y promocin del software open source, especficamente a travs del programa de certificacin de software open source. Requerimiento Requerimientos de calidad.- una necesidad o deseo del usuario, explcito o implcito, que se traduce en atributos, caractersticas o funciones necesarias de un artefacto de software (o ente), y que se puede considerar desde el contexto del sistema en un proceso dado. UML Unified Modeling Language. Lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software.

133

Usabilidad Es una caracterstica de calidad de alto nivel -que se la puede medir mediante clculo a partir de mtricas directas e indirectas-, y representa la capacidad o potencialidad del producto para ser utilizado, comprendido y operado por los usuarios, adems de ser atractivo. Incluye principalmente a subcaractersticas como comprensibilidad, operabilidad, y comunicatividad, entre otras caractersticas como estticas y de estilo que hacen del artefacto que sea agradable de usar. XML eXtensible Markup Language. Formato estndar para el intercambio de datos basado en archivos de texto plano con una estructura de tags. Tomcat Contenedor de aplicaciones web que proporciona la implementacin estndar del API servlets y JSP, aunque cualquier otra implementacin puede ser usada. Web (World Wide Web) Sistema de informacin en Internet que vincula mediante hipermedia a documentos o artefactos ubicados en servidores distribuidos en todo el mundo y que, desde el punto de vista del usuario, permite en principio acceder e interactuar con los mismos independientemente de la ubicacin fsica. Web-site QEM. Que en ingls se traduce en Web-site Quality Evaluation Method, es una metodologa basada en mtodos, modelos, principios y herramientas de Ingeniera de Software til para la evaluacin y comparacin cuantitativa de la calidad de artefactos Web, principalmente en la fase operativa del ciclo de vida. No obstante, se puede utilizar en fases de exploracin y desarrollo, en este caso se debe sincronizar con el modelo de proceso de desarrollo.

134

ANEXOS

ARBOL DE PROBLEMAS
LA FACULTAD DE CIENCIAS GEOLOGICAS NO CUENTA CON UN SISTEMA DE GESTION ACADEMICA

En las convalidaciones: las materias del antiguo pensum con materias actuales, no existe una base de datos con esta clase de informacin, donde el alumno pueda verificar esta operacin.

EXISTE DIFERENCIAS ENTRE LOS SISTEMAS DE INFORMACION ACADEMICA

En inscripciones: no se tiene un sistema que controle horarios, prerrequisitos, aulas, retiro y adicin

Tiempos largos en los procesos acadmicos

Tiempos largos en los procesos acadmicos

Las convalidaciones lo realizan manualmente los administrativos

Registro de notas por los docentes: presentan sus notas en actas impresas para luego ser transcritas, lo cual demora mucho tiempo

Reportes: de los titulados y convalidaciones lo realizan en Word

Record acadmico: los estudiantes tienen que esperar para verificar sus notas piden con solicitud su historial o record acadmico

No se cuenta con estadsticas que le muestre acerca de cuantos alumnos tienen inscritos en las diferentes materias que se dictan, ni cuantos estudiantes han reprobado y aprobado por materia

ARBOL DE OBJETIVOS
INPLEMENTAR LAS TICs FACULTATIVAS EN LA FACULTAD DE CIENCIAS GEOLOGICAS

Implementar y desarrollar el Sistema de Informacin Acadmico que automatic los procesos acadmicos de tal manera se pueda controlar, administrar y agilizar los procesos acadmicos que tiene la carrera

Control de inscripciones y retiro de adicin controlando prerrequisitos

Registro de notas por los docentes por Internet Disminuir tiempos en los procesos acadmicos Las convalidaciones automatizadas

Reportes automatizados

Control de los procesos acadmicos

Listas que le muestran cuantos alumnos tienen inscritos en las diferentes materias que se dictan, cuantos estudiantes han reprobado y aprobado por materia