77
UNIVERSIDAD AUTÓNOMA DEL ESTADO DE MÉXICO CENTRO UNIVERSITARIO UAEM TEMASCALTEPEC “Modelado e implementación de un sistema de registro de protocolos y titulaciones en el Centro Universitario UAEM Temascaltepec.” TESIS QUE PARA OBTENER EL TÍTULO DE Maestría en ciencias de la computación PRESENTA: L.I.A. Rafael Rigoberto López Orozco DIRECTOR: M. en T.I. Rafael Valentín Mendoza Méndez

Indice tentativo (Autoguardado).docx

Embed Size (px)

Citation preview

Page 1: Indice tentativo (Autoguardado).docx

UNIVERSIDAD AUTÓNOMA DEL ESTADO DE

MÉXICO

CENTRO UNIVERSITARIO UAEM TEMASCALTEPEC

“Modelado e implementación de un sistema de

registro de protocolos y titulaciones en el Centro

Universitario UAEM Temascaltepec.”

TESIS

QUE PARA OBTENER EL TÍTULO DE

Maestría en ciencias de la computación

PRESENTA:

L.I.A. Rafael Rigoberto López Orozco

DIRECTOR:

M. en T.I. Rafael Valentín Mendoza Méndez

Temascaltepec, a Diciembre de 2013.

Page 2: Indice tentativo (Autoguardado).docx

Índice

Capítulo I Marco conceptual

1.1 Definición de software1.2 Tipos de software 1.3 Ciclos de vida del software1.3.1 Modelos del ciclo del software1.3.2 Modelo tradicionales

1.3.2.1 Cascada1.3.2.2 Espiral1.3.2.3 Prototipo1.3.2.4 Incremental

1.3.3 Modelos agiles1.3.3.1 Xp

1.4 Los sistemas de información1.4.1 Clasificación de los sistemas de información

1.5 Definición de base de datos1.6 Clasificación general de los sistemas de información1.7 Sistema manejador de datos (DBMS o SGBD)1.8 Lenguaje de manipulación de datos (LMD)1.9 Lenguaje de definición de datos (DDL)1.10 Seguridad de bases de datos1.10.1 Tipos de seguridad1.11 Modelo entidad-relación1.12 Normalización de bases de datos1.13 Definición de lenguajes de programación1.13.1 Tipos de lenguajes de programación

Capítulo II Por que usar XP

Capítulo III Análisis de factibilidad

Capítulo IV Modelado de aplicación para el registro automático de protocolos y titulaciones

1.1 Modelo entidad relación1.2 Diagrama de clases1.3 Diagrama de casos de uso

Page 3: Indice tentativo (Autoguardado).docx

1.3.1 Coordinador1.3.2 Alumno1.3.3 Profesor1.3.4 Control escolar

1.4 Casos de usoCapítulo I Marco conceptual

1.1Definición de software

El software recurriendo al diccionario de informática publicado originalmente por la Oxford University Press(1993) se define como a aquellos componentes de un sistema informático que no son tangibles, es decir, que físicamente no se pueden tocar. ParaFreedman(1984) el software es sencillamente un conjunto de instrucciones que contiene la computadora, ya sean instrucciones para poner en funcionamiento el propio sistema informático (software de sistema) o instrucciones concretas dirigidas a programas particulares del usuario (software específico). En otras palabras, según Sánchez Montoya (1995:54) el software supone un conjunto de pasos que indican a la máquina (hardware) aquello que debe hacer (Prendes y Amoros, 2001).

Por tanto podemos concluir que el software es un conjunto de aplicaciones de cómputo, procedimientos, reglas, y datos asociados que indican al hardware que es lo que debe hacer y como lo debe hacer.

1.2Tipos de software

En la actualidad podemos clasificar al software en distintos tipos de acuerdo a la función que realizan, según esta clasificación el software se divide en 3 categorías principales que son software de sistema, software de aplicaciones y software de desarrollo, las cuales se describen a continuación:

Software de sistema: Es el software que nos permite tener una interacción con nuestro hardware, es decir, es el sistema operativo. Dicho sistema es un conjunto de programas que administran los recursos del hardware y proporciona una interfaz al usuario. Es el software esencial para una computadora, sin el no podría funcionar, como ejemplo tenemos a Windows, Linux, Mac OS X.

El software de sistema puede clasificarse en sistema operativo, controladores de dispositivos y programas utilitarios, donde el sistema operativo será el conjunto de programas que efectúan la gestión de procesos básicos en un sistema informático y permitan la normal ejecución del resto de las operaciones, mientras que los controladores de dispositivos son programas informáticos que permiten al sistema operativo interactuar con un periférico, haciendo una abstracción del hardware y proporcionando una interfaz posiblemente estandarizada para usarlo, por otro lado están los programas utilitarios que van hacer aquellos programas que se encargan de las tareas de mantenimiento y otras tareas en general.

Page 4: Indice tentativo (Autoguardado).docx

Software de Aplicación: Son los programas que nos permiten realizar tareas específicas en nuestro sistema. A diferencia del software de sistema, el software de aplicación está enfocado en un área específica para su utilización. La mayoría de los programas que utilizamos diariamente pertenecen a este tipo de software, ya que nos permiten realizar diversos tipos de tareas en nuestro sistema.

El software de aplicación se puede considerar como una herramienta que extiende las capacidades humanas, permitiendo la realización de tareas que de otro modo sería difícil o imposible realizar. Por lo tanto, la mayor parte del software cae dentro esta clase. Dentro de ella podemos distinguir entre los siguientes tipos de software:

Aplicaciones de publicación electrónica (Procesadores de textos, entornos de desarrollo de sitios Web)

Aplicaciones de cálculo numérico (Hojas de cálculo) Aplicaciones de almacenamiento de información n (Bases de datos) Aplicaciones de telecomunicaciones y redes (Navegadores, Chats, FTPs, Correo) Aplicaciones gráficas de diseño (vectorial, 2D, 3D) Aplicaciones multimedia e hipermedia Aplicaciones de gestión empresarial

Software de Programación: Es un conjunto de aplicaciones que permiten a un programador desarrollar sus propios programas informáticos haciendo uso de sus conocimientos lógicos y lenguajes de programación, entre los cuales podemos destacar los editores de texto, compiladores, interpretes, enlazadores, depuradores entre otros.

1.3Ciclos de vida del software

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado.

Entre las funciones que debe tener un ciclo de vida se pueden destacar:

Determinar el orden de las fases del proceso de software Establecer los criterios de transición para pasar de una fase a la siguiente Definir las entradas y salidas de cada fase Describir los estados por los que pasa el producto Describir las actividades a realizar para transformar el producto Definir un esquema que sirve como base para planificar, organizar, coordinar,

desarrollar…

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se

Page 5: Indice tentativo (Autoguardado).docx

van produciendo (retroalimentación) (Laboratorio Nacional de Calidad del Software deINTECO, 2009).

1.3.1 Modelos del ciclo de vida del software

La ingeniería del software establece y se vale de una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del software”.

Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en que se ejecutan las fases.

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software Define las fases primarias esperadas de ser ejecutadas durante esas fases Ayuda a administrar el progreso del desarrollo Provee un espacio de trabajo para la definición de un proceso detallado de

desarrollo de software

En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y la elección de un modelo para un determinado tipo de proyecto es realmente importante; el orden es uno de estos puntos importantes.

Existen varias alternativas de modelos de ciclo de vida. A continuación se muestran algunos de los modelos tradicionales y más utilizados (Laboratorio Nacional de Calidaddel Software de INTECO, 2009).

1.3.2 Modelos tradicionales

1.3.2.1 Modelo en Cascada

Este modelo utiliza tramos como puntos de transición y de carga. Al usar el modelo de cascada, se necesitaría completar un conjunto de tareas en forma de fase para después continuar con la fase próxima. El modelo en cascada trabaja perfectamente para los proyectos en los cuales los requisitos del proyecto se encuentran definidos claramente y no son obligados a futuras modificaciones. Ya que este modelo está compuesto por puntos de transición entre fases, se puede monitorear fácilmente ya que asigna responsabilidades definidas (Méndez, 2010).

Page 6: Indice tentativo (Autoguardado).docx

Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido ampliamente en la ingeniería el software. La innovación estuvo en la primera vez que la ingeniería del software fue dividida en fases separadas.

El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación. Funciona bien para proyectos pequeños donde los requisitos están bien entendidos (Laboratorio Nacional de Calidad delSoftware de INTECO, 2009).

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma puramente secuencial, así como se observa en la siguiente imagen véase Figura 1.

Figura 1. Modelo cascada

1.3.2.2 Modelo en espiral

El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniería del software.

El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Toma los beneficios de los ciclos de vida incremental y prototipos, pero se tiene más en cuenta el concepto de riesgo que aparece debido a las incertidumbres e ignorancias de los requerimientos proporcionados al principio del proyecto o que surgirán durante el desarrollo. A medida que el ciclo se cumple (el avance del espiral), se van obteniendo prototipos sucesivos que van ganando la satisfacción del cliente o usuario. Falta cita

(Pressman, 2011)

Page 7: Indice tentativo (Autoguardado).docx

A menudo, la fuente de incertidumbres es el propio cliente o usuario, que en la mayoría de las oportunidades no sabe con perfección todas las funcionabilidades que debe tener el producto

Este modelo consta de cuatro actividades las cuales envuelven a las etapas véase Figura 2.

Figura 2. Modelo espiral

1. Determinar o fijar objetivos:

Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.

Fijar las restricciones Identificación de riesgos del proyecto y estrategias alternativas para evitarlos Hay una cosa que solo se hace una vez: planificación inicial o previa

2. Análisis del riesgo:

Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos

3. Desarrollar, verificar y validar (probar):

Tareas de la actividad propia y de prueba Análisis de alternativas e identificación de resolución de riesgos Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para el

desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario

Fuente: Elaboración propia

Page 8: Indice tentativo (Autoguardado).docx

son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos.

4. Planificar:

Revisamos todo lo que hemos hecho, evaluándolo y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

3.1.2.3 Modelo de Prototipos

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque (LaboratorioNacional de Calidad del Software de INTECO, 2009).

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer véase Figura 3.

Figura 3. Modelo de prototipo

3.1.2.4 Modelo Incremental

Fuente: (Laboratorio Nacional de Calidad del Software de INTECO, 2009)

Page 9: Indice tentativo (Autoguardado).docx

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software véase Figura 4.

Figura 4. Modelo incremental

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación (Laboratorio Nacional de Calidad del Softwarede INTECO, 2009).

Así como los 4 modelos de ciclo de vida del software descritos anteriormente existen más, pero describir cada uno de ellos sería una investigación demasiado amplia, es por ello que a continuación se muestran otros modelos de manera resumida véase Cuadro 1.

Cuadro 1. Otros modelos de vida del software

Modelo DescripciónModelo en V El modelo en v se desarrolló para terminar con algunos de los

problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificación.

Modelo Sashimi El modelo sashimi (llamado así porque tiene fases solapadas,

Fuente: (Laboratorio Nacional de Calidad del Software de INTECO, 2009)

Page 10: Indice tentativo (Autoguardado).docx

como el pescado japonés sashimi) fue creado originalmente por Peter DeGrace. A veces se hace referencia a él como el modelo en cascada con fases superpuestas o el modelo en cascada con retroalimentación. Ya que las fases en el modelo sashimi se superponen, lo que implica que se puede actuar durante las etapas anteriores.

Modelo Lineal Consiste en descomponer la actividad global del proyecto en etapas separadas que son separadas de manera lineal, es decir cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa siguiente. Con el ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos.

Ciclo de vida evolutivo

Este modelo acepta que los requerimientos del usuario puedan cambiar en cualquier momento. Resulta ser un modelo muy útil cuando desconocemos la mayoría de los requerimientos iniciales, o estos requerimientos no están completos.

1.3.3 Modelos agiles

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágil aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto (Jose H. Canos, 2010).

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas (Jose H. Canos, 2010).

Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es el manifiesto ágil, un documento que resume la filosofía ágil véase (Jose H. Canos, 2010).

1.3.3.1 Modelo eXtremeProgramming (XP)

XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo ( Calderon et al, 2007). Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico (Jose H. Canos,2010).

Fuente: Elaboración propia

Page 11: Indice tentativo (Autoguardado).docx

A continuación en el siguiente apartado presentamos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas.

Historias de usuario: Son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas (Jose H. Canos, 2010).

A efectos de planificación, las historias pueden ser de una a tres semanas de tiempo de programación (para no superar el tamaño de una iteración). Las historias de usuario son descompuestas en tareas de programación (taskcard) y asignadas a los programadores para ser implementadas durante una iteración (Jose H. Canos, 2010).

Roles XP: De acuerdo con la propuesta original de Beck son:

Programador. El programador escribe las pruebas unitarias y produce el código del sistema.

Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio.

Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración.

Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.

Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.

Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación ( Calderon et al, 2007).

Proceso XP: El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:

1. El cliente define el valor de negocio a implementar.2. El programador estima el esfuerzo necesario para su implementación.3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las

restricciones de tiempo.

Page 12: Indice tentativo (Autoguardado).docx

4. El programador construye ese valor de negocio.5. Vuelve al paso 1 ( Calderon et al, 2007).

En todas las iteraciones de este ciclo tanto el cliente como el programadoraprenden. No se debe presionar al programador a realizar más trabajo que el estimado,ya que se perderá calidad en el software o no se cumplirán los plazos. De la mismaforma el cliente tiene la obligación de manejar el ámbito de entrega del producto,para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración ( Calderon et al, 2007).

El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación dela Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

Prácticas XP: La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las siguientes prácticas (Jose H. Canos, 2010).

El juego de la planificación. Hay una comunicación frecuente el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.

Entregas pequeñas. Producir rápidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versión ya constituye un resultado de valor para el negocio. Una entrega no debería tardar más 3 meses.

Metáfora.El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema (conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema, ayudando a la nomenclatura de clases y métodos del sistema).

Diseño simple. Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento determinado del proyecto.

Pruebas. La producción de código está dirigida por las pruebas unitarias. Éstas son establecidas por el cliente antes de escribirse el código y son ejecutadas constantemente ante cada modificación del sistema.

Refactorización (Refactoring). Es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Se mejora la estructura interna del código sin alterar su comportamiento externo.

Programación en parejas. Toda la producción de código debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implícitas (menor tasa de errores, mejor diseño, mayor satisfacción de los programadores, etc.).

Propiedad colectiva del código. Cualquier programador puede cambiar cualquier parte del código en cualquier momento.

Integración continúa. Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día.

Page 13: Indice tentativo (Autoguardado).docx

40 horas por semana. Se debe trabajar un máximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo.

Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Éste es uno de los principales factores de éxito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita.

Estándares de programación. XP enfatiza que la comunicación de los programadores es a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación para mantener el código legible.

A continuación se presenta una imagen donde se puede visualizar cómo interactúan todas las prácticas en el XP véase Figura 5.

Figura 5. Practicas XP

El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la Figura 5, donde una línea entre dos prácticas significa que las dos prácticas se refuerzan entre sí. La mayoría de las prácticas propuestas por XP no son novedosas sino que en alguna forma ya habían sido propuestas en ingeniería del software e incluso demostrado su valor en la práctica El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo ( Calderon et al, 2007).

(Jose H. Canos, 2010)

Page 14: Indice tentativo (Autoguardado).docx

Si bien XP es la metodología ágil de más renombre en la actualidad, se diferencia de las demás metodologías que forman este grupo en un aspecto en particular: el alto nivel de disciplina de las personas que participan en el proyecto ( Calderon et al, 2007).

El presente proyecto se realizara bajo la metodologia XP, por lo que las demas metodologias agiles sera resumidas en el siguiente apartado vease Cuadro 2.

Cuadro 2. Otras metodologías agiles

Metodología DescripciónSCRUM Desarrollada por Ken Schwaber, Jeff Sutherland y Mike

Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años.Está especialmente indicada para proyectos con un rápido cambio de requisitos. Susprincipales características se pueden resumir en dos. El desarrollo de software se realizamediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cadasprint es un incremento ejecutable que se muestra al cliente. La segunda característicaimportante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15minutos del equipo de desarrollo para coordinación e integración.

CrystalMethodologies Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por AlistairCockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave,por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

Dynamic Systems Development Method

(DSDM)

Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación.Las tres últimas son iterativas, además de existir realimentación a todas las fases.

Adaptive Software Development8 (ASD)

Su impulsor es JimHighsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en

Page 15: Indice tentativo (Autoguardado).docx

la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

Feature -DrivenDevelopment(FDD)

Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.

Lean Development Definida por Bob Charette.s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero sise manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.

Como se puede observar en el cuadro 2 existe una gran variedad de metodologías agiles todas ellas con diferentes técnicas pero con un objetivo en común el cual es desarrollar software de calidad, reducir tiempo y reducir costos.

1.4Los Sistema de información

Un sistema de información, es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. En un sentido amplio, un sistema de información no necesariamente incluye equipo electrónico (hardware). Sin embargo en la práctica se utiliza como sinónimo de sistema de información computarizado. Estos elementos son de naturaleza diversa y normalmente incluyen:

El equipo computacional, es decir, el hardware necesario para que el sistema pueda operar

El recurso humano que interactúa con el sistema de información, el cual está formado por las personas que utilizan el sistema

Los datos o información fuente que son introducidos en el sistema, son todas las entradas que este necesita para generar un resultado específico

Los programas que son ejecutados por la computadora y producen diferentes tipos de resultados

Las telecomunicaciones que son básicamente hardware y software, facilitan la trasmisión de texto, datos, imágenes y voz en forma electrónica.

Procedimientos que incluyen políticas y reglas de operación, tanto en la parte funcional del proceso del negocio, como en los mecanismos para hacer trabajar una aplicación en la computadora (JICA, 2004).

Un sistema de información puede realizar cuatro actividades básicas que a continuación describiremos en el siguiente apartado.

Fuente: Elaboración propia

Page 16: Indice tentativo (Autoguardado).docx

Entrada de información: Es el proceso mediante el cual el sistema de información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las entradas manuales son aquellas que son proporcionadas en forma directa por el usuario mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos.

Almacenamiento de información: es una de las actividades o capacidades más importantes que tiene una computadora, ya que, a través de esta propiedad el sistema puede recordar la información guardada en la sesión o proceso anterior.

Procesamiento de información:es la capacidad de un sistema de información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida.

Salida de la información: Es la capacidad de un sistema de información para sacar la información procesada o bien datos de entrada al exterior. Es importante aclarar que la salida de un sistema de información puede constituir la entrada a otro sistema de información o modulo (JICA, 2004).

1.4.1 Clasificación general de los sistemas de información

Los sistemas de información cumplen 3 objetivos básicos dentro de las organizaciones los cuales se describen a continuación:

Automatizar los procesos operativos Proporcionar información que sirva de apoyo al proceso de toma de decisiones Lograr ventajas competitivas a través d su implantación y uso

Los sistemas de información que logran la automatización de procesos operativos dentro de una organización son llamados sistemas transaccionales, ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, pólizas, entradas, salidas etc. Por otra parte, los sistemas de información que ayudan al proceso de toma de decisiones son los sistemas de apoyo a la toma de decisiones (DDS), sistemas para la toma de decisiones de grupo (GDSS), sistemas expertos de apoyo a la toma decisiones (EDSS) y sistemas de información para ejecutivos (EIS). El tercer tipo de sistemas, de acuerdo con su uso u objetivos que cumplen, es el de los sistemas estratégicos, los cuales se desarrolla en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información (JICA, 2004).

