Sistema de Gestion de Beca y Trabajo Socialmente Util.

Universidad de las Ciencias Informáticas

“Facultad 4”

Título: Sistema de Gestión de Beca y Trabajo Socialmente Útil

Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas

Autor(es): Yarlis Macias Rodríguez

Liliam Celia Beyris Soulary

Tutor: Ing. Nadiesda Sanz Carmenates

Julio del 2008

Declaración de Autoría

DECLARACIÓN DE AUTORÍA

Declaramos ser autores de la presente tesis y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.

Para que así conste, firmo la presente a los ____ días del mes de ________ del año ________.

Yarlis Macias Rodríguez Liliam Celia Beyris Soulary

______________ ______________

Firma del Autor Firma del Autor

Ing. Nadiesda Sanz Carmenates ______________

Firma del Tutor

Datos de Contacto

III

DATOS DEL CONTACTO

Tutora: Ing. Nadiesda Sanz Carmenates, graduada en el año 2007 de Ingeniería en Ciencias Informáticas en la Universidad de las Ciencias Informáticas. Es profesora adiestrada y especialista de la Dirección de producción 5, se encuentra cursando el diplomado de Docencia Universitaria. Además, tiene una publicación en el evento UCIENCIA como coautora del trabajo ¨Pruebas de aceptación al cliente¨. Imparte las asignaturas de historia de la Informática y Práctica Profesional I.

Pensamiento

IV

“Pero ninguna idea triunfa así, fácilmente. Para que una idea triunfe hay que empezar a pensarla bien, hay que predicarla, hay que defenderla, hay que persuadir a mucha gente, y entonces al final la idea triunfa.”

Fidel Castro.

Agradecimientos

V

AGRADECIMIENTOS

A todas las personas que me apoyaron en el desarrollo de este trabajo y durante toda mi vida como universitaria.

A mis padres por ser tan especiales y darme todo su amor.

A mi tutora Nadiesda por su labor dedicada.

A mis amigos, por ser tan especiales, en especial a Liliam, Dunier, Yoleidis y Geovanys.

A mi novio, Dairon Javier Soler Gónzalez, por brindarme todo su amor y estar conmigo en los momentos más difíciles.

A mis suegros, por todo su cariño y por preocuparse tanto.

A todos agradecida eternamente

Yarlis

A mis padres y hermana por su amor, apoyo, sacrificio y confianza incalculables, por creer siempre en mí.

A mi familia por su preocupación constante.

A mis amigos por su apoyo incondicional, por estar siempre para mi en los momentos mas difíciles, especialmente a Yarlis, Dunier y Liuba.

A mi tutora Nadiesda, por su dedicación.

A todas aquellas personas que contribuyeron a la realización de este trabajo.

A las personas que me han ayudado en el transcurso de mi vida estudiantil.

A Fidel y a la Revolución, por darme la oportunidad de realizar mis sueños.

A todos muchísimas gracias…

Liliam

Dedicatoria

VI

DEDICATORIA

A mis padres, a mi hermana, a mi sobrino, a Carmita y en especial a mi amor, Dairon Javier Yarlis

A mis padres Iliana y Pedro Enrique; y a mi hermana Adrialis, los seres más importantes en mi vida.

A mis abuelas, tías, tíos, primas y primos por todo su cariño, por toda la vida.

Liliam

Resumen

VII

RESUMEN

En la Universidad de las Ciencias Informáticas (UCI) con el incremento poblacional, cada curso, se hace cada vez más necesaria la creación de un buen sistema de Gestión de Beca y Trabajo Socialmente Útil capaz de brindar la información correspondiente a las actividades realizadas en el área de Beca y sobre el TSU, para apoyar a las personas involucradas en la toma de decisiones de corte organizativo en la facultad. Para agilizar todo este proceso se requiere del modelado de los procesos ejecutados por el vicedecanato de extensión y residencia y las técnicas-c de atención al becario (instructoras) de los edificios, y el desarrollo de un proyecto de automatización.

El presente trabajo brinda una propuesta de modelado para automatizar los principales procesos asociados con la prestación de servicios informativos sobre el estado de la beca y las distintas actividades realizadas en la misma y sobre el TSU de la facultad en cuestión.

El modelado que se desarrolle debe cumplir con las necesidades reales de los clientes, por eso en este trabajo se modela el negocio y se identifican los requisitos funcionales del sistema. Además se realiza el análisis y diseño del futuro sistema informático a realizar.

PALABRAS CLAVE

Sistema, proceso, gestión, modelamiento, casos de uso, análisis, diseño.

Tabla de Contenidos

VIII

TABLA DE CONTENIDOS

INTRODUCCIÓN ... 1

CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 4

1.1 Introducción ... 4

1.2 Sistemas de Gestión ... 4

1.3 ¿Qué es la gestión de la información? ... 4

1.3.1 Sistemas de Gestión de Información ... 5

1.4 Metodología de desarrollo a utilizar: RUP ... 6

1.5 Lenguaje de Modelado: UML ... 9

1.6 Herramientas CASE ... 10

1.6.1 Rational Rose ... 11

1.7 Lenguaje de Programación PHP ... 12

1.8 Herramienta útil en la elaboración de Interfaces de Usuario ... 13

1.9 Técnica usada para capturar requisitos ... 14

1.10 Técnica para validación de requisitos: Prototipo ... 14

1.11 Conclusiones... 15

CAPÍTULO 2: CARACTERÍSTICAS DEL SISTEMA ... 16

2.1 Introducción ... 16

2.2 Modelación del negocio ... 16

2.3 Proceso del Negocio ... 16

2.4 Actores y Trabajadores del Negocio ... 18

2.5 Diagrama de casos de uso del negocio ... 20

2.6 Requerimientos funcionales ... 22

2.7 Requerimientos no funcionales ... 26

2.8 Actores del sistema ... 27

2.9 Diagrama de casos de uso del sistema ... 27

2.10 Conclusiones... 29

CAPÍTULO 3: ANÁLISIS Y DISEÑO DEL SISTEMA ... 30

3.1 Introducción ... 30

3.2 Modelo del Análisis ... 30

3.3 Clases de análisis ... 30

Tabla de Contenidos

IX

3.4 Diagrama de clases del análisis ... 31

3.5 Modelo de Diseño ... 42

3.7 Patrón Model-View-Controller (Modelo-Vista-Controlador) ... 42

3.8 Diagrama de clases del diseño ... 44

3.9 Diseño de la base de datos ... 61

3.9.1 Diagrama de clases persistentes ... 61

3.9.2 Modelo de despliegue ... 62

3.10 Conclusiones... 62

CONCLUSIONES ... 63

RECOMENDACIONES ... 64

REFERENCIAS BIBLIOGRÁFICAS ... 65

BIBLIOGRAFÍA ... 66

ANEXOS ... 68

