Carrera: Licenciatura en Ciencias de la Computación V año V Jornada Universitaria de Desarrollo Científico Titulo: Sistema de control de matricula del colegio San pablo Elaborado por: Br: Franklin Ramón Mendoza Salazar Tutora: Sonia Rojas Fargas. 12 de octubre del 2007
Índice Contenido Páginas Resumen----------------------------------------------------------3 Tema---------------------------------------------------------------4 Introducción ------------------------------------------------------5 Justificación-------------------------------------------------------6 Objetivos-----------------------------------------------------------7 Antecedentes-----------------------------------------------------8-9 Marco teórico-----------------------------------------------------10-35 Preguntas directrices------------------------------------------36 Diseño metodológico------------------------------------------37 Resultados-------------------------------------------------------38 Análisis y discusión de los resultado----------------------39 Conclusiones----------------------------------------------------40 Recomendaciones---------------------------------------------41 Bibliografía-------------------------------------------------------42 Anexos------------------------------------------------------------43-65 1. Estudios de factibilidad 2. Diagrama de flujo de datos 3. Diagrama E/R 4. Diagrama de entidad relación en Access 5. Diagrama de dialogo 6. Manual de usuario
Resumen Los lenguajes de programación visuales como Fox Pro, permiten realizar sistemas.el colegio San pablo siendo un centro de educación para estudiantes de: Preescolar, primaria y secundaria que lleva un control manual de matricula que le provoca problemas de organización de la información almacenamiento; El sistema de control de matricula resuelve los problemas al crear un diseño eficaz y sencillo.los catálogos como Estudiante, Centro de estudios, recibos, ocupación de los padres y ubicación permiten decepcionar los datos de entradas en el sistema de, los procesos que realiza: Efectuar recibo y matricula.las pantallas de salida del sistema permiten generar matricula y recibo de acuerdo al establecido por el colegio de esta manera soluciona los problemas que la secretaria tenia que lidiar antes de que existiera el sistema. Autor: Franklin Ramón Mendoza Salazar 3
Tema: Sistema de control de Matricula del colegio san pablo Autor: Franklin Ramón Mendoza Salazar 4
INTRODUCCIÓN El Colegio San Pablo fue fundado en el año de 1961, en la Ciudad de Juigalpa. Desde su instauración como centro de enseñanza, constaba con tres tipos de modalidades: preescolar, primaria y secundaria. La matricula estudiantil del presente año asciende a 515 alumnos. A pesar que, desde hace ya algún tiempo, la institución cuenta con un Laboratorio de Informática, el registro de matriculas, de periodicidad anual, se continua llevando de manera manual. El Colegio San Pablo realiza su registro de matricula de manera manual. El control manual constituye una serie de problemas al no haber un modo de evitar los errores producto de la redacción manual, ni poder impedir la ilegibilidad de la escritura de la persona encargada de llevar dicho control. Además, la información tiende a acumularse hasta convertir el registro en una tarea tediosa, sin mencionar que los archivos se acumulan incrementando el espacio necesario para su almacenamiento. Esta investigación se propone plantear una solución tentativa a dicho problema a través de un prototipo de sistema automatizado para el control de matricula del Colegio San Pablo de la ciudad de Juigalpa. El uso de un sistema automatizado evitará la acumulación de documentación y agilizará el proceso de matricula. Autor: Franklin Ramón Mendoza Salazar 5
JUSTIFICACIÓN Esta investigación, y el prototipo de sistema que de ella se derive, constituyen un beneficio para el Colegio San Pablo y, más específicamente, para el personal que labora en el área de secretaría. Con la propuesta de prototipo se pretende agilizar el registro de matriculas y la realización de consultas e informes, a la ves se optimizara la atención durante el proceso de matricula. Facilitar la administración del registro de matriculas en el sentido de poder localizar un determinado dato a modificar o eliminar en el momento que se requiera. Autor: Franklin Ramón Mendoza Salazar 6
Objetivos Objetivo General Diseñar un prototipo de sistema para control de matricula del colegio san pablo de la ciudad de juigalpa, año 2007. Objetivos específicos 1. Realizar el control de matrícula y recibo del colegio san pablo 2. proporcionar un mejor almacenamiento de los recibos de los estudiantes en el proceso de matrícula 3. Controlar los registros de estudiantes y de matricula Autor: Franklin Ramón Mendoza Salazar 7
ANTECEDENTES La escuela san pablo, fue fundada en la ciudad de Juigalpa en 1961, desde su fundación desarrollo tres modalidades de clases: preescolar, primaria, secundaria. El numero de estudiantes inscritos desde el 2006 al 2007 disminuyo en un 3% de 592 estudiantes a 515. Cuentan con laboratorio de informática que es utilizado para dar clases de Microsoft office no para el registro de matricula, se ven en la necesidad de guardar la información por medio de registro manual, implica una problemática de respuesta inmediata en secretaria en el día de matricula. Los registros manuales en los cuales anotan los datos personales de cada uno de los estudiantes nuevo y de reingreso ;así como también los requisitos que el colegio les solicita a los estudiantes y el pago de matricula reflejado en el control financiero del colegio. Los problemas que ocasiona son: Confusión al llevar el control de estudiantes Pago de matricula en un año que no correspondía Llenado de datos de un estudiante que no correspondía Problema en el control financiero por no reflejar pago de matricula Pago de matricula no sustentado con recibo Anteriormente, ya se había realizado una propuesta de sistema con la tentativa de que fuera utilizado para la administración del registro de matriculas Autor: Franklin Ramón Mendoza Salazar 8
Dicha propuesta no paso de ser una solución tentativa ya que quedo inconclusa por lo tanto no se implemento. Además, los requisitos del colegio han cambiado significativamente. La importancia del colegio san pablo por medio del control de la información de los estudiantes son : documentos de matricula y recibos, hace necesario resolver las dificultades como: Equivocación al momento de llenar los datos del estudiante, perdida de algún recibo de un estudiante que pago matricula, reclamos de estudiantes matriculados, esto se presenta en el proceso manual de matricula que ocasiona poco aprovechamiento del tiempo y una atención lenta, es necesario llevar el almacenamiento de la información automáticamente. Las tecnologías computarizadas ofrecen la estrategia de mantener la información en orden, llevar un mejor control y proporcionar integridad en los datos; se hace necesario análisis y diseño de un sistema de control de matricula, para que responda a la problemática actual y facilite :El acceso y almacenamiento de la información en el colegio San Pablo de esta manera los usuarios ahorran tiempo y trabajo evitando perdida de la información; lo que causaría problemas al estudiante y al colegio. Autor: Franklin Ramón Mendoza Salazar 9
MARCO TEÓRICO Prototipo de sistema de control de matricula del colegio san pablo Sistema Un sistema es un conjunto de elementos organizados que interactúan entre sí y con su ambiente, para lograr objetivos comunes, operando sobre información, sobre energía o materia u organismos para producir como salida información o energía o materia u organismos. Un sistema aislado no intercambia ni materia ni energía con el medio ambiente. (es.wikipedia.org/wiki/sistema) Sistemas de información Un sistema de información puede definirse técnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución Análisis y diseño de sistemas El análisis y diseño de sistema analiza sistemáticamente la entrada de datos y el flujo de datos, el proceso de datos, almacenamiento de datos y la salida de información dentro de un contexto particular. Además el diseño y análisis de sistemas se usa para analizar, diseñar e implementar mejoras en el funcionamiento de los negocios que puedan hacer uso de los sistemas de información computarizados. Ciclo de vida Según kendall & kendall Pág. 10-13 análisis y diseño de sistemas (sexta edición).el análisis y diseño de sistema de información es enfoque se incluye en el ciclo de vida del desarrollo de sistemas [SDLC. Systems Development Life Cycle (Ciclo de Vida del Desarrollo sistema)]. de SDLC es un enfoque por fases para el análisis y diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especificote actividades del analista y el usuario. Autor: Franklin Ramón Mendoza Salazar 10
Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el ciclo de vida del desarrollo del sistema, pero en general alaban su enfoque organizado. Aquí hemos dividido el ciclo en siete fases como se aprecia en la figura. A pesar que cada fase se explica por separado. Fases del ciclo de vida del desarrollo de sistema 1 Identificación de problemas Oportunidades y objetivos. 2 Determinación de los requerimientos de información 3 Análisis de las necesidades del sistema 7 Implementación y evaluación del sistema 6 Pruebas y mantenimiento del sistema 5 Desarrollo y documentación del software 4 Diseño del sistema recomendado 1. Identificación de problema, oportunidades y objetivos La primera fase requiere que el analista observe objetivamente lo que sucede en el negocio. A continuación, en conjunto con otros miembros de la organización, el analista determina con precisión cuales son los problemas. Con frecuencia los problemas son detectados por alguien más, y esta es la razón de la llamada inicial al analista. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados. Autor: Franklin Ramón Mendoza Salazar 11
El aprovechamiento de las oportunidades podría permitir a la empresa obtener una ventaja competitiva o establecer un estándar para la industria. La identificación de objetivos también es una parte importante de la primera fase. En primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A continuación, podrá determinar si algunas funciones de las aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase consiste en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos. A continuación, la administración debe decidir si se sigue adelante con el proyecto propuesto. Si el grupo de usuarios no cuenta con fondos suficientes, si desea atacar problemas distintos, o si la solución a estos problemas no amerita un sistema de cómputo, se podría sugerir una solución diferente y el proyecto de sistema se cancelaría. 2. Determinación de los requerimientos de información La siguiente fase que enfrenta el analista es la determinación de requerimientos de información de los usuarios. Entre las herramientas que utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios, métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos de oficina, al igual que métodos de amplio alcance como la elaboración de prototipos. Autor: Franklin Ramón Mendoza Salazar 12
En la frase de determinación de requerimientos de información, el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Como puede ver, varios de los métodos para determinar los requerimientos de información implica interactuar directamente con los usuarios. Esta fase es útil para que el analista confirma la idea que tiene de la organización y sus objetivos. En ocasiones sólo realizan las dos primeras fases del ciclo de vida del desarrollo de sistema. Esta clase de estudio podría tener un propósito distinto y por lo general la lleva a la práctica un especialista conocido como analista de información. Los implicados en esta fase son el analista y los usuarios, por lo general trabajadores y gerentes del área de operaciones. El analista de sistema necesita conocer los detalles de las funciones del sistema actual: el quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuando (el momento oportuno) y el como (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. A continuación el analista debe preguntar la razón por la cual se utiliza el sistema actual. Podría haber buenas razones para realizar los negocios con los métodos actuales, y es importante tomarlas en cuenta al diseñar el nuevo sistema. Sin embargo, si la razón de ser de las operaciones actuales es que siempre se ha hecho de esta manera, quizá será necesario que el analista mejore los procedimientos. Análisis de las necesidades del sistema La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesidades del sistema. De nueva cuenta, herramientas y técnicas especiales auxilian al analista en la determinación de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma grafica estructurada. A partir de los diagramas de flujo de datos se Autor: Franklin Ramón Mendoza Salazar 13
desarrolla un diccionario de datos que en lista todos los datos utilizados en el sistema, así como sus respectivas especificaciones. Durante esta fase el analista de sistema analiza también las decisiones estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden determinar las condiciones, las alternativas de condición, las acciones y las reglas de acción. Existen tres métodos principales para el análisis de decisiones estructurada: español estructurado, talas y árboles de decisión. En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. Si la administración de la empresa considera factible alguna de las recomendaciones, el analista sigue adelante. Cada problema de sistema es único, y nunca existe solo una solución correcta. La manera de formular una recomendación o solución depende de las cualidades y la preparación profesional de cada analista. 3. Diseño del sistema recomendado El analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos. Además, el analista facilita la entrada eficiente de datos al sistema de información mediante técnicas adecuadas de diseño de formularios y pantallas. La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. Entre los ejemplos de interfaz de usuario se encuentra el teclado (para teclear preguntas y respuestas), los menús de pantalla (para Autor: Franklin Ramón Mendoza Salazar 14
obtener los comandos de usuario) y diversas interfaces gráficas de usuario que se manejan a través de un ratón o de una pantalla sensible al tacto. La fase de diseño también incluye el diseño de archivos o base de datos que almacenan en gran parte de los datos indispensables para los encargados de tomar decisiones en la organización. Una base de datos bien organizada es el cimiento de cualquier sistema de información. En esta fase el analista también interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. Finalmente, el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos, producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procedimiento; también podría incluir árboles o tablas de decisión, diagramas de flujo de datos, un diagrama de flujo de sistema, y los nombres y funciones de cualquier rutina de código previamente escrita. 4. Desarrollo y documentación del software En la quinta fase del ciclo de vida del desarrollo de sistema, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructura, los diagramas de Nassi- Shneiderman y el pseudocódigo. El analista se vale de una o más de estas herramientas para comunicar al programador lo que se requiere programar. Durante esta fase el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos. La documentación indica a los usuarios como utilizar el software y que deben hacer en caso de que surjan problemas derivados de este uso.los programadores desempeñan un rol clave en esta fase por que diseñan, codifican y eliminan errores sintácticos de los programas de cómputo. Para garantizar la Autor: Franklin Ramón Mendoza Salazar 15
calidad, un programador podrá efectuar un repaso estructurado del diseño y del código con el propósito de explicar las partes complejas del programa y de otro equipo de programadores. 5. Prueba y mantenimiento del sistema Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. El mantenimiento del sistema de información y su documentación a través de diagramas de UML empieza en esta fase y se lleva a cabo de manera rutinaria durante toda la vida útil. Gran parte del trabajo habitual del programador consiste en el mantenimiento, y las empresas invierten enormes sumas de dinero en esta actividad. Parte del manteniendo, como las actualizaciones de programas, se pueden realizar de manera automática a través de un sitio Web. Muchos de los procedimientos sistemáticos que el analista emplea durante el ciclo de vida del desarrollo de sistemas pueden contribuir a garantizar que el mantenimiento se mantendrá al mínimo. 6. Implementación y evaluación del sistema El analista participa en la implementación del sistema de implementación. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas. El analista tiene que plantear una conversión gradual del sistema anterior al actual. Este proceso incluye la conversión de los archivos de formatos anteriores a los nuevos, o la construcción de una base de datos, la instalación de equipos y la puesta en producción del nuevo sistema.se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principal mente en hora de debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. Autor: Franklin Ramón Mendoza Salazar 16
Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigido el sistema lo están utilizando realmente.debe hacerse hincapié en que, con frecuencia, el trabajo de sistemas es cíclico. Modelo de construcción del prototipo La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información específica acerca de los requerimientos de información de los usuarios. Hablando en términos generales, los prototipos efectivos deben hacerse tempranamente en el siclo de vida del desarrollo de sistema, durante la fase de determinación de requerimientos, es una técnica compleja que requiere el conocimiento del ciclo de vida del desarrollo completo antes de que pueda ser lograda satisfactoriamente las reacciones son recopiladas por medio de observaciones, entrevistas y formas de retroalimentación. Reacciones del usuario Innovaciones Sugerencia del usuario Planes de revisión Reacciones del usuario: las reacciones son recopiladas por medio de observaciones, entrevistas y formas de retroalimentación diseñadas para recoger la opinión de cada persona acerca del prototipo cuando interactúa con el. Por medio de tales reacciones de usuarios, el analista descubre muchas perspectivas en el prototipo. Sugerencia del usuario: el analista esta interesado en la sugerencia de los usuarios y la administración acerca de cómo refinar o cambiar el prototipo Autor: Franklin Ramón Mendoza Salazar 17
presentado. Las sugerencias obtenidas de los usuarios deben apuntar al analista hacia formas de refinación, cambio o limpieza del prototipo para que se ejecute mejor alas nesecidades de los usuarios. Innovaciones: las innovaciones para el prototipo son partes de la información buscada por el equipo de análisis del sistema, son capacidades nuevas del sistema que no habían sido pensada antes de la interacción con el prototipo van más allá de las características prototípicas actuales añadiendo algo nuevo e innovador. Planes de revisión: los prototipos son una visión preliminar del sistema futuro. Los planes de revisión ayudan ha identificar prioridades para los que se debe construir un prototipo a continuación la información recolectada en la fase de hechura del prototipo permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mínimo de ruptura debido a esto la elaboración de prototipos y la planeación van mano a mano. Ventajas de la elaboración de los prototipos: Existe el potencial para hacer cambios en el sistema en las primeras etapas de su desarrollo. Existen oportunidades para detener el desarrollo de un sistema que no es funcional. Puede atacar nesecidades de usuario y expectativas más de cerca. Desventajas de la elaboración de los prototipos: Es difícil manejar la elaboración de prototipos como un proyecto dentro de un esfuerzo de sistema más grande. Los usuarios y analistas pueden adoptar a un prototipo como un sistema terminado cuando es inadecuado. Diagramas de flujo de datos Autor: Franklin Ramón Mendoza Salazar 18
Concepto Es una representación grafica que permite al analista definir entradas, procedimientos y salidas de la información en la organización bajo estudio, permitiendo así comprender los procedimientos existentes con la finalidad de optimizarlos reflejándolos en el sistema propuesto. Ventajas del enfoque del flujo de datos El enfoque de flujo de datos posee Cuatro ventajas principales sobre las explicaciones descriptivas en relación con la forma en que los datos se mueven a través del sistema: 1. Libertad para emprender la implementación técnica del sistema en las etapas tempranas. 2. Una comprensión más profunda de la interrelación entre sistema y subsistema. 3. Comunicar a los usuarios el conocimiento sobre el sistema actual mediante diagramas e flujo de datos. 4. Análisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. Simbologías En los diagramas de flujo de datos se usan cuatro símbolos básicos para graficar el movimiento de los datos: un cuadro doble, una fecha, un rectángulo con esquinas redondeadas y un rectángulo abierto (cerrado al lado izquierdo y abierto en el derecho). Con la combinación de estos cuatro símbolos se puede describir gráficamente un sistema completo y varios subsistemas. Autor: Franklin Ramón Mendoza Salazar 19
Entidad Estudiante 2.1 Proceso Crear registro de estudiante Nueva información del estudiante Flujo de datos Almacén de datos D3 Archivo maestro del estudiante Normalización La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas) según su afinidad. Aquí no se utilizará la normalización como una técnica de diseño de bases de datos, sino como una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la normalización son las siguientes: Evita anomalías en inserciones, Autor: Franklin Ramón Mendoza Salazar 20
modificaciones y borrados. Mejora la independencia de datos. No establece restricciones artificiales en la estructura de los datos. Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una dependencia funcional es una relación entre atributos de una misma relación (tabla). Si e son atributos de la relación, se dice que es funcionalmente dependiente de (se denota por ) si cada valor de tiene asociado un solo valor de ( e pueden constar de uno o varios atributos). A se le denomina determinante, ya que determina el valor de. Se dice que el atributo es completamente dependiente de si depende funcionalmente de y no depende de ningún subconjunto de. La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, más bien, los modelos mentales del usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada dependencia funcional es una clase especial de regla de integridad y representa una relación de uno a muchos. En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple, la relación se debe descomponer en varias relaciones que sí la cumplan. La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de relaciones en primera forma normal. Las Autor: Franklin Ramón Mendoza Salazar 21
restantes formas normales son opcionales. Pero es recomendable llegar al menos a la tercera forma normal. Primera forma normal (1FN) Una relación está en primera forma normal si, y sólo si, todos los dominios de la misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la relación gráficamente como una tabla, estará en 1FN si tiene un solo valor en la intersección de cada fila con cada columna. Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla de la relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas redundancias se eliminarán después mediante las restantes formas normales Segunda forma normal (2FN) Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo que no está en la clave primaria es completamente dependiente de la clave primaria. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Las relaciones que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones. Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en una nueva relación con una copia de su determinante (los atributos de la clave primaria de los que dependen). Tercera forma normal (3FN) Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, cada atributo que no está en la clave primaria no depende transitivamente de la clave primaria. La dependencia es transitiva si existen las dependencias Autor: Franklin Ramón Mendoza Salazar 22
,, siendo,, atributos o conjuntos de atributos de una misma relación. Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una relación de 2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se eliminan los atributos que dependen transitivamente y se ponen en una nueva relación con una copia de su determinante (el atributo o atributos no clave de los que dependen). Forma normal de Boyce-Codd (BCFN) Una relación está en la forma normal de Boyce-Codd si, y sólo si, todo determinante es una clave candidata. La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La BCFN es más fuerte que la 3FN, por lo tanto, toda relación en BCFN está en 3FN. (http://es.wikipedia.org) Diccionario de datos. Contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño. Razones para su utilización: 1. Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas más chicos hay gran cantidad de datos. Autor: Franklin Ramón Mendoza Salazar 23
Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles. Por eso se registra la información, ya sea sobre hoja de papel o usando procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseñados específicamente para el análisis y diseño de software. 2. Para asignarle un solo significado a cada uno de los elementos y actividades del sistema. Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema y registrando detalles adicionales relacionados con el flujo de datos en el sistema, de tal manera que todo pueda localizarse con rapidez. 3. Para documentar las características del sistema, incluyendo partes o componentes así como los aspectos que los distinguen. También es necesario saber bajo que circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren. Produciendo una comprensión más completa. Una vez que las características están articuladas y registradas, todos los participantes en el proyecto tendrán una fuente común de información con respecto al sistema. 4. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema. Determina si son necesarias nuevas características o si están en orden los cambios de cualquier tipo. 5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un informe. Aun en los manuales, se revelan errores. Contenido de un registro del diccionario Autor: Franklin Ramón Mendoza Salazar 24
El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los elementos datos y estructura de datos. Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si mismos no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos. Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema. Cada uno esta identificado con: Un nombre: para distinguir un dato de otro. Descripción: indica lo que representa en el sistema. Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso este dato. Longitud: porque es de importancia de saber la cantidad de espacio necesario para cada dato. Valores de los datos: porque en algunos procesos solo son permitidos valores muy específicos para los datos. Si los valores de los datos están restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario. Estructura de datos: es un grupo de datos que están relacionados con otros y que en conjunto describen un componente del sistema. Descripción: Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes combinaciones ya sea individualmente o en conjunción con alguna otra. Relación secuencial: define los componentes que siempre se incluyen en una estructura de datos. Relación de selección: (uno u otro), define las alternativas para datos o estructuras de datos incluidos en una estructura de datos. Autor: Franklin Ramón Mendoza Salazar 25
Relación de iteración: (repetitiva), define la repetición de un componente. Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteración. (http://www.monografias.com) Estudios de Factibilidad: En general los análisis de factibilidad más profundos, o los estudios de factibilidad, se completan durante la fase de diseño de sistemas, en general durante la consideración de la evaluación de las diferentes alternativas de solución propuestas. Los estudios de factibilidad consideran la factibilidad técnica, económica y operacional de cada alternativa, así como si el proyecto es o no apropiado dados los factores políticos y otros del contexto institucional. Factibilidad Técnica: El análisis de factibilidad técnica evalúa si el equipo y software están disponibles (o, en el caso del software, si puede desarrollarse) y si tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté considerando. Los estudios de factibilidad técnica también consideran las interfases entre los sistemas actuales y nuevos. Por ejemplo, los componentes que tienen diferentes especificaciones de circuito no pueden interconectarse, y los programas de software no pueden pasar datos a otros programas si tienen diferentes formatos en los datos o sistemas de codificación; tales componentes y programas no son compatibles técnicamente. Sin embargo, puede hacerse una interfase entre los sistemas no compatibles mediante la emulación, la cual son circuitos diseñados para hacer que los componentes sean compatibles, o por medio de la simulación, que es un programa de cómputo que establece compatibilidad, pero con frecuencia estas formas de factibilidad técnica no están disponibles o son demasiado costosas. Autor: Franklin Ramón Mendoza Salazar 26
Factibilidad operacional: Esta factibilidad comprende una determinación de la probabilidad de que un nuevo sistema se use como se supone. Deberían considerarse cuatro aspectos de la factibilidad operacional por lo menos. Primero, un nuevo sistema puede ser demasiado complejo para los usuarios de la organización o los operadores del sistema. Segundo, un sistema puede hacer que los usuarios se resistan a él como consecuencia de una técnica de trabajo, miedo a ser desplazados, intereses en el sistema antiguo u otras razones. Para cada alternativa debe explorarse con cuidado la posibilidad de resistirse al cambio al nuevo sistema. Tercero, un nuevo sistema puede introducir cambios demasiado rápido para permitir al personal adaptarse a él y aceptarlo. Un cambio repentino que se ha anunciado, explicado y vendido a los usuarios con anterioridad puede crear resistencia. Sin importar qué tan atractivo pueda ser un sistema en su aspecto económico si la factibilidad operacional indica que tal vez los usuarios no aceptarán el sistema o que uso resultará en muchos errores o en una baja en la moral, el sistema no debe implantarse. Una última consideración es la probabilidad de la obsolescencia subsecuente en ele sistema. La tecnología que ha sido anunciada pero que aún no está disponible puede ser preferible a la tecnología que se encuentra en una o más de las alternativas que se están comparando, o cambios anticipados en las practicas o políticas administrativas pueden hacerse que un nuevo sistema sea obsoleto muy pronto. En cualquier caso, la implantación de la alternativa en consideración se convierte en impráctica. Factibilidad Económica: Los estudios de factibilidad económica incluyen análisis de costos y beneficios asociados con cada alternativa del proyecto. Con análisis de costos/beneficio, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se hace una comparación de ellos. Autor: Franklin Ramón Mendoza Salazar 27
Primero se comparan os costos esperados de cada alternativa con los beneficios esperados para asegurarse que los beneficios excedan a los costos. Después la proporción costo/beneficio de cada alternativa se compara con las proporcionan costo/beneficio de las otras alternativas para identificar la alternativa que sea más atractiva e su aspecto económico. Una tercera comparación, por lo general implícita, se relaciona con las formas en que la organización podría gastar su dinero de modo que no fuera en un proyecto de sistemas. Los costos de implementación incluyen comúnmente el costo remanente de la investigación de sistemas (ara este propósito, los costos en los que ya se ha incurrido no son relevantes), los costos de hardware y software, los costos de operación del sistema para su vida útil esperada, y los costos de mano de obra, material, energía, reparaciones y mantenimiento. A través del análisis de costo/beneficio, la organización debe apoyarse en los conceptos tradicionales de análisis financiero y las herramientas como teoría del valor presente, análisis de costos diferenciales y análisis de flujos descontados. Diagramas de UML UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto. Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visión dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase de diseño de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento. El diagrama de Autor: Franklin Ramón Mendoza Salazar 28
clases continua siendo muy importante, pero se debe tener en cuenta que su representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes ni de sincronización o recuperación ante estados de error. En resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien. UML también intenta solucionar el problema de propiedad de código que se da con los desarrolladores, al implementar un lenguaje de modelado común para todos los desarrollos se crea una documentación también común, que cualquier desarrollador con conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para el desarrollo. Diagrama de casos de uso. Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. Por ello es un buen sistema de documentar partes del código que deban ser reutilizables por otros desarrolladores. El diagrama también puede ser utilizado para que los expertos de dominio se comuniquen con los informáticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto. En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas: Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros casos de uso. Sus relaciones son: Autor: Franklin Ramón Mendoza Salazar 29
Incluye: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso. Extiende: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A Generalización: Es la típica relación de herencia. Actores: se representan por un muñeco. Sus relaciones son: Comunicar: Comunica un actor con un caso de uso, o con otro actor. Parte del sistema: Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman. (http://usuarios.lycos.es/oopere/uml.htm) Diagrama de dialogo Un diagrama de dialogo es la representación en forma general de cómo estará compuesto el sistema indicando la trayectoria que se debe de seguir para trabajar con cada uno de los módulos que lo componen. Base de datos Dato Un dato es la unidad o cantidad mínima de información no elaborada, sin sentido en sí misma, pero que convenientemente tratada se puede utilizar en la realización de cálculos o toma de decisiones. Es de empleo muy común en el ámbito informático. (http://es.wikipedia.org/wiki/dato) Base de datos Autor: Franklin Ramón Mendoza Salazar 30
Una colección compartida de datos lógicamente relacionados, junto con una descripción de estos datos, que están diseñados satisfacer las necesidades de información de una organización. Una base de datos es un repositorio centralizado posiblemente de gran tamaño, compuesto por datos que pueden ser utilizados simultáneamente por múltiples departamentos y usuarios. En lugar de disponer de una serie de archivos desconectados con datos redundantes, todos los elementos de datos están integrados, manteniéndose al mínimo de posibles duplicaciones. (Sistemas de bases de datos, 4ª.ed. Thomas M. Connlly Pág.14) Sistema de gestión de base de datos (SGBD) El SGBD es el software que interactúa con los programas de aplicación del usuario y con la base de datos. Normalmente, un SGBD proporciona la siguiente funcionalidad: Permite a los usuarios definir la base de datos, usualmente un lenguaje de definición de datos (DDL, Data Definición Language). El DDL permite a lo usuarios especificar la estructura y tipos de datos y las restricciones aplicables a los datos que hay que almacenar en la base de datos. Permite a los usuarios insertar, actualizar, borrar y extraer datos de la base de datos usualmente mediante un lenguaje de manipulación de datos. (DML, Data Manipulation Language) Proporciona un acceso controlado a la base de datos. (Sistemas de bases de datos, 4ª.ed. Thomas M. Connlly, Pág.15) Microsoft Office Access 2003 Microsoft Office Access es el SGBD relacional mas ampliamente utilizado por los entornaos Microsoft Windows. Se trata de un SGBD típico básico en PC capaz de almacenar, ordenar y extraer datos para una gran diversidad de aplicaciones. Access proporciona una interfaz gráfica de usuario (GUI, Graphical User Interface) para crear tablas, consultas, formularios o informes, así como Autor: Franklin Ramón Mendoza Salazar 31
herramientas para desarrollar aplicaciones personalizadas de bases de datos utilizando el lenguaje de macros de Microsoft Office Access o el lenguaje de Microsoft Visual Basic for Applications (VBA). Office Access proporciona una serie de programas, denominados asistentes, para simplificar muchos de los procesos de diseño de una aplicación de base de datos, llevando al usuario a través de una serie de cuadros de dialogo de tipo pregunta-respuesta. También proporciona generadores para ayudar a cada usuario a construir expresiones sintácticamente correctas, como por ejemplo las que se requieren en las instrucciones SQL. Objetos El usuario que interactúa con Microsoft Access y desarrolla aplicaciones de base de datos utiliza diversos objetos. Tablas. Las tablas base que formulan la base de datos. Utilizando la terminología Microsoft, una tabla esta organizada en columnas (denominadas campos) y filas (denominadas registros). Consultas. Permite al usuario ver, modificar y analizar los datos de distintas maneras. Las consultas también pueden almacenarse y utilizarse como origen de registro para formularios, informes y páginas de acceso de datos. Formularios. Pueden utilizarse para diverso propósitos, como por ejemplo crear formularios de introducción de datos para añadir información a una tabla. Informes. Permite presentar los datos de la base de datos de una manera efectiva, en un formato impreso personalizado (http://www.monografias.com). Ciclo de vida del desarrollo de sistema de base de datos Como los sistemas de base de datos son un componente fundamental de los sistemas de información corporativos, el ciclo de vida del desarrollo de sistema de Autor: Franklin Ramón Mendoza Salazar 32
base de datos esta relativamente asociado con el de los propios sistemas de información. Es importante tener en cuenta que la etapa del ciclo de vida del desarrollo de sistemas de base de datos no son estrictamente secuenciales, si no que existe una cierta repetición de las etapas anteriores a través de lo que se denomina bucles de realimentación.por ejemplo, los problemas que se encuentran durante el diseño de la base de datos puede necesitar una nueva labor de recopilación y análisis de requerimientos adicionales.la siguiente tabla proporciona un resumen de las actividades principales asociadas con cada etapa del ciclo de vida del desarrollo de sistema de base de datos. Tabla1. Resumen de las actividades principales asociadas con cada etapa del ciclo de vida del desarrollo de sistema de base de datos. Sistema de base de datos Pág.206 Etapa Planificación de la base de datos Definición del sistema Actividades Principales Planificación del modo en que pueden llevarse a cabo las distintas etapas del ciclo del vida de la forma más eficiente y efectiva Especificación del ámbito y los límites del sistema de base de datos, incluyendo las principales vistas de usuario, tipos e usuario y áreas de aplicación. Recopilación y análisis de requerimientos Recopilación y análisis de los requerimientos del nuevo sistema de base de datos. Diseño de la base de datos Diseño conceptual, lógico y físico de la base de datos. Selección del SGBD (Opcional) Selección de SGBD adecuado para el sistema de base de datos. Diseño de la aplicación Diseño de la interfaz de usuario y de los programas de aplicación que sirvan para utilizar y procesar los datos de la base de datos. Prototipado (Opcional) Construcción de un modelo funcional del sistema de base de Autor: Franklin Ramón Mendoza Salazar 33
Implementación Conversión y carga de datos Pruebas Mantenimiento operativo datos que permite a los diseñadores o usuarios visualizar y evaluar el aspecto y la función del sistema final. Creación de las definiciones físicas de la base de datos y de los programas de aplicación. Carga de los datos del antiguo sistema en el nuevo, y siempre que sea posible, conversión de las aplicaciones existentes para que se ejecuten sobre la nueva base de datos. Prueba de la base de datos en busca de errores y validación de la misma con respecto a los requerimientos especificados por los usuarios El sistema de base de datos esta completamente implementado, después de lo cual se lo monitoriza y mantiene de manera continua. Cundo sea necesario, se incorporaran nuevos requisitos al sistema de base de datos aplicando de nuevo las etapas precedentes del ciclo de vida. Autor: Franklin Ramón Mendoza Salazar 34
Herramientas CASE La primera etapa del ciclo de desarrollo de un sistema de base de datos, es la especificación de la base de datos, puede también implicar la selección de las adecuadas herramienta CASE (Computer-Aided Software Engineering). En su sentido mas amplio, el termino CASE puede aplicarse a cualquier herramienta que de soporte a la ingeniería de software. El personal de administración de datos y de la administración de base de datos necesita las adecuadas herramientas de productividad para que las actividades de desarrollo de la base de datos se lleve a cabo de la forma más eficiente y efectiva posible. El soporte CASE puede incluir: Un diccionario de datos para almacenar información acerca de los datos del sistema de base de datos; Herramientas de diseño para soportar el análisis de datos; Herramientas que permita el desarrollo del modelo de datos corporativo y de los modelos conceptual y lógico de los datos; Herramientas que permitan el prototipado de aplicación. Las herramientas CASE Se dividen en tres categorías: 1. CASE de alto nivel que soporta las etapas iniciales del ciclo de desarrollo de los sistemas de base de datos, desde la planificación hasta el diseño de la base de datos. 2. CASE de bajo nivel soportan las ultimas etapas del ciclo de vida desde la implementación a las pruebas y el mantenimiento operativo. 3. CASE integradas soportan todas las etapas de ciclo de desarrollo y proporciona por lo tanto, la funcionalidad de las herramientas CASE de alto y bajo nivel en una única herramienta. Autor: Franklin Ramón Mendoza Salazar 35