El BLOG de FLamelas

El objetivo del presente proyecto es diseñar y construir una base de datos en el SGBD SQL Anywhere 9 de Sybase así como construir un aplicativo en un lenguaje visual de su elección que interactúe con dicha base de datos por medio de un driver ODBC.

Se desea una base de datos relacional y una aplicación que controle las distintas tareas de una unidad de soporte de tecnologías de información en una empresa cualquiera. La unidad cuenta con especialistas en tecnologías de la información (TI) de distinta formación, por lo que la unidad puede atender distintos tipos de solicitudes de soporte técnico. Cada tipo de solicitud puede contar con varias categorías (también parametrizables). Por ejemplo, una solicitud de soporte técnico de hardware puede contar con las siguientes categorías: impresora, cpu, monitor, ups, entre otras tantas. Una solicitud de soporte técnico de software puede contar con las categorías: sistema de información de la empresa, correo electrónico, procesador de texto, entre otras tantas.

De un especialista en TI se almacenan todos sus datos generales (nombres, apellidos, número de identidad, número de RTN (si tiene), e-mail, teléfono fijo, teléfono móvil (si tiene), pager (si tiene), dirección del domicilio, teléfono del domicilio, fecha de nacimiento, edad, sexo, y cualquier otro dato de identificación que se considere necesario). Un especialista en TI puede contar con uno o varios grados académicos superiores (secundaria técnico, técnico universitario, licenciatura, maestría, doctorado) y para cada grado, se deberá almacenar la universidad o centro técnico donde se formó, año en que se tituló y título obtenido (i.e. Ingeniero en Sistemas Computacionales, Licenciado en Informática Administrativa, Ingeniero en Ciencias de la Computación, Técnico en Computación, entre otros tantos títulos que pueden considerarse). Un especialista en TI también puede contar con una serie de seminarios o cursos a los cuales ha asistido. Se requiere guardar esta información. Cada especialista en TI tiene una nivel mayor de especialización y varios niveles menores de especialización. Por ejemplo, Miguel Pérez es Especialista en Redes y tiene los siguientes niveles menores de especialización: enrutadores CISCO, firewalls.

Una solicitud de soporte técnico puede generarse desde cualquier departamento o división de la empresa. Toda solicitud, además de especificársele el tipo y la categoría, cuenta también con la siguiente información: Fecha y hora de la solicitud, nombre de la persona que hace la solicitud, breve descripción o título de la solicitud (i.e. La impresora reporta que está fuera de línea), detalle de la solicitud (una ampliación a la descripción del problema, con todos los datos que proporciona la persona que reporta el problema), estado de la solicitud (representa las distintas etapas por las que puede pasar una solicitud de soporte; por ejemplo: abierta, en proceso de solución, solucionada, no solucionada; los estados de una solicitud pueden variar de una empresa a otra por lo que los estados posibles deberían ser parametrizables).

Un especialista en TI puede ser asignado para que atienda una o varias solicitudes de soporte técnico, pero una solicitud sólo es asignada a un especialista en TI (por cada solicitud sólo hay un especialista responsable de la misma). Se deberá almacenar la fecha y hora de la asignación. Si la solicitud no ha sido resuelta, se puede cambiar el especialista en TI responsable de dicha solicitud (re-asignación de funciones) y se deberá guardar la fecha y hora de la re-asignación. Se deberá guardar en la base el motivo de la re-asignación (los motivos posibles deberán ser parametrizables). Una solicitud sólo puede ser re-asignada una vez.

Una solicitud de soporte técnico puede tener asociada una o varias soluciones. De cada solución, se deberá registrar lo siguiente: Descripción de la solución o diagnóstico, fecha y hora de la solución, nombre(s) de el(los) especialista(s) en TI que participó(aron) en la solución del problema o solicitud, recursos requeridos para la solución (si aplica). Si una solicitud de soporte técnico no se puede solucionar, se deberán almacenar los motivos de su no solución (esto para que el administrador o coordinador de los especialistas en TI pueda re-asignar una solicitud o se conozcan las causas más comunes por las que no se resuelven problemas en la unidad).

Algunas solicitudes de soporte técnico podrían requerir de ciertos recursos para su solución. Por ejemplo, si la solicitud era que el CPU no encendía y el diagnóstico o solución fue: “se requiere cambiar la fuente de poder”, entonces, dicha solicitud requiere para su solución de una nueva fuente de poder. Un especialista en TI deberá indicar los recursos requeridos para una solución; sin embargo, el administrador o coordinador de los especialistas en TI es la persona que deberá aprobar los recursos requeridos.

Se requiere que el sistema de soporte técnico que se desarrolle cuente con un sub-sistema de control de accesos. Lo anterior se requiere porque existen distintos tipos de usuarios del sistema con distintos niveles de acceso.

Existen usuarios que ingresan las solicitudes de soporte técnico al sistema.