GLOSARIO ... 109

Introducción

1

INTRODUCCIÓN

Cuba se esfuerza para que todas las personas aptas y con disposición puedan desempeñarse en un Trabajo Socialmente Útil (TSU) sin discriminación alguna, y expresar de este modo su condición revolucionaria y su deseo de participar en todas las actividades útiles a la sociedad, fortaleciendo de esta manera el orden laboral y elevando el carácter educativo en los más pequeños que participan en estas tareas.

En la Universidad de las Ciencias Informáticas el TSU y la residencia ocupan un lugar muy importante dentro del área de la Universidad, la residencia en sus edificios y apartamentos acogen a la totalidad de los estudiantes y una gran parte de sus profesores. Siguiendo las líneas de trabajo del centro y sus principales misiones, la beca trabaja por convertirse en un espacio esencialmente educativo, abierto a la participación y al diálogo a través de las actividades culturales, recreativas y deportivas, orientado a elevar en los estudiantes la disciplina y el compromiso con la Patria.

La residencia se convierte cada día más en un modelo de ciudad digital, las experiencias alcanzadas en este sentido serán llevadas a cada rincón de nuestra isla en pocos años, incorporando de esta manera los logros de la informática en el desarrollo de una cultura general integral de la sociedad cubana. (1)

Este proyecto surge por la creciente necesidad de resolver un problema existente en el marco del recinto universitario de la UCI, cada curso con el incremento notable de la matrícula se hace cada vez más difícil el trabajo de organización, control y atención de las personas que cada año van formando parte de esta moderna universidad de nuevo tipo.

En estos momentos la labor de las instructoras y la vicedecana de extensión y residencia en general esta matizada por un número elevado de documento que repite información de los estudiantes y los apartamentos en uno y otro modelo. Esta información se lleva de forma manual, esto trae consigo un trabajo engorroso para ellas, provocando la pérdida y deterioro de la información. La búsqueda y actualización de la misma es más difícil y consume más tiempo. Además no se tiene un control de los estudiantes afectados por la cuartelaría, la guardia y el TSU, que les permita a los profesores comprobar su inasistencia a los turnos de clases y a los proyectos productivos provocando pérdidas en la producción.

A partir de esta situación, se ha definido como problema a resolver: El Sistema de trabajo existente no es capaz de gestionar organizadamente la información sobre la Beca y el Trabajo Socialmente Útil (TSU).

Introducción

2

Basado en lo anterior, se ha definido como Objeto de Estudio de este trabajo: Procesos de gestión de información y como campo de acción:

 Procesos de gestión de información de Beca y el Trabajo Socialmente Útil (TSU) de la facultad 4.

Para dar solución al problema se propone como Objetivo general: Obtener el análisis y diseño del Sistema de Gestión de Beca y Trabajo Socialmente Útil (TSU) de la facultad 4.

Las tareas de investigación planificadas para dar solución al problema y dar cumplimiento a los objetivos planteados son:

1. Selección y revisión bibliográfica sobre los sistemas de gestión de información.

2. Realizar un estudio detallado de las actividades realizadas en la beca y sobre el TSU.

3. Definir los conceptos más significativos en el dominio del problema.

4. Selección de las herramientas para llevar a cabo el proyecto, fundamentando su elección.

5. Identificar las actividades automatizables de cada uno de los subprocesos descritos.

6. Realizar la captura de requisitos funcionales y no funcionales del sistema.

7. Realizar el análisis y diseño de los procesos identificados.

8. Diseño de una base de datos que soporte las funcionalidades del sistema.

Para la realización de las tareas se emplearán los siguientes métodos:

Métodos teóricos:

 Análisis y síntesis: Se utiliza para aumentar los conocimientos acerca de la línea de investigación a partir de los modelos registrados y luego haciendo uso de la síntesis se integraron los resultados del análisis.

 Modelación: Con el objetivo de modelar el diseño propuesto.

Métodos empíricos:

 Entrevistas: Se realizaron varias entrevistas a la vicedecana y a las instructoras con el objetivo de obtener la información precisa que se requiere para desarrollar la investigación.

Para esto se realizó una preparación sobre el tema a tratar y se elaboró una guía para su desarrollo.

 Análisis de documentos: Se analizaron todos los modelos registrados en área de beca y sobre el TSU para comprender mejor como se desarrollan los procesos.

Introducción

3

Con este trabajo se espera, además de viabilizar y agilizar el trabajo de los trabajadores, tener un estricto control sobre las actividades efectuadas en la beca y brindar las informaciones pertinentes a las personas que les puedan interesar.

El trabajo se dividió en 3 capítulos que contienen la información referente a la investigación realizada, así como la parte de análisis y diseño del sistema a desarrollar la cual está organizada de la siguiente forma:

Capítulo 1: En el Capítulo 1 con la Fundamentación Teórica, se aborda sobre los Sistemas de Gestión, sus principales características y beneficios. Se realiza un estudio sobre la metodología RUP, las herramientas más importantes utilizadas para desarrollar el proyecto y se describen conceptos que son esenciales para la comprensión de este trabajo.

Capítulo 2: En el Capítulo 2, Características del Sistema, se describen los actores y trabajadores del negocio. Además se identifican los requisitos funcionales y no funcionales del sistema que darán solución al problema planteado; quiénes interactuarán con él (actores del sistema) y las distintas funcionalidades que ofrecerá a cada uno de los actores.

Capítulo 3: En el Capítulo 3, Análisis y diseño del sistema, se muestran los diagramas de clases del análisis y los diagramas de clases del diseño. También está el modelo lógico de datos (diagrama de

clases persistentes), el modelo físico de datos (modelo de datos) y el modelo de despliegue.

Capítulo 1: Fundamentación Teórica

4

CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA

1.1 Introducción

En el presente capítulo, para una mayor comprensión del trabajo se brinda información acerca de los Sistemas de Gestión de Información, así como su importancia y se fundamenta la utilización de un conjunto de herramientas para realizar el proceso de desarrollo de software.

1.2 Sistemas de Gestión

El continuo desarrollo de las técnicas y métodos del desarrollo de los Sistemas, como respuesta a la dinamicidad de las organizaciones, y consecuentemente demanda de información cada vez más precisa, fidedigna y oportuna, han determinado la necesidad de preparar recursos humanos capaces de enfrentar los nuevos paradigmas de la gestión y de técnicas y métodos orientados a la toma de decisiones institucionales.

La Universidad comprende las necesidades de información y de mecanismos de Toma de Decisiones cada vez más especializados y dinámicos de la vida institucional de las organizaciones, tanto públicas como privadas, en consecuencia, le ofrecemos algunos conceptos, para obtener conocimientos teóricos de tan importante área de especialización.