Los tipos y usos de sistemas de información se muestra en la siguiente figura véase Figura 6.

Page 17: Indice tentativo (Autoguardado).docx

Figura 6. Tipos de sistemas de información

1.5 Definición de base de datos

Es una colección de datos referentes a una organización estructurada según un modelo de datosde forma que refleja las relaciones y restricciones existentes entre los objetos del mundo real, y consigue independencia, integridad y seguridad de los datos.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

1.6 Clasificación de las bases de datos

Las bases de datos pueden clasificarse en dos formas, atendiendo a su función y deacuerdo a su modelo de administración de datos a continuación se describen dichas clasificaciones:

Atendiendo a su función Las bases de datos pueden dividirse en dos grupos, considerando su función primordial:

Bases de datos analíticas: Estas son bases de datos de sólo lectura, utilizadas primordialmente paraalmacenar datos históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de datos a través del tiempo, realizar proyecciones y tomar decisiones.

Bases de datos dinámicas:Estas son bases de datos más dinámicas, orientadas a almacenar información que es modificada con el tiempo, permitiendo operaciones como actualización y adición de datos, además de las operaciones fundamentales de consultas.

Fuente: (JICA, 2004)

Page 18: Indice tentativo (Autoguardado).docx

De acuerdo a su modelo de administración de datos: Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de datos (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos. De acuerdo a esta clasificación podemos encontrar 6 tipos de bases de datos que se describen en el siguiente apartado:

Bases de datos jerárquicas:Estas son bases de datos que, como su nombre indica, almacenan su información en una estructura jerárquica. En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas. .Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.

Bases de datos de red: Este es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico). Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales.

Bases de datos relacionales:Este es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros (las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla). En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información. El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, StructuredQueryLanguage o Lenguaje Estructurado de Consultas, un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales. Durante su diseño, una

Page 19: Indice tentativo (Autoguardado).docx

base de datos relacional pasa porun proceso al que se le conoce como normalización de una base de datos.

Bases de datos orientadas a objetos:Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento). Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes de la programación orientada a objetos: Encapsulación: Ocultar datos del resto de los datos, impidiendo así accesos incorrectos o conflictos. Herencia: Reusabilidad del código. Polimorfismo: Sobrecarga de operadores o de métodos.

Bases de datos documentales: Permiten la indexación a texto completo, y en líneas generales realizar búsquedas más potentes.

Bases de datos distribuidas: Una base de datos distribuida (BDD) es la unión de las bases de datos con redes. La base de datos está almacenada en varias computadoras conectadas en red (ya sea físicamente en el mismo lugar o distribuidas a lo largo de la red), lo que permite el acceso a los datos desde diferentes máquinas. Está manejada por el Sistema de Administración de Datos Distribuida (SABDD) O Sistema de Gestión de Base de Datos Distribuida. Son la evolución del cliente-servidor. La razón principal que hay tras las BDD es los organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder así a la información, sin tener todo centralizado en un solo punto.

1.7 Sistema manejador de base de datos (DBMS o SGBD)

Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar más a menudo las siglas DBMS procedentes del inglés, Data Base Management System) es el software que permite a los usuarios procesar, describir, administrar y recuperar los datos almacenados en una base de datos (Asenjo, 2009).

En estos sistemas se proporciona un conjunto coordinado de programas, procedimientos y lenguajes que permiten a los distintos usuarios realizar sus tareas habituales con los datos, garantizando además la seguridad de los mismos (Asenjo, 2009) véase Figura 7.

Figura 7. Funcionamiento de un DBMS

Fuente: (Asenjo, 2009)

Page 20: Indice tentativo (Autoguardado).docx

En la actualidad existe una gran cantidad demanejadores de datos, de los cuales algunos son más utilizados que otros, esto por las características o funciones que estos ofrecen, tratar de describir cada uno de ellos seria interminable, es por ello que a continuación solo se describirán, aquellos que son más populares o comerciales dentro de la sociedad véase Cuadro 3.

Cuadro 3. Manejadores de Bases de datos

DBMS o SGBD DescripciónMySQL MySQL es un sistema de administración de bases de datos

(Database Management System, DBMS) para bases de datos relacionales. Así, MySQL no es más que una aplicación que permite gestionar archivos llamados de bases de datos.Existen muchos tipos de bases de datos, desde un simple archivo hasta sistemas relacionales orientados a objetos. MySQL, como base de datos relacional, utiliza multiples tablas para almacenar y organizar la información. MySQL fue escrito en C y C++ y destaca por su gran adaptación a diferentes entornos de desarrollo, permitiendo su interactuación con los lenguajes de programación más utilizados como PHP, Perl y Java y su integración en distintos sistemas operativos.También es muy destacable, la condición de open source de MySQL, que hace que su utilización sea gratuita e incluso se pueda modificar con total libertad, pudiendo descargar su código fuente. Esto ha favorecido muy positivamente en su desarrollo y continuas actualizaciones, para hacer de MySQL una de las herramientas más utilizadas por los programadores orientados a Internet.

Microsoft Access Es un sistema de gestión de bases de datos incluido en el paquete de programas de Microsoft Office. Es igualmente un gestor de datos que recopila información relativa a un asunto o propósito particular, como el seguimiento de pedidos de clientes o el mantenimiento de una colección de música. Access es un completo y demandado programa informático en entornos de empresa, que permite la creación y gestión de bases de datos, así como su modificación, control y mantenimiento.

Microsoft SQL Server

Es un sistema para la gestión de bases de datos creado por Microsoft, el mismo se basa en el modelo relacional. SQL Server utiliza como lenguajes de consulta T-SQL y ANSI SQL.

Oracle Oracle la Primera Base de Datos Diseñada para Grid Computing, es un sistema de gestión de base de datos relacional fabricado por Oracle Corporation.Oracle es básicamente un herramienta cliente/servidor para la gestión de base de datos la gran potencia que tiene y su elevado precio hace que solo se vea en empresas muy grandes y multinacionales, por norma general.

IBM Informix Es un sistema de desarrollo de aplicaciones de bases de datos que proporciona la velocidad, potencia y seguridad necesarias para las aplicaciones grandes y pequeñas.

Sybase ASE Adaptive Server Enterprise (ASE) es el motor de bases de datos (RDBMS) insignia de la compañía Sybase. ASE es un sistema de

Page 21: Indice tentativo (Autoguardado).docx

gestión de datos, altamente escalable, de alto rendimiento, con soporte a grandes volúmenes de datos, transacciones y usuarios, y de bajo costo, que permite:

Almacenar datos de manera segura Tener acceso y procesar datos de manera inteligente Movilizar datos.

dBase Fue el primer sistema de gestión de base de datos usado ampliamente para microcomputadoras, publicado por Ashton-Tate para CP/M, y más tarde para Apple II, Apple Macintosh, UNIX , VMS , e IBM PC bajo DOS donde con su legendaria versión III Plus se convirtió en uno de los títulos de software más vendidos durante un buen número de años.

Firebird es un sistema de administración de base de datos relacional (o RDBMS) (Lenguaje consultas: SQL) de código abierto, basado en la versión 6 de Interbase, cuyo código fue liberado por Borland en 2000. Su código fue reescrito de C a C++. El proyecto se desarrolla activamente, el 18 de abril de 2008 fue liberada la versión 2.1 y el 26 de diciembre de 2009 fue liberada la versión 2.5.0 RC1. La versión 2.5.2, la más reciente del proyecto, fue liberada el 24 de Marzo de 2013.

Como se puede observar en el Cuadro 3. Existe una gran variedad de manejadores de datos de los cuales solo se hiso una versión resumida. Dejando en claro que estos son solo algunos de los muchos que hay alrededor del mundo.

1.8 Lenguaje de manipulación de datos (LMD)

Un lenguaje de manipulación de datos (Data ManipulationLanguage, o DML en inglés) es un lenguaje proporcionado por el sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de datos adecuado. El lenguaje de manipulación de datos más popular hoy día es SQL, usado para recuperar y manipular datos en una base de datos relacional(Gutierrez, 2010).

Otros ejemplos de DML son los usados por bases de datos IMS/DL1, CODASYL entre otras. Básicamente existen dos tipos de LMD estos son: los LMDs procedimentales que requieren que el usuario especifiqué que datos necesitan y como obtener esos datos y los LMDs declarativos que requieren que el usuario especifique que datos se necesitan sin especificar como obtenerlos.(Armenta y Gomez, 2007).

1.9 Lenguaje de definicion de datos (DDL)

Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado lenguaje de definicion de datos (LDD).

Un diccionario de datos contienen metadados, ees decir, datos acerca de datos. El esquema de unaa tabla pro ejemplo es un ejemplo de metadatos. Un sistema de base de datos consulta el diccionario de datos antes de leer o modificar los datos reales.

Fuente: Elaboración propia

Page 22: Indice tentativo (Autoguardado).docx

Especificamos el almacenamiento y los metodos de acceso usados por el sistema de base de datos por un conjunto de instrucciones en un tipo especial de LDD denominado lenguaje de almacenamiento y definicion de datos. Estas instrucciones defien los detalles de implementacion de los esquemas de base de datos, que se ocultan usualmente a los usuarios (Armenta y Gomez, 2007).

1.10 Seguridad en bases de datos

Es la capacidad dl sistema para proteger datos, servicios y recursos de usuarios no autorizados. El fin de la seguridad es garantizar la protección o estar libre de todo peligro o daño, y que en cierta manera es fiable. Para que una base de datos sea segura debe presentar 3 características esenciales las cuales describimos a continuación:

Confidencialidad: Nos dice que los objetos de un sistema han de ser accedidos únicamente por elementos autorizados a ello, y que esos elementos autorizados no van a convertir esa información en disponible para otras entidades.

Integridad: Significa que los objetos solo pueden ser modificados por elementos autorizados, y de una manera controlada.

