About Taringa!

Popular channels

Sistema de control escolar

PROTOTIPO DE TESIS
HUGO ALEJANDRO ESPINOSA GUIZAR

RESUMEN
En la actualidad vemos un tipo de trabajo muy tradicionalista por parte de varias instituciones educativas, que no van acorde a nuestros tiempos donde la tecnología está influyendo en la vida cotidiana.
Es donde nos vemos inmerso en una de las problemáticas de las escuelas que no contamos con el tiempo suficiente al querer informarnos de las calificaciones o hacer un trámite de nuestros hijos. Ya que las instituciones por su forma de trabajo acumulan demasiado papeleo no solo de un alumno sino de todos los que están en la institución provocando mucha pérdida de tiempo el solo saber la calificación de una materia y eso nos causa molestia por el simple hecho que no contamos con el tiempo suficiente.
Es ahí donde entra la necesidad de modernizar las escuelas con un sistema de control escolar en línea ya que dicho sistema agilizará la consulta de calificaciones de nuestros hijos desde cualquier lugar, no solo los profesores podrán subir las calificaciones desde la comodidad de sus hogares ayudando al personal de servicios escolares en la absurda acumulación de documentos









INDICE
CAPÍTULOS
1.- INTRODUCCIÓN
2.- PROTOCOLO DE INVESTIGACIÓN
2.1 TÍTULO
2.2 PLANTEAMIENTO DEL PROBLEMA
2.3.- OBJETIVOS
2.3.1.- GENERAL
2.3.2.- ESPECÍFICOS
2.4.- JUSTIFICACIÓN
3.- MARCO TEÓRICO
3.1.2.- INGENIERÍA DE DESARROLLO DE SOFTWARE
3.1.3.-TIPOS DE SISTEMAS
3.1.4.-MODELO EN CASCADA
3.1.5.-EL CICLO DE VIDA
3.1.6.-EL MODELO DE DESARROLLO EN CASCADA
3.2.- DEFINICIÓN
3.3.- DISEÑO
3.4.- CODIFICACIÓN
3.5.- INTEGRACIÓN
3.6.- PRUEBA
3.7.- DOCUMENTACIÓN

4.-BASES DE DATOS
5.- HIPÓTESIS
6.- MÉTODO
7.- FASES DE ELABORACIÓN.
8.- RECURSOS HUMANOS.
9.- RECURSOS FINANCIEROS.
10.- RECURSOS MATERIALES
11.- CONCLUSIONES
12.-BIBLIOGRAFIA





1. INTRODUCCIÓN

Las bases de datos permiten que los sistemas control de alumno crezcan considerablemente en la cantidad de información que manejan, ya que permiten contar con sistemas integrados de múltiples computadoras, las cuales pueden estar distribuidas en lugares geográficamente lejanos y contar con los recursos suficientes para contener y manejar por si solas grandes cantidad de información. El empleo de sistemas de base de datos permite también dividir las consultas o transacciones para que sean realizadas a una mayor velocidad por distintas maquinas o procesadores, incrementando el rendimiento del sistema de base de datos.
Las bases de datos pueden variar su tamaño de una forma más sencilla. Se puede agregar maquinas a la red a medida que se incrementa los usuarios y aumentar la carga de procesamiento, brindando facilidad y menor consumo de recursos al agregar pequeña en vez de actualizar una computadora centralizada y se tiene la opción de reducir el tamaño de la red cuando la carga de procesamiento disminuya.













2.- PROTOCOLO DE INVESTIGACIÓN
2.1 TÍTULO
Sistema de control escolar para el área de calificaciones en la escuela preparatoria “pendiente la escuela”.

2.2 PLANTEAMIENTO DEL PROBLEMA
¿De qué manera se puede sistematizar el proceso de recepción, entrega y recopilación de información tanto de los alumnos como de las calificaciones?