Los Sistemas de Gestión son estructuras interactivas formadas por personas, equipos y métodos destinados a crear un flujo de información capaz de proporcionar un fundamento adecuado para la toma de decisiones o sencillamente la solución a problemas específicos.

1.3 ¿Qué es la gestión de la información?

Gestión: Actividades coordinadas para dirigir y controlar una organización.

Información: Forma social de existencia del conocimiento consolidada en una fuente determinada.

Gestión de información: Comprende las actividades relacionadas con la obtención de la información adecuada, a un precio adecuado, en el tiempo y lugar adecuado, para tomar la decisión adecuada. (2) La gestión de la información es el proceso de analizar y utilizar la información que se ha recabado y registrado para permitir a los administradores (de todos los niveles) tomar decisiones documentadas, así como para mejorar los procesos, productos y servicios de la organización. La información para la gestión es la información necesaria para tomar decisiones de gestión. Comprende las actividades relacionadas con la obtención de la información adecuada, a un costo adecuado, en el tiempo y lugar adecuado, para tomar la decisión adecuada.

Capítulo 1: Fundamentación Teórica

5

La información para la gestión y la gestión de la información son dos conceptos diferentes; la información para la gestión es un tipo de información (los datos); la gestión de la información es un tipo de gestión (el sistema).

Para poder utilizar la información para tomar decisiones de gestión, debe gestionarse la información (recabar, registrar y analizar). Aunque la gestión de la información (el proceso de recabar y guardar la información) y la información para la gestión (la información necesaria para tomar decisiones bien documentadas) son diferentes, se refuerzan entre sí y no pueden separarse en las operaciones cotidianas.

La gestión de la información implica: determinar la información que se precisa, recoger y analizar la información, registrarla y recuperarla cuando sea necesaria, utilizarla y divulgarla.

1.3.1 Sistemas de Gestión de Información

Los sistemas de gestión de información constituyen la base de todos los demás sistemas, garantiza la disponibilidad de las herramientas y procedimientos organizativos necesarios para la generación, adquisición, procesamiento, almacenamiento, búsqueda, recuperación, transmisión y uso de la información interna y externa de interés para el trabajo de la organización.

La implantación de un sistema de gestión de cualquier tipo es una tarea de gran envergadura para cualquier organización que enfrenta retos como la: rentabilidad, competitividad, rapidez de cambio, adaptabilidad y que desee mejorar su actividad empresarial. Sin embargo, una planificación adecuada y el respaldo de la alta dirección pueden facilitar en gran medida este proceso. Además las grandes organizaciones requieren de la certificación de sus Sistemas de Gestión.

Ciertas organizaciones, incluso actualmente, son incapaces de comprender que la información es un recurso, un valor o un activo igual que cualquier otro y que como recurso tiene características que lo hacen similar o diferente a los demás, o sea, que se adquiere a un costo, posee valores, requiere del control de sus costos, tiene un ciclo de vida, puede procesarse y existen sustitutos para informaciones específicas.

La información se diferencia por ser: (9)

 Expandible

 Comprimible

 Sustituible

 Difusa

 Compartida

Capítulo 1: Fundamentación Teórica

6

Los Sistemas de Gestión cuentan con una serie de beneficios como:

La implementación y certificación de un sistema de gestión ayuda a que una organización logre mejoras continuas en su operación. El uso de un sistema de gestión probado combinado con una validación externa en su desarrollo, permite a una organización modernizar continuamente su misión, estrategias, operaciones y niveles de servicio. Un buen sistema de gestión de la información debe ayudar a los administradores del proyecto a saber qué información necesitan recabar, para tomar diferentes decisiones en distintos momentos. (3)

1.4 Metodología de desarrollo a utilizar: RUP

Dentro de las metodologías pesadas se encuentra RUP (del Inglés Rational Unified Process), Proceso Unificado de Desarrollo, que es un proceso de desarrollo de software que junto con el Lenguaje Unificado de Modelado UML, forman la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El Proceso Unificado es más que un simple proceso, provee un marco genérico de trabajo que puede especializarse para una gran variedad de sistemas de software. (1)

RUP en su modelación define como sus principales elementos:

 Trabajadores: Son los que realizan las actividades y son propietarios de elementos.

 Actividades: Tareas que tienen un propósito claro.

 Artefactos: Productos tangibles de un proyecto como: modelos, código fuente y ejecutables.

Un proyecto realizado siguiendo RUP se divide en cuatro fases:

 Inicio: Se describe el negocio y se delimita el proyecto describiendo sus alcances con la identificación de los casos de uso del sistema.

 Elaboración: Se define la arquitectura del sistema y se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la base de la comprensión del sistema completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido.

 Construcción: Se obtiene un producto listo para su utilización que está documentado y tiene un manual de usuario. Se obtiene uno o varios release del producto que han pasado las pruebas.

Se ponen estos release a consideración de un subconjunto de usuarios.

Capítulo 1: Fundamentación Teórica

7

 Transición: El release ya está listo para su instalación en las condiciones reales. Puede implicar reparación de errores.

En la figura 1.1 se puede apreciar las fases e hitos

Figura 1.1 Fases e hitos

RUP define nueve flujos de trabajo a realizar en cada fase del proyecto.

 Modelado del negocio: Describe los procesos de negocio, identifica quiénes participan y las actividades que requieren automatización.

 Requerimientos: Define qué es lo que el sistema debe hacer, se identifican la funcionalidades requeridas y las restricciones.

 Análisis y diseño: Describe cómo el sistema será realizado a partir de la funcionalidad y las restricciones, es decir indica lo que se debe programar.

 Implementación: Define cómo se organizan las clases y objetos en componentes, cuáles nodos se utilizarán y la ubicación en ellos de los componentes y la estructura de capas de la aplicación.

 Prueba: Busca los defectos a los largo del ciclo de vida.

 Instalación: Produce release del producto y realiza actividades (empaque, instalación, asistencia a usuarios, etc.).

 Gestión del proyecto: Involucra actividades con las que se busca producir un producto que satisfaga las expectativas y necesidades de los clientes.

Capítulo 1: Fundamentación Teórica

8

 Administración de configuración y cambios: Describe cómo controlar los elementos producidos por todos los integrantes del proyecto en cuanto a utilización, actualización concurrente de elementos y control de versiones.

 Ambiente: Contiene actividades que describen los procesos y herramientas que soportarán el equipo de trabajo del proyecto; así como el procedimiento para implementar el proceso en una organización.

A continuación se muestra en la Figura 1.2 los distintos flujos de trabajo

Figura 1.2 Flujos de trabajo

Las características fundamentales que se definen en el Proceso Unificado son: dirigido por casos de uso, iterativo e incremental y centrado en la arquitectura.

 Dirigido por casos de uso:

Teniendo en cuenta que la razón de ser de un sistema es brindar servicios a los usuarios, “se define un caso de uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los casos de uso representan los requisitos funcionales del sistema.” (2) Además se utilizan para guiar los demás pasos de su desarrollo, dígase diseño, implementación y prueba.

Los casos de uso reflejan lo que los usuarios futuros necesitan y desean, lo cual se capta cuando se modela el negocio y se representa a través de los requerimientos. A partir de aquí los casos de uso guían el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo). (3)

Capítulo 1: Fundamentación Teórica

9

 Iterativo e incremental:

La alta complejidad de los sistemas actuales hace que sea factible dividir el proceso de desarrollo en varios mini-proyectos. Cada uno de estos mini-proyectos se les denomina iteración que resulta en un incremento. En cada iteración los desarrolladores seleccionan un grupo de casos de uso, los cuales se diseñan, implementan y prueban. Una iteración involucra actividades de todos los flujos de trabajo, aunque desarrolla fundamentalmente algunos más que otros. Las iteraciones hacen referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del producto.

 Centrado en la arquitectura:

La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Ésta no sólo incluye las necesidades de los usuarios e inversores, sino también otros aspectos técnicos como el hardware, sistema operativo, sistema de gestión de base de datos, protocolos de red; con los que debe coexistir el sistema. Es decir, la arquitectura representa la forma del sistema, la cual va madurando en su interacción con los casos de uso hasta llegar a un equilibrio entre funcionalidad y características técnicas, muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo que describe los elementos del modelo que son más importantes para su construcción. El modelo de arquitectura se representa a través de vistas en las que se incluyen los diagramas de UML.

1.5 Lenguaje de Modelado: UML

La metodología RUP utiliza Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; aún cuando todavía no es un estándar oficial, está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software.

El UML esta compuesto por diversos elementos gráficos que se combinan para conformar diagramas.

Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de estos diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Un modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.

Capítulo 1: Fundamentación Teórica

10

Es importante recalcar que UML no es una guía para realizar el análisis y diseño orientado a objetos, es decir, no es un proceso, UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos y que es para especificar y no para describir métodos o procesos. Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir.

En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado de Rational) pero no especifica en sí mismo qué metodología o proceso usar.” (4)

1.6 Herramientas CASE

“Las Herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.” (5) Los objetivos principales de estas son:

 Mejorar la productividad en el desarrollo y mantenimiento del software.

 Aumentar la calidad del software.

 Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.

 Mejorar la planificación de un proyecto.

 Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.

 Automatizar, desarrollo del software, documentación, generación de código, pruebas de errores y gestión del proyecto.

 Ayuda a la reutilización del software, portabilidad y estandarización de la documentación.

 Gestión global en todas las fases de desarrollo de software con una misma herramienta.

 Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Capítulo 1: Fundamentación Teórica

11

1.6.1 Rational Rose

Es una de las mejores herramientas CASE de modelado visual en el mundo y se encuentra a la cabeza en cuanto al desarrollo de UML, que se ha convertido en la notación estandarizada empleada en Rational Rose para especificar, visualizar y construir desarrollos de software y sistemas.

Rational es actualmente conocida como una familia de software de IBM para el levantamiento de requerimientos, diseño, construcción, pruebas y administración de proyectos en el proceso desarrollo de software y sus productos están centrados en la metodología del Proceso Racional Unificado o RUP.

Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y que soporta de forma completa la especificación del UML 1.1. Esta herramienta propone la utilización de cuatro tipos de modelo para realizar un diseño del sistema, utilizando una vista estática y otra dinámica de los modelos del sistema, uno lógico y otro físico. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del problema y el sistema de software.

 Desarrollo Iterativo:

Rational Rose utiliza un proceso de desarrollo iterativo controlado (controlled iterative process development), donde el desarrollo se lleva a cabo en una secuencia de iteraciones. Cada iteración comienza con una primera aproximación del análisis, diseño e implementación para identificar los riesgos del diseño, los cuales se utilizan para conducir la iteración, primero se identifican los riesgos y después se prueba la aplicación para que éstos se hagan mínimos. Cuando la implementación pasa todas las pruebas que se determinan en el proceso, esta se revisa y se añaden los elementos modificados al modelo de análisis y diseño. Una vez que la actualización del modelo se ha modificado, se realiza la siguiente iteración.

 Trabajo en Grupo:

Rose permite que haya varias personas trabajando a la vez en el proceso iterativo controlado, para ello posibilita que cada desarrollador opere en un espacio de trabajo privado que contiene el modelo completo y tenga un control exclusivo sobre la propagación de los cambios en ese espacio de trabajo.

También es posible descomponer el modelo en unidades controladas e integrarlas con un sistema para realizar el control de proyectos que permite mantener la integridad de dichas unidades.

 Generador de Código:

Capítulo 1: Fundamentación Teórica

12

Se puede generar código en distintos lenguajes de programación a partir de un diseño en UML.

 Ingeniería Inversa:

Rational Rose proporciona mecanismos para realizar la denominada Ingeniería Inversa, es decir, a partir del código de un programa, se puede obtener información sobre su diseño.

1.7 Lenguaje de Programación PHP

PHP es un lenguaje interpretado de propósito general ampliamente usado y que está diseñado especialmente para desarrollo web y puede ser embebido dentro de código HTML. Generalmente se ejecuta en un servidor web, tomando el código en PHP como su entrada y creando páginas web como salida. Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno.

Las cuatro grandes características: Velocidad, estabilidad, seguridad y simplicidad.

Velocidad: No solo la velocidad de ejecución, la cual es importante, sino además no crea demoras en la máquina. Por esta razón no debe requerir demasiados recursos de sistema. PHP se integra muy bien junto a otro software, especialmente bajo ambientes Unix, cuando se configura como módulo de Apache, esta listo para ser utilizado.

Estabilidad: La velocidad no sirve de mucho si el sistema se cae cada cierta cantidad de ejecuciones.

Ninguna aplicación es 100% libre de bugs, pero teniendo de respaldo una increíble comunidad de programadores y usuarios es mucho mas difícil para lo bugs sobrevivir. PHP utiliza su propio sistema de administración de recursos y dispone de un sofisticado método de manejo de variables, conformando un sistema robusto y estable.

Seguridad: El sistema debe poseer protecciones contra ataques. PHP provee diferentes niveles de seguridad, estos pueden ser configurados desde el archivo .ini.

Simplicidad: Se les debe permitir a los programadores generar código productivamente en el menor tiempo posible. Usuarios con experiencia en C y C++ podrán utilizar PHP rápidamente.

Capítulo 1: Fundamentación Teórica

13

Otra característica a tener en cuenta seria la conectividad. PHP dispone de una amplia gama de librerías, y agregarle extensiones es muy fácil. Esto le permite al PHP ser utilizado en muchas áreas diferentes, tales como encriptado, gráficos, XML y otras.

