SISTEMA DE INFORMACIÓN WEB QUE ASISTE EL PROCESO...

SISTEMA DE INFORMACIÓN WEB QUE ASISTE EL PROCESO DE RADICACION Y

SEGUIMIENTO DE PROYECTOS DE GRADO DE LA ESPECIALIZACIÓN EN

INGENIERÍA DE SOFTWARE DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE

CALDAS

DIEGO DAYIBER MURILLO GALVIS

JAVIER MOSQUERA DÍAZ

HUGO LEONARDO BARRAGÁN BOHÓRQUEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERIA

ESPECIALIZACIÓN EN INGENIERÍA DE SOFTWARE

BOGOTA, COLOMBIA

2015

SISTEMA DE INFORMACIÓN WEB QUE ASISTE EL PROCESO DE RADICACION Y

SEGUIMIENTO DE PROYECTOS DE GRADO DE LA ESPECIALIZACIÓN EN

INGENIERÍA DE SOFTWARE DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE

CALDAS

Presentado por:

DIEGO DAYIBER MURILLO GALVIS

JAVIER MOSQUERA DÍAZ

HUGO LEONARDO BARRAGÁN BOHÓRQUEZ

TESIS REALIZADA COMO

REQUISITO PARA OPTAR AL

TÍTULO DE ESPECIALISTA EN

INGENIERÍA DE SOFTWARE

Director:

MSC. ALEXANDRA ABUCHAR PORRAS

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERIA

PROYECTO CURRICULAR

COLOMBIA

2015

i

ADVERTENCIA

UNIVERSIDAD FRANCISCO JOSÉ DE CALDAS

Especialización en Ingeniería de Software

Bogotá, D.C. – 2015

Todos los contenidos de esta tesis son producto de la contribución intelectual de los autores,

los datos y referencias a materiales ya publicados están debidamente identificados con su

respectivo crédito e incluidos en las referencias bibliográficas y en las citas que se mencionan y en

los casos que así lo requiera, contamos con las debidas autorizaciones de quienes poseen los

derechos patrimoniales.

Por lo anterior declaramos que todos los materiales que se presentan están totalmente libres

de derechos de propiedad intelectual, exonerando de responsabilidades a la Universidad Distrital

Francisco José de Caldas.

En virtud de lo previsto en los artículos 76 t 77 de la ley 23 de 1982 de la República de

Colombia y las demás normas internacionales sobre Derechos de Autor, y en caso de ser publicada

la Tesis por la Universidad; está podrá disponer en toda su extensión para realizarse en forma

electrónica (digital).

Por medio de la presente autorizamos a la Universidad Distrital Francisco José de Caldas para

publicar en formato digital con las seguridades pertinentes, tanto en red local como en la gran red

Internet, en sitio web de la Universidad o en hosting especial para ello, siempre y cuando se haga

sin fines de lucro y con el fin de divulgar el conocimiento a la comunidad académica y científica

nacional e internacional de acuerdo con las condiciones establecidas, a fin que la investigación

realizada pueda continuar y ser ampliada en caso necesario.

Para constancia de lo anteriormente expuesto, firmamos esta declaración:

Firma: _______________________ Firma: _______________________

Nombre: Diego Dayiber Murillo Nombre: Javier Mosquera Díaz

C.C. C.C.

Firma: _______________________

Nombre: Hugo Leonardo Barragán

C.C.

ii

Universidad Distrital Francisco José de Caldas

Especialización en Ingeniería de Software

Diseño e Implementación del Sistema de Información TheSys

Diego Dayiber Murillo Galvis

Javier Mosquera Díaz

Hugo Leonardo Barragán Bohórquez

Tesis presentada para optar el título de

Especialista en Ingeniería de Software

__________________________

__________________________

__________________________

__________________________

Director

__________________________

__________________________

__________________________

__________________________

Jurado

__________________________

__________________________

__________________________

__________________________

Jurado

Bogotá, D.C., 2015

iii

AGRADECIMIENTOS

Los autores desean expresar su sentimiento de gratitud a sus familias, por su constante apoyo

en nuestras labores académicas, a los docentes Alexandra Abuchar Porras quien fue la directora

del proyecto, Sandro Bolaños quien fue el revisor del proyecto; y en general a todos aquellos que

a través de las asignaturas vistas en el curso de los estudios de Especialización en Ingeniería de

Software en la Universidad Distrital nos dieron las herramientas y consejos necesarios para el

desarrollo del proyecto aquí presentado.

iv

DEDICATORIA

Dedicamos este trabajo a Dios por darnos cada día la bendición de un nuevo día más de vida,

a nuestras familias por su apoyo constante y por ser parte de la motivación que nos impulsa a lograr

nuestros propósitos en esta especialización, a nuestros docentes y compañeros de estudio por

compartir sus experiencias y permitirnos crecer con ellas, finalmente los integrantes de este trabajo

por su esfuerzo y dedicación en la realización de mismo.

v

RESUMEN

Libro de tesis de grado radicado en la Universidad Distrital Francisco José de Caldas para

optar al título de Especialista en Ingeniería de Software de la Facultad de Ingeniería. El proyecto

aborda todas las etapas del ciclo de vida básico para el desarrollo de un sistema de información

web que apoye el proceso de radicación de proyectos de grado de los estudiantes de la

Especialización en Ingeniería de Software de la Universidad Distrital Francisco José de Caldas,

este sistema apoya y respalda el proceso de asignación de directores y revisores, el proceso de

seguimiento y ofrece herramientas funcionales que apoyen la gestión de búsqueda de los proyectos

existentes para contar con estos en referencia sobre estado del arte o para continuar la investigación

que los primeros iniciaron.

Desarrollar este proyecto implicó el uso de métodos y herramientas de desarrollo que

permitieron aplicar los conocimientos adquiridos durante el curso de la especialización, para este

desarrollo se utilizaron metodologías de desarrollo XP y diferentes lenguajes de programación

entre los cuales se encuentra Archimate para el desarrollo de los modelos de los puntos de vista de

la arquitectura del sistema a nivel de negocio, aplicación e infraestructura. Finalmente se detalla el

proceso de gestión de proyectos que se lleva a cabo dentro de la coordinación de la Especialización

en Ingeniería de Software y se identifica la importancia de aplicar herramientas de tecnología que

le aporten mayor eficiencia en tiempo, costos y disponibilidad respecto a los procedimientos

establecidos en dicho proceso.

vi

ABSTRACT

Thesis book submitted at the District University Francisco Jose de Caldas, in accordance with

the requirements of the degree of Specialist in Software Engineering of the Engineering Faculty.

The project approaches all the stages of the lifecycle for the development of a Web information

system, which supports the file process of the grade projects of the students of the program of

Software Engineering Specialization, of the District University Francisco Jose de Caldas, this

system supports the revisers and directors assignment and the tracing processes, and presents

functional tools that support the historical projects searching for the students to have an state-of-

art reference in order to continue those investigations.

To develop this project, it was necessary the usage of methods and tools of software

development, that made possible to apply the knowledge acquired across the study of the

specialization. For this development it was used the XP software development method and different

kinds of programming languages which include Archimate for the design of the different system

architecture viewpoints at the business, application and infrastructure level. Finally it is detailed

the whole projects gestion process which is made inside the Coordination of the Software

Engineering Specialization and it is identified the value of using technological tools that improves

more time, cost and availability efficiency compared to the process originally formulated.

vii

TABLA DE CONTENIDO

1. CAPITULO 1 .................................................................................................................... 2

1.1 Introducción ............................................................................................................... 2

1.2 Justificación ................................................................................................................ 2

1.2.1 Metodológica ............................................................................................... 2

1.2.2 Practica ........................................................................................................ 2

1.3 Objetivos .................................................................................................................... 3

1.3.1 Objetivo General .......................................................................................... 3

1.3.2 Objetivos Específicos .................................................................................. 3

2. CAPITULO 2 .................................................................................................................... 4

2.1 Estudio del problema .................................................................................................. 4

2.1.1 Planteamiento del problema ........................................................................ 4

2.1.2 Formulación del Problema ........................................................................... 5

2.1.3 Sistematización del Problema ...................................................................... 5

3. CAPITULO 3 .................................................................................................................... 6

3.1 Marco Teórico ............................................................................................................ 6

3.1.1 Proyecto de Grado ....................................................................................... 6

3.1.2 Reglamentación de los Proyectos de Grado ................................................ 7

3.1.3 Directores y Revisores ................................................................................. 7

viii

3.2 Marco Conceptual ...................................................................................................... 7

3.2.1 Sistema de Información ............................................................................... 7

3.2.2 MVC ............................................................................................................ 7

3.2.3 Aplicación Web ........................................................................................... 7

3.2.4 Internet ......................................................................................................... 8

3.2.5 Software Libre ............................................................................................. 8

3.2.6 UML ............................................................................................................ 8

3.2.7 Arquitectura de Software ............................................................................. 8

3.2.8 Archimate .................................................................................................. 10

3.3 Marco Espacial ......................................................................................................... 11

3.4 Marco Temporal ....................................................................................................... 11

4. CAPITULO 4 .................................................................................................................. 12

4.1 Tipo de Estudio ........................................................................................................ 12

4.2 Método de Investigación .......................................................................................... 12

4.2.1 Fases de gestión del proyecto .................................................................... 13

4.2.2 Desarrollo del proyecto .............................................................................. 15

4.3 Fuentes y Técnicas para Recolección de Información ............................................. 20

4.3.1 Fuentes Primarias ....................................................................................... 20

4.3.2 Fuentes Secundarias ................................................................................... 20

4.3.3 Recolección de la Información .................................................................. 21

ix

4.3.4 Tratamiento de la Información .................................................................. 21

5. CAPITULO 5 .................................................................................................................. 23

5.1 Contexto Arquitectónico .......................................................................................... 23

5.1.1 Análisis contextual ..................................................................................... 23

5.1.2 Interesados y sus Preocupaciones .............................................................. 24

5.1.3 Puntos de Vista Estándar en Archimate ..................................................... 25

5.2 Desarrollo del Proyecto ............................................................................................ 37

5.2.1 Gestión ....................................................................................................... 37

5.2.2 Planificación del proyecto ......................................................................... 37

5.2.3 Implementación ......................................................................................... 38

5.2.4 Pruebas ....................................................................................................... 39

CONCLUSIONES .................................................................................................................. 40

PROSPECTIVA ..................................................................................................................... 41

BIBLIOGRAFIA .................................................................................................................... 42

ANEXO 1. ACTAS DE REUNIONES .................................................................................. 44

ANEXO 2. PLANIFICACIÓN DEL PROYECTO ................................................................ 45

Descripción de la Iteración 1 .............................................................................................. 45




x


ANEXO 3. PLANEACIÓN DE BASE DE DATOS .............................................................. 57

ANEXO 4. MODELO ENTIDAD RELACIÓN .................................................................... 59

Modelo Entidad Relación.................................................................................................... 59

Diccionario de Datos ........................................................................................................... 59

ANEXO 5. IMPLEMENTACIÓN DE AGREGACIÓN DE RECURSOS AL SISTEMA

(BASE DE DATOS) ...................................................................................................................... 70

ANEXO 6. PRUEBA DE BASE DE DATOS ....................................................................... 78

ANEXO 7. PLANIFICACIÓN DE PRUEBAS ..................................................................... 79

1

TABLA DE ILUSTRACIONES

Figura 1. Esquema Metodológico para el Proyecto. ............................................................... 13

Figura 2. Diagrama de Organización. ..................................................................................... 26

Figura 3. Diagrama de función de negocio. ............................................................................ 27

Figura 4. Diagrama de proceso actual. ................................................................................... 28

Figura 5. Diagrama de modelo propuesto de solución ........................................................... 30

Figura 6. Diagrama de infraestructura. ................................................................................... 31

Figura 7. Diagrama de capas. ................................................................................................. 33

Figura 8. Diagrama de Realización de Objetivos. .................................................................. 34

Figura 9. Diagrama de realización de requerimientos. ........................................................... 35

Figura 10. Diagrama de motivación. ...................................................................................... 36

Figura 11. Diagrama de migración e implementación. ........................................................... 36

2

1. CAPITULO 1

1.1 Introducción

Para la coordinación de la Especialización en Ingeniería de software de la Universidad

Distrital Francisco José de Caldas, es importante realizar de forma adecuada y ágil, todos los

procesos de gestión de proyectos de grado, permitiendo de esta manera que los involucrados en

dicho proceso realicen su participación de forma adecuada y eficiente, y que las labores realizadas

desde la coordinación y los servicios ofrecidos en este ámbito a los estudiantes de las

especializaciones sea eficaz y siempre en pro de hacer que su proceso de radicación de proyecto de

grado tenga la gestión y el seguimiento necesario para garantizar que sus propuestas sean atendidas

y tomadas en cuenta de una forma profesional y correcta.

1.2 Justificación

1.2.1 Metodológica

Desarrollar un sistema de información que permita la gestión de proyectos de grado y agilizar

las actividades que rodean este proceso, ya que actualmente todas se realizan de forma manual y

presencial, por esta razón, el desarrollo del sistema propuesto contribuirá al mejoramiento de las