Actualmente existen muchas escuelas de los diferentes niveles educativos que trabajan de una manera arcaica o tradicional, en la obtención, recopilación, captura y al almacenar la información de los alumnos, ya sea sus general o en las calificaciones, todo esto realizado de forma manual, lo cual genera una excesiva cantidad de papelería aunado a esto la pérdida de tiempo que esto conlleva, además en el proceso de la entrega de calificaciones por parte de los docentes para el personal de control escolar.
Este es el caso que presenta la Escuela Preparatoria “pendiente la escuela”, la cual aún realiza todo su proceso administrativo del área de control escolar de manera tradicional, la cual ha generado una cantidad excesiva de documentos recopilados (copias fotostáticas) y con ello la pérdida de tiempo al realizar la búsqueda de algún documento, así también cuando los docentes hacen la entrega y reporte de calificaciones a control escolar.
También esta forma tradicional de trabajar no solo genera molestias para el personal de control escolar, sino también para los padres de familia que llegan a la institución a pedir informes o por algún documento que requieran para algún trámite, ya que no se les es entregado al momento, sino que tienen que esperar hasta un día.




2.3.- OBJETIVOS
2.3.1.- GENERAL.
Desarrollar un sistema de control escolar del módulo de calificaciones, para la Escuela Preparatoria “pendiente la escuela”.

2.3.2.- ESPECÍFICOS
• Sistematizar el proceso de alta/baja de alumnos así la recepción, captura y entrega de calificaciones.
• Crear la base de datos.
• Diseñar la interfaz del sistema.
• Diseñar la mercadotecnia del sistema.


2.4.- JUSTIFICACIÓN
Muchas instituciones educativas carecen de un sistema en el que puedan llevar toda la información de sus alumnos, el control, reporte de calificaciones e historiales. Estando en la era de la tecnología de la información, es necesario formar parte de ella.
Es por eso que el desarrollar e implementar este sistema de control escolar en la escuela preparatoria “pendiente la escuela”, reduciremos el exceso de documentación en archivos físicos, así también la reducción en el tiempo en la captura, la recopilación de la información de los alumnos y entrega de calificaciones de parte de los docentes para control escolar y de control escolar para los padres de familia.
Así este sistema podrá ser implementado en muchas más instituciones educativas que presenten esta misma problemática o una similar, ya que nuestro sistema al ser de robusto y de fácil adaptación puede integrarse a requerimientos específicos de cada institución.



ALCANCES Y LIMITACIONES
ALCANCES
• Reducir los tiempos en la recopilación de información, captura y entrega de información y calificaciones, por parte del personal administrativo y docente.
• Al ser un sistema robusto y de fácil adaptación y adecuación puede ser implementado en cualquier nivel educativo.
• Reducir los tiempos de actualización de la información de los alumnos.
• Reducir el tiempo en la entrega de calificaciones por parte del personal docente al área de control escolar.
• Reducir ampliamente la documentación que se genera en el área de control escolar.

LIMITACIONES
• El sistema no tendrá complemento extras que no sean para recopilar la información del alumno, como sus generales y calificaciones, además de la información de los grupos.
• Que sea aceptado tanto por el personal administrativo y docente, por el cambio que este les producirá al modificar su forma tradicional de trabajar.











3.- MARCO TEÓRICO
3.1.1.- ANTECEDENTES:
Teoría general de sistemas: es un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades comunes a entidades llamadas sistemas. Éstos se presentan en todos los niveles de la realidad, pero que tradicionalmente son objetivos de disciplinas académicas diferentes.
Presenta los planteamientos iniciales de la teoría general de sistemas (TGS). Trabajó el concepto de sistema abierto e inició el pensamiento sistémico como un movimiento científico importante. Bertalanffy, (1968).
La TGS nos permite unir y organizar los conocimientos con la intención de una mayor eficacia de acción así también engloba la totalidad de los elementos del sistema estudiado así como las interacciones que existen entre los elementos y la interdependencia entre ambos. Es una aplicación al mejoramiento de organización de una empresa para un mejor concepto hay que tener en cuenta la perspectiva, enfoque, punto de vista, cosmovisión. Que nos ayude a alcanzar objetivos planteados operando sobre las entradas y salidas procesadas.