Disponibilidad: Indica que los objetos del sistema tienen que permanecer accesibles a elementos autorizados; es el contrario de la negación del servicio.

1.10.1 Tipos de seguridad

Existen 3 tipos de seguridad al momento de desarrollar un elegir una base de datos los cuales se describen a continuación.

Seguridad lógica: Este nivel de seguridad implica mantener la integridad y consistencia de los datos en la base de datos cuando se realicen las operaciones de altas, bajas y modificaciones en la base de datos del sistema.

Seguridad física: Este nivel de seguridad implica mantener la integridad física de los archivos donde se almacena la base de datos y el log de transacciones, en el disco del servidor. Será implementado con procedimientos de resguardo, back-up, y restauración. Dichos procedimientos serán realizados periódicamente por el administrador de la aplicación.

Seguridad de acceso: Este nivel de seguridad implica restringir el acceso a los datos por parte de usuarios no autorizados. Será implementado tanto en la base de datos como en la aplicación. La administración de la seguridad se realiza con un módulo especialmente diseñado para esa tarea.

1.11 Modelo entidad-relación

El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo

Page 23: Indice tentativo (Autoguardado).docx

entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante representaciones gráficas y lingüísticas. Estos conceptos se muestran a continuación véase Figura 8.

Figura 8. Diagramas del modelo entidad-relación

Las tareas a realizar en el diseño conceptual son las siguientes:

1. Identificar las entidades.2. Identificar las relaciones.3. Identificar los atributos y asociarlos a entidades y relaciones.4. Determinar los dominios de los atributos.5. Determinar los identificadores.6. Determinar las jerarquías de generalización (si las hay).7. Dibujar el diagrama entidad-relación.8. Revisar el esquema conceptual local con el usuario (Marquez, 2011).

1.12 Normalización de bases de datos

La normalización es una técnica para diseñar la estructura lógica de losdatos de un sistema de información en el modelo relacional, desarrollada porE. F. Codd en 1972. Es una estrategia de diseño de abajo a arriba: se parte delos atributos y éstos se van agrupando en tablas según su afinidad. Aquí no seutilizará la normalización como una técnica de diseño de bases de datos, sinocomo una etapa posterior a la correspondencia entre el esquema conceptual yel esquema lógico, que elimine las dependencias entre atributos no deseadas (Marquez, 2011).

En la mayoría de las ocasiones, una base de datos completamente normalizadano proporciona la máxima eficiencia; sin embargo, el objetivo en estaetapa es conseguir una base de datos normalizada por las siguientes razones:

(Marquez, 2011)

Page 24: Indice tentativo (Autoguardado).docx

Un esquema normalizado organiza los datos de acuerdo a sus dependenciasfuncionales, es decir, de acuerdo a sus relaciones lógicas.

Un esquema normalizado es robusto y carece de redundancias, por loque está libre de ciertas anomalías que las redundancias pueden provocarcuando se actualiza la base de datos.

Los equipos informáticos de hoy en día son cada vez más potentes, por loque en ocasiones es más razonable implementar bases de datos fáciles demanejar (las normalizadas), a costa de un tiempo adicional de proceso.

La normalización produce bases de datos con esquemas flexibles que puedenextenderse con facilidad.

La normalización se lleva a cabo en una serie de pasos. Cada paso correspondea una forma normal que tiene unas propiedades. Conforme se va avanzandoen la normalización, las tablas tienen un formato más estricto (más fuerte) y,por lo tanto, son menos vulnerables a las anomalías de actualización. El modelorelacional sólo requiere un conjunto de tablas en primera forma normal(en caso contrario no se pueden implementar). Las restantes formas normalesson opcionales. Sin embargo, para evitar las anomalías de actualización, esrecomendable llegar al menos a la tercera forma normal (Marquez,2011)véase Cuadro 3.

Cuadro 3. Normas formales

Norma DescripciónPrimera forma normal Una tabla está en primera forma normal (1fn) si, y sólo si,

todos los dominiosde sus atributos contienen valores atómicos, es decir, no hay gruposrepetitivos. Un grupo repetitivo es un atributo que puede tener múltiples valorespara cada fila de la relación. Son los atributos que tienen forma de tabla.Si una tabla no está en 1fn, hay que eliminar de ella los grupos repetitivos.La forma de eliminar los grupos repetitivos consiste en poner cada uno deellos como una tabla aparte, heredando la clave primaria de la tabla en la quese encontraban.

Segunda forma normal Una tabla está en segunda forma normal (2fn) si, y sólo si, está en 1fn y,además, cada atributo que no forma parte de la clave primaria es completamentedependiente de la clave primaria.La 2fn se aplica a las tablas que tienen claves primarias compuestas pordos o más atributos. Si una tabla está en 1fn y su clave primaria es simple(tiene un solo atributo), entonces también está en 2fn.Para pasar una tabla en 1fn a 2fn hay que eliminar las dependenciasparciales de la clave primaria. Para ello, se eliminan los atributos que sonfuncionalmentedependientes y se ponen en una nueva tabla con una copia desu determinante. Su

Page 25: Indice tentativo (Autoguardado).docx

determinante estará formado por los atributos de la claveprimaria de los que depende.

Tercera forma normal Una tabla está en tercera forma normal (3fn) si, y sólo si, está en 2fn y,además, cada atributo que no forma parte de la clave primaria no dependetransitivamente de la clave primaria. La dependencia x −→ z es transitiva siexisten las dependencias x −→ y, y −→ z, siendo x, y, z atributos o conjuntosde atributos de una misma tabla.Para pasaruna relación en 2fn a 3fn hay que eliminar las dependencias transitivas. Paraello, se eliminan los atributos que dependen transitivamente y se ponen en unanueva relación con una copia de su determinante (el atributo o atributos noclave de los que depende).

Forma normal de Boyce-Codd

Una tabla está en la forma normal de Boyce-Codd (bcfn) si, y sólo si, tododeterminante es una clave candidata.La 2fn y la 3fn eliminan las dependencias parciales y las dependenciastransitivas de la clave primaria. Pero este tipo de dependencias todavía puedenexistir sobre otras claves candidatas, si éstas existen. La bcfn es más fuerte que la 3fn, por lo tanto, toda tabla en bcfn está en 3fn.

La violación de la bcfn es poco frecuente ya que se da bajo ciertas condicionesque raramente se presentan. Se debe comprobar si una tabla viola la bcfn en caso de tener dos o más claves candidatas compuestas que tienen almenos un atributo en común.

Cuarta forma normal Una relación se encuentra en la cuarta forma normal si está en BNFC y no tiene dependencias multivaluadas

Quinta forma normal Ocurre cuando una tabla está en 4FN y cada dependencia de unión (JOIN) en ella es implicada por las claves candidatas.Es la más compleja y polémica de todas. Polémica pues no está claro en muchas ocasiones está muy claro que el paso a 5FN mejore la base de datos. Fue definida también por Fagin.Es raro encontrarse este tipo de problemas cuando la normalización llega a 4FN. Se deben a restricciones semánticas especiales aplicadas sobre la tabla.

1.13 Definición de lenguajes de programación

Un lenguaje de programación es un convenio entre personas que puede definirse así:

Conjunto de reglas o normas que permiten asociar a cada programa correcto un cálculo que será llevado a cabo por un ordenador (sin ambigüedades).

Por tanto, un lenguaje de programación es un convenio o acuerdo acerca de cómo se debe de interpretar el significado de los programas de dicho lenguaje muchas veces se confunden los lenguajes con los compiladores, interpretes o con los entornos de desarrollo de software (Almagro, 2012).

Fuente: Elaboración propia

Page 26: Indice tentativo (Autoguardado).docx

Actualmente los lenguajes de programación pueden dividirse de la siguiente manera:Los lenguajes declarativos son los más parecidos al castellano o inglés en su potencia expresiva y funcionalidad y están en el nivel más alto respecto a los otros. Son fundamentalmente lenguajes de órdenes, dominados por sentencias que expresan “lo que hay que hacer” en vez de “cómo hacerlo”.

Los lenguajes de alto nivel son los más utilizados como lenguajes de programación. Aunque no son fundamentalmente declarativos, estos lenguajes permiten que los algoritmos se expresen en un nivel y estilo de escritura fácilmente legible y comprensible por otros programadores. Además, los lenguajes de alto nivel suelen tener la característica de “transportabilidad”. Es decir, están implementados sobre varias máquinas, de forma que un programa puede ser fácilmente “transportado” (transferido) de una máquina a otra sin una revisión sustancial. En este sentido, se llaman “independientes de la máquina”.

Los lenguajes ensambladores y los lenguajes máquina son dependientes de la máquina. Cada tipo de máquina tiene su propio lenguaje máquina distinto y su lenguaje ensamblador asociado. El lenguaje ensamblador es simplemente una representación simbólica del lenguaje máquina asociado, lo cual permite una programación menos tediosa que con el anterior

1.13.1 Tipos de lenguajes de programación

A continuación en el siguiente cuadro se presenta una versión resumida de los lenguajes de programación más importantes en el mundo véase Cuadro 4.

Lenguaje DescripciónPascal Fue claramente diseñado para servir como un lenguaje para

enseñar diseño de algoritmos y metodología de programación. Como el ALGOL, PASCAL ha jugado un papel único como el principal lenguaje usado para publicar algoritmos en las revistas y libros. A pesar de sus fuertes mejoras sobre ALGOL, -especialmente en el área de entrada-salida, archivos, registros, gestión dinámica de memoria y estructuras de control- PASCAL también fue cuestionado por sus deficiencias, y por ello se propusieron sucesores importantes como algunos de los que describimos a continuación.