actividades de gestión de proyectos de grado desde la coordinación de la Especialización en

Ingeniería de Software.

1.2.2 Practica

El desarrollo de un sistema de información, que apoye el proceso de gestión de proyectos de

grado en la coordinación de la Especialización en Ingeniería de Software, y permitirá a las

3

directivas, estudiantes, directores de proyectos y revisores de los mismos, adelantar un proceso

adecuado puesto que con una herramienta tecnológica se realizaran dichas operaciones,

comunicándolas en tiempo real, ahorrando tiempos de desplazamiento, costos y gestión de la

información de los proyectos radicados. Además, ofrecerá a las directivas una herramienta que

permita la gestión de la información de los proyectos de grado y al mismo contar con un buscador

de proyectos para el apoyo de futuras propuestas de grado de nuevos estudiantes.

1.3 Objetivos

1.3.1 Objetivo General

Mejorar el proceso de gestión de los proyectos de grado de la Especialización en Ingeniería

de Software de la Universidad Distrital Francisco José de Caldas mediante la implementación de

un sistema de información web, permitiendo tener un mayor seguimiento sobre el estado de los

proyectos de grado y manteniendo informados a los involucrados en el mismo.

1.3.2 Objetivos Específicos

1. Agilizar el proceso de radicación de proyectos de grado mediante la creación de un

sistema de información web, logrando que este sea un proceso más eficiente y fácil de

usar por parte de los involucrados.

2. Mejorar el proceso de asignación de directores y revisores de los proyectos de grado

con el fin de hacer de éste un proceso eficiente y ágil, ofreciendo esta funcionalidad en

el sistema de información web.

3. Proporcionar un proceso de verificación y seguimiento de los proyectos de grado a

través del sistema de información web con el fin de mantener informados a todos los

involucrados sobre el estado del mismo y facilitando la comunicación entre estos.

4

2. CAPITULO 2

2.1 Estudio del problema

2.1.1 Planteamiento del problema

Actualmente la Universidad Distrital Francisco José de Caldas cuenta con veintidós

especializaciones en diferentes ámbitos del conocimiento, dichas ofertas académicas generan para

cada periodo un grupo amplio de estudiantes que para optar por un título de especialistas tienen

como requisito presentar y radicar sus proyectos de grado para la gestión y seguimiento de los

mismos, actualmente en la coordinación de la Especialización de Ingeniería de Software, no se

cuenta con una herramienta que permita la adecuada gestión y seguimiento del proceso de

radicación, asignación y seguimiento de proyectos de grado, de momento todos los procesos se

realizan de forma manual, y el canal de comunicación se realiza mediante correos electrónicos

dirigidos de esta misma manera o mediante información presencial, no existe un control sobre el

seguimiento o trabajo realizado por parte de los directores de proyectos de tesis, los revisores del

proyecto y tampoco los avances o versiones entregados por los estudiantes a las modificaciones

realizadas en sus correspondientes proyectos de grado.

Se ha evidenciado que el número de estudiantes egresados cada periodo hace que el archivo

de radicación de proyectos de grado crezca de forma considerable y, de mantenerse esta forma de

manejo que se ofrece al proceso de radicación de proyectos, prontamente se encontrará que estas

faltas de organización y sistematización causarán perdidas de información y demoras en las

gestiones que engloban todo el proceso de gestión de proyectos de grado de la Especialización en

5

Ingeniería de Software, para ofrecer un control a las condiciones actuales, se plantea el desarrollo

de un sistema de información que permita la gestión de radicación de proyectos de grado para las

especializaciones previamente referenciadas, este sistema permitirá la radicación y codificación de

los proyectos de grado, además de la asignación de directores y revisores de dichos proyectos,

realizar seguimiento de los cambios y sugerencias realizados al documento de proyecto por parte

de los involucrados, finalmente el proceso de comunicación se realizará automáticamente desde el

sistema, permitiendo de esta manera mantener constantemente actualizados a los actores

involucrados en el proceso de gestión de proyectos de grado.

2.1.2 Formulación del Problema

¿El proceso de gestión de proyectos de grado de la Especialización en Ingeniería de Software

podrá ser mejorado mediante el desarrollo de un sistema de información?

2.1.3 Sistematización del Problema

1. ¿Podrá un sistema de información hacer más ágil el proceso de radicación de proyectos

de software?

2. ¿Podrá un sistema de información permitir que el proceso de asignación de directores

y revisores de proyectos de grado se realice de manera eficiente y ágil?

3. ¿Se podrá mediante un sistema de información, permitir que el proceso de verificación

y seguimiento de los proyectos de grado se realice de manera eficiente y que la

comunicación entre los involucrados del proyecto se efectúe de una manera adecuada?

6

3. CAPITULO 3

3.1 Marco Teórico

El desarrollo de proyectos de grado en la Especialización de Ingeniería de Software, se da

como complemento al establecimiento de iniciativas profesionales que estén alienadas de acuerdo

a lo enunciado en el reglamento estudiantil en el capítulo 1 artículo3, literal B, en el que se define

como uno de los objetivos de la especialización, que todos los estudiantes de las especializaciones

se deberán preparar para contribuir al mejoramiento de la calidad académica de la Universidad

Distrital y responder a los requerimientos del progreso de la ciencia y la ingeniería, así como a las

necesidades sociales del país, debido a lo anterior se contempla el desarrollo del sistema de

información como una forma de aportar al mejoramiento de la calidad académica, abordando de

esta manera el alcance de las normativas que enmarcan el proceso de radicación de proyectos de

grado en la Especialización de Ingeniería de Software, artículos normativos que se detallan a

continuación.

3.1.1 Proyecto de Grado

La Universidad Distrital Francisco José de Caldas define el trabajo de grado como: “El Trabajo

de Grado es un proceso formativo que hace parte del plan de estudios desarrollado por el estudiante

y le conduce a la obtención de un resultado final que ha de presentar, para optar a un título

universitario, en cumplimiento del requisito establecido en el artículo 70 del acuerdo 027 de1993

del Consejo Superior Universitario. Contribuye en la formación integral del estudiante de pregrado

a su preparación para el desempeño profesional, ampliando las posibilidades de investigación,

creación, desarrollo tecnológico, innovación y proyección social”.

7

3.1.2 Reglamentación de los Proyectos de Grado

De acuerdo al artículo 21 del reglamento estudiantil para posgrados de la facultad de

ingeniería, se define lo siguiente: “El Consejo de Facultad reglamentará las formas de presentación

de los proyectos de trabajo de grado y señalará las normas y procedimientos acerca del diseño,

elaboración, presentación y corrección de los trabajos de grado propiamente.”

3.1.3 Directores y Revisores

De acuerdo al artículo 22 del reglamento estudiantil para posgrados de la facultad de

ingeniería, se define lo siguiente: “Todo trabajo de grado tendrá un Director y un Jurado

Calificador, compuesto por un mínimo de dos (2) profesores del programa, nombrados por el

Consejo de Postgrado.”

3.2 Marco Conceptual

3.2.1 Sistema de Información

Un sistema de información es un conjunto de elementos (equipos computacionales, recursos

humanos, datos e información y software) que interactúan entre sí para apoyar las actividades de

una organización.

3.2.2 MVC

El Modelo-Vista-Controlador (MVC) es un patrón de arquitectura de software que separa los

datos y la lógica de negocio (Modelo) de una aplicación de la interfaz de usuario (Vista) y el

módulo encargado de gestionar los eventos y las comunicaciones (Controlador).

3.2.3 Aplicación Web

En la ingeniería de software se denomina aplicación web a aquellas herramientas que los

usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet

8

mediante un navegador. En otras palabras, es una aplicación software que se codifica en un

lenguaje soportado por los navegadores web en la que se confía la ejecución al navegador.

3.2.4 Internet

Internet es un conjunto descentralizado de redes de comunicación interconectadas que utilizan

la familia de protocolos TCP/IP, lo cual garantiza que las redes físicas heterogéneas que la

componen funcionen como una red lógica única, de alcance mundial.

3.2.5 Software Libre

Según la FSF (Free Software Foundation), software libre es el software que respeta la libertad

de los usuarios y la comunidad. En grandes líneas, significa que los usuarios tienen la libertad para

ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software. Un programa es software libre

si los usuarios tienen las cuatro libertades esenciales: libertad de ejecutar el programa como se

desea, con cualquier propósito; libertad de estudiar cómo funciona el programa, y cambiarlo para

que haga lo que usted quiera (el acceso al código fuente es una condición necesaria para ello);

libertad de redistribuir copias para ayudar a su prójimo y libertad de distribuir copias de sus

versiones modificadas a terceros.

3.2.6 UML

“UML (Lenguaje Unificado de Modelado) permite a los creadores de sistemas generar diseños

que capturan sus ideas en una forma convencional y de fácil comprensión para comunicarlas a otras

personas”.

3.2.7 Arquitectura de Software

Según el estándar ISO 42010 la arquitectura de software es el proceso de concebir, definir,

expresar, documentar y certificar la implementación y mejora de un sistema a través de su ciclo de

9

vida. Adicionalmente según ese estándar los sistemas se representan a través de sus conceptos

fundamentales o propiedades en su ambiente representadas en sus elementos, relaciones, y los

principios de su diseño y evolución.

En los siguientes numerales se listan algunos conceptos básicos utilizados en el desarrollo del

proyecto.

3.2.7.1 Interesados

Un interesado o Stakeholder Persona, equipo, organización o sus clases, que tienen algún

interés en un sistema.

3.2.7.2 Preocupaciones

Una preocupación o Concern es un interés en un sistema relevante a uno o más interesados, a

continuación se listan ejemplos típicos de interesados y sus preocupaciones:

Gerencia de alto nivel: ¿Cómo podemos asegurar que nuestras políticas son seguidas

en el desarrollo y operación de los procesos y sistemas? ¿Cuál es el impacto de las

decisiones en las distintas áreas de la empresa (persona, finanzas, IT, etc.)?

Gerente operacional: Responsable de la explotación o el mantenimiento: Por ejemplo,

¿De Cuales tecnologías nuevas se requiere preparación? ¿Hay alguna necesidad de

adaptar los procesos de mantenimiento? ¿Cuál es el impacto de los cambios de las

aplicaciones existentes? ¿Qué tan seguros son mis sistemas?

Gerente de proyecto: Responsable del desarrollo de nuevas aplicaciones: ¿Cuáles son

los dominios relevantes y sus relaciones? ¿Cuál es la dependencia de los procesos de

negocio de las aplicaciones a ser construidas? ¿Cuál es su desempeño esperado?

Desarrollador: ¿Cuáles son las modificaciones respecto de la situación actual que

necesitan ser realizadas?

10

3.2.7.3 Puntos de Vista

Cada interesado tiene unas preocupaciones que pueden ser exclusivos o comunes a otros

interesados, dichas preocupaciones se deben caracterizar desde distintas perspectivas o vistas de

arquitectura. El estándar de representación de dichas vistas se denomina un punto de vista.

Los puntos de vista se clasifican de acuerdo a su propósito en:

Diseño: Los puntos de vista de diseño dan soporte a los arquitectos y diseñadores en

el proceso de diseño, desde las plantillas iniciales hasta el diseño detallado.

Típicamente los tipos de puntos de vista de diseño consisten en diagramas, como

aquellos utilizados por ejemplo en UML.

Decisión: Los puntos de vista apoyan a los gerentes en el proceso de toma de

decisiones a través de la revisión de las relaciones transversales de arquitectura,

típicamente a través de proyecciones e intersecciones de los distintos modelos, aunque

también por medio de técnicas analíticas. Ejemplos típicos son las tablas de referencia

cruzadas, mapas de paisaje (Landscape), listas y reportes.

Informe: Los puntos de vista de informe ayudan a informar a cualquier interesado de

la arquitectura empresarial, con el objetivo de lograr un entendimiento, lograr

compromisos, y convencer a detractores. Ejemplos típicos son ilustraciones,

animaciones, caricaturas, etc.

3.2.8 Archimate

Archimate es un lenguaje grafico estándar abierto de la organización Open Group que fue

desarrollado para describir, analizar y visualizar las relaciones entre elementos pertenecientes a

distintos dominios de una arquitectura empresarial de una forma no ambigua.

Los dominios definidos y representados por Archimate se listan a continuación:

11

Negocio: Todo lo relacionado con los procesos de negocio, así como los roles y actores

que intervienen en ellos.

Aplicación: Todo los relacionado con las aplicaciones de software utilizadas para

apoyar los procesos de negocio.

Infraestructura: Todo los relacionado con la infraestructura física que soporta las

aplicaciones utilizadas en los procesos de negocio.

Motivacionales: Todo lo relacionado con los aspectos que motivan el diseño y la

operación de la empresa, más exactamente como se alinea la operación de los procesos

de negocio y tecnológicos con los objetivos estratégicos de la empresa.

3.3 Marco Espacial

El desarrollo será llevado a cabo en la Universidad Distrital Francisco José de Caldas,

directamente en la coordinación de la Especialización de Ingeniería de Software de la facultad de

ingeniería.

3.4 Marco Temporal

La implementación de la solución propuesta en este documento comprenderá un periodo de