SISTEMA
Un sistema es una combinación de componentes que actúan conjuntamente para alcanzar un objetivo específico. Un sistema es dinámico cuando la salida presente depende de las entradas pasadas y es estático cuando la salida presente depende solamente de las entradas presentes.

3.1.2.- INGENIERÍA DE DESARROLLO DE SOFTWARE
Es la disciplina y la aplicación de métodos de ingeniería para el campo del software.
Como puede leerse en [Grady, 1990], hoy por hoy no disponemos de herramientas, ni siquiera de metodologías, que nos permitan transformar el software ordinario en otro que sea fiable y fácilmente mantenible. En el campo del hardware, por el contrario, esta anhelada situación está mucho más cerca de la realidad. Así, disponemos de chips que son a la vez extremadamente complejos y muy fiables. Sin embargo, los sistemas software medianamente grandes suelen estar "plagados" de errores, y realizar cambios en ellos es, cuando menos, una tarea arriesgada.

Esta diferencia puede ser debida al hecho de que el desarrollo de hardware siempre ha estado constreñido por limitaciones físicas (por ejemplo, densidad de integración). Así, la evolución se ha hecho "paso a paso", añadiendo complejidad poco a poco en cada uno de estos pasos, a medida que se lograba introducir más componentes en una superficie dada. Pero el software no tiene este tipo de limitaciones, con lo que desde el principio tenemos una gran cantidad de complejidad, que hemos de manejar de alguna forma.

Por eso, el gran desafío con que se encuentra la gestión de proyectos software consiste precisamente en limitar los productos que se desarrollan en esos proyectos a unos niveles de complejidad aceptable y manejable. Dicho de otra forma, se pretende reducir los grados de libertad en la producción de software para, al operar dentro de unos ciertos márgenes, mantener la complejidad resultante lo más baja posible.

Esto ha llevado a la concepción y uso de varios modelos del ciclo de vida. Con ellos se intenta descomponer los problemas de la gestión del proyecto de forma lógica, a la vez que generar productos tras cada etapa del modelo. Estos productos pueden ser usados para comprobar si estamos moviéndonos en la dirección deseada, o si por el contrario nos apartamos de los objetivos de complejidad previstos. Al fin y al cabo, utilizamos la acreditada técnica del "divide y vencerás".

“En la sociedad moderna el papel de la ingeniera es proporcionar sistemas y productos que mejoren los aspectos materiales de la vida humana, para que la vida humana sea más fácil, segura y placentera” Richard Fairley/Mary Willshire.

En la actualidad, el software tiene un papel dual, como un producto y como un vehículo mediante el cual se entrega un producto.
El software entrega el producto más importante para nuestro tiempo: información.

El papel del software de las computadoras ha experimentado un cambio significativo en un periodo no mayor a 50 años, las mejoras se han hecho presente desde el desempeño del hardware, en la arquitectura de cómputo, incremente en las capacidades de memoria y almacenamiento y una infinidad de dispositivos tanto de entrada como de salida.