Fortran El miembro original de la familia, FORTRAN I, nació en 1.954, y fue implementado sobre la computadora IBM 704 en 1.956. Dos años más tarde, apareció FORTRAN II. Entre 1.958 y 1.963, FORTRAN se implementó sobre varias computadoras. FORTRAN III fue desarrollado durante este período, pero debido a que contenía demasiadas características dependientes de la máquina, nunca se implementó para uso público. En 1.962 FORTRAN IV fue desarrollado para las computadoras IBM 7090/7094. En 1.966 se estandarizaron las distintas versiones en dos únicas: la “Basic FORTRAN” y “FORTRAN”.

Cobol (Common Bussiness Oriented Language) A finales de 1.950, se sintió la necesidad de un lenguaje de procesamiento de datos. En mayo de 1.959, los representantes de los fabricantes de

Page 27: Indice tentativo (Autoguardado).docx

computadoras y de los usuarios de la industria y gobierno, se reunieron para formar el Comité CODASYL (Conference on Data Systems Languages), y se desarrolló una descripción de tal lenguaje, cuya revisión, en 1.960, empezó a conocerse como COBOL-60. Numerosas extensiones fueron formando nuevas versiones de este lenguaje COBOL inicial, hasta aprobarse un estándar en 1.974 por la ANS (American National Standard).

PROLOG (Programming in Logic) Se diseñó principalmente para las aplicaciones de inteligencia artificial, definiendo objetos y relaciones de inferencia entre clases de objetos. Tiene unos fuertes fundamentos teóricos en el cálculo de proposiciones. Representaba una desviación tajante de las ideas tradicionales sobre comportamiento de programas, las cuales se basaban todas en las arquitecturas de máquina de von Neumann. PROLOG fue desarrollado a principios de los años 70 por Philippe Roussel. Su primer intérprete se implementó en 1.972. Desde entonces, PROLOG no cambió desde su concepción, ni se hizo ningún esfuerzo por estandarizarlo.

C y C++ C evolucionó a partir de dos lenguajes previos, BCPL y B. BCPL fue desarrollado en 1.967 por Martin Richards, como un lenguaje para escribir software y compiladores de sistemas operativos. En el lenguaje B, muchas características de BCPL fueron modeladas y se utilizó para crear versiones iniciales de lo que se llegó a denominar UNIX. Ambos lenguajes, BCPL y B eran lenguajes “sin tipo”. Cada elemento de datos ocupaba una palabra en memoria y quedaba a cargo del programador el tratar un elemento de datos como si se tratara de un número entero o de un número real. El lenguaje C fue derivado de B por Dennis Ritchie de los Laboratorios Bell, implantándose por primera vez en 1.972. C al inicio se popularizó como lenguaje de desarrollo del sistema operativo UNIX. Hoy día, virtualmente todos los sistemas están escritos en C y/o C++.

DELPHI En el año 1995 se crea el nuevo sucesor de Pascal, al que se llamó Delphi, siendo la primera herramienta con un entorno de desarrollo visual construida por Borland. Esta caracterizado por ser un lenguaje orientado a eventos, es decir, que la ejecución del programa no es secuencial, sino que depende de los eventos que suceden durante la ejecución de la aplicación.Delphi es una herramienta de Desarrollo Rápido de Aplicaciones (RAD). Los componentes que incorpora facilitan el acceso a bases de datos, comunicación a través de Internet, calidad en impresiones, desarrollo de aplicaciones multimedia, enlaces DDE, componentes OLE y VBX, etc.Borland ha introducido al mercado varias versiones de Delphi, aportando mejoras notables, entre las que cabe destacar el CodeInsight, un asistente que muestra automáticamente las listas de parámetros de procedimientos, métodos y eventos.

JAVA Este lenguaje, hoy en día ampliamente utilizado en Internet, fue desarrollado en 1990 por James Gosling , de Sun Microsystems, basándose en C y C++. ¿Un lenguaje para Internet cuando, en aquella época, la Red estaba casi circunscrita al ámbito

Page 28: Indice tentativo (Autoguardado).docx

universitario?En realidad, el objetivo de Sun no tenía nada que ver con Internet; era crear un interfaz atractivo e intuitivo para electrónica de consumo (calculadoras, televisión interactiva, etc.).Sin embargo, la electrónica de consumo no evolución ó como se esperaba y, durante unos años, el lenguaje de Gosling permaneció aparcado, hasta que Bill Joy (cofundador de Sun) consideró que podía ser interesante para Internet y propuso modificarlo para el nuevo medio. En agosto de 1995, ya con el nombre de JAVA, se presentó en sociedad.A pesar de que JAVA resulta un tanto lento en su ejecución, cada día es más popular. Por un lado, es relativamente sencillo y bastante potente; además, es válido para cualquier plataforma y, sobre todo, muy fiable y seguro, manteniendo alejado a los virus.

Basic BASIC es la abreviación de Beginners All-purpose Symbolic Instruction Code. Basic fue desarrollado en la Universidad de Dartmouth en 1964 bajo la dirección de J. Kemeny y T. Kurtz. Surgió como un idioma simple de aprender y fácil de traducir. En los 70´s, cuando se creó la computadora personal Altair, Bill Gates y Paul Allen implementaron su propia versión de Basic en dicha computadora. Con ello comenzó el futuro de BASIC y de la PC. En ese tiempo, Gates era estudiante de Harvard y Allen era un empleado de Honeywell. La versión BASIC de Gates ocupaba un total de 4KB de memoria incluyendo el código y los datos que se usaron para el código fuente. Luego Gates implementó BASIC en otras plataformas (Apple, Comodor y Atari) y fue a partir de entonces que la corporación de Microsoft empezó su reinado en el mundo de las PC. Más tarde en los 70’s, surgió el sistema operativo MS-DOS de Bill Gates que incluía un intérprete de BASIC. La versión distribuida con MS-DOS era GW-BASIC y podía ser ejecutada en cualquier máquina que pudiera ejecutar DOS.

Fuente: Elaboración propia

Como se puede observar en el cuadro anterior, existen muchos leguajes de programación, cada uno de ellos con sus propias estructuras e instrucciones, pero con el objetivo en común de resolver algún problema.

Page 29: Indice tentativo (Autoguardado).docx

Capitulo II Analisis de factibilidad y requerimentos

Estudio de factibilidad

2.1 Factibilidad técnica

La factibilidad técnica consistió en realizar una evaluación de la tecnología existente en el Centro Universitario UAEM Temascaltepec, esto con la finalidad de recolectar información sobre los componentes técnicos que posee el CUT y la posibilidad de hacer uso de los mismos para el desarrollo e implementación del sistema propuesto y de ser necesario adquirir los requerimientos tecnológicos para el desarrollo e implementación del sistema propuesto.

De acuerdo a la tecnología necesaria para la implementación del Sistema de Registro y Control Automatizado de Protocolos y titulaciones del Centro Universitario UAEM Temascaltepec, se analizo sobre dos enfoques: Hardware y Software, los cuales se describe a continuación.

2.1.1 Hardware

En cuanto a Hardware, específicamente se requiere una computadora donde se instalara el sistema propuesto y una impresora para la impresión de reportes y oficios.

Evaluando el hardware existente y tomando en cuenta los requisitos mínimos del sistema, el Centro Universitario UAEM Temascaltepec, no requerirá realizar una inversión inicial para la adquisición de equipos, ya que de acuerdo al estudio realizado los equipos con los que actualmente cuenta el CUT satisfacen los requerimientos establecidos tanto para el desarrollo como para la implementación del sistema propuesto, además cabe mencionar que actualmente estos componentes de hardware se encuentra en el mercado a un bajo costo.

En el siguiente cuadro se muestra la descripción del hardware disponible en el Centro Universitario UAEM Temascaltepec y que será utilizado para el desarrollo e

Page 30: Indice tentativo (Autoguardado).docx

implementación del Sistema de Registro y Control Automatizado de Protocolos y titulaciones.

Hardware disponible

Cantidad Descripción2 HP - Motherboard INTEL, Procesador Intel Core i5 2400

CPU 3.10 Ghz, 4 Gb. de RAM, Tarjeta de video, Disco duro 500 Gb., Tarjeta Ethernet, Monito LCD, Teclado, Mouse, DVD-Rewritable.

1 HP - Motherboard INTEL, Procesador INTEL Pentium CPU 6630 @ 2.70 Ghz., 4 Gb. de RAM, Tarjeta de video, Disco duro 500 Gb, Tarjeta Ethernet, Monito LCD, Teclado, Mouse, DVD-Rewritable.

3 Lenovo - Motherboard INTEL, Procesador INTEL CORE™2 duo CPU E7500 @ 2.93 Ghz., 4 Gb. de RAM, Tarjeta de video, Disco duro 500 Gb, Tarjeta Ethernet, Monito LCD, Teclado, Mouse, DVD-Rewritable.

6 Impresoras (HP, Epson y Brother)

Fuente: Elaboración propia

2.1.2 Software

En cuanto a software las tecnologias nercesarias para el desarrollo e implementacion del sistema de registro de protocolos y tiulaciones, las podemos dividir en las siguientes areas:

Sistema operativo Base de datos Desarrollo Procesadores de textos

Cabe mencionar que para cada una de estas áreas, se han definido varias propuestas y alternativas que actualmente se encuentran disponibles en el mercado aun costo considerable y que son apropiadas para el desarrollo e implementación del sistema, también cabe destacar que el CUT actualmente ya cuenta con algunas licencias de software que podrían utilizarse.

A continuación para tener una idea mas clara sobre la disponibilidad y el tipo de software que se desea adquirir se muestra la siguiente tabla.

Tabla 1. Tipo de software

Área Alternativas Disponibilidad Licencia CUTSistema operativo Windows 7

Windows 8ComercialComercial

SiSi

Page 31: Indice tentativo (Autoguardado).docx

Base de datos SQLMYSQLAccess

ComercialLibreComercial

NoNoSi

Desarrollo Microsoft Visual 6Microsoft Visual .NET 2010Microsoft Visual .NET 2012Microsoft NetFramework 3.5