ejecución establecido entre Enero y Junio de 2015.

12

4. CAPITULO 4

4.1 Tipo de Estudio

Esta investigación es de tipo Experimental ya que presenta la manipulación de diferentes

variables no comprobadas en condiciones controladas, la idea de esta investigación es experimentar

sobre el proceso de radicación y gestión de proyectos de grado para identificar formas de mejorar

dicho proceso. Esta investigación también tiene estudios de tipo Exploratoria ya que este indaga

sobre una perspectiva innovadora, y prepara el terreno para nuevos estudios. La metodología de

investigación para este proyecto será la siguiente:

1. Identificación y definición del problema.

2. Definición de variables.

3. Diseño de un plan experimental.

4. Realización de experimentos.

5. Tratamiento de datos.

6. Presentación de Informe

4.2 Método de Investigación

Para la implementación del sistema TheSys, se utilizó la metodología de desarrollo XP, por

ser rápida, eficiente y detallada en los diferentes aspectos de requerimientos necesarios para

cualquier solución.

En la metodología XP, se habla de Iteraciones, de Historias y de Tareas, entendiéndose estas

primeras como fases, las segundas como requerimientos y las terceras como las actividades que se

13

deben realizar para cada requerimiento, en la Figura 1 se muestra el diagrama general de la

estructura de desglose de trabajo del ciclo de un proyecto típico manejado según XP.

4.2.1 Fases de gestión del proyecto

Figura 1. Esquema Metodológico para el Proyecto.

4.2.1.1 Gestión del proyecto

En la fase inicial del proyecto se hace un acercamiento global del proyecto que se quiere

realizar, en este punto se presentan las necesidades y el nivel de importancia de cada una de las

actividades requeridas.

4.2.1.1.1 Planificación del Proyecto

En la planificación del proyecto se toman todas las necesidades obtenidas y se determinan las

diferentes iteraciones a desarrollar.

14

Planificación Inicial: Durante esta etapa, se recopilará, analizará y clasificará la

información del proceso de gestión de proyectos de grado en la coordinación de la

especialización. También se describirán las ideas iníciales que se tienen acerca del

proyecto.

Iteraciones: En este documento de presentación se mostrará una descripción de las

historias llevadas a cabo en esta iteración, junto con sus pruebas funcionales,

capturas de pantalla y finalmente las incidencias que hubo en esta iteración.

Historia: En este nivel de la metodología se definirán las Historias ò

requerimientos pertenecientes a cada iteración o fase.

Tarea: Serán las diferentes actividades que se van a realizar para poder llevar a cabo

una historia.

4.2.1.2 Implementación

El proceso de implementación consiste en llevar a cabo cada uno de las fases planeadas dentro

de la gestión del proyecto, en estas se abordan los temas relacionados con la base de datos, las

interfaces de usuarios, la modulación del sistema a desarrollar y los diferentes reportes que se

requieran para cumplir con lo establecido en la gestión.

Una vez finalizado el desarrollo de cada ítem de gestión propuesto se deben realizar pruebas

del desarrollo.

4.2.1.2.1 Bases de datos

La base de datos debe estar obligatoriamente incluida en la planificación de la gestión del

proyecto, ya que es indispensable contar con ésta para el desarrollo del sistema de información.

Planificación: Para el desarrollo de la base de datos en necesario conocer los diferentes

módulos que se requieren implementar en el sistema a desarrollar, para esto en

15

indispensable conocer los diferentes requerimientos del software, además es

indispensable definir en este punto el motor de bases de datos que se implementará en

el sistema.

Implementación: El proceso de implementación de la base de la base de datos consta

de la elaboración del modelo entidad relación, los script necesarios para la creación

real de la base de datos, cumpliendo con todas las características identificadas en el

MER propuesto, por último de la implementación surge el diccionario de datos del

sistema, que debe ser incluido en la documentación técnica del proyecto.

Pruebas: En las pruebas de bases de datos consiste en identificar que las entidades de

la base de datos creada cubren todas las necesidades de los diferentes requerimientos

indicados para el proyecto a desarrollar.

4.2.1.2.2 Elaboración de código fuente

Actividad en la cual se lleva a cabo la construcción de la interfaces de usuario de las cuales se

compone el sistema TheSys.

4.2.2 Desarrollo del proyecto

4.2.2.1 Gestión

En todo el transcurso de la gestión del proyecto se utiliza el formato del acta de avances

mostrado en la Tabla 1, tal formato sirve como herramienta para registrar las reuniones a realizar

tanto internas como externas, que se utilizan como guía para registrar el estado del proyecto y la

planeación hecha en cada reunión

16

Tabla 1. Acta de avances del proyecto.

Acta de Avances de Desarrollo del Proyecto

Fecha: Hora Inicio: Hora Fin:

Participantes: Lista de participantes de la reunión.

Temas de Avance: ítems de temas a tratar en la reunión.

Compromisos: Nuevas actividades que surgen durante la reunión y se asigna a un responsable.

Conclusiones: Resultado al que se llega una vez revisados los ítems propuestos en los temas de

avance.

4.2.2.2 Planificación del proyecto

Los siguientes son los diferentes formatos a través de los cuales se realizará la entrega formal

de la planificación del proyecto.

Tabla 2. Planificación de Iteraciones.

Planificación de Iteraciones

Iteración:1

Usuario: Usuario(s) responsable(s) de esta fase o iteración

Nombre Iteración: Nombre de la iteración o fase.

Prioridad en negocio:

(Alta/ Media / Baja)

Riesgo en desarrollo:


Historias estimadas: #

Programadores responsables: Nombre de los programadores o personas responsables de las

historias de esta fase.

Descripción:

Descripción detallada de la iteración

Lista de Historias Estimadas:

Todas las posibles historias que se estimen para esta iteración

17

Observaciones:

Todas las observaciones que se tengan de iteración.

Tabla 3. Planificación de Historias.

Planificación de historias [Usuario]

Número:1 Usuario: Usuario que interviene en la actividad

Nombre historia: Nombre de la historia o requerimiento





Tareas

estimadas: #

Iteración asignada: #

Programador responsable: Nombre del programador o persona responsable de la actividad

Descripción:

Descripción detallada de la Historia

Observaciones:

Todas las observaciones que se tengan de la historia o requerimiento.

Tabla 4. Planificación de Tareas.

Planificación de tareas

Número tarea: 2

Número historia: 1

Puntos estimados: 5

Nombre tarea: Nombre de la tarea a realizar

Fecha inicio: dd / mes / aaaa Fecha fin: dd / mes / aaaa

Programador responsable: Equipo o persona responsable

Descripción:

Comprobación que la definición establecida para la base de datos admite los campos que se leen

del fichero de entrada, realizando las oportunas modificaciones.

18

4.2.2.3 Implementación

Para el desarrollo del proyecto teniendo en cuenta la metodología planteada eXtreme

Programming XP se dividirá la etapa de implementación en: bases de datos, interfaces de usuario

y pruebas. Cada una de estas etapas tiene un ciclo interno de planeación, implementación y pruebas.

De esta manera se asegura el mantenimiento de un correcto ciclo de vida de acuerdo a los

lineamientos planteados en la planeación inicial.

4.2.2.3.1 Bases de datos

Planeación: En la planeación de la base de datos, se analizan las entidades necesarias

para cumplir con cada una de las iteraciones planeadas en el documento de gestión. En

la Tabla 5 se muestra la plantilla del formato a utilizar en la planeación.

Tabla 5. Planeación de Bases de Datos.

Planeación de Bases de datos

Nombre del Módulo Entidades de BD

Relacionadas

Observaciones

Ciudades

Departamentos

Ciudades

La entidad ciudades incluye

como llave foránea la llave

primaria de la entidad

departamentos.

Implementación: Para la implementación de la base de datos se definen los scripts de

las tablas identificadas en la planeación y su correspondiente MER Tales artefactos se

registran en un documento cuya plantilla se muestra en la Tabla 6.

Tabla 6. Implementación de recursos al sistema Bases de Datos.

Implementación de recursos al sistema [Bases de Datos]

Nombre historia: Nombre de la historia o requerimiento

Iteración asignada: # Numero historia: # Tareas cumplidas con este

agregado:

# Programador responsable: Nombre del programador o persona responsable de la actividad

19

Descripción:

Descripción detallada del módulo agregado

Respaldos:

Scripts correspondientes a las entidades agregadas.

Imagen del modelo agregado al sistema:

• Pruebas: La pruebas de integridad de las bases de datos a diseñar e implementar se registran

en un documento cuya plantilla se muestra en la Tabla.

Pruebas de Bases de datos

Modulo Normalización

Adecuada

Llaves primarias,

Foráneas e índices

definidos

Diccionario de

datos definido

para la tabla

Observaciones

Si No Si No Si No

4.2.2.4 Pruebas

Muestra el entregable formal de la etapa en el cual se detallan: Número de tarea, historia e

interacción, encargado de la prueba, nombre de tarea, descripción, datos de entrada, resultado

esperado y evaluación de la prueba. Dichas pruebas se registran en un documento cuyo formato se

muestra en la Tabla 7.

Tabla 7. Planificación de Pruebas.

Planificación de pruebas

Número tarea: 2 Número historia: 1 Iteración:1

Encargado de prueba: Equipo o persona responsable

Nombre de tarea: Desarrollo / Corrección / Mejora / Verificación

Descripción:

Descripción de las funcionalidades que presenta la tarea a testear.

20

Condiciones de ejecución:

Condiciones iníciales para poder ejecutar correctamente la tarea.

Datos de entrada:

Datos o parámetros de entrada para la el correcto funcionamiento de la tarea.

Resultado esperado:

Resultado esperado después de realizar la prueba con las entradas establecidas.

Evaluación de la prueba:

Evaluación del resultado obtenido en la prueba realizada.

4.3 Fuentes y Técnicas para Recolección de Información

Para la investigación referente al desarrollo del sistema de información propuesto se contó con

las siguientes fuentes para la recolección de la información que permitiera llegar a la solución

propuesta.

4.3.1 Fuentes Primarias

Amalia Carrillo - “Secretaria Coordinación Posgrados Especialización Ingeniería de

Software”

Msc. Alexandra Abuchar Porras - “Directora del grupo de investigación de la

especialización- ESPINSOFT”

4.3.2 Fuentes Secundarias

Doce006E tes asignaturas bases de datos e informática universidad Distrital.

SOMMERVILLE, Ian. Ingeniería del Software. Séptima Edición. Madrid: Pearson

Education S.A., 2005 ISBN: 84-7829074-5.

GRACIA, Joaquín. Patrones de diseño: Diseño de software orientado a objetos.

Zaragoza, 2003 [disponible en línea]

http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php.

http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php

21

4.3.3 Recolección de la Información

La información para adelantar esta propuesta de grado se llevó a cabo mediante entrevista

presencial con los actores expertos en los procesos de radicación de proyectos de grados y

seguimiento a los mismos de la coordinación de la Especialización en Ingeniería de Software.

4.3.4 Tratamiento de la Información

El problema de investigación planteado se va a resolver a través del diseño e implementación

de un sistema de información basado en computador para la gestión y control del proceso descrito.

Como se explicó anteriormente se escogió el proceso XP como método de desarrollo para el

proyecto debido a que esta técnica se adapta a equipos de desarrollo de software pequeños como

es este caso, ya que se pretende la obtención de un producto con características de calidad, sin

rigurosidad en la documentación asociada al proceso de desarrollo más allá de la estrictamente

requerida.

Todo proceso de desarrollo de software se puede dividir en cuatro grandes fases:

Especificación de requerimientos

Diseño y desarrollo

Pruebas

Despliegue y mantenimiento.

Estas fases generarán de forma inevitable información asociada que será vital para realizar el

análisis de cada etapa del proyecto y a su vez servirá como entrada a la siguiente fase según

corresponda. Por este motivo es imperativa la definición de un estándar en la administración de la

información manejada en todo el proceso de desarrollo del producto.

La información manejada en todo el proceso de desarrollo se divide en dos grandes categorías:

22

Documentos de desarrollo: se llevarán a cabo las actas de reunión, los requerimientos

estarán definidos en los formatos de iteraciones, historias y tareas, en adición, se

diligenciarán todos los formatos establecidos en la metodología elegida para este

desarrollo.

Código fuente: La codificación del diseño planteado en la plataforma de desarrollo

seleccionada para ello.

Se hace la distinción en los dos tipos de documentos descritos arriba porque la administración

de versiones se va a hacer en una herramienta distinta en cada caso como se detalla a continuación:

Documentos de desarrollo

Se plantea la utilización de la plataforma Dropbox para el almacenamiento y el control

de la versión de los documentos, esto garantiza que la información esté disponible en

la medida en que la plataforma lo esté, adicionalmente se garantiza una herramienta

que soporta el control de versiones para asegurar la correcta trazabilidad en la gestión

del proyecto. Todos los documentos a versionar se codificarán en función de su tipo y

objeto.

Código fuente

Se plantea la utilización de un servidor GIT para el almacenamiento de las fuentes del

programa a desarrollar, esto asegura que la información se va a mantener privada a los

interesados del proyecto, y que los cambios hechos se van a versionar.