Aunque para otras personas la ingeniería de desarrollo de software lo definen como un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades comunes a entidades llamadas sistemas. Éstos se presentan en todos los niveles de la realidad, pero que tradicionalmente son objetivos de disciplinas académicas diferentes.
El Consejo Americano de Ingenieros para el Desarrollo Profesional define "ingeniería" como la aplicación creativa de los principios científicos para diseñar o desarrollar estructuras, máquinas, aparatos o procesos de manufactura, o que trabaja usándolas individualmente o en combinación; o para construirlas u operarlas con el completo conocimiento de su diseño; o para predecir su comportamiento bajo condiciones operativas específicas en lo que respecta a una función deseada, operación económica y seguridad a la vida y la propiedad.
Quizás estas definiciones no están tan apartadas; todas comparten la idea general de aplicar conocimiento científico y principios al software.
Entonces La Ingeniería de Software es la forma de producir, crear un software, donde estos son llevados por los ingenieros donde utilizan herramientas para dar soluciones a los problemas creados para el desarrollo, como también para distribuir todos los recursos necesarios para llevarlo a cabo y así sacar a producción un software que este dentro de los estándares calidad.
Así también en la ingeniería de software juega un papel muy importante la metodología de desarrollo de software que es el marco usado para estructurar, planificar y poder controlar todo el proceso en el desarrollo de un sistema de información sea este cual sea.
Muchos de los modelos que actualmente en día existen fueron originados en los años 60’s para desarrollar en gran escala sistemas de negocio empresariales, es ahí cuando surgen las etapas del ciclo de vida de un sistema.
La metodología para el desarrollo de software tiene como su principal objetivo presentar un conjunto de técnicas tradicionales y modernas de modelados que permitirán el desarrollo de software de calidad, ya sea orientados a objetos, estructurada, secuencial.




3.1.3.-Tipos de sistemas:
Los sistemas de información se desarrollan con diversos propósitos, según las necesidades de la empresa. Los sistemas de procesamientos de transacciones (TPS), los sistemas de automatización de la oficina (OAS) y los sistemas de trabajo del conocimiento (KWS) apoyan el trabajo al nivel de conocimiento. Los sistemas de información gerencial (MIS) y los sistemas de apoyo a la toma de decisiones (DSS) se encuentran entre los sistemas de alto nivel.
Para [Kendall & Kendall, 1998] los sistemas de automatización de oficina (OAS) apoyan a los trabajadores de datos, quienes por lo general no generan conocimientos nuevos, sino más bien analizan la información con el propósito de transformar los datos o manipularlos de alguna manera antes de compartirlos o, en su caso, distribuirlos formalmente con el resto de la organización y en ocasiones más allá de ésta, entre los componentes más comunes de un OAS están las de procesamiento de texto, las hojas de cálculo, la autoedición, la calendarización electrónica y las comunicaciones mediante correo de voz, correo electrónico y video conferencias

[Kendall y Kendall, 1998] plantea un esquema para el desarrollo de software
I. Identificación del problema, oportunidades y objetivos.
II. Determinación de los requerimientos de información.
III. Análisis de las necesidades del sistema.
IV. Diseño del sistema recomendado.
V. Desarrollo y documentación del software.
VI. Pruebas y mantenimiento del sistema.
VII. Implantación y evaluación del sistema.
3.1.4.-Modelo en cascada
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implementación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el término "cascada" de este artículo.

Los principios básicos del modelo de cascada son los siguientes:1
• El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.
• Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.
• Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de comenzar la próxima fase.
3.1.5.-El ciclo de vida.

En principio, el ciclo de vida de un proyecto software incluye todas las acciones que se realizan sobre él desde que se especifican las características que debe tener, hasta que se mantiene en operación. A veces (aunque no será éste nuestro caso) se incluyen en el ciclo de vida las modificaciones que pueden realizarse al sistema para adaptarse a nuevas especificaciones.

Podría pensarse que el ciclo de vida de un programa no tiene por qué seguir un desarrollo "lineal", entendiendo como tal una sucesión de etapas. En principio, las distintas actividades que se realizan son bastante independientes, y pueden llevarse (hasta cierto punto) en paralelo. Por ejemplo, para empezar a codificar hay que tener mínimamente claras las especificaciones que hay que cumplir. Pero (aunque no es una buena decisión, como veremos más adelante), podría pensarse en comenzar la producción de código mientras se completan las especificaciones, para poder irlo probando, por ejemplo. Más adelante se harían las modificaciones necesarias.