Ventajas de php:

 Es un lenguaje multiplataforma.

 Capacidad de conexión con la mayoría de los manejadores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL.

 Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).

 Posee una amplia documentación en su página oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.

 Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.

 Permite las técnicas de Programación Orientada a Objetos.

 Biblioteca nativa de funciones sumamente amplia e incluida.

 No requiere definición de tipos de variables.



Tiene manejo de excepciones

.

1.8 Herramienta útil en la elaboración de Interfaces de Usuario

Dreamweaver MX 2004 es un editor HTML profesional para diseñar, codificar y desarrollar sitios, páginas y aplicaciones Web. Tanto si desea controlar manualmente el código HTML como si prefiere trabajar en un entorno de edición visual, Dreamweaver proporciona útiles herramientas que mejorarán la experiencia en la creación Web. (Dreamweaver)

Las funciones de edición visual de Dreamweaver permiten crear páginas de forma rápida, sin escribir una sola línea de código. No obstante, si se prefiere crear el código manualmente, Dreamweaver también incluye numerosas herramientas y funciones relacionadas con la codificación. Además, Dreamweaver ayuda a crear aplicaciones Web dinámicas basadas en bases de datos empleando lenguajes de servidor como ASP, ASP.NET, ColdFusion Markup Language (CFML), JSP y PHP que es el que más nos concierne.(Dreamweaver ).

Capítulo 1: Fundamentación Teórica

14

1.9 Técnica usada para capturar requisitos

La captura de requisitos es la actividad mediante la que el equipo de desarrollo de un sistema de software extrae, de cualquier fuente de información disponible, las necesidades que debe cubrir dicho sistema. El proceso de captura de requisitos puede resultar complejo, principalmente si el entorno de trabajo es desconocido para el equipo de analistas, y depende mucho de las personas que participen en él. Por la complejidad que todo esto puede implicar, la ingeniería de requisitos ha trabajado desde hace años en desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y precisa.

A continuación se presenta la técnica utilizada para esta actividad:

Entrevistas: Resultan una técnica muy aceptada dentro de la ingeniería de requisitos y su uso está ampliamente extendido. Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada. A través de esta técnica el equipo de trabajo se acerca al problema de una forma natural.

Básicamente, la estructura de la entrevista abarca tres pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados.

A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos y con su aplicación el equipo de desarrollo puede obtener una amplia visión del trabajo y las necesidades del usuario, es necesario destacar que no es una técnica sencilla de aplicar, requiere que el entrevistador sea experimentado y tenga capacidad para elegir bien a los entrevistados y obtener de ellos toda la información posible en un período de tiempo siempre limitado. Aquí desempeña un papel fundamental la preparación de la entrevista.

1.10 Técnica para validación de requisitos: Prototipo

Un prototipo es una representación limitada del diseño de un producto que permite a las partes responsables de su creación experimentar, probarlo en situaciones reales y explorar su uso (Alberto la Calle, 2006). Un prototipo es un modelo (representación, demostración o simulación) fácilmente ampliable y modificable de un sistema planificado, probablemente incluyendo su interfaz y su funcionalidad de entradas y salidas (Walter Maner, 1997). Un prototipo puede ser cualquier cosa, desde un trozo de papel con dibujos sencillos hasta un complejo software. Es un modelo a escala o

Capítulo 1: Fundamentación Teórica

15

facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final proporcionando una retroalimentación temprana por parte de los usuarios acerca del Sistema.

La validación de requisitos tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita o el cliente desea. Es necesario asegurar que el análisis realizado y los resultados obtenidos de la etapa de definición de requisitos son correctos. Esta técnica se utiliza para que el cliente valore si el prototipo tiene las capacidades de desempeño que la aplicación requiere. Explora las características que puedan poner en peligro su utilización futura, evalúa su funcionalidad y estabilidad. En función de las opiniones obtenidas de los clientes se pueden cambiar e incluso desechar algunas ideas para desarrollos futuros pero el objetivo principal de esta técnica es lograr una aceptación de los requisitos funcionales. Esta técnica tiene el problema de que el usuario debe entender que lo que está viendo es un prototipo y no el sistema final.

La finalidad del prototipo es probar varias suposiciones formuladas por analistas y usuarios con respecto a las características requeridas del sistema. Los prototipos se crean con rapidez, evolucionan a través de un proceso interactivo y tienen un bajo costo de desarrollo.

1.11 Conclusiones

En este capítulo se analizaron los conceptos fundamentales relacionados a los sistemas de gestión y se detallaron las condiciones y problemas que rodean el objeto de estudio; llegando a la conclusión de que para desarrollar la tesis el proceso de desarrollo es RUP, para el modelado visual se usará UML, la herramienta de modelado es Racional Rose, pues es es muy recomendado y altamente profesional, y la técnica para validar requisitos que se usará es Prototipo.

Capítulo 2: Características del Sistema

16

CAPÍTULO 2: CARACTERÍSTICAS DEL SISTEMA

2.1 Introducción

El modelo del negocio posibilita obtener una visión más clara del proceso en cuestión, por ello en este capítulo se describen los actores y trabajadores del negocio y el modelo de negocio. Además se identifican los requisitos funcionales y no funcionales del sistema que darán solución al problema planteado; quiénes interactuarán con él (actores del sistema) y las distintas funcionalidades que ofrecerá a cada uno de los actores.

2.2 Modelación del negocio

La modelación de negocio se hace con el objetivo de comprender la estructura y la dinámica de la beca y el TSU, comprender mejor los problemas actuales que los afectan e identificar las mejoras potenciales, derivar los requisitos del sistema y lograr un entendimiento común entre los consumidores, los usuarios finales y los desarrolladores.

En resumen, el objetivo del modelo del negocio es describir los procesos, existentes u observados, con el propósito de comprenderlos. Se especifican aquí qué procesos del negocio soportará el sistema.

2.3 Proceso del Negocio

Un proceso del negocio es el conjunto estructurado de las actividades que han sido diseñadas para producir un resultado para un cliente o el mercado.

El modelo del negocio tiene como objetivo describir los procesos, existentes u observados, con el propósito de comprenderlos. A continuación se muestran los procesos:

 Gestionar Cuartelería: En este proceso la instructora del edificio le asigna a cada estudiante una fecha de realización de la cuartelería, en dependencia de su apartamento y su paso de escalera y teniendo en cuenta que los domingos no se realiza dicha actividad. Luego la instructora le da una evaluación a los cuarteleros según el cumplimiento de sus tareas y la misma es archivada.

 Gestionar Guardia Estudiantil: En este proceso la vicedecana de extensión y residencia de la facultad asigna a cada grupo una fecha para realizar la guardia estudiantil. Una vez hecha la guardia por el grupo correspondiente, el profesor que esta a cargo le entrega la planilla de la guardia a la vicedecana, en la cual los estudiantes firmaron la entrada y la salida de la guardia,