23

5. CAPITULO 5

5.1 Contexto Arquitectónico

5.1.1 Análisis contextual

El proyecto se desarrolla en la coordinación de la Especialización en Ingeniería de Software

en la Universidad Distrital Francisco José de Caldas, una entidad de educación superior pública

adscrita a la Alcaldía Mayor de la ciudad de Bogotá. A continuación se detallan los aspectos de la

organización que se consideraron más relevantes para el análisis del proyecto.

5.1.1.1 Misión

La misión de la Universidad Distrital Francisco José de Caldas‚ es la democratización del

acceso al conocimiento para garantizar, a nombre de la sociedad y con participación de Estado, el

derecho social a una Educación Superior con criterio de excelencia, equidad y competitividad

mediante la generación y difusión de saberes y conocimientos con autonomía y vocación hacia el

desarrollo sociocultural para contribuir fundamentalmente al progreso de la Ciudad‚ Región de

Bogotá y el país.

5.1.1.2 Visión

La Universidad Distrital Francisco José de Caldas, en su condición de Universidad autónoma

y estatal del Distrito Capital, será reconocida nacional e internacionalmente por su excelencia en

la construcción de saberes, conocimientos e investigación de alto impacto para la solución de los

problemas del desarrollo humano y transformación sociocultural, mediante el fortalecimiento y la

24

articulación dinámica, propositiva y pertinente de sus funciones universitarias en el marco de una

gestión participativa, transparente y competitiva.

5.1.1.3 Aspecto Legal

La Universidad Distrital Francisco José de Caldas define el trabajo de grado de la siguiente

manera: “El Trabajo de Grado es un proceso formativo que hace parte del plan de estudios

desarrollado por el estudiante y le conduce a la obtención de un resultado final que ha de presentar,

para optar a un título universitario, en cumplimiento del requisito establecido en el artículo 70 del

acuerdo 027 de 1993 del Consejo Superior Universitario. Contribuye en la formación integral del

estudiante de pregrado a su preparación para el desempeño profesional, ampliando las posibilidades

de investigación, creación, desarrollo tecnológico, innovación y proyección social”.

5.1.2 Interesados y sus Preocupaciones

Se identifican los siguientes interesados y sus correspondientes preocupaciones:

Estudiante: Actor que se encarga de la radicación del proyecto y sus correspondientes

correcciones posteriores a las revisiones del Director o Revisor del proyecto.

Preocupaciones:

o Realizar las entregas en las fechas oportunas sin tener que desplazarse a las

instalaciones de la Universidad.

o Realizar la radicación y las correcciones del proyecto sin incurrir en costos de

impresión por cada nuevo ajuste

o Tener un histórico de consulta de los proyectos existentes.

Coordinador: Actor que se encarga de la recepción de los proyectos y la asignación

de los Directores y Revisores de los mismos.

25

Preocupaciones:

o Tener un control adecuado de la asignación de Directores y Revisores en cada

proyecto teniendo en cuenta su carga de asignación, no más de 3 proyectos por

Director y Revisor.

o Realizar seguimiento de la gestión llevada a cabo por los directores y revisores

asignados a los proyectos.

o Contar con un historial de proyectos de fácil acceso y consulta.

Director y Revisor: Actores que se encargan de guiar el desarrollo de los proyectos

degrado previamente asignados por parte de la coordinación.

Preocupaciones:

o Contar con una manera eficiente de acceder al historial de los proyectos de tesis

asignados.

o Realizar la retroalimentación de las revisiones de los proyectos asignados de

una manera eficiente y en el menor tiempo posible.

5.1.3 Puntos de Vista Estándar en Archimate

En Archimate se ha definido un conjunto de puntos de vista de arquitectura estándar basados

en la experiencia práctica. Cada punto de vista es una selección de un subconjunto relevante de

concepto de Archimate y sus relaciones, además de la representación de esa parte de la arquitectura

que es expresada en diferentes diagramas.

26

En las siguientes subsecciones se describen en detalle los puntos de vista estándar definidos

en Archimate aplicados al proyecto, acompañadas de la definición de cada punto de vista según la

documentación de Archimate1.

5.1.3.1 Diagrama de Organización

El punto de vista de organización se enfoca en la organización interna de una compañía, un

departamento, una red de compañías o cualquier otra entidad organizacional. Es posible

representarlos modelos de este punto de vista como bloques de diagrama anidados, pero también

de una forma más tradicional, tal como cuadros organizacionales. El punto de vista organizacional

es muy útil para identificar competencias, autoridades y responsabilidades en una organización.

Figura 2. Diagrama de Organización.

La estructura de organización mediante la cual se lleva a cabo la gestión de proyectos de grado

se establece de la siguiente manera:

La organización se compone a través del coordinador de la especialización en ingeniería de

software y el comité de evaluación de proyectos de grado, además, se cuenta con docentes que

1 The Open Group; Archimate 2.1 Specification; http://pubs.opengroup.org/architecture/archimate2-

doc/toc.html; consultado el 17/05/2015

http://pubs.opengroup.org/architecture/archimate2-doc/toc.html

http://pubs.opengroup.org/architecture/archimate2-doc/toc.html

27

pueden cumplir los roles de “Director” y/o “Revisor” con el fin de colaborar en la asesoría de los

proyectos de grado presentados por los estudiantes.

5.1.3.2 Diagrama de Función de Negocio

El punto de vista de función de negocio muestra las principales funciones de negocio y sus

relaciones en términos de flujos de información, valor o bienes entre ellas.

Figura 3. Diagrama de función de negocio.

Las funciones de negocio definidas de acuerdo a cada rol son las siguientes:

Estudiante:

o Radicar Proyecto.

o Ajustar Proyecto.

Coordinador:

o Generar estrategias de terminación en el tiempo de la especialización.

o Asignar Directores y Revisores.

o Mediar en las diferencias de conceptos entre los Estudiantes, Directores y

Revisores.

Director:

28

o Guiar el desarrollo del proyecto.

o Revisar el proyecto

5.1.3.3 Diagrama de Proceso de Negocio Actual

Figura 4. Diagrama de proceso actual.

La coordinación de especialización en Ingeniería de Software de la Universidad Distrital

cuenta un servicio que permite gestionar los proyectos de grado de los estudiantes de la

especialización en ingeniería de software, este servicio se realiza mediante el proceso de gestión

de proyectos de grado al cual tienen acceso los estudiantes dueños del proyecto, directores de los

proyectos, revisores de los proyectos y el coordinador de la especialización en ingeniería de

software.

El proceso para gestionar un proyecto de grado se inicia desde el momento en que se registra

el proyecto, acción que se implementa mediante el proceso de recepción de proyectos, proceso en

29

el que participan tanto estudiantes como coordinadores, una vez recibido el proyecto se continúa

con el proceso de asignación de director y revisor del proyecto recibido, en este proceso intervienen

el coordinador y los directores y revisores; una vez asignados el director y el revisor del proyecto

se lleva a cabo el proceso de realización de seguimiento de proyectos, en este proceso intervienen

los estudiantes del proyecto y el director y revisor asignados al mismo, el proceso se ejecuta las

veces que sean necesarias hasta llegar al evento de aprobación.

Una vez aprobado el proyecto de grado se llega al objeto de negocio que es dado mediante la

realización y presentación final del proyecto de grado de los estudiantes que se verá reflejado a

través un documento en el que se registra todo el proceso de elaboración del proyecto y que

finalmente será entregado de forma física y digital “CD”.

30

5.1.3.4 Modelo propuesto de solución

Figura 5. Diagrama de modelo propuesto de solución

31

La coordinación de la Universidad Distrital proporcionará un servicio por medio del cual se

pretende facilitar la radicación, seguimiento y finalización de los proyectos de grado de los

estudiantes de la especialización en Ingeniería de Software, dicho servicio será proporcionado a

través del sistema TheSys para apoyar el proceso de gestión de proyectos de grado haciéndolo más

eficiente y logrando que se cumpla de forma eficaz la ejecución del contrato (Acta de sustentación)

establecido entre la coordinación de la especialización en ingeniería de software y el estudiante.

5.1.3.5 Diagrama de Infraestructura

El punto de vista de infraestructura contiene los elementos de infraestructura de software y

hardware que soportan la capa de aplicación, tal como dispositivos físicos, redes o sistemas de

software.

Figura 6. Diagrama de infraestructura.

Para garantizar un funcionamiento óptimo y eficiente del sistema TheSys se define una

infraestructura basada en web, en la cual su distribución se presenta de la siguiente manera:

Un servidor de base de datos que almacenará la base de datos del sistema.

Un servidor de aplicación que almacenará los archivos del sistema TheSys.

32

Un servidor de archivos que almacenará los documentos del proyecto de grado de los

estudiantes en sus diferentes versiones de revisión.

Acceso a Internet.

Una red LAN.

Computadores con Acceso a Internet para acceder la aplicación desde el lado del

cliente.

El sistema TheSys requerirá de un servidor de aplicaciones desde el cual se accederá a los

componentes de Seguimiento de Proyectos, Directorio de Participantes, Registro de Usuarios y

Biblioteca de Proyectos, que harán funcional el sistema y eficiente el proceso de Gestión de

Proyectos de Grado.

5.1.3.6 Diagrama en Capas

El punto de vista en capas muestra distintos capas y aspectos de una arquitectura empresarial

en un solo diagrama. Debido a que se representan múltiples aspectos de una arquitectura

empresarial en un único diagrama, el metamodelo de este punto de vista es la especificación

completa de Archimate que puede ser incluida.

33

Figura 7. Diagrama de capas.

En el diagrama se muestran la interacción entre los actores y roles identificados, los procesos

de negocio que soportan el proceso de gestión de proyectos de grado, los componentes de software

principales planificados y la infraestructura necesaria para alojar tales aplicaciones.

34

5.1.3.7 Diagrama de Realización de Objetivos

El punto de vista de realización de objetivos permite a un diseñador modelar un refinamiento

de alto nivel de los objetivos a objetivos más concretos, y dichos refinamientos a requerimientos o

restricciones que describen las propiedades que son requeridas para la realización de los objetivos.

Figura 8. Diagrama de Realización de Objetivos.

El principio fundamental del sistema TheSys es la Facilidad y la Disponibilidad, en estos

principios se enmarcan los requerimientos y las restricciones para lograr los objetivos establecidos.

5.1.3.8 Diagrama de Realización de Requerimientos

El punto de vista de realización de requerimientos permite al diseñador modelar la realización

de los requerimientos por los elementos base del modelo, tal como los actores del negocio, servicios

del negocio, procesos de negocio, servicios de aplicación, componentes, etc.

35

Figura 9. Diagrama de realización de requerimientos.

En la Figura 9 se detallan los diferentes objetivos con sus correspondientes requerimientos, y

las restricciones asociadas identificadas para la realización de cada objetivo.

5.1.3.9 Diagrama de Motivación

El punto de vista de motivación permite a los diseñadores o analistas modelar el aspecto

motivacional, sin enfocarse en elementos determinados dentro de ese aspecto. Por ejemplo este

punto de vita puede ser utilizado para presentar un resumen total o parcial del aspecto motivacional

relacionando los interesados, sus objetivos principales, los principios que son aplicados, y los

principales requerimientos, sobre los servicios, procesos, aplicaciones y objetos.

En la Figura 10 se presentan los interesados con sus correspondientes motivaciones

(Manejadores), y el valor agregado que desean obtener al lograr sus objetivos, además se identifican

los requerimientos asociados en la contribución de estos objetivos y sus fortalezas y debilidades.

36

Figura 10. Diagrama de motivación.

5.1.3.10 Diagrama de Migración e Implementación

El punto de vista de implementación y migraciones utilizado para relacionar programas y

proyectos a las porciones de la arquitectura que ellas desarrollan.

Figura 11. Diagrama de migración e implementación.

En la Figura 11 se presenta el proceso de migración para realizar la puesta en marcha del

sistema TheSys con su correspondiente flujo de proceso identificando los hitos correspondientes,

adicionalmente se muestra la visión general del proyecto correspondiente al sistema TheSys.

37

5.2 Desarrollo del Proyecto

El desarrollo del proyecto aquí descrito corresponde a las fases explicadas en el numeral 4.2.

A continuación se referencian los artefactos producidos de la gestión del proyecto y adjuntos a este

documento como anexos.

5.2.1 Gestión

En las distintas etapas del proyecto se realizaron una serie de reuniones, el desarrollo de dichas

reuniones, sus las conclusiones y los compromisos adquiridos por los participantes se registraron

en actas.

En el Anexo 1 se adjuntan todas las actas de las reuniones que tuvieron lugar en el desarrollo

del proyecto.

5.2.2 Planificación del proyecto

Para llevar a cabo la planificación del proyecto, primero se realizó el análisis de arquitectura

detallado en el numeral 5.1, dicho análisis dio como resultado los objetivos que debe suplir el

sistema a modelar, así como las tareas que tal sistema debe soportar, además se propuso una serie

de componentes lógicos de software que son responsables de dichas tareas.

Con base en los elementos identificados en el análisis de arquitectura se planteó una estructura