Existen usuarios del tipo administradores de sistema que tienen acceso para asignar o re-asignar solicitudes a especialistas de TI. Igualmente, los administradores de sistema son los que tienen el acceso para generar todos los reportes y/consultas asociadas al rendimiento y carga de trabajo de todos los especialistas en TI. Un administrador de sistema podrá ver todas las solicitudes asignadas a cada especialista en TI así como los recursos requeridos para completar la solución de una solicitud.

Finalmente, existen usuarios del tipo especialista en TI que sólo tiene acceso a solucionar las solicitudes de soporte asignadas a él(o ella). Un especialista en TI podrá generar reportes y/o consultas asociados a su propio rendimiento así como a su carga de trabajo. Un especialista en TI podrá seleccionar recursos disponibles para una solución; no obstante, hasta que esos recursos sean aprobados por un administrador, entonces la solicitud podrá darse como cerrada.

A. Elaborar un documento impreso que contenga el Diseño Conceptual de la base de datos relacional que resuelva los requerimientos expuestos. El documento en cuestión usará los lineamientos generales contenidos en el Ejemplo de Diseño de una Base de Datos Relacional colocado en el blog de la clase (flamelas.blogspot.com) (5 puntos).

Los apartados del documento deberán ser estos (además de contar con una portada y tabla de contenido):

a. Identificación de Entidades y criterios usados para su selección.

b. Identificación de atributos por Entidad.

c. Identificación de Relaciones o Vínculos existentes y criterios usados para su selección.

d. Identificación de Restricciones de Clave Primaria para las Entidades.

e. Identificación de Restricciones de Cardinalidad de las Relaciones identificadas.

f. Diagrama Entidad-Relación (E-R) construído con el software DIA.

B. Elaborar un documento impreso que contenga el Diseño Lógico y Físico de la base de datos relacional que resuelva los requerimientos expuestos. El documento en cuestión usará los lineamientos generales contenidos en el Ejemplo de Diseño de una Base de Datos Relacional colocado en el blog de la clase (flamelas.blogspot.com). Adicionalmente, el documento contendrá las sentencias DDL del Modelo Relacional. Dichas sentencias se construirán usando la sintaxis SQL del SGBD Sybase Adaptive Server Anywhere 9 tomando en cuenta TODAS las restricciones de integridad necesarias (llaves primarias, llaves foráneas, referencias relacionales, checks).

Los apartados del documento deberán ser estos (además de contar con una portada y tabla de contenido):

a. Esquema Relacional (2 puntos)

b. Sentencias DDL del SQL de Sybase (3 puntos)

Ejecutar en el aula de clases en la base de datos Sybase SQL Anywhere del proyecto las sentencias DDL (que incluyen las tablas, vistas y demás objetos identificados). (3 puntos)

Ejecutar en el aula de clases en la base de datos Sybase SQL Anywhere del proyecto las sentencias de llenado de las tablas antes creadas con datos de muestra de distinta índole. (2 puntos)

C. Construir un aplicativo en un lenguaje de programación visual que interactúe con el SGBD Sybase Adaptive Server Anywhere 9. (10 puntos)

Por medio del aplicativo visual se deben poder realizar las siguientes operaciones de mantenimiento en la base de datos:

a) Crear, borrar o modificar los datos generales de los especialistas en TI. (2 punto)

b) Crear, borrar o modificar tipos y categorías de solicitudes de soporte. (2 punto)

Por medio del aplicativo visual se deben poder realizar las siguientes transacciones sobre la base de datos:

c) Ingresar solicitudes de soporte técnico. (2 puntos)

d) Realizar asignaciones de solicitudes de soporte a especialistas de TI. Se requiere mostrar una re-asignación de una solicitud a otro especialista en TI indicando el motivo de la nueva asignación. (2 puntos)

e) Asociar soluciones a solicitudes de soporte técnico y mostrar una solución en donde el especialista en TI indique que se requiere de un recurso para poder solucionar el problema. Por su parte, el coordinador o administrador de especialistas en TI deberá aprobar el recurso para que el especialista pueda cerrar o dar por solucionada la solicitud. (2 puntos)

D. Por medio del aplicativo visual se debe poder satisfacer los siguientes requerimientos de información por medio de consultas a pantalla o de reportes: (5 puntos)

a) Mostrar a una fecha determinada, todas las solicitudes de soporte en proceso de solución (incluyendo: identificación de la solicitud, breve descripción de la solicitud, fecha de la solicitud, hora de la solicitud, fecha de la asignación, hora de la asignación y nombre del especialista en TI responsable) y todas las solicitudes de soporte NO asignadas a algún especialista en TI (incluyendo: identificación de la solicitud, breve descripción de la solicitud, fecha de la solicitud y hora de la solicitud). (1 punto)

b) Mostrar todas las solicitudes de soporte que requieren recursos para su solución (incluyendo: identificación de la solicitud y breve descripción de la solicitud) especificando el recurso o los recursos requeridos para cada solicitud así como el especialista en TI que requirió el recurso. (1 punto)