Capítulo 2: Características del Sistema

17

en caso de haber algún ausente injustificado el profesor le levanta un acta de indisciplina la cual es archivada por la vicedecana. Cuando todos los grupos de la facultad hayan rotado por esta actividad, se vuelven a distribuir los grupos.

 Gestionar TSU: En este proceso la vicedecana de extensión y residencia le asigna a cada grupo de la Facultad una fecha para realizar el TSU con el área de trabajo correspondiente. Una vez que todos los grupos hayan realizado la actividad se vuelve a realizar la distribución de los grupos empezando por el primero pero teniendo en cuenta que no vuelva a tocar la misma área y que le toque en la sesión contraria de las clases. En caso de haber algún ausente injustificado el profesor le levanta un acta de indisciplina la cual es archivada por la vicedecana.

 Realizar Inspección: En este proceso la instructora realiza inspecciones diarias a los apartamentos, controlando que se cumpla con todo lo establecido como la limpieza, la organización, y emite una evaluación al apartamento según el cumplimiento de los parámetros a medir.

 Controlar defectaciones: En este proceso la instructora registra y reporta a las áreas pertinentes todas las defectaciones existentes en todos los apartamentos, las cuales una vez resueltas se les da de baja.

 Controlar medios: En este proceso la instructora registra en un acta todos los medios existentes en los apartamentos, acta que tienen que firmar todos los estudiantes del apartamento para que quede constancia de los mismos, en caso de ocurrir alguna pérdida o rotura de algún medio los responsables tienen que pagarlo, elaborándose una acta de análisis por pérdida o rotura para que quede constancia de que el estudiante lo pagó, esta acta es archiva. Luego se actualiza el acta de los medios.

 Realizar Talleres: En este proceso la instructora realiza mensualmente talleres educativos con el objetivo de elevar la responsabilidad y la conciencia en los estudiantes, los cuales tienen una participación activa en el debate de los mismos, la psicopedagoga verifica su realización y emite una evaluación la cual es archivada.

 Evaluar Estudiantes: En este proceso la instructora emite mensualmente una evaluación a todos los estudiantes por su actitud en la residencia.

 Caracterizar estudiantes: En este proceso la instructora recoge una serie de datos generales de los estudiantes.

Capítulo 2: Características del Sistema

18

 Distribuir Estudiantes: La vicedecana de extensión y residencia después de recibir la matrícula de los estudiantes de la facultad y el listado de los edificios que le corresponde a la misma, realiza la distribución de los estudiantes a los cuales se le asigna un edificio y un apartamento, esta distribución se le informa al grupo de la FEU, que es encargado de informárselo a los estudiantes, los cuales son ubicados por las instructoras.

 Entregar Aseo: En este proceso la instructora reparte el aseo a todos los estudiantes en tres días como límite, los cuales tienen que firmar la tarjeta de control de entrega de aseo individual para que quede constancia de que el mismo lo recibió. En caso de que algún estudiante se encuentre fuera de la universidad autorizadamente, la vicedecana de beca y extensión universitaria es la encargada de recogerle el aseo. Una vez transcurridos los tres días establecidos para recogerlo, el aseo de los estudiantes que no lo recogieron es reintegrado para el cual se elabora una tarjeta de control de devolución del aseo individual la cual tiene que firmar la instructora.

2.4 Actores y Trabajadores del Negocio

Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o sistema de información externos; con los que el negocio interactúa. Lo que se modela como actor es el rol que se juega cuando se interactúa con el negocio para beneficiarse de sus resultados.

Son actores candidatos del negocio:

Socios Proveedores

Autoridades (legales, reguladoras, etc.).

Propietarios, si no están dentro del negocio que se modela.

Sistemas de información externos al negocio.

Otras partes del negocio si este es grande y esas partes no están dentro del campo de acción del negocio que se modela. (7)

A continuación se muestra en la tabla 2.1, los actores del negocio y su correspondiente justificación:

Capítulo 2: Características del Sistema

19

Actores del negocio Justificación

Vicedecana de Extensión y Residencia La Vicedecana de Extensión es la que inicia las acciones que dan lugar a planificar la guardia y el TSU y distribuir estudiantes en los edificios, es la más beneficiada con el resultado de dichos procesos.

Psicopedagoga La psicopedagoga es la que inicia las acciones que dan lugar a planificar la cuartelaría, realizar inspecciones a los apartamentos, realizar talleres educativos, caracterizar estudiantes y evaluar estudiantes, siendo esta la más beneficiada con el resultado de dichos procesos.

Técnico General El técnico general es el que inicia las acciones que dan lugar al proceso de controlar las defectaciones de los apartamentos, el cual es el más beneficiado con ese control.

Técnico de Medios Básicos El técnico de medios básicos es el que inicia las acciones que dan lugar al proceso de controlar los medios de los apartamentos, el cual es el más beneficiado con ese control.

Económico de la residencia El económico de la residencia es el que inicia las acciones que dan lugar al proceso de entregar aseo.

Tabla 2.1 Justificación de los Actores del Negocio

Un trabajador del negocio representa a personas, o sistemas (software) dentro del negocio que son las que realizan las actividades que están comprendidas dentro de un caso de uso. Estos trabajadores están dentro de la frontera del negocio.

A continuación se muestra en la tabla 2.2, los trabajadores del negocio y su correspondiente justificación:

Capítulo 2: Características del Sistema

20

Tabla 2.2 Justificación de los Trabajadores del Negocio

2.5 Diagrama de casos de uso del negocio

Un diagrama de casos de uso del negocio representa gráficamente a los procesos del negocio y su interacción con los actores del negocio (Ver figura 2.1).

Trabajadores del negocio Justificación

Estudiante Es la persona que le corresponde realizar la guardia, la cuartelería y el TSU, Recibir los recursos y activos del apartamento, reportar las defectaciones a las Técnica-C, Informar datos generales, firmar evaluación y debatir talleres educativos.

Profesor Es la persona encargada de chequear la realización de la guardia estudiantil y el TSU y es el encargado de realizar los análisis a los estudiantes en caso de ausencias.

Técnica-C de atención al becario Es la persona encargada de chequear la realización de la cuartelería, realizar inspección a los apartamentos para evaluar a los estudiantes, controlar las defectaciones y los medios de los apartamentos, emitir talleres educativos, entregar aseo y ubicar a los estudiantes en los apartamentos.

Técnico Es la persona encargada de arreglar las defectaciones que han sido reportadas de los apartamentos.

Administrador del área Es la persona encargada de recoger la asistencia de los estudiantes que participan en el TSU y comunicársela a la directora de servicios generales.

Directora de servicios generales Es la persona encargada de controlar la asistencia a los TSU, la misma envía esos reportes a la vicedecana de extensión y residencia.