de desglose de tareas o EDT (WBS por sus siglas en ingles), dicha estructura se compone de

iteraciones, historias y tareas, de acuerdo a los lineamientos establecidos en la metodología de

trabajo planteada. En el Anexo 2 se muestra el EDT planteado.

38

5.2.3 Implementación

Tal y como se explicó en la sección de metodología planeada, la implementación del proyecto

se dividió en tres fases principales: bases de datos, interfaz de usuario y pruebas, a continuación se

detalla el desarrollo de cada una de las fases.

5.2.3.1 Bases de Datos

Planeación

En la planeación de la base de datos se plantearon las entidades requeridas por el sistema, este

planteamiento se realizó con base en las necesidades identificadas en las entrevistas realizadas a

las personas que intervienen ante la coordinación de la Especialización en Ingeniería de Software

en la gestión de proyectos de grado; dichas entidades se muestran en el ANEXO 3. PLANEACIÓN

DE BASE DE DATOS.

El anexo contiene un mapeo completo de los módulos del prototipo, relacionando cada módulo

con una entidad planteada y registrando las principales operaciones que se espera ejecute cada

módulo sobre la entidad propuesta.

Implementación

La implementación de la base de datos consistió en el planteamiento del modelo entidad-

relación (MER) asociado a la estructura de datos identificada para el proyecto, dicho modelo se

muestra en el Anexo 4. En este anexo se asocia la historia o requerimiento asociado, el responsable,

la descripción del módulo, respaldos del código y el fragmento de la imagen MER de la entidad.

Adicionalmente se construyeron los scripts de creación de los objetos de base de datos que

representan las entidades formuladas en el modelo MER, dichos scripts se muestran en el Anexo

5.

39

Pruebas

Se realizaron pruebas de la base de datos planificada y construida, estas pruebas se basaron en

una lista de chequeo que contiene características básicas asociadas a modelos de datos relacionales.

Estas pruebas se muestran en el Anexo 6.

5.2.4 Pruebas

Posterior a cada fase de desarrollo de cada iteración se ejecutaron las pruebas que se plantearon

al inicio de dicha iteración, dichas pruebas se planificaron y registraron en una serie de formatos

que se muestran en el Anexo 7.

40

CONCLUSIONES

La construcción del Sistema TheSys logra concretar un estándar de buenas prácticas para el

proceso de gestión de proyectos de grado en la coordinación de la Especialización de Ingeniería de

Software de la Universidad Distrital, ya que con este sistema se adoptan formas agiles de llevar a

cabo dicho proceso, mejorando la experiencia los involucrados.

41

PROSPECTIVA

El sistema desarrollado cumple con todos los objetivos para los cuales fue diseñado. Sin

embargo, hay muchas opciones que pueden tomarse para retomar este proyecto y complementarlo.

Puesto que se ha desarrollado la base de una herramienta que puede crecer con nuevos proyectos

que den continuidad y aporten nuevas funcionalidades a las ya integrada en esta primera versión

de este sistema.

Actualmente el sistema cubre el proceso de gestión de proyectos de grado de la Especialización

en Ingeniería de Software de la Universidad Distrital, pero su estructura ha sido concebida para que

con unas pocas mejoras del sistema se pueda extender este proceso a las diferentes

especializaciones con las que cuenta la Universidad Distrital y que requieran de presentación de

trabajos de tesis como opción de grado.

Finalmente en razón a que la universidad utiliza varios sistemas de información, se plantea

una futura integración del sistema TheSys con los sistemas utilizados para la gestión de matrícula

de los estudiantes y la gestión de notas de asignaturas en caso que se desee plantear un requisito de

gestión de proyectos de grado en este sentido, otra posibilidad interesante de integración es con

sistemas de bases de datos de proyectos académicos especializados de otras instituciones para

interconsulta de proyectos.

42

BIBLIOGRAFIA

Andrews, S. Fastqc, (2010). A quality control tool for high throughput sequence data.

Augen, J. (2004). Bioinformatics in the post-genomic era: Genome, transcriptome, proteome, and

information-based medicine. Addison-Wesley Professional.

Blankenberg, D., Kuster, G. V., Coraor, N., Ananda, G., Lazarus, R., Mangan, M., ... & Taylor, J.

(2010). Galaxy: a web‐based genome analysis tool for experimentalists. Current protocols

in molecular biology, 19-10.

Bolger, A., & Giorgi, F. Trimmomatic: A Flexible Read Trimming Tool for Illumina NGS Data.

URL http://www. usadellab. org/cms/index. php.

Giardine, B., Riemer, C., Hardison, R. C., Burhans, R., Elnitski, L., Shah, P., ... & Nekrutenko, A.

(2005). Galaxy: a platform for interactive large-scale genome analysis. Genome research,

15(10), 1451-1455.

Goecks, J., Nekrutenko, A., & Taylor, J. (2010). Galaxy: a comprehensive approach for supporting

accessible, reproducible, and transparent computational research in the life sciences.

Genome Biol, 11(8), R86.

Haas, B. J., Papanicolaou, A., Yassour, M., Grabherr, M., Blood, P. D., Bowden, J., ... & Regev,

A. (2013). De novo transcript sequence reconstruction from RNA-seq using the Trinity

platform for reference generation and analysis. Nature protocols, 8(8), 1494-1512.

HÁJKOVÁ, P., Zemanová, B., BRYJA, J., Hájek, B., Roche, K., TKADLEC, E., & ZIMA, J.

(2006). Factors affecting success of PCR amplification of microsatellite loci from otter

faeces. Molecular Ecology Notes, 6(2), 559-562.

Mardis, E. R. (2008). The impact of next-generation sequencing technology on genetics. Trends in

genetics, 24(3), 133-141.

Martin, J. A., & Wang, Z. (2011). Next-generation transcriptome assembly. Nature Reviews

Genetics, 12(10), 671-682.

Martin, M. (2011). Cutadapt removes adapter sequences from high-throughput sequencing reads.

Michigan State University. (2013). Annotation pipeline [Imagen]. Recuperada de

http://cpgr.plantbiology.msu.edu/training/workshop_mar07/Lecture3_GenomeAnnotation.

pdf

Miller, D. J., Ball, E. E., Forêt, S., & Satoh, N. (2011). Coral genomics and transcriptomics—

ushering in a new era in coral biology. Journal of Experimental Marine Biology and

Ecology, 408(1), 114-119.

43

Miller, J. R., Koren, S., & Sutton, G. (2010). Assembly algorithms for next-generation sequencing

data. Genomics, 95(6), 315-327.

Wilhelm, B. T., & Landry, J. R. (2009). RNA-Seq-quantitative measurement of expression through

massively parallel RNA-sequencing. Methods (San Diego, Calif.), 48(3), 249.

44

ANEXO 1. ACTAS DE REUNIONES

En este anexo se detalla cada una de las actas resultantes de las reuniones que se hicieron en

el desarrollo del proyecto. A continuación se listan dichas actas en orden cronológico de realización

de la reunión.

45

ANEXO 2. PLANIFICACIÓN DEL PROYECTO

Descripción de la Iteración 1

Planificación de Iteraciones proyecto THESYS

Iteración: I1 Usuario: Estudiantes, Administrador, Director y Revisor

Nombre Iteración: Gestión Usuarios.

Prioridad en negocio: Alta Riesgo en desarrollo: Alto Historias estimadas: 1

Programadores responsables: Diego Murillo Galvis

Descripción:

Creación de módulo que permita gestionar todos los procesos que se deben llevar a cabo para el

registro de usuarios junto con su correspondiente proceso de seguridad (Login, Recordar

contraseña, Cambiar contraseña).


H1 – Gestión de Usuarios.

Observaciones:

Esta Iteración deberá adicionar en su historia los procesos adicionales que engloban la

operatividad del usuario dentro del sistema (Recordar contraseña, Cambiar contraseña, Iniciar

Sesión).

Iteración: I1 - Historia: H1

Planificación de historias proyecto THESYS

Iteración: I1 -

Historia: H1 Usuario: Estudiantes, Administrador, Director y Revisor

Nombre historia: Gestión de Usuarios.


Alta


Alto tareas estimadas:5

Programador responsable: Diego Murillo Galvis

Descripción:

Creación de los módulos requeridos para la gestión de usuarios y su correspondiente operación

en el sistema TheSys.

Observaciones:

Se requiere realizar test de efectividad para cada una de las tareas indicadas al momento de su

finalización, es necesario diligenciar las diferentes actas de pruebas (Documento de Pruebas).

46

Tareas T1 - Historia: H1 – Iteración: I1

Planificación de tareas proyecto THESYS

Número tarea: T1 Número historia: H1 – I1 Puntos estimados: 4

Nombre tarea: Gestión CRUD de Usuarios.

Tipo de tarea : Desarrollo

Fecha inicio: 01/03 /2012 Fecha fin: 04 /03/ 2015


Descripción: Crear interfaz para la captura, edición, presentación y eliminación de la información correspondiente a los usuarios del sistema TheSys, se requiere capturar los siguientes datos del usuario con rol estudiante: (código de estudiante, dirección de residencia y teléfono fijo) para el caso de los usuarios con rol Director o Revisor se requieren los siguientes datos: (código del docente, tipo de interesado “Revisor, Director o Ambos”, Exponer Datos) finalmente para todos los usuarios la información básica que se requerirá será la siguiente (nombre, email personal, email institucional, identificación de usuario, profesión, número celular, userName, Password, y perfil que lo identifique) Reglas: Los estudiantes deberán registrarse en el sistema antes de iniciar sesión, los directores y revisores deberán ser registrados por el administrador del sistema.




Nombre tarea: Iniciar Sesión.


Fecha inicio: 5/03 /2015 Fecha fin: 5 /03 / 2015


47

Descripción:

Realizar el módulo que permitirá a los usuarios tener acceso al sistema TheSys.

Regla:

Todo Usuario que desee tener acceso al sistema TheSys, deberá estar previamente registrado.




Nombre tarea: Recordar Contraseña.




Descripción:

Módulo que permitirá a los usuarios del sistema TheSys renovar su contraseña en caso de

olvidarla.

Regla:

Todo Usuario que desee recordar su contraseña de acceso al sistema TheSys deberá estar

previamente registrado.

Para que el sistema TheSys renueve su contraseña, el usuario deberá proporcionar los siguientes

datos (Email registrado en el sistema, Identificación) una vez el sistema haya comprobado dicha

información creará una nueva contraseña y notificará al correo registrado por el usuario.




Nombre tarea: Cambiar Contraseña.




48

Descripción:

Módulo que permitirá a los usuarios del sistema TheSys cambiar su contraseña en el momento

en que lo deseen.

Regla:

Todo Usuario que desee cambiar su contraseña deberá iniciar sesión en el sistema.

Para que el usuario pueda cambiar su contraseña deberá digitar primero su contraseña actual,

luego su nueva contraseña y finalmente confirmar la nueva contraseña.



Iteración: I2 Usuario: Administrador

Nombre Iteración: Gestión Líneas de Investigación, Especializaciones y Configuración


Programadores responsables: Hugo Leonardo Barragán

Descripción:

Creación de los módulos que permitan gestionar la información correspondiente a las líneas de

investigación y a las especializaciones, estos dos módulos gestionarán la información a nivel

CRUD.


H1 – Gestión de Líneas de Investigación y Especializaciones y Configuración.

Observaciones: N/A



Iteración: I2 - Historia:

H1 Usuario: Administrador

Nombre historia: Gestión Líneas de Investigación, Especializaciones y Configuración

Prioridad en negocio: Alta Riesgo en desarrollo: Alto tareas estimadas:3

Programador responsable: Hugo Leonardo Barragán

Descripción:

Creación de los módulos de gestión para las líneas de investigación, las especializaciones y

Configuración.

Observaciones:

49






Nombre tarea: Gestión CRUD de Especializaciones.


Fecha inicio: 09/03/2015 Fecha fin: 09/03/2015


Descripción:

Crear interfaz para la captura, edición, presentación y eliminación de la información

correspondiente a los registros de Especializaciones en el sistema TheSys.

se requiere capturar los siguientes datos: (nombre, código)

Reglas:

No podrán existir dos registros con el mismo nombre.




Nombre tarea: Gestión CRUD de Líneas de Investigación.


Fecha inicio: 10/03/2015 Fecha inicio: 10/03/2015


Descripción:


correspondiente a los registros de Líneas de Investigación en el sistema TheSys.

se requiere capturar los siguientes datos: (nombre, descripción)

Reglas:

50

No podrán existir dos registros con el mismo nombre.




Nombre tarea: Gestión de Configuración.




Descripción:

Crear interfaz para la captura, edición, presentación de la información correspondiente a los

registros de configuración en el sistema TheSys.

se requiere capturar los siguientes datos: (fecha inicio de radicación, fecha fin de radicación,

email administrador, número máximo de días para dar respuesta al proyecto, número máximo de

proyectos por director, número máximo de proyectos por revisor, número mínimo de

observaciones por proyecto, rango fechas semestre 1, rango fechas semestre 2, rango fechas

semestre 3)

Reglas: N/A.



Iteración: I3 Usuario: Administrador, Estudiantes

Nombre Iteración: Gestión Radicación de Proyectos.