Pero si el desarrollo de productos software ya es algo complejo en sí mismo (véase el capítulo sobre Medidas o Métricas de la Complejidad del Software), aún lo complicaremos más si intentamos "hacerlo todo a la vez", sin seguir una cuidadosa y detallada planificación. Y esto es precisamente lo que pretenden los modelos del ciclo de vida del software: simplificar en lo posible la gestión del proceso de desarrollo. La meta está en añadir la mínima complejidad que sea posible a la que de por sí ya implica el software.

Desde el punto de vista del esquema HxIxO->IO, podríamos decir que los modelos del ciclo de vida son un instrumento conceptual (I) que permite a la persona encargada (H) de gestionar un desarrollo de software (el O será por tanto el propio proceso de desarrollo) tratar con un problema más sencillo (el IO resultante).

Para ello, estos modelos dividen el proceso de desarrollo en unas cuantas etapas bien diferenciadas, y definen los posibles caminos por los que se deben relacionar. Además intentan que estos caminos lleven a un "progreso lineal", en el sentido de que antes de comenzar una etapa se haya concluido exitosamente (con las especificaciones cumplidas) la anterior. Sin embargo, esto no es siempre posible, y hay que recurrir a iteraciones (por ejemplo, entre el diseño y la codificación), que nos lleven mediante aproximaciones sucesivas a cumplir con los objetivos de la mejor forma posible.

Desde el punto de vista jerárquico (véase el capítulo sobre las jerarquías) esta división en etapas puede verse como una jerarquía multicapa de toma de decisiones. Así, cada una de las etapas (capa de decisiones) termina cuando, tras haber hecho todas las elecciones necesarias, se han cumplido los objetivos marcados, sentando las bases para la siguiente etapa. Al dividirse el problema en estas capas, en cada momento del desarrollo nos enfrentamos con una complejidad menor (únicamente la debida a cada capa, ya que las anteriores habrán sido satisfactoriamente resueltas).




3.1.6.-El modelo de desarrollo en cascada.

Uno de estos modelos del ciclo de vida, quizás el más ampliamente utilizado, es el del desarrollo en cascada. En él, cada etapa deja el camino preparado para la siguiente, de forma que esta última no debe comenzar hasta que no ha acabado aquélla. De esta forma, se reduce mucho la complejidad de la gestión, ya que basta con no dar por terminada una etapa hasta que haya cumplido totalmente con sus objetivos. De esta forma, la siguiente puede apoyarse con total confianza en ella. A la hora, por ejemplo, de fijar plazos, se podrían establecer planes de una forma totalmente secuencial, quedando perfectamente delimitadas las responsabilidades de los equipos que desarrollen cada etapa.

En la realidad la aplicación de este modelo no suele ser tan radical. Aunque se intenta conseguir la mayor secuencialidad posible, es difícil evitar las "vueltas atrás". Si después de la terminación de alguna etapa los resultados no son los esperados, en la práctica es muy posible que el problema esté en la mala realización de una etapa anterior. Y esto es así porque no sabemos cómo decidir con total certidumbre que una etapa ha sido perfectamente desarrollada hasta que se observan las consecuencias, quizás varias etapas y bastante tiempo después de que fue "cerrada". En estos casos, habrá que volver a ella, refinando el producto de una forma iterativa hasta que se considere que tiene la calidad deseada.

En el modelo "puro", las fases en que se suele dividir el ciclo de vida en este modelo son [Grady,1990]:

a. Definición (análisis de los requerimientos software).
b. Diseño (podría dividirse en preliminar y detallado).
c. Codificación.
d. Integración. e. Prueba.
f. Documentación.

Estas fases de desarrollarían una tras otra, excepto quizás las dos últimas. La prueba de módulos podría realizarse después de la codificación y la del sistema completo tras la integración. La documentación, por su parte, puede irse creando a lo largo de todo el proceso.