FEU Es la persona encargada de comunicarles a los estudiantes su ubicación.

Vicedecana de Extensión y Residencia

Es la persona encargada de recoger el aseo de los estudiantes que están fuera de la universidad.

Jefe de apartamento Es la persona encargada de firmar la evaluación que le otorgan al apartamento.

Capítulo 2: Características del Sistema

21

Figura 2.1 Diagrama de Casos de Uso del Negocio.

Capítulo 2: Características del Sistema

22

Los diagramas de actividades asociados a cada caso de uso, así como la descripción textual se pueden encontrar en el Anexo.

2.6 Requerimientos funcionales

Los requerimientos funcionales son capacidades o condiciones que el sistema debe cumplir.

Para cumplir con los objetivos propuestos se prevé que el sistema tenga las siguientes funcionalidades:

 R 1 Autenticar Usuario.

R 1.1 Introducir nombre de usuario y contraseña.

R 1.2 Validar datos introducidos.

R 1.3 Mostrar al usuario las opciones a las que tiene acceso según el rol o permiso que tiene asignado.

 R 2 Gestionar Usuario

R 2.1 Adicionar usuario al sistema

R 2.2 Modificar usuario en el sistema

R 2.3 Eliminar usuario del sistema

R 2.4 Mostrar usuario

 R 3 Gestionar Guardia Estudiantil

R 3.1 Generar guardia estudiantil

R 3.2 Modificar guardia estudiantil

R 3.3 Eliminar guardia estudiantil

R 3.4 Mostrar guardia estudiantil

Capítulo 2: Características del Sistema

23

 R 4 Gestionar TSU

R 4.1 Generar TSU

R 4.2 Mostrar TSU

R 4.3 Modificar TSU

R 4.4 Eliminar TSU

 R 5 Gestionar Datos del Profesor Guía

R 5.1 Adicionar datos del profesor guía

R 5.2 Eliminar datos del profesor guía

R 5.3 Modificar datos del profesor guía

R 5.4 Mostrar datos del profesor guía

 R 6 Gestionar Cuartelería

R 6.1 Generar cuartelería

R 6.2 Modificar cuartelería

R 6.3 Eliminar cuartelería

R 6.4 Mostrar cuartelería

 R 7 Gestionar Grupo

R 7.1 Adicionar grupo

R 7.2 Modificar grupo

R 7.3 Mostrar grupo

Capítulo 2: Características del Sistema

24

 R 8 Gestionar Defectaciones

R 8.1 Mostrar defectación

R 8.2 Adicionar defectación

R 8.3 Modificar defectación

 R 9 Gestionar Medios

R 9.1 Mostrar medios

R 9.2 Adicionar medios

R 9.3 Modificar medios

 R 10 Gestionar Caracterización del Estudiante

R 10.1 Adicionar caracterización del estudiante

R 10.2 Modificar caracterización del estudiante

R 10.3 Mostrar caracterización del estudiante

 R 11 Gestionar Evaluación del Estudiante

R 11.1 Adicionar evaluación del estudiante

R 11.2 La evaluación del estudiante puede ser:

R 11.2.1 Bien

R 11.2.2 Regular

R 11.2.3 Mal

R 11.3 Modificar evaluación del estudiante

R 11.4 Mostrar evaluación del estudiante

Capítulo 2: Características del Sistema

25

 R 12 Gestionar Señalamientos del Estudiante

R 12.1 Adicionar señalamientos del estudiante

R 12.2 Mostrar señalamientos del estudiante

R 12.3 Modificar señalamientos del estudiante

 R 13 Gestionar Evaluación del Apartamento

R 13.1 Adicionar evaluación al apartamento

R 13.2 La evaluación del apartamento puede ser:

R 13.2.1 Bien

R 13.2.2 Regular

R 13.2.3 Mal

R 13.3 Mostrar evaluación del apartamento

R 13.4 Modificar evaluación del apartamento

 R 14 Reportes

R 14.1 Ver cuartelería

R 14.2 Ver guardia estudiantil

R 14.3 Ver TSU

R 14.4 Ver evaluación del estudiante en la residencia

 R 15 Buscar Estudiante

 R 16 Buscar Apartamento

Capítulo 2: Características del Sistema

26

2.7 Requerimientos no funcionales

Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable.

A continuación se muestran los requerimientos no funcionales de:

Software: Sistemas operativos: Linux, Windows95 o superior.

Rendimiento: Un tiempo de respuesta rápido para evitar que los usuarios se sientan motivados a abandonar el software.

Soporte: Una vez que se ha terminado el desarrollo de nuestro software se realizarán diferentes acciones con motivo de asistir a los clientes, así como lograr su mejoramiento progresivo y evolución en el tiempo.

Portabilidad: El sistema debe ser capaz de ser soportado por varios Sistemas Operativos.

Usabilidad: Tendrán acceso a la aplicación los administradores, la vicedecana de extensión y residencia, la Técnica-c de atención al becario y todos los usuarios.

Confiabilidad: La aplicación estará protegida ante fallos menores, tal es el caso que en todos los campos se van a validar los datos que se enviarán al servidor para que no se de el caso que llegue a la Base de Datos un tipo de dato inesperado y de esta forma se almacena una información confiable.

Confidencialidad: La información manejada por el sistema deberá estar protegida de acceso no autorizado.

Apariencia o interfaz externa: Definimos un diseño accesible (sencillo) para todos los usuarios, es decir que no se necesite mucho conocimiento para navegar en el software.

Seguridad: Se requerirá de una contraseña para acceder al sistema. Las opciones del software se mostrarán según el nivel de acceso de los usuarios. El sistema debe comunicarse usando un protocolo seguro, https.

Capítulo 2: Características del Sistema

27

2.8 Actores del sistema

Los actores del sistema pueden representar el rol que juega una o varias personas, un equipo o un sistema automatizado, no son parte de él, pueden intercambiar información con él y pueden ser un recipiente pasivo de información. A continuación se muestran los actores del sistema:

Actores Justificación

Usuario Es una generalización de la Técnica –c de atención al

becario, del administrador, lleva a cabo el proceso de autenticación y ver reportes.

Administrador Puede realizar todas las acciones que realiza un usuario. Es una generalización de la Vicedecana de extensión y residencia, además es el responsable de gestionar usuario.

Vicedecana de extensión y residencia Es un administrador, que a su vez puede realizar todas las acciones que realiza el actor administrador, además es la responsable de Gestionar la Guardia Gestionar el TSU, Gestionar Grupo, Gestionar Datos del profesor guía.

Técnica-c de atención al

becario(instructora)

Es un usuario, que es la responsable de Gestionar defectaciones, Gestionar Medios, Gestionar Cuartelería, Gestionar Evaluación de los apartamentos, Gestionar señalamientos del estudiante, Gestionar Caracterización del estudiante y Gestionar Evaluación de los Estudiantes.