ComercialComercialComercialLibre

SiSiSiNo

Procesador de texto Microsoft Office 2007Microsoft Office 2010Open Office

ComercialComercialLibre

SiSiNo

Ademas de contar con la infraestrutura tecnologica necesaria, los desarrolladores del sistema tienen los conocimientos necesarios para utilizar las alternativas de software y hardware mencionadas anteriormente.

Como resultado del estudio técnico se determino que, el Centro Universitario UAEM Temascaltepec actualmente posee la infraestructura tecnológica (hardware y software) y los conocimientos tecnicos para el desarrollo e implementación del sistema de Registro y control automatizado de protocolos y titulaciones, por lo que se logra concluir que el sistema es factible tecnicamente

2.2 Factibilidad operativa

La necesidad de un sistema que permitiera llevar un control de registro de protocolos y titulaciones del Centro Universitario UAEM Temascaltepec, expresada por profesores, alumnos y coordinadores de las diferentes licenciaturas, obliga al desarrollo de un sistema que permita de una manera sencilla y amigable, cubrir todos sus requerimientos, expectativas y proporcionar la información en forma oportuna y confiable a sus usuarios. Todo esto basándonos en conversaciones y entrevistas sostenidas con el personal del Centro Universitario UAEM Temascaltepec, donde se demostró que estos no representan ninguna oposición a la implementación de dicho sistema.

Con la finalidad de garantizar el funcionamiento del sistema propuesto, y que este impactara en forma positiva a los usuarios “coordinador” fue desarrollado con una interfaz amigable , lo que lo convierte en una herramienta de fácil manejo y comprensión, que no requiere de personal especializado para su funcionamiento. Una vez implantado el sistema, los recursos humanos de las coordinaciones utilizaran el sistema en una forma comoda, segura y eficaz, ya que contaran con un sistema que agilize su trabajo. Por lo que se puede concluir que el sistema es factible operacionalmente.

Page 32: Indice tentativo (Autoguardado).docx

Plan de Actividades

Letra Actividad Tiempo en días AntecedeA Elegir tema de tesis 5B Análisis de bibliografía 10C Realización de protocolo 30D Registro de protocolo 5E Desarrollo del primer capitulo 15F Análisis de bibliografía 15G Correcciones del primer capitulo 5H Desarrollo del segundo capitulo 15I Análisis de bibliografía 15J Correcciones del Segundo capitulo 5K Desarrollo del tercer capitulo 20L Análisis de bibliografía 20M Diseño de cuestionario de estudio de factibilidad 2N Revisión del cuestionario de estudio de factibilidad 1O Aplicación de cuestionarios de estudio de factibilidad 4P Entrevista con coordinadores 4Q Entrevista con directivos 2R Entrevista con encargado de TICS 1S Análisis de cuestionarios de estudio de factibilidad 1T Redacción de análisis de factibilidad 3

Page 33: Indice tentativo (Autoguardado).docx

U Elaboración de plan de actividades 2W Elaboración de ruta critica 1V Corrección del tercer capitulo 5X Desarrollo del cuarto capitulo 25Y Análisis de bibliografía 10Z Análisis de requerimientos 5AA Modelado del sistema (UML) 20BB Elaboración de diagrama de clases 2CC Elaboración de diagrama de objetos 4DD Elaboración de diagrama de estados 5EE Elaboración de diagrama de actividades 5FF Elaboración de diagrama de secuencias 5GG Elaboración de diagrama de colaboración 5HH Elaboración de diagrama de componentes 2II Elaboración de diagrama de despliegue 2JJ Elaboración de diagrama de paquetes 2KK Elaboración de diagrama de casos de uso 20LL Elaboración de diagrama de comunicación 2MM Elaboración de diagrama de tiempos 2NN Elaboración de diagrama global de interacciones 2OO Corrección del cuarto capitulo 5PP Desarrollo del quinto capitulo 20QQ Diseño de interfaces 10RR Programación de interfaces 20SS Testeo de interfaces 10TT Elaboración de manual de usuario 8UU Elaboración de manual técnico 8

Page 34: Indice tentativo (Autoguardado).docx

Especificación de requisitos de software

Proyecto: Registro automático de protocolos y titulaciones del Centro Universitario UAEM Temascaltepec

Marzo 2014

Page 35: Indice tentativo (Autoguardado).docx

Ficha del documento

Fecha Revisión Autor Verificado dep. calidad.

05/03/2014 Rafael Rigoberto López Orozco

Documento validado por las partes en fecha: 5 Marzo 2014.

Por el cliente Por la empresa suministradora

Centro Universitario UAEM Temascaltepec C. Rafael Rigoberto López Orozco

Page 36: Indice tentativo (Autoguardado).docx

Contenido

FICHA DEL DOCUMENTO 35

CONTENIDO 36

1 INTRODUCCIÓN 38

1.1 Propósito 38

1.2 Alcance 38

1.3 Personal involucrado 38

1.4 Definiciones, acrónimos y abreviaturas 38

1.5 Referencias 39

1.6 Resumen 39

2 DESCRIPCIÓN GENERAL 39

2.1 Perspectiva del producto 39

2.2 Funcionalidad del producto 39

2.3 Características de los usuarios 39

2.4 Restricciones 40

2.5 Suposiciones y dependencias 40

2.6 Evolución previsible del sistema 40

3 REQUISITOS ESPECÍFICOS 40

3.1 Requisitos comunes de los interfaces 443.1.1 Interfaces de usuario 443.1.2 Interfaces de hardware 443.1.3 Interfaces de software 44

3.2 Requisitos funcionales 453.2.1 Requisito funcional 1 453.2.2 Requisito funcional 2 453.2.3 Requisito funcional 3 463.2.4 Requisito funcional 4 463.2.5 Requisito funcional 5 463.2.6 Requisito funcional 6 463.2.7 Requisito funcional 7 46

3.3 Requisitos no funcionales 47

Page 37: Indice tentativo (Autoguardado).docx

3.3.1 Requisitos de rendimiento 473.3.2 Seguridad 473.3.3 Fiabilidad 473.3.4 Disponibilidad 473.3.5 Mantenibilidad 473.3.6 Portabilidad 47

Page 38: Indice tentativo (Autoguardado).docx

1 IntroducciónEste documento es una Especificación de Requisitos Software (ERS) para el Sistema de registro automático de protocolos y titulaciones del Centro Universitario UAEM Temascaltepec. Esta especificación se ha estructurado basándose en las directrices dadas por el estándar IEEE Práctica Recomendada para Especificaciones de Requisitos Software ANSI/IEEE 830.

1.1 PropósitoEl presente documento tiene como propósito definir las especificaciones funcionales, no funcionales para el desarrollo de un sistema de registro automático de protocolos y titulaciones del Centro Universitario UAEM Temascaltepec. Éste será utilizado por estudiantes, profesores y coordinadores del CUT.

1.2 AlcanceEsta especificación de requisitos está dirigida al usuario del sistema, para continuar con el desarrollo de aplicaciones para la institución y para profundizar en la automatización de ésta, la cual tiene por objetivo principal el gestionar los distintos procesos administrativos (registro de protocolos, titulaciones, inventarios, etc.) y académicos.

1.3 Personal involucrado

Nombre Rafael Rigoberto López OrozcoRol Analista, diseñador y programadorCategoría profesional LicenciaturaResponsabilidades Análisis de la información, diseño y programación de swInformación de contacto [email protected]

Nombre Rafael Valentín Mendoza MéndezRol RevisorCategoría profesional Ma. en TI.Responsabilidades Revisión de aplicaciónInformación de contacto 1234556789

Nombre Gisela Regina Bahena CastroRol RevisorCategoría profesional Ma. En TI.Responsabilidades Revisión de aplicaciónInformación de contacto 3456780945

1.4 Definiciones, acrónimos y abreviaturas

Nombre Descripción

Usuario Persona que usará el sistema para gestionar procesos

CUT Centro Universitario UAEM Temascaltepec

Page 39: Indice tentativo (Autoguardado).docx

ERS Especificación de Requisitos Software

RF Requerimiento Funcional

RNF Requerimiento No Funcional

SW Software

HW Hardware

UAEM Universidad Autónoma del Estado de México

1.5 Referencias

Titulo del Documento Referencia

Standard IEEE 830 - 1998 IEEE

1.6 ResumenEste documento consta de tres secciones. En la primera sección se realiza una introducción al mismo y se proporciona una visión general de la especificación de recursos del sistema.

En la segunda sección del documento se realiza una descripción general del sistema, con el fin de conocer las principales funciones que éste debe realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles.

Por último, la tercera sección del documento es aquella en la que se definen detalladamente los requisitos que debe satisfacer el sistema.

2 Descripción general

2.1 Perspectiva del producto

El sistema de registro automático de protocolos y titulaciones será un producto diseñado para trabajar en una interfaz amigable fácil de utilizar, lo que permitirá su utilización de forma rápida y eficaz.

2.2 Funcionalidad del producto

Page 40: Indice tentativo (Autoguardado).docx

2.3 Características de los usuariosTipo de usuario CoordinadorFormación UniversitarioActividades Control y manejo del sistema general

Tipo de usuario AlumnoFormación PreparatoriaActividades Captura de datos, consultar información

Tipo de usuario ProfesorFormación UniversitariaActividades Consultar información contenida en el sistema, facilitar

proceso de aprendizaje

2.4 Restricciones

Interfaz para ser usada en plataforma Windows 7 o superior. Lenguajes y tecnologías en uso: Visual. NET, Netframework 3.5. El sistema deberá tener un diseño e implementación sencilla, independiente de la

plataforma o del lenguaje de programación. Base de datos en Access

2.5 Suposiciones y dependencias Se asume que los requisitos aquí descritos son estables Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos

antes indicados para garantizar una ejecución correcta