Programadores responsables: Diego Murillo Galvis

Descripción:

Creación de los módulos que permitan llevar a cabo el proceso de Radicación de proyectos en el

sistema TheSys.


H1 – Gestión de radicación de proyectos de grado.

Observaciones: N/A

51



Iteración: I3 -

Historia: H1 Usuario: Administrador, Estudiantes

Nombre historia: Gestión de radicación de proyectos de grado.



Descripción:

Creación de los módulos de gestión para llevar a cabo el proceso de radicación de proyectos de

grado en el sistema TheSys.

Observaciones:






Nombre tarea: Gestión CRUD para radicar proyecto.




Descripción:


correspondiente a los registros de proyectos de grado.

se requiere capturar los siguientes datos: (código, nombre, resumen, palabras clave de búsqueda,

director “opcional”, revisor “opcional”, especialización, línea de investigación, y documento del

proyecto)

Reglas:

El estudiante que cree el registro del proyecto deberá iniciar sesión.

Se asignará el proyecto a ese estudiante inicialmente.

Un estudiante no puede estar en dos proyectos activos de la misma especialización.

El código del proyecto se construirá automáticamente teniendo en cuenta las siguientes

características: PPPP-S-EEE-CCC, en donde PPPP corresponde al periodo (Año) en el cual se

radica el proyecto; S corresponde al semestre en el cual se radica el proyecto, para este caso se

52

obtienen los rangos de fecha radicados en la tabla de configuración y se valida obteniendo el

semestre 1,2 o 3; EEE corresponde al código de la especialización, que se debe obtener de la

tabla especialización en el registro correspondiente a la especialización asignada al proyecto;

CCC corresponde a un número consecutivo que se llevará por cada especialización, dicho valor

consecutivo deberá ser reiniciado cada semestre.

Una vez registrado el proyecto se deberá enviar un correo notificando al estudiante que radico el

proyecto y al administrador del sistema.

Cuando un estudiante esté logueado en el sistema, al seleccionar Director y Revisor se debe tener

en cuenta que el director o revisor no tenga más de los proyectos permitidos en la configuración;

esta regla no aplica en caso que el administrador realice la operación.

Se deberá crear un registro en la bitácora de proyectos en donde el registro del documento quede

con versión 1.

Los proyectos quedarán registrados con un estado pendiente de aprobación.

El documento del proyecto deberá están en versión .doc y versión .pdf




Nombre tarea: Aprobar proyectos y asignar Involucrados.




Descripción:

Crear interfaz para actualizar la información de los proyectos registrados en sistema TheSys y

que estén en estado pendientes de aprobación.

Se requiere listar todos los proyectos pendientes de aprobación.

se requiere modificar los siguientes datos: (estado, director, revisor)

Reglas:

No se podrá asignar un único involucrado al proyecto que cumpla las funciones de director y

revisor al mismo tiempo.

Se debe validar que al momento de asignar un director y revisor al proyecto, este no haya

superado el límite de proyectos parametrizados en la configuración del sistema.

Una vez asignados el Director y el Revisor, se enviará email de notificación a los estudiantes, al

director y al revisor asignados al proyecto.

Se deberá filtrar por: estado del proyecto (Pendiente de Aprobación, Aprobados, Rechazados,

Finalizados), por nombre del proyecto, por código del proyecto, por línea de investigación, por

director y por revisor.

53



Iteración: I4 Usuario: Administrador, Estudiantes, Director y Revisor

Nombre Iteración: Seguimiento y Correcciones.


Programadores responsables: Javier Mosquera Díaz.

Descripción:

Creación de los módulos que permitan llevar a cabo el proceso de seguimiento y revisión de los

proyectos registrados en el sistema TheSys.


H1 – Gestión de Seguimiento y Corrección.

Observaciones: N/A



Iteración: I4 -

Historia: H1 Usuario: Administrador, Estudiantes, Directores y Revisores

Nombre historia: Gestión de Seguimiento y Corrección.


Programador responsable: Javier Mosquera Díaz.

Descripción:

Creación de los módulos de gestión para llevar a cabo el proceso de seguimiento y verificación

de proyectos de grado desde el sistema TheSys.

Observaciones:






Nombre tarea: Gestión de seguimiento.


54


Programador responsable: Javier Mosquera Díaz

Descripción:

Crear interfaz para la realización de seguimiento de proyectos de grado por parte de los

Directores y revisores, en este módulo, tanto el director como el revisor descargará la versión

más reciente del proyecto de grado y realizarán sus comentarios dentro del documento, al subir

las observaciones del proyecto deberán registrar un comentario previo a la carga del documento

con observaciones.

se requiere capturar los siguientes datos: (estado (Observaciones, aprobado) comentario,

documento)

Reglas:

Es obligatorio que se cargue el documento con las observaciones si el estado asignado requiere

documento (verificar la tabla log_statuses)

Cuando el documento es cargado por el director o el revisor se deberá aumentar la versión en

una décima respecto a la versión anterior, ejemplo; Versión actual V1, primeras observaciones

del director V.1.1.

Cada vez que se realice un registro de seguimiento se deberá enviar al estudiante un correo de

notificación respecto a la novedad registrada en la bitácora de su proyecto.

Si el usuario que realiza el registro en la bitácora es el director y el estado que asigna al proyecto

es aprobado, se notificará a los estudiantes y al revisor, en caso de que el registro lo realice el

reviros y el estado sea aprobado, se deberá notificar a los estudiantes y al director del proyecto.




Nombre tarea: Correcciones.



Programador responsable: Javier Mosquera Díaz.

Descripción:

Crear interfaz para actualizar las correcciones de los proyectos registrados en sistema TheSys.

Se requiere seleccionar el proyecto al cual se le actualizará la corrección.

se requiere modificar los siguientes datos: (estado (Corrección Estudiante) comentario,

documento)

Reglas:

55

Cuando el documento es subido por los cargado por los estudiantes, se deberá aumentar la

versión en una unidad respecto a la unidad anterior, ejemplo; versión inicial V1, Corrección del

documento V2, etc.

Es obligatorio subir el documento cuando se realice el registro de la novedad en la bitácora.

Se deberá enviar un correo de notificación al usuario que creo el registro de observación en la

versión previa del proyecto.



Iteración: I5 Usuario: Administrador, Estudiantes, Director y Revisor, Comunidad.

Nombre Iteración: Buscador de Proyectos


Programadores responsables: Hugo Barragán.

Descripción:

Creación de un módulo que permita realizar la búsqueda de los proyectos finalizados que se

encuentren registrados en el sistema TheSys.


H1 – Buscador de Proyectos.

Observaciones: N/A



Iteración: I5 -

Historia: H1 Usuario: Administrador, Estudiantes, Director y Revisor, Comunidad.

Nombre historia: Gestión de Seguimiento y Corrección.


Programador responsable: Hugo Barragán.

Descripción:

Buscador de proyectos de grado que se encuentren en estado finalizado.

Observaciones:



56

Tareas T1 - Historia: H1 –Iteración: I5



Nombre tarea: Buscador de Proyectos.



Programador responsable: Hugo Barragán

Descripción:

Crear interfaz para la búsqueda de proyectos de grados en estado finalizado.

se requiere que para la búsqueda se lleve a cabo teniendo en cuenta el filtro inicial que realizará

la consulta por: (palabras clave), finalmente una búsqueda avanzada que permita adicionar a la

búsqueda inicial los filtros de(línea de investigación y especialización)

Reglas:

Solo se deben presentar proyectos en estado finalizado.

57

ANEXO 3. PLANEACIÓN DE BASE DE DATOS

Planeación de Bases de datos

Nombre del Módulo

Entidades de BD

Relacionadas

Observaciones

CRUD de Usuario

users Operaciones de inserción, lectura,

actualización y eliminación de

datos en la tabla

Inicio de Sesión users Lectura de datos de la tabla para

validar el usuario y contraseña de

un usuario

Recordar contraseña users Lectura de datos de la tabla para

validar el token de recordar

contraseña para efectuar el

cambio.

Cambiar Contraseña users Operación de actualización de la

contraseña de un registro en la

tabla

Gestión CRUD de

Especializaciones

specializations Operaciones de inserción, lectura,


datos en la tabla

Gestión CRUD de Líneas de

Investigación.

investigation_lines Operaciones de inserción, lectura,


datos en la tabla

Gestión de Configuración. setup Operaciones de inserción, lectura,


datos en la tabla

Gestión CRUD para radicar

proyecto.

projects, project_students,

project_logs

Operaciones de inserción, lectura,


datos en la tabla projects, así como

de la inserción de datos en las

tablas de relación 1..*

(project_students y project_logs)

58

Aprobar proyectos y asignar

Involucrados.

projects Operación para actualizar la

información de estado, revisor y

director

Gestión de seguimiento project_logs Operaciones para insertar datos en

la tabla que almacena el historial

del proyecto

Correcciones project_logs Operaciones para insertar datos en

la tabla que almacena el historial

del proyecto

Buscador de Proyectos projects Lectura de datos de la tabla para

listar los proyectos existentes

59

ANEXO 4. MODELO ENTIDAD RELACIÓN

Modelo Entidad Relación

Diccionario de Datos

Tabla investigation_lines

Fields

Field Type Collation Null Key Default Extra Privileges Comment

id int(11) (NULL) NO PRI (NULL) auto_increment select,insert,update Identificador

del Registro

name varchar(120) latin1_swedish_ci NO (NULL) select,insert,update Nombre de la

línea de

investigación

60

description varchar(1000) latin1_swedish_ci NO (NULL) select,insert,update Descripción

de la linea de

investigación

status bit(1) (NULL) NO (NULL) select,insert,update Estado del

Registro

created_by int(11) (NULL) NO (NULL) select,insert,update Usuario que

crea el

registro

created_at datetime (NULL) NO (NULL) select,insert,update Fecha de

creación del

registro

updated_by int(11) (NULL) YES (NULL) select,insert,update Último

usuario que

modifica el

registro

updated_at datetime (NULL) YES (NULL) select,insert,update Última fecha

de

modificación

del registro

Indexes

Table Non unique

Key name

Seq in index

Column name

Collation

Cardinality

Sub part

Packed

Null

Index type

Comment

investigation_lines

0 PRIMARY

1 id A 1 (NULL)

(NULL)

BTREE

Tabla log_statuses

Fields


id int(11) (NULL) NO PRI (NULL

)

auto_increme

nt

select,insert,updat

e

Identificado

r del registro

code varchar(20) latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Código de la

bitácora

name varchar(120

)

latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Nombre del

registro de

bitácora

profile_id int(11) (NULL) NO MU

L

(NULL

)

select,insert,updat

e

Perfil al que

pertenece el

registro de

bitácora

requires_docume

nt

bit(1) (NULL) NO (NULL

)

select,insert,updat

e

Requiere

documento

el registro

end_process bit(1) (NULL) NO (NULL

)

select,insert,updat

e

Indica si el

registro

61

finaliza el

proceso

status bit(1) (NULL) NO (NULL

)

select,insert,updat

e

Estado del

registro

created_by int(11) (NULL) NO (NULL

)

select,insert,updat

e

Usuario que

crea el

registro

created_at datetime (NULL) NO (NULL

)

select,insert,updat

e

Fecha de

creación del

registro

updated_by int(11) (NULL) YE

S

(NULL

)

select,insert,updat

e

Último

usuario que

modifica el

registro

updated_at datetime (NULL) YE

S

(NULL

)

select,insert,updat

e

Última

fecha de

modificació

n del

registro

Indexes

Table Non unique

Key name

Seq in index

Column name

Collation

Cardinality

Sub part

Packed

Null

Index type

Comment

log_statuses

0 PRIMARY

1 id A 0 (NULL)

(NULL)

BTREE

log_statuses

1 profile_id

1 profile_id

A 0 (NULL)

(NULL)

BTREE

Foreign Key Relationships

FK Id Reference Table

SourceColumn Target Column

Extra Info

log_statuses_ibfk_1 profiles `profile_id` `Id`

Tabla profiles

Fields



del registro

name varchar(120) latin1_swedish_ci NO (NULL) select,insert,update Nombre del

perfil


registro


crea el

registro

62


creación del

registro

updated_by int(11) (NULL) YES (NULL) select,insert,update Último

usuario que

modifica las

cosas


de

modificación

del registro

Indexes

Table Non

unique

Key

name

Seq

in

index

Column

name

Collation Cardinality Sub

part

Packed Null Index

type

Comment

profiles 0 PRIMARY 1 id A 3 (NULL) (NULL) BTREE

Tabla project_logs

Fields



)

auto_increme

nt

select,insert,updat

e

Identificado

r del registro

project_id int(11) (NULL) NO MU

L

(NULL

)

select,insert,updat

e

Identificado

r del

proyecto

document_name varchar(150) latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Nombre del

documento

version varchar(3) latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Versión del

documento

observation varchar(1000

)

latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Observació

n del

documento

predecessor int(11) (NULL) NO (NULL

)

select,insert,updat

e

Documento

predecesor

logbook_status_i

d

int(11) (NULL) NO (NULL

)

select,insert,updat

e

Estado del

documento


)