c) Mostrar todas aquellas solicitudes de soporte (identificación de la solicitud y breve descripción de la misma) que en su solución participaron más de un especialista en TI. Incluir nombre de los especialistas en TI que participaron en la solución (incluyendo al especialista en TI responsable de la solicitud). (1 punto)

d) Mostrar el nombre completo y niveles de especialización (mayores y menores) de aquellos especialistas en TI NO asignados a solicitud de soporte alguna. (1 punto)

e) Mostrar todas las solicitudes de soporte que fueron re-asignadas, incluyendo la siguiente información: Identificación de la solicitud, breve descripción de la solicitud, f echa, hora y especialista de TI asignados originalmente y la fecha, hora y especialista de TI re-asignado así como el motivo de la re-asignación. (1 punto)

· El proyecto tiene un valor total de 30 puntos ORO y deberá ser presentado por ambos integrantes del equipo el día que les corresponda (si uno de los miembros del equipo NO se presenta, perderá los puntos correspondientes a esa revisión. Si un grupo NO se presenta el día que le corresponda, perderá 5 puntos ORO por cada día de atraso). A partir de la segunda entrega de la presentación del proyecto, cada equipo deberá traer un computador desde donde le mostrará al profesor el proyecto desarrollado.

· El proyecto será presentado en tres (3) entregas (La primera con un valor de 5 puntos ORO, la segunda con un valor de 10 puntos ORO y la tercera con un valor de 15 puntos ORO. La primera entrega se efectuará los días: 1 y 2 de febrero y comprende el punto A de la descripción del proyecto. La segunda entrega se realizará los días: 22 y 23 de febrero y comprende el punto B de la descripción del proyecto. La tercera y última entrega se llevará a cabo los días: 15 y 16 de marzo y comprende los puntos C y D de la descripción del proyecto.

· En la primera entrega, cada grupo sólo deberá entregar su documento. Durante la segunda y tercera entrega, además de la entrega de documentos se harán revisiones en el aula de clases (segunda entrega, revisión de scripts DDLs y carga de datos; tercera entrega, revisión de interacción del aplicativo visual desarrollado con la base de datos creada en las fases anteriores).

· Los documentos de la primera y segunda entrega serán revisados por el profesor y serán entregados hasta el día lunes de la siguiente semana con las correcciones sugeridas para cada caso. Cada grupo deberá aplicar dichas correcciones antes de proceder con las siguientes etapas del proyecto.

· En la última entrega, cada grupo deberá presentar la versión final impresa del documento del diseño de la base de datos relacional y un CD que contenga el aplicativo desarrollado y la base de datos Sybase SQL Anywhere.

El documento impreso deberá contener:

o Portada

o Tabla de contenido

o Introducción

o Objetivos

o Versión corregida del Diseño Conceptual

o Versión corregida del Diseño Lógico y Conceptual

o Conclusiones

o Bibliografía

o Anexos

El CD deberá contener los códigos fuente y objeto del software de aplicación desarrollado. Se deberán incluir los scripts DDLs de creación de la base de datos y los scripts de llenado de tablas. También, se deberá incluir la base de datos final con los datos de muestra.

· Toda consideración que se haga en el proyecto, deberá estar debidamente documentada y justificada en los distintos documentos donde se aplique.

· Cada grupo deberá construir y darle mantenimiento a un blog site (por medio del blogger.com). En este blog site, se deberán colocar avances semanales en el desarrollo de su proyecto así como problemas con los cuales se hayan encontrado. En el blog site: flamelas.blogspot.com se encuentra una nota que contiene el directorio de los blog sites de todos los grupos de proyecto (cada grupo deberá remitir por correo electrónico su dirección para poder subir esta información al blog site antes enunciado). La idea es que cada grupo pueda visitar todos los blogs y pueda aportar ideas o soluciones a problemas detectados en el desarrollo de cada proyecto.

· La descripción del proyecto representa los productos mínimos esperados en este proyecto y se podrán otorgar puntos adicionales sólo si el proyecto excede las expectativas de todos los productos mínimos esperados en el mismo.

· El calendario de entregas por grupo se muestra al final de este documento.

Grupo	Primera Revisión	Segunda Revisión	Tercera Revisión
1 Jorge Hernández y Donaldo Amaya	1/02	23/02	15/03
2 Saúl Villaseñor e Iván Ordóñez	1/02	23/02	16/03
3 Luis Melgar y Elvin Carrasco	1/02	23/02	15/03
4 Héctor Pagoaga y Léster López	2/02	22/02	16/03
5 Denis Jirón y Ana García	2/02	22/02	15/03
6 Román Pineda y Rony López	2/02	22/02	16/03
7 German Aguilar y Ricardo Palma	2/02	22/02	15/03
8 Mario Rodríguez y Arturo Barahona	1/02	23/02	16/03
9 Geofrey Burgos y Mario Henríquez	2/02	22/02	15/03
10 José Chajtur y Tommy Ponce	1/02	23/02	16/03