Tabla 2.3 Actores del Sistema

2.9 Diagrama de casos de uso del sistema

Un diagrama de casos de uso del sistema representa gráficamente a los procesos y su interacción con los actores.

Capítulo 2: Características del Sistema

28

Figura 2.2 Diagrama de Casos de Uso del Sistema

Capítulo 2: Características del Sistema

29

2.10 Conclusiones

En este capítulo después de haber realizado el modelado de negocio, se pudo lograr una mejor comprensión del problema que el sistema tiene que resolver. Además se comenzó a profundizar en el desarrollo de la propuesta de solución, obteniéndose a partir del análisis de los procesos del negocio, un listado con las principales funcionalidades que debe tener el sistema, se representaron los diagramas de casos de uso del sistema, y finalmente se describieron las acciones de los actores del sistema con los casos de uso con los que interactúan. A partir de aquí se puede comenzar a construir el sistema, cumpliendo con todos los requerimientos y las funcionalidades que se derivaron en este capítulo.

Capítulo 3: Análisis y Diseño del Sistema

30

CAPÍTULO 3: ANÁLISIS Y DISEÑO DEL SISTEMA 3.1 Introducción

En este capitulo se muestran todos los diagramas de clases del análisis donde se tratan las clases interfaces, las controladoras, entidades y las relaciones entre ellas. Se presentan los diagramas de diseño donde se utilizan los estereotipos para modelar aplicaciones Web estos son las clases servidoras, clientes, los formularios y clases que permitirán el acceso a los datos que se almacenan en la BD.

3.2 Modelo del Análisis

En el análisis podemos estructurar los requisitos de manera que facilite su comprensión, su preparación, su modificación y en general su mantenimiento. Esta estructura (basada en clases de análisis y paquetes) es independiente de la estructura que se dio a los requisitos (basada en casos de uso). Sin embargo existe una trazabilidad directa entre esas distintas estructuras, la cual se define entre casos de uso del modelo de casos de uso y realizaciones del caso de uso en el modelo de análisis.

En la construcción del modelo de análisis se tienen que identificar las clases que describen la realización de los casos de uso, los atributos y las relaciones entre ellas. Con esta información se construye el Diagrama de clases del análisis, que por lo general se descompone para agrupar las clases en paquetes.

3.3 Clases de análisis

Se centran en los requisitos funcionales y son evidentes en el dominio del problema porque representan conceptos y relaciones del dominio. Tienen atributos y entre ellas se establecen relaciones de asociación, agregación / composición, generalización / especialización y tipos asociativos. Las clases se clasifican en:

Clases Interfaz: Al modelar la interacción entre el sistema y sus actores

Capítulo 3: Análisis y Diseño del Sistema

31

Clases entidad: Estas clases modelan información que posee una larga vida y que a menudo es persistente y fenómenos, conceptos y sucesos que ocurren en el mundo real. La fuente principal de obtención son las clases entidades del negocio y el glosario de términos que se ha ido elaborando.

Clases de control: Las clases de control coordinan el trabajo de uno o unos pocos casos de uso, coordinando las actividades de los objetos que implementan la funcionalidad del caso de uso, por lo que definen el flujo de control y las transacciones dentro de un caso de uso delegando el trabajo a otros objetos.

3.4 Diagrama de clases del análisis

Un Diagrama de clases del análisis es un artefacto en el que se representan los conceptos en un dominio del problema. Representa las cosas del mundo real, no de la implementación automatizada de estas.

Figura 3.1 DCA. CU del Sistema Autenticar Usuario.

Capítulo 3: Análisis y Diseño del Sistema

32

Figura 3.2 DCA. CU del Sistema Gestionar Caracterización del Estudiante.

Figura 3.3 DCA. CU del Sistema Gestionar Cuartelería.

Capítulo 3: Análisis y Diseño del Sistema

33

Figura 3.4 DCA. CU del Sistema Gestionar Datos del Profesor Guía

Capítulo 3: Análisis y Diseño del Sistema

34

Figura 3.5 DCA. CU del Sistema Gestionar Defectación.

Capítulo 3: Análisis y Diseño del Sistema

35

Figura 3.6 DCA. CU del Sistema Gestionar Guardia Estudiantil.

Capítulo 3: Análisis y Diseño del Sistema

36

Figura 3.7 DCA. CU del Sistema Gestionar Evaluación del Apartamento.

Figura 3.8 DCA. CU del Sistema Gestionar Evaluación del Estudiante.

Capítulo 3: Análisis y Diseño del Sistema

37

Figura 3.9 DCA. CU del Sistema Gestionar Medios.

Figura 3.10 DCA. CU del Sistema Buscar Estudiante.

Capítulo 3: Análisis y Diseño del Sistema

38

Figura 3.11 DCA. CU del Sistema Gestionar Señalamientos del Estudiante.

Figura 3.12 DCA. CU del Sistema Gestionar TSU.

Capítulo 3: Análisis y Diseño del Sistema

39

Figura 3.13 DCA. CU del Sistema Buscar Apartamento.

Figura 3.14 DCA. CU del Sistema Gestionar Usuario.

Capítulo 3: Análisis y Diseño del Sistema

40

Figura 3.15 DCA. CU del Sistema Gestionar Grupo.

Capítulo 3: Análisis y Diseño del Sistema

41

Figura 3.16 DCA. CU del Sistema Ver Reportes

Capítulo 3: Análisis y Diseño del Sistema

42

3.5 Modelo de Diseño

En el diseño se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los no funcionales y las restricciones que se le suponen. Una entrada esencial en el diseño es el resultado del análisis, o sea el modelo de análisis, que proporciona una comprensión detallada de los requisitos. Además impone una estructura del sistema que se debe esforzar por conservar lo más fielmente posible cuando se le de forma al sistema. El Modelo de Diseño es un modelo de objetos que describe la realización de los casos de uso y al mismo tiempo constituye una abstracción del modelo de implementación y del código fuente. El diseño del software sirve como fundamento para todos los pasos siguientes del soporte del software y de la ingeniería del software.

Sin un diseño, se corre el riesgo de construir un sistema inestable, un sistema que fallará cuando se lleven a cabo cambios; un sistema que puede resultar difícil de comprobar. Para lograr esto existen los patrones de diseño. Un patrón de diseño no es más que un par problema–solución que recibe un nombre en dependencia del problema que resuelve. Como por ejemplo: ¿Cómo dar soporte a una dependencia escasa y a un aumento de la reutilización? ¿Cómo mantener la complejidad dentro de límites manejables?, entre otras responsabilidades.

3.7 Patrón Model-View-Controller (Modelo-Vista-Controlador)

Es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista.

Modelo: Esta es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comprar un número de unidades negativo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o importes en un carrito de la compra.

Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.