2.6 Evolución previsible del sistemaEl sistema de registro automático de protocolos y titulaciones después de ser implementado en las coordinaciones del Centro Universitario UAEM Temascaltepec, tendera hacer una herramienta de vital importancia para el almacenamiento de información, lo cual lo obliga a que después de cierto tiempo el sistema tenga que ser migrado aun sistema de cliente servidor, al cual se pueda accesar desde cualquier punto para realizar ciertas consultas.

3 Requisitos específicos

Requisitos funcionales

Identificación del requerimiento:

RF01

Nombre del Requerimiento:

Autentificación de Usuario.

Descripción del requerimiento:

Los usuarios deberán identificarse para acceder al sistema

Requerimiento NO funcional:

RNF01 RNF02 RNF05 RNF08

Prioridad del requerimiento:

Page 41: Indice tentativo (Autoguardado).docx

Alta

Identificación del requerimiento:

RF02

Nombre del Requerimiento:

Alta registros

Descripción del requerimiento:

El sistema permitirá al usuario (estudiante, docente y coordinador) dar de alta registros (Alumnos, maestros, protocolos)

Requerimiento NO funcional:

RNF01 RNF02 RNF05 RNF08

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RF03

Nombre del Requerimiento:

Modificar registros

Descripción del requerimiento:

El sistema permitirá al usuario (estudiante, docente y coordinador) modificar registros de la base de datos (Alumnos, maestros, protocolos y titulaciones)

Requerimiento NO funcional:

RNF01 RNF02 RNF05 RNF08

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RF04

Nombre del Requerimiento:

Eliminar registros

Descripción del requerimiento:

El sistema permitirá al usuario (estudiante, docente y coordinador) dar de baja registros de la base de datos (Alumnos, Maestros, Protocolos y titulaciones)

Requerimiento NO funcional:

RNF01 RNF02 RNF05 RNF08

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RF05

Nombre del Requerimiento:

Consultar información

Descripción del requerimiento:

El sistema permitirá al usuario (estudiante, docente y Administrador) consultar información de los directores de tesis

Requerimiento RNF01

Page 42: Indice tentativo (Autoguardado).docx

NO funcional: RNF02Prioridad del requerimiento:Alta

Identificación del requerimiento:

RF06

Nombre del Requerimiento:

Gestionar Reportes

Descripción del requerimiento:

Permite al administrador imprimir todos los oficios que tengan que ver con el registro de protocolo y titulación

Requerimiento NO funcional:

RNF01 RNF02

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RF07

Nombre del Requerimiento:

Backcup

Descripción del requerimiento:

El sistema permitirá hacer respaldos automáticamente o cuando se le indique

Requerimiento NO funcional:

RNF01 RNF02

Prioridad del requerimiento:Alta

Requerimientos No Funcionales.

Identificación del requerimiento:

RNF01

Nombre del Requerimiento:

Interfaz del sistema.

Características: El sistema presentara una interfaz de usuario sencilla para que sea de fácil manejo a los usuarios del sistema.

Descripción del requerimiento:

El sistema debe tener una interfaz de uso intuitiva y sencilla.

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF02

Page 43: Indice tentativo (Autoguardado).docx

Nombre del Requerimiento:

Ayuda en el uso del sistema.

Descripción del requerimiento:

La interfaz del usuario deberá de presentar un sistema de ayuda para que los mismos usuarios del sistema se les faciliten el trabajo en cuanto al manejo del sistema.

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF03

Nombre del Requerimiento:

Mantenimiento.

Descripción del requerimiento:

El sistema deberá de tener un manual de instalación y manual de usuario para facilitar los mantenimientos que serán realizados por el administrador.

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF04

Nombre del Requerimiento:

Diseño de la interfaz

Descripción del requerimiento:

El sistema deberá de tener una interfaz de usuario, teniendo en cuenta los colores institucionales.

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF05

Nombre del Requerimiento:

Desempeño

Descripción del requerimiento:

El sistema garantizara a los usuarios un desempeño en cuanto a los datos almacenado en el sistema ofreciéndole una confiabilidad a esta misma.

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF06

Nombre del Requerimiento:

Nivel de Usuario

Descripción del requerimiento:

Garantizara al usuario el acceso de información de acuerdo al nivel que

Page 44: Indice tentativo (Autoguardado).docx

posee.

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF07

Nombre del Requerimiento:

Confiabilidad continúa del sistema.

Descripción del requerimiento:

El sistema tendrá que estar en funcionamiento siempre que se le requiera

Prioridad del requerimiento:Alta

Identificación del requerimiento:

RNF08

Nombre del Requerimiento:

Seguridad en información

Descripción del requerimiento:

El sistema garantizara a los usuarios una seguridad en cuanto a la información que se procede en el sistema.

Prioridad del requerimiento:Alta

3.1 Requisitos comunes de los interfaces

3.1.1 Interfaces de usuarioLa interfaz con el usuario consistirá en un conjunto de ventanas con botones, listas y campos de textos con colores institucionales. Ésta deberá ser construida específicamente para el sistema propuesto y, será visualizada desde una computadora .

3.1.2 Interfaces de hardwareSerá necesario disponer de equipos de cómputos en perfecto estado con las siguientes características:

Procesador de 1.66GHz o superior Memoria mínima de 1 gb Disco duro 160 gb Mouse Teclado Impresora

3.1.3 Interfaces de software Sistema Operativo: Windows 7 o superior. Netframework 3.5 o superior Microsoft office 2007 o superior

Page 45: Indice tentativo (Autoguardado).docx

3.2 Requisitos funcionales

3.2.1 Requisito funcional 1

Autentificación de Usuarios: los usuarios deberán identificarse para acceder a cualquier parte del sistema.

El sistema podrá ser consultado por cualquier usuario dependiendo del módulo en el cual se encuentre y su nivel de accesibilidad.

3.2.2 Requisito funcional 2

Consultar Información: El sistema ofrecerá al usuario información general acerca del proceso de registro de protocolo y titulaciones, así como consultas de temas e índices de titulación.

Consulta de registro de protocolo. El sistema podrá consultar si el alumno ya registro algún protocolo

Consulta titulación. El sistema deberá consultar si el alumno ya se encuentra titulado o en proceso

Consulta tema de protocolo. El sistema podrá consultar si el tema ya se encuentra registrado pro otro alumno

Consulta generación. El sistema permitirá consultar los alumnos que ya registraron su protocolo por generación

Consulta por sexo. El sistema permitirá consultar cuantos hombres y mujeres han registrado protocolo

Consulta por fecha. El sistema permitirá consultar aquellos protocolos registrados por rangos de fechas

Consulta alumnos. El sistema permitirá verificar que algún alumno se encuentre dado de alta en el sistema

Consulta maestro. El sistema permitirá verificar que maestros se encuentras dados de alta en el sistema

Consulta director de tesis. El sistema permitirá verificar cuantas veces ha sido director de tesis un maestro

Consulta asesor de tesis. El sistema permitirá verificar cuantas veces ha sido asesor de tesis un maestro

Consulta titulaciones. El sistema permitirá consultar cuantos alumnos se han titulado por generación

Consulta titulación por sexo. El sistema permitirá consultar cuantos hombres y mujeres se han titulado

Page 46: Indice tentativo (Autoguardado).docx

Consultar titulaciones por fecha. El sistema permitirá consultar titulaciones en un rango de fechas.

Consultar alumnos por modalidad de titulación. El sistema permitirá consultar que alumnos se han titulado por alguna modalidad de titulación.

3.2.3 Requisito funcional 3

Modificar usuarios: los usuarios de acuerdo a su nivel de accesos podrán modificar datos como datos de alumno, profesores, protocolos y titulaciones.

3.2.4 Requisito funcional 4

Alta registros: los usuarios de acuerdo a su nivel de accesos podrán ingresar nuevos registros a la base de datos, como datos de alumnos, profesores, protocolos y titulaciones.

3.2.5 Requisito funcional 5

Eliminar registros: los usuarios de acuerdo a su nivel de accesos podrán eliminar registros a la base de datos, como datos de alumnos, profesores, protocolos y titulaciones.

3.2.6 Requisito funcional 6 Generar reportes: los usuarios de acuerdo a su nivel de accesos podrán

generar reportes del proceso de registro de protocolo y titulación.

Generar anexos f1 y f2 Generar nombramientos de director y asesor Generar oficios de comisión de revisores de protocolo Generar oficios de cumplimiento de revisión de protocolo Generar oficio de registro de protocolo Generar oficios de alta y baja de protocolo Generar oficios de revisión de tesis Generar oficios de impresión de tesis Generar oficios de asignación de sinodales Generar oficios de cumplimiento de revisor de tesis Generar oficio de palabras de titulación Generar graficas de las consultas Generar formatos llenos con leyenda de cada año

3.2.7 Requisito funcional 7

Backcup: El sistema podrá generar automáticamente y manualmente respaldo de la base de datos

Page 47: Indice tentativo (Autoguardado).docx

3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento Garantizar que el diseño de las consultas u otro proceso no afecte el

desempeño de la base de datos.

3.3.2 Seguridad Garantizar la confiabilidad, la seguridad y el desempeño del sistema

informático a los diferentes usuarios. En este sentido la información almacenada o registros realizados podrán ser consultados y actualizados permanente, sin que se afecte el tiempo de respuesta.

Garantizar la seguridad del sistema con respecto a la información y datos que se manejan tales sean documentos, archivos y contraseñas.

Facilidades y controles para permitir el acceso a la información al personal autorizado a través de Internet, con la intención de consultar y subir información pertinente para cada una de ellas.

3.3.3 Fiabilidad El sistema debe tener una interfaz de uso intuitiva y sencilla

La interfaz de usuario debe ajustarse a las características institucionales.

3.3.4 Disponibilidad La disponibilidad del sistema debe ser continua, garantizando un esquema