Sin embargo, los caminos reales que se siguen en el desarrollo de software suelen parecerse mucho más a los que se pueden ver en la figura 2 (basada en [Fox, 1982]. En ella, las flechas que apuntan en sentido descendente representarían el modelo puro, mientras que las ascendentes corresponden a los demás caminos que se suelen seguir en la realidad.

Pasemos a describir ahora cada una de las etapas del modelo en cascada, que ya hemos nombrado.

3.2.- Definición.

La definición de requisitos o especificación de características que ha de cumplir el software que vamos a desarrollar es la primera etapa del modelo en cascada. Y probablemente sea la más importante. Al fin y al cabo, lo que sea o no sea el producto final depende de decisiones tomadas en esta etapa. Se trata fundamentalmente de estudiar las necesidades y preferencias del usuario. Es también muy importante dejar clara constancia de las decisiones tomadas en esta etapa, para ser tenidos en cuenta posteriormente. Por ello, la documentación producida en esta fase debe ser concreta y estar siempre disponible durante el resto del proceso.

3.3.- Diseño.

Una vez planteada la especificación del programa, hay que analizar desde un punto de vista técnico las posibles soluciones. Entre ellas, se elegirá la que se considere más adecuada. A partir de ese momento, se decidirá la estructura general del programa (subdivisión en partes y relaciones entre ellas). Para cada una de las partes se seguirá recursivamente un proceso similar, hasta que tengamos totalmente definido el programa y estemos listos para pasar a la fase de codificación.


Algunos trabajos recientes ([Rombach, 1990], [Henry y Selig, 1990]) proponen utilizar métricas en la fase de diseño para predecir la calidad del producto software antes de llegar a la codificación. Así se ahorrarían esfuerzos, al encontrar pronto zonas de gran complejidad y de poca calidad. De esta forma estas zonas podrían rediseñarse, consiguiéndose así que den menos problemas en posteriores etapas del desarrollo.

3.4.- Codificación.

En un proyecto grande ésta es la etapa más sencilla (en contra de lo que suele suponer cualquier persona que comienza a aprender un lenguaje de programación). Si el diseño es adecuado y suficientemente detallado la codificación de cada módulo es algo casi automático.

Evaluar la calidad de la codificación es una tarea nada fácil. Para un mismo diseño son posibles muchas implementaciones diferentes. Y no hay criterios claros que no permitan decidir cuál es la mejor. En este punto, las métricas del software pueden ser utilizadas en nuestra ayuda (ver capítulo sobre las métricas).

Cuando intervienen varias personas, pueden aparecer problemas a la hora de realizar modificaciones, debido a que cada uno tiene su propio estilo. Por eso se hace necesario definir estándares de estilo para facilitar la legibilidad y claridad del software producido.







3.5.- Integración.

Una vez que tenemos los módulos codificados, hay que ensamblarlos. Desgraciadamente el proceso no consiste simplemente en unir piezas. Suelen aparecer problemas con las interfaces entre los módulos, con la comunicación de datos compartidos, con el encadenamiento de flujos de ejecución, etc.

Si el programa es además bastante grande, la gestión de versiones se convierte en un problema no despreciable. Afortunadamente, ésta es una de las etapas donde disponemos de más herramientas CASE, que nos pueden ayudar.



3.6.- Prueba.

En esta fase hay que comprobar que las especificaciones se cumplen perfectamente y en todos los casos. En la realidad es prácticamente imposible probar un programa totalmente: por ello siempre suele quedar algún error escondido. Este problema se agrava cuando sobre él se realizan repetidos cambios y correcciones. Si no los gestionamos de una forma adecuada podemos acabar con un conjunto de parches que más que soluciones aportan problemas.


Actualmente se están comenzando a utilizar técnicas de verificación y validación como alternativa a la simple prueba de programas. Según Wallace y Fujii [Wallace y Fujii, 1989], la verificación y validación es una disciplina de ingeniería de sistemas, que intenta evaluar el software desde un punto de vista sistémico. Utiliza una aproximación estructurada para analizar y probar el software en relación con todos los aspectos del sistema en el cual se incluye, y en especial con el hardware, los usuarios y las interfaces con otras piezas de software.

Idealmente, la verificación y validación se realiza paralelamente al desarrollo de software, durante todo su ciclo de vida (por lo que no entra en el modelo en cascada, estrictamente hablando), y pretende alcanzar los siguientes objetivos:

a. Descubrir pronto errores de alto riesgo, dando al equipo de diseño la oportunidad de elaborar una solución adecuada, evitando que se vea obligado a poner un "parche" si el error se detecta demasiado tarde.
b. Evaluar el ajuste de los productos desarrollados a las especificaciones del sistema.
c. Proporcionar al equipo de gestión información actualizada sobre la calidad y el progreso del esfuerzo de desarrollo.

Éste de la verificación y validación es un campo donde se están realizando activas investigaciones, mientras comienzan a obtenerse los primeros frutos.


3.7.- Documentación.

La documentación es algo totalmente necesario para poder mantener un programa. Incluso la persona que lo ha codificado se perderá con gran facilidad en un programa a los pocos meses de haberlo terminado. No sólo hay que documentar el código (las conocidas líneas de comentario del programa), sino todas las etapas del ciclo de vida. Especialmente es importante que todas las decisiones que se han tomado queden claramente expuestas, así como las razones que han llevado a ellas.

Además, hay que generar la documentación de "caja negra", esto es, la que se refiere no a aspectos internos del programa, sino a su manejo y características "externas". Esto incluye normalmente un manual de usuario, para las personas que normalmente van a utilizarlo (en el caso de que sea un programa directamente utilizado por personas) y un manual de referencia técnica, donde se dan detalles de su instalación y explotación, de cara al personal técnico encargado de estas tareas.

En el modelo en cascada hemos colocado la etapa de documentación al final, porque es cuando se realizará la documentación definitiva, y especialmente los manuales "de caja negra" de los que hemos hablado. Pero es conveniente ir preparándola a lo largo de todo el desarrollo, según van realizándose las actividades a documentar.

Para gestionar esta etapa (llevar el control de las versiones de la documentación, incluso generarla automáticamente en algunos casos) también se dispone de herramientas informáticas de ayuda.



4.-BASES DE DATOS

Un sistema de base de datos es básicamente un sistema computarizado para guardar registros; es decir, es un sistema computarizado cuya finalidad general es almacenar información y permitir a los usuarios recuperar y actualizar esa información con base en peticiones.

La información en cuestión puede ser cualquier cosa que sea de importancia para el individuo u organización; en otras palabras, todo lo que sea necesario para auxiliarle en el proceso general de su administración.

Para Date, C. (2001), algunos autores prefieren distinguir entre ambos, utilizando "datos" para referirse a lo que está en realidad almacenado en la base de datos e "información" para referirse al significado de esos datos como lo entiende algún usuario. La diferencia es importante; tan importante que parece preferible hacerla explícita donde sea necesario, en vez de depender de una diferenciación un tanto arbitraria entre dos términos que son en esencia sinónimos.

Un sistema de base de datos comprende cuatro componentes principales: datos, hardware, software y usuarios.

Podríamos considerar una base de datos como una especie de armario electrónico en el cual podríamos guardar mucha información es decir, es un depósito o contenedor de una colección de archivos de datos computarizados. Los usuarios del sistema pueden realizar una variedad de operaciones sobre dichos archivos. Por ejemplo:

• Agregar nuevos archivos vacíos a la base de datos;
• Insertar datos dentro de los archivos existentes;
• Recuperar datos de los archivos existentes;
• Modificar datos en archivos existentes;
• Eliminar datos de los archivos existentes;
• Eliminar archivos existentes de la base de datos.



¿POR QUÉ UNA BASE DE DATOS?

¿Por qué utilizar un sistema de base de datos? ¿Cuáles son las ventajas?
Hasta cierto punto, la respuesta a estas preguntas depende de si el sistema en cuestión es de un solo usuario o multiusuario (o para ser más precisos, existen muchas ventajas adicionales en el caso del sistema multiusuario).

Una base de datos es tan reducida y sencilla que las ventajas podrían no ser tan obvias. Pero imagine una base de datos similar para un gran restaurante, con una existencia tal vez de miles de botellas y cambios muy frecuentes a dichas existencias; o piense en una tienda de licores, también con una gran existencia y una mayor rotación en la misma. Tal vez en estos casos sea más fácil apreciar las ventajas de un sistema de base de datos sobre los métodos tradicionales basados en papel, para llevar un registro. He aquí algunas:
• Compactación: No hay necesidad de archivos en papel voluminosos.
• Velocidad: La máquina puede recuperar y actualizar datos más rápidamente que un humano.


Beneficios del enfoque de base de datos
En esta subsección identificaremos algunas de las ventajas específicas que surgen de la noción anterior de control centralizado.

Los datos pueden compartirse, pero compartir no sólo significa que las aplicaciones existentes puedan compartir la información de la base de datos, sino también que sea posible desarrollar nuevas aplicaciones para operar sobre los mismos datos.

5.- Hipótesis.
Si el personal docente y administrativo de la escuela utiliza un sistema de control escolar, se reducirá el tiempo y trabajo en las de control escolar.
El exceso de documentación que se entrega a control escolar genera una pérdida de tiempo al realizar consulta de información.
6.-Método.
Se desarrollara basándonos en el método científico, para la investigación documentada del proyecto.
Así también usaremos el método de cascada, como parte del desarrollo del software,
Para el sistema de base de datos implementaremos el método de entidad relación para el proceso de elaboración e implementación de la base de datos.




7.- Fases de elaboración.
1.- Planteamiento de la problemática.
2.- Recopilación de información y datos, así como su debido análisis.
3.- Diseño de base de datos.
4.- Diseño de la Interfaz de la aplicación y del Empaque y presentación.
5.- Desarrollo de la aplicación, basado en el modelo de cascada.
6.- Pruebas.
7.- Retroalimentación.

8.- Recursos humanos.
Para la realización de nuestro proyecto se cuenta con el apoyo de la institución, para facilitarnos información que podamos requerir en el desarrollo del mismo, además de que contamos con las capacidades y habilidades para poder llevar acabo el desarrollo exitoso del sistema de control de alumnos.


9.- Recursos financieros.
Al ser este un proyecto que no genera costos excesivos en su desarrollo contamos con la solvencia suficiente para el desarrollo, los gastos que se generar serán mínimos, los cuales serán mayormente enfocado a la adquisición el hosting (Alojamiento WEB) para las pruebas y en su futura implementación.

10.- Recursos materiales
Para nuestro proyecto los recursos materiales no generaran un problema ya que se cuenta con todas las herramientas y materiales para su desarrollo, así como también para su futura implementación.


11.- Conclusiones
Con el desarrollo del proyecto del sistema de control escolar se contribuyó en la mejora de tiempos en consulta de calificación por parte del alumno y padres de familia, facilitando el trabajo a los profesores y al personal de servicios escolares en la manipulación de la información del alumno.
















12.-Bibliografía

Bertalanffy, L. V. (1968): “Teoría General de los Sistemas”, Fondo de cultura Económica, 7ª Reimpresión, México, P.P 308.
Date, C. (2001): “Introducción a los sistemas de base de datos”, Prentice Hall 7ª Edición, P.P 959.
Hernández S., Fernández-Collado, Baptista Lucio (2006), “Metodología de la Investigación” McGraw-Hill 4ª Edición, México D.F., P.P. 850.

Kendall K. & Kendall J. (1998): “Análisis y Diseño de Sistemas”, Pearson Education, 6ª Edición, México, P.P. 726.
Pressman, R. (1998):”Ingeniería de Software un Enfoque Práctico”, McGraw Hill, España, P.P. 927.
Sáuz V. F. sistemas de la información. España. Madrid. Disponible en: informaihttp://www.gsi.dit.upm.es/~fsaez/intl/libro_complejidad/15-el-desarrollo-del-software.pdf.(2008).
2Comments