select,insert,updat

e

Usuario que

crea el

registro


)

select,insert,updat

e

Fecha de

creación del

registro


S

(NULL

)

select,insert,updat

e

Último

usuario que

modifica el

registro

63


S

(NULL

)

select,insert,updat

e

Última

fecha de

modificació

n del

registro

Indexes

Table Non

uniqu

e

Key

name

Seq

in

inde

x

Column

name

Collatio

n

Cardinalit

y

Sub

part

Packed Nul

l

Index

type

Commen

t

project_log

s

0 PRIMARY 1 id A 0 (NULL

)

(NULL

)

BTRE

E

project_log

s

1 project_logboo

k

1 project_i

d

A 0 (NULL

)

(NULL

)

BTRE

E


FK Id Reference Table SourceColumn Target Column Extra Info

project_logbook projects `project_id` `id`

Tabla project_students

Fields


project_id int(11) (NULL) NO PRI (NULL) select,insert,update Identificador

del proyecto

student_id int(11) (NULL) NO PRI (NULL) select,insert,update Identificador

del estudiante


registro


crea el registro


creación del

registro

updated_by int(11) (NULL) NO (NULL) select,insert,update Último usuario

que modifica el

registro

updated_at datetime (NULL) YES (NULL) select,insert,update Última fecha de

modificación

del registro

Indexes

Table Non

uniqu

e

Key

name

Seq

in

inde

x

Column

name

Collatio

n

Cardinalit

y

Sub

part

Packed Nul

l

Index

type

Commen

t

project_student

s

0 PRIMAR

Y

1 project_id A 0 (NULL

)

(NULL

)

BTRE

E

64

project_student

s

0 PRIMAR

Y

2 student_i

d

A 0 (NULL

)

(NULL

)

BTRE

E

project_student

s

1 Student 1 student_i

d

A 0 (NULL

)

(NULL

)

BTRE

E



project_students_ibfk_2 users `student_id` `id` ,

project_students_ibfk_1 projects `project_id` `id`

Tabla projects

Fields

Field Type Collation Nul

l

Key Default Extra Privileges Comment


)

auto_increme

nt

select,insert,upd

ate

Identificador

del registro


ci

NO (NULL

)

select,insert,upd

ate

Código del

proyecto

name varchar(120

)

latin1_swedish_

ci

NO (NULL

)

select,insert,upd

ate

Nombre del

proyecto

summary varchar(100

0)

latin1_swedish_

ci

NO (NULL

)

select,insert,upd

ate

Resumen del

proyecto

key_words varchar(500

)

latin1_swedish_

ci

NO (NULL

)

select,insert,upd

ate

Palabras

claves de la

búsqueda

director_id int(11) (NULL) YE

S

MU

L

(NULL

)

select,insert,upd

ate

Director del

proyecto

revisor_id int(11) (NULL) YE

S

MU

L

(NULL

)

select,insert,upd

ate

Revisor del

proyecto

especialization_id int(11) (NULL) NO MU

L

(NULL

)

select,insert,upd

ate

Especializaci

ón

investigation_line

_id

int(11) (NULL) NO MU

L

(NULL

)

select,insert,upd

ate

Línea de

Investigación

period int(4) (NULL) NO (NULL

)

select,insert,upd

ate

Periodo

semester varchar(3) latin1_swedish_

ci

NO (NULL

)

select,insert,upd

ate

Semestre

sequence int(3) (NULL) NO (NULL

)

select,insert,upd

ate

Secuencia


)

select,insert,upd

ate

Estado del

Proyecto


)

select,insert,upd

ate

Usuario que

crea el

registro

65


)

select,insert,upd

ate

Fecha de

creación del

registro


S

(NULL

)

select,insert,upd

ate

Último

usuario que

modifica el

registro


S

(NULL

)

select,insert,upd

ate

Última fecha

de

modificación

del registro

Indexes

Table Non

uniqu

e

Key

name

Seq

in

inde

x

Column

name

Collati

on

Cardinali

ty

Sub

part

Packe

d

Nul

l

Index

type

Comme

nt

projec

ts

0 PRIMARY 1 id A 0 (NUL

L)

(NUL

L)

BTRE

E

projec

ts

1 ProjectReviwer 1 revisor_id A 0 (NUL

L)

(NUL

L)

YE

S

BTRE

E

projec

ts

1 ProjectDirectorRev 1 director_id A 0 (NUL

L)

(NUL

L)

YE

S

BTRE

E

projec

ts

1 ProjectSpecialization 1 especialization_id A 0 (NUL

L)

(NUL

L)

BTRE

E

projec

ts

1 ProjectInvestigation

Line

1 investigation_line

_id

A 0 (NUL

L)

(NUL

L)

BTRE

E



ProjectDirectorRev users `revisor_id` ìd` ,

ProjectInvestigationLine investigation_lines ìnvestigation_line_id` ìd` ,

ProjectReviwer users `director_id` ìd` ,

ProjectSpecialization specializations èspecialization_id` Ìd`

Tabla setup

Fields

Field Type Collation Null Ke

y

Default Extra Privileges Comment


)

auto_incremen

t

select,insert,updat

e

Identificador

del registro

email_admin varchar(120

)

utf8_general_c

i

NO (NULL

)

select,insert,updat

e

Email del

administrador

66

proj_dir int(2) (NULL) NO (NULL

)

select,insert,updat

e

Número de

proyectos por

Director

proj_rev int(2) (NULL) NO (NULL

)

select,insert,updat

e

Número de

proyectos por

revisor

num_obs_dir int(2) (NULL) NO (NULL

)

select,insert,updat

e

Número de

observacione

s por director

num_obs_rev int(2) (NULL) NO (NULL

)

select,insert,updat

e

Número de

observacione

s por revisor

days_for_answe

r

int(2) (NULL) NO (NULL

)

select,insert,updat

e

Número de

días máximo

para dar

respuesta al

proyecto

begin_rad date (NULL) NO (NULL

)

select,insert,updat

e

Fecha inicio

de radicación

de proyectos

end_rad date (NULL) NO (NULL

)

select,insert,updat

e

Fecha fin de

radicación de

proyectos

begin_sem1 date (NULL) NO (NULL

)

select,insert,updat

e

Fecha de

inicio del

semestre 1

end_sem1 date (NULL) NO (NULL

)

select,insert,updat

e

Fecha fin del

semestre 1


)

select,insert,updat

e

Fecha inicio

del semestre 2


)

select,insert,updat

e

Fecha fin del

semestre 2


)

select,insert,updat

e

Fecha inicio

del semestre 3


)

select,insert,updat

e

Fecha fin del

semestre 3


)

select,insert,updat

e

Estado del

registro


)

select,insert,updat

e

Usuario que

crea el

registro


)

select,insert,updat

e

Fecha de

creación del

registro


S

(NULL

)

select,insert,updat

e

Usuario que

modifica el

registro


S

(NULL

)

select,insert,updat

e

Fecha de

modificación

del registro

Indexes

67

Table Non

unique

Key

name

Seq

in

index

Column

name


part

Packed Null Index

type

Comment

setup 0 PRIMARY 1 id A 0 (NULL) (NULL) BTREE

Tabla specializations

Fields



del registro

name varchar(120) latin1_swedish_ci NO (NULL) select,insert,update Nombre de la

especialización

code varchar(15) latin1_swedish_ci NO (NULL) select,insert,update Código de la

especialización


registro


crea el registro


creación del

registro

updated_by int(11) (NULL) YES (NULL) select,insert,update Último usuario

que modifica el

registro


de

modificación

del registro

Indexes

Table Non

unique

Key

name

Seq

in

index

Column

name


part

Packed Null Index

type

Comment

specializations 0 PRIMARY 1 id A 1 (NULL) (NULL) BTREE

Tabla users

Fields



)

auto_increme

nt

select,insert,updat

e

Identificador

del registro


ci

NO 0 select,insert,updat

e

Código del

estudiante o

interesado

68

name varchar(120

)

latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Nombre del

Estudiante

personal_email varchar(60) latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Email

Personal

institutional_ema

il

varchar(60) latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Email

Institucional

identification int(15) (NULL) NO (NULL

)

select,insert,updat

e

Identificació

n Usuario

profession varchar(120

)

latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Profesión del

estudiante

cell_phone int(12) (NULL) NO (NULL

)

select,insert,updat

e

Número

celular

phone int(15) (NULL) YE

S

(NULL

)

select,insert,updat

e

Teléfono del

estudiante

home_address varchar(120

)

latin1_swedish_

ci

YE

S

(NULL

)

select,insert,updat

e

Dirección

del

estudiante

expose_data bit(1) (NULL) YE

S

(NULL

)

select,insert,updat

e

Exponer los

datos del

director o

revisor al

estudiante

nickname varchar(60) latin1_swedish_

ci

NO UNI (NULL

)

select,insert,updat

e

UserName

password varchar(120

)

latin1_swedish_

ci

NO (NULL

)

select,insert,updat

e

Clave de

acceso

profile_id int(11) (NULL) NO MU

L

(NULL

)

select,insert,updat

e

Rol al que

pertenece el

usuario


)

select,insert,updat

e

Estado del

registro

remember_token varchar(255

)

latin1_swedish_

ci

YE

S

(NULL

)

select,insert,updat

e

Token para

validar

petición de

cambio de

contraseña


)

select,insert,updat

e

Usuario que

crea el

registro


)

select,insert,updat

e

Fecha de

creación del

registro


S

(NULL

)

select,insert,updat

e

Último

usuario que

modificó el

registro


S

(NULL

)

select,insert,updat

e

Última fecha

de

modificació

n del registro

Indexes

69

Table Non

unique

Key

name

Seq

in

index

Column

name


part

Packed Null Index

type

Comment

users 0 PRIMARY 1 id A 4 (NULL) (NULL) BTREE

users 0 nickname 1 nickname A 4 (NULL) (NULL) BTREE

Users 1 UserProfile 1 profile_id A 4 (NULL) (NULL) BTREE

70

ANEXO 5. IMPLEMENTACIÓN DE AGREGACIÓN DE RECURSOS AL SISTEMA

(BASE DE DATOS)

Implementación de recursos al sistema [Bases de Datos ]

Nombre historia: Gestión de Usuarios

Iteración asignada: 1

Número historia: 1

Tareas cumplidas con este

agregado: 3


Descripción:

Creación de los módulos requeridos para la gestión de usuarios y su correspondiente operación en

el sistema TheSys.

Respaldos:

DROP TABLE IF EXISTS ùsers`;

CREATE TABLE ùsers` (

ìd` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Identificador del registro',

`code` varchar(20) NOT NULL DEFAULT '0' COMMENT 'Código del estudiante o interesado',

`name` varchar(120) NOT NULL COMMENT 'Nombre del Estudiante',

`personal_email` varchar(60) NOT NULL COMMENT 'Email Personal',

ìnstitutional_email` varchar(60) NOT NULL COMMENT 'Email Institucional',

ìdentification` int(15) NOT NULL COMMENT 'Identificación Usuario',

`profession` varchar(120) NOT NULL COMMENT 'Profesión del estudiante',

`cell_phone` int(12) NOT NULL COMMENT 'Número celular',

`phone` int(15) DEFAULT NULL COMMENT 'Teléfono del estudiante',

`home_address` varchar(120) DEFAULT NULL COMMENT 'Dirección del estudiante',

èxpose_data` bit(1) DEFAULT NULL COMMENT 'Exponer los datos del director o revisor al

estudiante',

`nickname` varchar(60) NOT NULL COMMENT 'UserName',

`password` varchar(120) NOT NULL COMMENT 'Clave de acceso',

`profile_id` int(11) NOT NULL COMMENT 'Rol al que pertenece el usuario',

`status` bit(1) NOT NULL COMMENT 'Estado del registro',

`remember_token` varchar(255) DEFAULT NULL COMMENT 'Token para validar petición de

cambio de contraseña',

`created_by` int(11) NOT NULL COMMENT 'Usuario que crea el registro',

`created_at` datetime NOT NULL COMMENT 'Fecha de creación del registro',

ùpdated_by` int(11) DEFAULT NULL COMMENT 'Último usuario que modificó el registro',

ùpdated_at` datetime DEFAULT NULL COMMENT 'Última fecha de modificación del

registro',

PRIMARY KEY (ìd`),

UNIQUE KEY `nickname` (`nickname`),

KEY ÙserProfile` (`profile_id`)

) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=latin1;

71



Nombre historia: Gestión Líneas de Investigación, Especializaciones y Configuración


Numero historia: 1


agregado: 3

#


Descripción:

Creación de los módulos de gestión para las líneas de investigación, las especializaciones y

Configuración.

72

Respaldos:

DROP TABLE IF EXISTS ìnvestigation_lines`;

CREATE TABLE ìnvestigation_lines` (

ìd` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Identificador del Registro',

`name` varchar(120) NOT NULL COMMENT 'Nombre de la línea de investigación',

`description` varchar(1000) NOT NULL COMMENT 'Descripción de la linea de investigación',

`status` bit(1) NOT NULL COMMENT 'Estado del Registro',



ùpdated_by` int(11) DEFAULT NULL COMMENT 'Último usuario que modifica el registro',


registro',

PRIMARY KEY (ìd`)


DROP TABLE IF EXISTS `specializations`;

CREATE TABLE `specializations` (


`name` varchar(120) NOT NULL COMMENT 'Nombre de la especialización',

`code` varchar(15) NOT NULL COMMENT 'Código de la especialización',






registro',

PRIMARY KEY (ìd`)


DROP TABLE IF EXISTS `setup`;

CREATE TABLE `setup` (


èmail_admin` varchar(120) NOT NULL COMMENT 'Email del administrador',

`proj_dir` int(2) NOT NULL COMMENT 'Número de proyectos por Director',

`proj_rev` int(2) NOT NULL COMMENT 'Número de proyectos por revisor',

`num_obs_dir` int(2) NOT NULL COMMENT 'Número de observaciones por director',

`num_obs_rev` int(2) NOT NULL COMMENT 'Número de observaciones por revisor',

`days_for_answer` int(2) NOT NULL COMMENT 'Número de días máximo para dar respuesta

al proyecto',

`begin_rad` date NOT NULL COMMENT 'Fecha inicio de radicación de proyectos',

ènd_rad` date NOT NULL COMMENT 'Fecha fin de radicación de proyectos',

`begin_sem1` date NOT NULL COMMENT 'Fecha de inicio del semestre 1',

ènd_sem1` date NOT NULL COMMENT 'Fecha fin del semestre 1',

`begin_sem2` date NOT NULL COMMENT 'Fecha inicio del semestre 2',


`begin_sem3` date NOT NULL COMMENT 'Fecha inicio del semestre 3',




73



Nombre historia: Gestión de radicación de proyectos de grado.


Numero historia: 1


agregado: 2

#


Descripción:

Creación de los módulos de gestión para llevar a cabo el proceso de radicación de proyectos de

grado en el sistema TheSys.

74

Respaldos:

DROP TABLE IF EXISTS `project_students`;

CREATE TABLE `project_students` (

`project_id` int(11) NOT NULL COMMENT 'Identificador del proyecto',

`student_id` int(11) NOT NULL COMMENT 'Identificador del estudiante',




ùpdated_by` int(11) NOT NULL COMMENT 'Último usuario que modifica el registro',


registro',

PRIMARY KEY (`project_id`,`student_id`),

KEY `Student` (`student_id`),

CONSTRAINT `project_students_ibfk_2` FOREIGN KEY (`student_id`) REFERENCES

ùsers` (ìd`),

CONSTRAINT `project_students_ibfk_1` FOREIGN KEY (`project_id`) REFERENCES

`projects` (ìd`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

/*Table structure for table `projects` */

DROP TABLE IF EXISTS `projects`;

CREATE TABLE `projects` (


`code` varchar(15) NOT NULL COMMENT 'Código del proyecto',

`name` varchar(120) NOT NULL COMMENT 'Nombre del proyecto',

`summary` varchar(1000) NOT NULL COMMENT 'Resumen del proyecto',

`key_words` varchar(500) NOT NULL COMMENT 'Palabras claves de la búsqueda',

`director_id` int(11) NOT NULL COMMENT 'Director del proyecto',

`revisor_id` int(11) NOT NULL COMMENT 'Revisor del proyecto',

èspecialization_id` int(11) NOT NULL COMMENT 'Especialización',

ìnvestigation_line_id` int(11) NOT NULL COMMENT 'Línea de Investigación',

`period` int(4) NOT NULL COMMENT 'Periodo',

`semester` varchar(3) NOT NULL COMMENT 'Semestre',

`sequence` int(3) NOT NULL COMMENT 'Secuencia',

`status` bit(1) NOT NULL COMMENT 'Estado del Proyecto',





registro',

PRIMARY KEY (ìd`),

KEY `ProjectReviwer` (`revisor_id`),

KEY `ProjectDirectorRev` (`director_id`),

KEY `ProjectSpecialization` (èspecialization_id`),

KEY `ProjectInvestigationLine` (ìnvestigation_line_id`),

CONSTRAINT `ProjectReviwer` FOREIGN KEY (`director_id`) REFERENCES ùsers` (ìd`),

CONSTRAINT `ProjectDirectorRev` FOREIGN KEY (`revisor_id`) REFERENCES ùsers`

(ìd`),

CONSTRAINT `ProjectInvestigationLine` FOREIGN KEY (ìnvestigation_line_id`)

75



Nombre historia: Gestión de Seguimiento y Corrección


Numero historia: 1


agregado: 2

#

Programador responsable: Javier Mosquera Díaz

Descripción:

Creación de los módulos de gestión para llevar a cabo el proceso de seguimiento y verificación de

proyectos de grado desde el sistema TheSys.

76

Respaldos:

DROP TABLE IF EXISTS `project_logs`;

CREATE TABLE `project_logs` (


`project_id` int(11) NOT NULL COMMENT 'Identificador del proyecto',

`document_name` varchar(150) NOT NULL COMMENT 'Nombre del documento',

`version` varchar(3) NOT NULL COMMENT 'Versión del documento',

òbservation` varchar(1000) NOT NULL COMMENT 'Observación del documento',

`predecessor` int(11) NOT NULL COMMENT 'Documento predecesor',

`logbook_status_id` int(11) NOT NULL COMMENT 'Estado del documento',





registro',

PRIMARY KEY (ìd`),

KEY `project_logbook` (`project_id`),

CONSTRAINT `project_logbook` FOREIGN KEY (`project_id`) REFERENCES `projects`

(ìd`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;



Nombre historia: Gestión de Seguimiento y Corrección


Numero historia: 1


agregado: 1

#

77


Descripción:

Buscador de proyectos de grado que se encuentren en estado finalizado.

Respaldos:

Tabla projects creada anteriormente


78

ANEXO 6. PRUEBA DE BASE DE DATOS

Pruebas de Bases de Datos

Entidad

Normalización

Adecuada

Llaves primarias,

Foráneas e índices

definidos

Diccionario de

datos definido para

la tabla Observaciones

Si No Si No Si No

users X X X

specializations X X X

investigation_lines X X X

setup X X X

projects X X X

project_students X X X

project_logs X X X

profiles X X X

log_statuses X X X

79

ANEXO 7. PLANIFICACIÓN DE PRUEBAS

Planificación de pruebas Modulo Administración de Usuarios


Número tarea: 1 Número historia: 1 Iteración: 1

Encargado de prueba: Hugo Leonardo Barragán

Nombre de tarea : Verificación

Descripción:

Prueba de la funcionalidad de administración de usuarios basado en las reglas definida para dicho

modulo

Condiciones de ejecución.

Para la modificación de usuarios, se requiere de usuarios creados en el sistema y con sesión

activa.

Para la creación de usuarios con rol director o revisor, se requiere un usuario administrador

creado en el sistema y con sesión activa.

Datos de entrada:

Datos personales y de contacto de los usuarios a crear o modificar.

Resultado esperado:

Los usuarios se crean o modifican de acuerdo a las reglas definidas.

80


1. Creación de estudiantes:

a. Ingreso de datos en pantalla de registro de estudiantes:

b. Datos registrados en base de datos:

81

c. Correo de confirmación

d. Ingreso al sistema con el usuario creado:

82

2. Creación de directores y revisores

a. Ingreso de datos en pantalla de registro de usuarios

b. Datos registrados en base de datos:

83

c. Ingreso al sistema con el usuario creado

3. Modificación de estudiantes

a. Modificación de datos de estudiantes creados por parte del mismo estudiante

84

b. Datos modificados en la base de datos

4. Modificación de revisores y directores

a. Modificación de datos a través del módulo de administración de usuarios por parte

de un usuario administrador.

85

b. Datos del usuario modificado en la base de datos

Planificación de pruebas Modulo de Acceso de Usuarios





Descripción:

Prueba de la funcionalidad de acceso de usuarios al sistema.


Deben haber usuarios registrados previamente

Datos de entrada:

Nombre de usuario y contraseña de acceso.

Resultado esperado:

El sistema controla el acceso a usuarios de acuerdo a lo estipulado en las reglas definidas.

86


1. Ingreso de usuario estudiante exitoso.

a. Acceso al módulo de ingreso de usuario e ingreso de nombre de usuario y

contraseña.

b. Pantalla de inicio de sistema para estudiantes

87

2. Ingreso de usuario estudiante fallido

a. Ingreso de datos de acceso.

b. Mensaje de intento de ingreso fallido

3. Ingreso de usuario director o revisor exitoso

88

a. Ingreso de datos de acceso

b. Pantalla de inicio de sistema para directores o revisores

89

4. Ingreso de usuario revisor o director fallido

a. Ingreso de datos de acceso

b. Mensaje de error de ingreso

90

Planificación de pruebas Modulo de Recuperación de Contraseña





Descripción:

Prueba de la funcionalidad de recuperación de contraseña.


Debe haber un usuario creado en el sistema.

Datos de entrada:

Datos de identificación de cuenta: nombre de usuario y correo electrónico.

Resultado esperado:

El sistema suministrará un mecanismo de restablecimiento de la contraseña de acceso a los

usuarios que se acrediten como creados en el sistema.


1. Recuperación de contraseña exitosa.

a. Ingreso de nombre de usuario para recuperar contraseña

91

b. Notificación del sistema de envío de un correo de cambio de contraseña y envio de

dicho correo.

92

c. Cambio de contraseña a través del link enviado al correo electrónico de contracto

93

d. Ingreso al sistema con la nueva contraseña.

2. Intento fallido de recuperación de contraseña de un usuario no creado en el sistema.

a. Ingreso de nombre de usuario no existente en el modulo de recuperación de

contraseña.

94

b. Mensaje de fallo de recuperación de contraseña.

Planificación de pruebas Modulo de Cambio de Contraseña





Descripción:

Prueba de la funcionalidad de cambio de contraseña de acceso al sistema por parte de los usuarios

registrados


Debe haber por lo menos un usuario creado en el sistema.

Datos de entrada:

Datos de ingreso de usuario al sistema (nombre de usuario y contraseña)

Resultado esperado:

El usuario podrá cambiar la contraseña de acceso al sistema una vez realizado el ingreso.

95


1. Cambio exitoso de contraseña de acceso.

a. Ingreso al sistema

b. Ingreso al módulo de cambio de contraseña, ingreso de contraseña actual, nueva

contraseña y confirmación.

96

c. Mensaje de confirmación de operación exitosa

d. Ingreso al sistema con las nuevas credenciales de acceso.

97

2. Cambio de contraseña fallido por contraseña actual invalida.

a. Ingreso al sistema

98

a. Ingreso al módulo de cambio de contraseña, ingreso de contraseña actual, nueva

contraseña y confirmación, contraseña actual fallida.

b. Mensaje de operación fallida.

99

Planificación de pruebas Modulo de Administración de Especializaciones





Descripción:

Prueba de la funcionalidad de administración de especializaciones.


Debe haber por lo menos un usuario administrador creado y logueado en el sistema.

En las pruebas de actualización de datos de especialización se debe contar con

especializaciones creadas

Datos de entrada:

Los datos de la especialización a registrar o modificar según lo especificado en las reglas de

negocio

Resultado esperado:

Creación y modificación de especializaciones en el sistema según lo establecido por las

reglasde negocio.


1. Creación exitosa de especializaciones

a. Ingreso de información asociada a la especialización a crear.

100

b. Mensaje de confirmación de la especialización creada en el sistema.

101

c. Registro de la especialización creada en la base de datos

2. Creación fallida de especializaciones por registro existente con el mismo nombre.

a. Ingreso de datos de la especialización a crear.

102

b. Notificación del sistema de operación fallida por duplicidad de registros por el

nombre de la especialización.

3. Creación fallida de especializaciones por registro existente con el mismo código.

a. Ingreso de datos de la especialización a crear.

103

b. Notificación del sistema de operación fallida por duplicidad de registros por el

código de la especialización.

104



Número tarea: 1 Número historia:1 Iteración: 3



Descripción:

Prueba de la funcionalidad de radicación de proyectos de grado


Tener usuarios de tipo estudiantes y revisores creados y líneas de investigación creadas

Datos de entrada:

Nombres de estudiantes, directores y revisores creados.

Resultado esperado:

El modulo responde de acuerdo a las reglas de negocio definidas.


1. Radicar un proyecto de grado en el sistema TheSys.

a. Diligenciamiento de datos de proyecto y selección de primera versión de archivo.

105

b. Proyecto de grado radicado con el código de acuerdo con el estándar.






Descripción:

Prueba de la funcionalidad de búsqueda de proyectos de grado.


Tener proyectos gestionados en el sistema y finalizados (opcional)

Datos de entrada:

Datos del filtro de búsqueda de proyectos.

Resultado esperado:

Listado de proyectos de grado finalizados de acuerdo con el filtro seleccionado .

106


1. Búsqueda de proyectos..

a. Ingreso de datos de filtro.

b. Listado de proyectos encontrados en función del filtro ingresado.

SISTEMA DE INFORMACIÓN WEB QUE ASISTE EL PROCESO...

Documents

Transcript of SISTEMA DE INFORMACIÓN WEB QUE ASISTE EL PROCESO...