adecuado que permita la posible falla en cualquiera de sus componentes, contar con una contingencia, generación de alarmas o mensajes.

3.3.5 Mantenibilidad El sistema debe disponer de una documentación fácilmente actualizable que

permita realizar operaciones de mantenimiento con el menor esfuerzo posible

La interfaz debe estar complementada con un buen sistema de ayuda (la administración puede recaer en personal con poca experiencia en el uso de aplicaciones informáticas).

3.3.6 Portabilidad El sistema será implantado bajo la plataforma de Windows 7 o superior.

Page 48: Indice tentativo (Autoguardado).docx

Capítulo III Modelado de aplicación para el registro automático de protocolos y titulaciones

1.1 Modelo entidad relación

Fuente: Elaboración propia

Page 49: Indice tentativo (Autoguardado).docx

1.2 Diagrama de clases

Fuente: Elaboración de datos

Fuente: Elaboración propia

Page 50: Indice tentativo (Autoguardado).docx

1.3 Diagrama de casos de uso

1.3.1 Coordinador

Fuente: Elaboración propia

1.3.2 Alumno

Fuente: Elaboración propia

Page 51: Indice tentativo (Autoguardado).docx

1.3.3 Maestros

Fuente: Elaboración propia

1.3.4 Control escolar

Fuente: Elaboración propia

1.4 Casos de uso

REFERENCIA CASO DE USO: CASO DE USO – 00 ENCENDER COMPUTADORA

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es)

Descripción CoordinadorPrecondiciones N/A

Post-condiciones N/A

Page 52: Indice tentativo (Autoguardado).docx

Referencia cruzada N/AACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAPresionar el botón de encendido.

FALLO POSIBLE SOLUCIÓNEquipo Dañado Reparación o sustitución de Equipo.

REFERENCIA CASODE USO: CASO DE USO - 01 INGRESAR AL SISTEMA

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Coordinador, Sistema

Descripción El coordinador puede ingresar al sistema insertando su nombre de usuario y contraseña.

Precondiciones Caso 00.Post-condiciones N/A

Referencia cruzada N/AACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMACoordinador El sistema Valida la conexión

FALLO POSIBLE SOLUCIÓNContraseña incorrecta.Usuario Incorrecto.

Mostrar: “Ingresar Datos correctos”.Verificar Contraseña y nombre de Usuario.

REFERENCIA CASODE USO: CASO DE USO - 02 VALIDAR USUARIO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Sistema

Descripción Verificar que el login y password ingresado por el coordinador sea correctoPrecondiciones Caso 00, 01.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAN/A El sistema Valida la información.

FALLO POSIBLE SOLUCIÓNDatos de Usuario no válidos.

Mostrar: “Ingresar Datos correctos”.Verificar Datos.

REFERENCIA CASODE USO: CASO DE USO - 03 AGREGAR ALUMNO, MAESTRO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Coordinador

Descripción Permite al coordinador dar de alta registrosPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

Page 53: Indice tentativo (Autoguardado).docx

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador agrega un nuevo registro

Actualización en Base de datos.

FALLO POSIBLE SOLUCIÓNEL número de cuenta ya fue dado de altaEl RFC debe contar con 13 dígitosEl número de cuenta está incompletoNúmero de teléfono incompleto

Mostrar: “Inserte otro número de cuenta”Mostrar: “RFC incompleto”Mostrar:” Numero ce cuenta incompleto favor de verificarlo”Mostrar: “El número de teléfono debe contar con 10 dígitos”

REFERENCIA CASODE USO: CASO DE USO - 04

AGREGAR PROTOCOLO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Coordinador

Descripción Permite al coordinador registrar un protocolo al alumnoPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador inserta el registro

El registro ha sido dado de alta

FALLO POSIBLE SOLUCIÓNEl número de cuenta no existeEl protocolo esta duplicadoRevisores duplicados

Mostrar: “Desea dar del ata el número de cuenta”Mostrar:” Este protocolo ya ha sido dado de alta”Mostrar:” No puede hacer revisores duplicados”

REFERENCIA CASODE USO: CASO DE USO - 05 ELIMINAR ALUMNOS, MAESTROS, PROTOCOLOS

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Coordinador

Descripción Permite al coordinador eliminar registrosPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl Administrador selecciona el registro a eliminar

Actualización en Base de datos.

FALLO POSIBLE SOLUCIÓNEl registro no existe Mostrar: “Ingresar Datos correctos”.

Verificar Datos.REFERENCIA CASODE

USO: CASO DE USO - 06 ACTUALIZAR ALUMNOS, MAESTROS, PROTOCOLOS

NIVEL Alto _X_ Medio_ _ Bajo__

Page 54: Indice tentativo (Autoguardado).docx

Actor(es) CoordinadorDescripción Permite al coordinador realizar modificaciones a los registros

Precondiciones Caso 00, 01, 02.Post-condiciones N/A

Referencia cruzada N/AACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador busca el registro a modificar

Actualización en Base de datos.

FALLO POSIBLE SOLUCIÓNEl registro no existeDatos incorrectos o duplicados

Mostrar: “Ingresar Datos correctos”.Verificar Datos.

REFERENCIA CASODE USO: CASO DE USO - 07 BUSCAR ALUMNOS, MAESTROS, PROTOCOLOS

NIVEL Alto __ Medio_X _ Bajo__Actor(es) Coordinador

Descripción Permite al coordinador realizar consultas de los registros almacenadosPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEL coordinador inserta el nombre que quiere buscar

El sistema realiza la búsqueda en la base de datos

FALLO POSIBLE SOLUCIÓNEl registro no existe Envía un mensaje “El registro no existe”

REFERENCIA CASODE USO: CASO DE USO - 08 IMPRIMIR REPORTES

NIVEL Alto __ Medio_X_ Bajo__Actor(es) Coordinador

Descripción Permite al coordinador imprimir reportes según los criterios de búsqueda que el elija

Precondiciones Caso 00, 01, 02.Post-condiciones N/A

Referencia cruzada N/AACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador manda imprimir un reporte

Manda a vista previa el resultado del reporte y le pregunta si lo desea imprimir

FALLO POSIBLE SOLUCIÓNNo hay registros en base de datosNo imprime

No se encuentra ningún registro con ese criterio de búsquedaVerificar que la impresora este instalado o encendida

REFERENCIA CASODE USO: CASO DE USO - 09 ASIGANCION DE COMITÉ REVISOR

Page 55: Indice tentativo (Autoguardado).docx

NIVEL Alto __ Medio_X_ Bajo__Actor(es) Coordiandor

Descripción Se asigna a los maestro que van a revisar el protocoloPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador designa comité revisor e imprime los oficios

Inserte el RFC de los maestros revisoresImprime los oficios

FALLO POSIBLE SOLUCIÓNRFC Duplicado Un maestro no puede ser revisor 2 veces en un mismo protocolo

REFERENCIA CASODE USO: CASO DE USO - 10 ASIGANCION DE JURADO

NIVEL Alto __ Medio_X_ Bajo__Actor(es) Coordinador

Descripción Se asigna a los maestros que van hacer jurado en la titulaciónPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador designa el jurado e imprime los oficios de comisión

Inserte el RFC de los maestros del juradoImprime los oficios

FALLO POSIBLE SOLUCIÓNRFC Duplicado Un maestro no puede ser revisor 2 veces en un mismo protocolo

REFERENCIA CASODE USO: CASO DE USO - 11

REVISION DE PROTOCOLO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Maestro

Descripción El maestro revisa protocolo del alumnoPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl maestro revisa el protocolo

Firma de visto bueno

FALLO POSIBLE SOLUCIÓNRealizar correcciones de protocolo

El maestro no firma de visto bueno

REFERENCIA CASODE USO: CASO DE USO - 12

REGISTRO PROTOCOLO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Alumno

Descripción El alumno asiste con el coordinador a registrar su protocoloPrecondiciones Caso 00, 01, 02.

Page 56: Indice tentativo (Autoguardado).docx

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador registra el protocolo

Protocolo registrado

FALLO POSIBLE SOLUCIÓNTema duplicadoEl número de cuenta no existe

Mostrar “El protocolo ya fue registrado”Mostrar” Desea dar de alta el número de cuenta”

REFERENCIA CASODE USO: CASO DE USO - 13

BUSCAR PROTOCOLO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Alumno

Descripción El alumno verifica que el nombre del tema no existaPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAAlumno inserta nombre del tema

Mostrar “Este tema no se encuentra registrado”

FALLO POSIBLE SOLUCIÓNTema duplicado Mostrar “El protocolo ya fue registrado”

REFERENCIA CASODE USO: CASO DE USO - 14

REGISTRO PROTOCOLO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Alumno

Descripción El alumno asiste con el coordinador a registrar su protocoloPrecondiciones Caso 00, 01, 02.

Post-condiciones N/AReferencia cruzada N/A

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAEl coordinador registra el protocolo

Protocolo registrado

FALLO POSIBLE SOLUCIÓNTema duplicadoEl número de cuenta no existe

Mostrar “El protocolo ya fue registrado”Mostrar” Desea dar de alta el número de cuenta”

REFERENCIA CASODE USO: CASO DE USO - 11

MODIFICAR USUARIO

NIVEL Alto _X_ Medio_ _ Bajo__Actor(es) Bibliotecario, Administrador.

Descripción Permite al Administrador o Bibliotecario realizar cambios o agregar informaciónpersonal, por ejemplo, teléfono, dirección, fotos y también cambiar su contraseña y privilegios.

Precondiciones Caso 00, 01, 02.Post-condiciones N/A

Referencia cruzada N/A

Page 57: Indice tentativo (Autoguardado).docx

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMAAdministrador o Bibliotecario actualiza los datos del Usuario.

Actualización de Usuario en la base de datos.

FALLO POSIBLE SOLUCIÓNDatos no correctos. Mostrar: “Ingresar Datos correctos”.