Sistema Colegio SAN PABLO

Carrera: Licenciatura en Ciencias de la Computacin
V ao
V Jornada Universitaria de Desarrollo Cientfico
Titulo: Sistema de control de matricula del colegio San pablo
Elaborado por:
Br: Franklin Ramn Mendoza Salazar
Tutora: Sonia Rojas Fargas.
12 de octubre del 2007
ndice
Contenido
Pginas
Resumen----------------------------------------------------------3
Tema---------------------------------------------------------------4
Introduccin ------------------------------------------------------5
Justificacin-------------------------------------------------------6
Objetivos-----------------------------------------------------------7
Antecedentes-----------------------------------------------------8-9
Marco terico-----------------------------------------------------10-35
Preguntas directrices------------------------------------------36
Diseo metodolgico------------------------------------------37
Resultados-------------------------------------------------------38
Anlisis y discusin de los resultado----------------------39
Conclusiones----------------------------------------------------40
Recomendaciones---------------------------------------------41
Bibliografa-------------------------------------------------------42
Anexos------------------------------------------------------------43-65
1. Estudios de factibilidad
2. Diagrama de flujo de datos
3. Diagrama E/R
4. Diagrama de entidad relacin en Access
5. Diagrama de dialogo
6. Manual de usuario
Prototipo de sistema de control de matricula del colegio san pablo
Resumen
Los lenguajes de programacin visuales como Fox Pro, permiten realizar sistemas
.El colegio San pablo siendo un centro de educacin para estudiantes de:
Preescolar, primaria y secundaria que lleva un control manual de matricula que le
provoca problemas de organizacin de la informacin almacenamiento; El sistema
de control de matricula resuelve los problemas al crear un diseo eficaz y sencillo
.Los catlogos como Estudiante, Centro de estudios, recibos, ocupacin de los
padres y ubicacin 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 Ramn Mendoza Salazar
Tema: Sistema de control de Matricula del colegio san pablo

INTRODUCCIN
El Colegio San Pablo fue fundado en el ao de 1961, en la Ciudad de Juigalpa.
Desde su instauracin como centro de enseanza, constaba con tres tipos de
modalidades: preescolar, primaria y secundaria.
La matricula estudiantil del presente ao asciende a 515 alumnos. A pesar que,
desde hace ya algn tiempo, la institucin cuenta con un Laboratorio de
Informtica, 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 redaccin manual, ni poder impedir la ilegibilidad de la
escritura de la persona encargada de llevar dicho control. Adems, la informacin
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 investigacin se propone plantear una solucin tentativa a dicho problema a
travs 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 acumulacin de documentacin y agilizar el proceso de matricula.

JUSTIFICACIN
Esta investigacin, y el prototipo de sistema que de ella se derive, constituyen un
beneficio para el Colegio San Pablo y, ms especficamente, para el personal que
labora en el rea de secretara.
Con la propuesta de prototipo se pretende agilizar el registro de matriculas y la
realizacin de consultas e informes, a la ves se optimizara la atencin durante el
proceso de matricula.
Facilitar la administracin del registro de matriculas en el sentido de poder
localizar un determinado dato a modificar o eliminar en el momento que se
requiera.
Objetivos
Objetivo General
Disear un prototipo de sistema para control de matricula del colegio san pablo de
la ciudad de juigalpa, ao 2007.
Objetivos especficos
1. Realizar el control de matrcula y recibo del colegio san pablo
2. proporcionar un mejor almacenamiento de los recibos de los estudiantes en el
proceso de matrcula
3. Controlar los registros de estudiantes y de matricula

ANTECEDENTES
La escuela san pablo, fue fundada en la ciudad de Juigalpa en 1961, desde su
fundacin
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 informtica que es utilizado para dar clases de
Microsoft office no para el registro de matricula, se ven en
la necesidad de
guardar la informacin por medio de registro manual, implica una problemtica de

respuesta inmediata en secretaria en el da de matricula.
Los registros manuales en los cuales anotan los datos personales de cada uno de
los estudiantes
nuevo y de reingreso ;as como tambin 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:
Confusin al llevar el control de estudiantes
Pago de matricula en un ao que no corresponda
Llenado de datos de un estudiante que no corresponda
Problema en el control financiero por no reflejar pago de matricula
Pago de matricula no sustentado con recibo
Anteriormente, ya se haba realizado una propuesta de sistema con la tentativa de
que fuera utilizado para la administracin del registro de matriculas

Dicha propuesta no paso de ser una solucin tentativa ya que quedo inconclusa
por lo tanto no se implemento. Adems, los requisitos del colegio han cambiado
significativamente.
La importancia del colegio san pablo por medio del control de la informacin de
los estudiantes son : documentos de matricula y recibos, hace necesario resolver
las dificultades como: Equivocacin al momento de llenar los datos del estudiante,
perdida de algn 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 atencin lenta, es necesario
llevar el almacenamiento de la informacin automticamente .
Las
tecnologas computarizadas ofrecen
la estrategia
de mantener la
informacin en orden, llevar un mejor control y proporcionar integridad en los

datos; se hace necesario anlisis y diseo de un sistema de control de matricula,
para que responda a la problemtica actual y facilite :El acceso y almacenamiento
de la informacin en el colegio San Pablo de esta manera los usuarios ahorran
tiempo y trabajo evitando perdida de la informacin; lo que causara problemas al
estudiante y al colegio.

MARCO TERICO
Sistema
Un sistema es un conjunto de elementos organizados que interactan entre s y
con su ambiente, para lograr objetivos comunes, operando sobre informacin,
sobre energa o materia u organismos para producir como salida informacin o
energa o materia u organismos.
Un sistema aislado no intercambia ni materia ni energa con el medio ambiente.
(es.wikipedia.org/wiki/Sistema)
Sistemas de informacin
Un sistema de informacin puede definirse tcnicamente como un conjunto de
componentes interrelacionados que permiten capturar, procesar, almacenar y
distribuir la informacin para apoyar la toma de decisiones y el control en una
institucin
Anlisis y diseo de sistemas
El anlisis y diseo de sistema analiza sistemticamente la entrada de datos y el
flujo de datos, el proceso de datos, almacenamiento de datos y la salida de
informacin dentro de un contexto particular. Adems el
diseo y anlisis de
sistemas se usa para analizar, disear e implementar

funcionamiento
mejoras en el
de los negocios que puedan hacer uso de los sistemas
de
informacin computarizados.
Ciclo de vida
Segn kendall & kendall Pg. 10-13
anlisis y diseo de sistemas (sexta
edicin).El anlisis y diseo de sistema de informacin 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 anlisis y diseo cuya premisa principal consiste en que los sistemas se
desarrollan mejor utilizando un ciclo especificote actividades del analista y el
usuario.
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 Identificacin de
problemas
Oportunidades y
objetivos.
2 Determinacin de
los requerimientos de
informacin
3 Anlisis de las
necesidades del
sistema
7 Implementacin y
evaluacin del
sistema
4 Diseo del
6 Pruebas y
mantenimiento del
sistema
sistema
recomendado
5 Desarrollo y
documentacin
del software
1. Identificacin de problema, oportunidades y objetivos

La primera fase requiere que el analista observe objetivamente lo que sucede
en el negocio. A continuacin, en conjunto con otros miembros de la
organizacin, el analista determina con precisin cuales son los problemas.
Con frecuencia los problemas son detectados por alguien ms, y esta es la
razn de la llamada inicial al analista. Las oportunidades son situaciones que el
analista considera susceptibles de mejorar utilizando sistemas de informacin
computarizados.
11
El aprovechamiento de las oportunidades podra permitir a la empresa obtener

una ventaja competitiva o establecer un estndar para la industria.
La identificacin de objetivos tambin es una parte importante de la primera
fase. En primer lugar, el analista debe averiguar lo que la empresa trata de
conseguir. A continuacin, podr determinar si algunas funciones de las
aplicaciones de los sistemas de informacin pueden contribuir a que el negocio
alcance sus objetivos aplicndolas a problemas u oportunidades especficos.
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 definicin del problema y un resumen de los objetivos. A continuacin, la
administracin 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 solucin a estos problemas no amerita un sistema
de cmputo, se podra sugerir una solucin diferente y el proyecto de sistema
se cancelara.
2. Determinacin de los requerimientos de informacin
La siguiente fase que enfrenta el analista es la determinacin de
requerimientos de informacin de los usuarios. Entre las herramientas que utilizan
para determinar los requerimientos de informacin de un negocio se encuentran
mtodos interactivos como las entrevistas, los muestreos, la
investigacin de
datos impresos y la aplicacin de cuestionarios, mtodos que no interfieren con el

usuario como la observacin del comportamiento de los encargados de tomar las
decisiones y sus entornos de oficina, al igual que mtodos de amplio alcance
como la elaboracin de prototipos.
12

En la frase de determinacin de requerimientos de informacin, el analista
se esfuerza por comprender la informacin que necesitan los usuarios para llevar
a cabo sus actividades. Como puede ver, varios de los mtodos para determinar
los requerimientos de informacin implica interactuar
directamente con los
usuarios. Esta fase es til para que el analista confirma la idea que tiene de la
organizacin y sus objetivos. En ocasiones slo realizan las dos primeras fases
del ciclo de vida del desarrollo de sistema. Esta clase de estudio podra tener un
propsito distinto y por lo general la lleva a la prctica un especialista conocido
como analista de informacin.
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 quin (la gente
involucrada), el qu (la actividad del negocio), el dnde (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 continuacin el analista debe preguntar la razn por la cual se utiliza el
sistema actual. Podra haber buenas razones para realizar los negocios con los
mtodos actuales, y es importante tomarlas en cuenta al disear el nuevo sistema.
Sin embargo, si la razn de ser de las operaciones actuales es que
siempre se ha hecho de esta manera, quiz ser necesario que el analista
mejore los procedimientos.
Anlisis de las necesidades del sistema
La siguiente fase que debe enfrentar el analista tiene que ver con el anlisis
de las necesidades del sistema. De nueva cuenta, herramientas y tcnicas
especiales auxilian al analista en la determinacin 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
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 tambin las decisiones
estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en
las cuales se pueden determinar las condiciones, las alternativas de condicin, las
acciones y las reglas de accin. Existen tres mtodos principales para el anlisis
de decisiones estructurada: espaol estructurado, talas y rboles de decisin.
En este punto del ciclo de vida del desarrollo de sistemas, el analista
prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un
anlisis
de
costo/beneficio
de
las
alternativas
ofrece,
en
su
caso,
recomendaciones sobre lo que se debe hacer. Si la administracin de la empresa

considera factible alguna de las recomendaciones, el analista sigue adelante.
Cada problema de sistema es nico, y nunca existe solo una solucin correcta. La
manera de formular una recomendacin o solucin depende de las cualidades y
la preparacin profesional de cada analista.
3. Diseo del sistema recomendado
El analista utiliza la informacin recopilada en las primeras fases para realizar
el diseo lgico del sistema de informacin. El analista disea procedimientos
precisos para la captura de datos que aseguran que los datos que ingresen al
sistema de informacin sean correctos. Adems, el analista facilita la entrada
eficiente de datos al sistema de informacin mediante tcnicas adecuadas de
diseo de formularios y pantallas.
La concepcin de la interfaz de usuario forma parte del diseo lgico del
sistema de informacin. 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 mens de pantalla (para
14

obtener los comandos de usuario) y diversas interfaces grficas de usuario que se
manejan a travs de un ratn o de una pantalla sensible al tacto.
La fase de diseo tambin incluye el diseo de archivos o base de datos
que almacenan en gran parte de los datos indispensables para los encargados de
tomar decisiones en la organizacin. Una base de datos bien organizada es el
cimiento de cualquier sistema de informacin. En esta fase el analista tambin
interacta con los usuarios para disear la salida (en pantalla o impresa) que
satisfaga las necesidades de informacin de estos ltimos.
Finalmente, el analista debe disear 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;
tambin podra incluir rboles o tablas de decisin, diagramas de flujo de datos, un
diagrama de flujo de sistema, y los nombres y funciones de cualquier rutina de
cdigo previamente escrita.
4. Desarrollo y documentacin 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 tcnicas estructuradas para disear y documentar
software se encuentran los diagramas de estructura, los diagramas de NassiShneiderman y el pseudocdigo. El analista se vale de una o ms de estas
herramientas para comunicar al programador lo que se requiere programar.
Durante esta fase el analista tambin trabaja con los usuarios para
desarrollar documentacin efectiva para el software, como manuales de
procedimientos. La documentacin indica a los usuarios como utilizar el software y
que deben hacer en caso de que surjan problemas derivados de este uso .Los
programadores desempean un rol clave en esta fase por que disean, codifican y
eliminan errores sintcticos de los programas de cmputo. Para garantizar la
15

calidad, un programador podr efectuar un repaso estructurado del diseo y del
cdigo con el propsito 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 informacin y su documentacin a travs
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 automtica a travs de un sitio Web. Muchos de los
procedimientos sistemticos que el analista emplea durante el ciclo de vida del
desarrollo de sistemas pueden contribuir a garantizar que el mantenimiento se
mantendr al mnimo.
6. Implementacin y evaluacin del sistema
El analista participa en la implementacin del sistema de implementacin. En
esta fase se capacita
a los usuarios en el manejo del sistema. Parte de la
capacitacin la imparten los fabricantes, pero la supervisin de sta es

responsabilidad del analista de sistemas.
El analista tiene que plantear una conversin gradual del sistema anterior al
actual. Este proceso incluye la conversin de los archivos de formatos anteriores a
los nuevos, o la construccin de una base de datos, la instalacin de equipos y la
puesta en produccin del nuevo sistema .Se menciona la evaluacin como la fase
final del ciclo de vida del desarrollo de sistemas principal mente en hora de
debate. En realidad, la evaluacin se lleva a cabo durante cada una de las fases.
16

Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigido el
sistema lo estn utilizando realmente .Debe hacerse hincapi en que, con
frecuencia, el trabajo de sistemas es cclico.
Modelo de construccin del prototipo

La elaboracin de prototipos de un sistema de informacin es una tcnica
valiosa para la recopilacin rpida de informacin especfica acerca de los
requerimientos de informacin de los usuarios. Hablando en trminos generales,
los prototipos efectivos deben hacerse tempranamente en el siclo de vida del
desarrollo de sistema, durante la fase de determinacin de requerimientos, es una
tcnica 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
formas
de
retroalimentacin.
Reacciones del usuario

Innovaciones
Sugerencia del usuario

Planes de revisin
Reacciones
del usuario: las reacciones son recopiladas
por medio de
observaciones, entrevistas y formas de retroalimentacin diseadas para recoger

la opinin de cada persona acerca del prototipo cuando interacta 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 administracin acerca de cmo refinar o cambiar el prototipo
17

presentado. Las sugerencias obtenidas de los usuarios deben apuntar al analista
hacia formas de refinacin, 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 informacin
buscada por el equipo de anlisis del
sistema, son capacidades nuevas del
sistema que no haban sido pensada antes de la interaccin con el prototipo van
ms all de las caractersticas
prototpicas actuales aadiendo algo nuevo e
innovador.
Planes de revisin: los prototipos son una visin preliminar del sistema futuro.
Los planes de revisin ayudan ha identificar prioridades para los que se debe
construir un prototipo a continuacin la informacin recolectada en la fase de
hechura del prototipo permite al analista asignar prioridades y redirigir los planes
sin realizar gastos con un mnimo de ruptura debido a esto la elaboracin de
prototipos y la planeacin van mano a mano.
Ventajas de la elaboracin 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 ms de cerca.
Desventajas de la elaboracin de los prototipos:
Es difcil manejar la elaboracin de prototipos como un proyecto dentro de un
esfuerzo de sistema ms grande.
Los usuarios y analistas pueden adoptar a un prototipo como un sistema
terminado cuando es inadecuado.
Diagramas de flujo de datos
18
Concepto
Es una representacin grafica que permite al analista definir entradas,
procedimientos
y salidas de la informacin en la organizacin bajo estudio,
permitiendo as comprender
los procedimientos existentes con la finalidad de
optimizarlos reflejndolos 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 relacin con la forma en que los datos se mueven a
travs del sistema:
1. Libertad para emprender la implementacin tcnica del sistema en las
etapas tempranas.
2. Una comprensin ms profunda de la interrelacin entre sistema y
subsistema.
3. Comunicar a los usuarios el conocimiento sobre el sistema actual mediante
diagramas e flujo de datos.
4. Anlisis de un sistema propuesto para determinar si se han definido los
datos y procesos necesarios.
Simbologas
En los diagramas de flujo de datos se usan cuatro smbolos bsicos para
graficar el movimiento de los datos: un cuadro doble, una fecha, un rectngulo
con esquinas redondeadas y un rectngulo abierto (cerrado al lado izquierdo y
abierto en el derecho). Con la combinacin de estos cuatro smbolos se puede
describir grficamente un sistema completo y varios subsistemas.
19
Estudiante
Entidad
2.1
Proceso
Crear
registro de
estudiante
Nueva informacin
del estudiante
Flujo de datos
Almacn
de datos
D3
Archivo maestro del estudiante
Normalizacin
La normalizacin es una tcnica para disear la estructura lgica de los datos de
un sistema de informacin en el modelo relacional, desarrollada por E. F. Codd en
1972. Es una estrategia de diseo de abajo a arriba: se parte de los atributos y
stos se van agrupando en relaciones (tablas) segn su afinidad. Aqu no se
utilizar la normalizacin como una tcnica de diseo de bases de datos, sino
como una etapa posterior a la correspondencia entre el esquema conceptual y el
esquema lgico, que elimine las dependencias entre atributos no deseadas. Las
ventajas de la normalizacin son las siguientes: Evita anomalas en inserciones,
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 normalizacin es el de dependencia
funcional. Una dependencia funcional es una relacin entre atributos de una
misma relacin (tabla). Si
son atributos de la relacin
funcionalmente dependiente de
asociado un solo valor de
(se denota por

e
) si cada valor de
es
tiene
pueden constar de uno o varios atributos). A
se le denomina determinante, ya que

atributo
, se dice que
determina el valor de
es completamente dependiente de
no depende de ningn subconjunto de
. Se dice que el
si depende funcionalmente de
La dependencia funcional es una nocin semntica. Si hay o no dependencias

funcionales entre atributos no lo determina una serie abstracta de reglas, sino,
ms bien, los modelos mentales del usuario y las reglas de negocio de la
organizacin o empresa para la que se desarrolla el sistema de informacin. Cada
dependencia funcional es una clase especial de regla de integridad y representa
una relacin de uno a muchos.
En el proceso de normalizacin se debe ir comprobando que cada relacin (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 normalizacin. Si una
regla no se cumple, la relacin se debe descomponer en varias relaciones que s
la cumplan.
La normalizacin 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
normalizacin, las relaciones tienen un formato ms estricto (ms fuerte) y, por lo
tanto, son menos vulnerables a las anomalas de actualizacin. El modelo
relacional slo requiere un conjunto de relaciones en primera forma normal. Las
21

restantes formas normales son opcionales. Pero es recomendable llegar al menos
a la tercera forma normal.
Primera forma normal (1FN)
Una relacin est en primera forma normal si, y slo si, todos los dominios de la
misma contienen valores atmicos, es decir, no hay grupos repetitivos. Si se ve la
relacin grficamente como una tabla, estar en 1FN si tiene un solo valor en la
interseccin de cada fila con cada columna.
Si una relacin no est en 1FN, hay que eliminar de ella los grupos repetitivos. Un
grupo repetitivo ser el atributo o grupo de atributos que tiene mltiples valores
para cada tupla de la relacin. 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 eliminarn despus mediante las restantes formas
normales
Segunda forma normal (2FN) Una relacin est en segunda forma normal si, y
slo si, est en 1FN y, adems, 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 ms atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene
un solo atributo), entonces tambin est en 2FN. Las relaciones que no estn en
2FN pueden sufrir anomalas cuando se realizan actualizaciones.
Para pasar una relacin 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 relacin con una copia de
su determinante (los atributos de la clave primaria de los que dependen).
Tercera forma normal (3FN)
Una relacin est en tercera forma normal si, y slo si, est en 2FN y, adems,
cada atributo que no est en la clave primaria no depende transitivamente de la
clave primaria. La dependencia
es transitiva si existen las dependencias
22

,
, siendo
, atributos o conjuntos de atributos de una misma
relacin.
Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en
1FN, todava pueden sufrir anomalas frente a las actualizaciones. Para pasar una
relacin 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
relacin con una copia de su determinante (el atributo o atributos no clave de los
que dependen).
Forma normal de Boyce-Codd (BCFN)
Una relacin est en la forma normal de Boyce-Codd si, y slo 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 todava pueden
existir sobre otras claves candidatas, si stas existen. La BCFN es ms fuerte que
la 3FN, por lo tanto, toda relacin en BCFN est en 3FN.
(http://es.wikipedia.org)
Diccionario de datos.
Contiene las caractersticas lgicas de los sitios donde se almacenan los datos del
sistema, incluyendo nombre, descripcin, alias, contenido y organizacin.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita
el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de
datos y auxilia a los analistas que participan en la determinacin de los
requerimientos del sistema, su contenido tambin se emplea durante el diseo.
Razones para su utilizacin:
1. Para manejar los detalles en sistemas muy grandes, ya que tienen enormes
cantidades de datos, aun en los sistemas ms chicos hay gran cantidad de
datos.
23

Los sistemas al sufrir cambios continuos, es muy difcil manejar todos los
detalles. Por eso se registra la informacin, ya sea sobre hoja de papel o
usando procesadores de texto. Los analistas mas organizados usan el
diccionario de datos automatizados diseados especficamente para el
anlisis y diseo 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 caractersticas del sistema, incluyendo partes o
componentes as como los aspectos que los distinguen. Tambin es
necesario saber bajo que circunstancias se lleva a cabo cada proceso y con
que frecuencia ocurren. Produciendo una comprensin ms completa. Una
vez que las caractersticas estn articuladas y registradas, todos los
participantes en el proyecto tendrn una fuente comn de informacin con
respecto al sistema.
4. Para facilitar el anlisis de los detalles con la finalidad de evaluar las
caractersticas y determinar donde efectuar cambios en el sistema.
Determina si son necesarias nuevas caractersticas o si estn 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
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 bsicos para todos los dems datos del sistema,
por si mismos no le dan un significado suficiente al usuario. Se agrupan para
formar una estructura de datos.
Descripcin: 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.
Descripcin: 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 especficos para los datos. Si los valores de los datos estn restringidos a un
intervalo especifico, esto debe estar en la entrada del diccionario.
Estructura de datos: es un grupo de datos que estn relacionados con otros y
que en conjunto describen un componente del sistema.
Descripcin:
Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las
siguientes combinaciones ya sea individualmente o en conjuncin con alguna otra.
Relacin secuencial: define los componentes que siempre se incluyen en una
estructura de datos.
Relacin de seleccin: (uno u otro), define las alternativas para datos o
estructuras de datos incluidos en una estructura de datos.
25

Relacin de iteracin: (repetitiva), define la repeticin de un componente.
Relacin opcional: los datos pueden o no estar incluidos, o sea, una o ninguna
iteracin.
(http://www.monografias.com)
Estudios de Factibilidad:
En general los anlisis de factibilidad ms profundos, o los estudios de
factibilidad, se completan durante la fase de diseo de sistemas, en general
durante la consideracin de la evaluacin de las diferentes alternativas de solucin
propuestas. Los estudios de factibilidad consideran la factibilidad tcnica,
econmica y operacional de cada alternativa, as como si el proyecto es o no
apropiado dados los factores polticos y otros del contexto institucional.
Factibilidad Tcnica: El anlisis de factibilidad tcnica evala si el equipo y

software estn disponibles (o, en el caso del software, si puede desarrollarse) y si
tienen las capacidades tcnicas requeridas por cada alternativa del diseo que se
est considerando. Los estudios de factibilidad tcnica tambin 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
codificacin; tales componentes y programas no son compatibles tcnicamente.
Sin embargo, puede hacerse una interfase entre los sistemas no compatibles
mediante la emulacin, la cual son circuitos diseados para hacer que los
componentes sean compatibles, o por medio de la simulacin, que es un
programa de cmputo que establece compatibilidad, pero con frecuencia estas
formas de factibilidad tcnica no estn disponibles o son demasiado costosas.
26

Factibilidad operacional:
Esta factibilidad comprende una determinacin de la probabilidad de que un nuevo
sistema se use como se supone. Deberan considerarse cuatro aspectos de la
factibilidad operacional por lo menos. Primero, un nuevo sistema puede ser
demasiado complejo para los usuarios de la organizacin o los operadores del
sistema.
Segundo, un sistema puede hacer que los usuarios se resistan a l como
consecuencia de una tcnica 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 rpido 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 econmico si la factibilidad
operacional indica que tal vez los usuarios no aceptarn el sistema o que uso
resultar en muchos errores o en una baja en la moral, el sistema no debe
implantarse.
Una ltima consideracin es la probabilidad de la obsolescencia subsecuente en
ele sistema. La tecnologa que ha sido anunciada pero que an no est disponible
puede ser preferible a la tecnologa que se encuentra en una o ms de las
alternativas que se estn comparando, o cambios anticipados en las practicas o
polticas administrativas pueden hacerse que un nuevo sistema sea obsoleto muy
pronto. En cualquier caso, la implantacin de la alternativa en consideracin se
convierte en imprctica.
Factibilidad Econmica: Los estudios de factibilidad econmica incluyen

anlisis de costos y beneficios asociados con cada alternativa del proyecto. Con
anlisis de costos/beneficio, todos los costos y beneficios de adquirir y operar
cada sistema alternativo se identifican y se hace una comparacin de ellos.
27

Primero se comparan os costos esperados de cada alternativa con los beneficios
esperados para asegurarse que los beneficios excedan a los costos. Despus la
proporcin costo/beneficio de cada alternativa se compara con las proporcionan
costo/beneficio de las otras alternativas para identificar la alternativa que sea ms
atractiva e su aspecto econmico. Una tercera comparacin, por lo general
implcita, se relaciona con las formas en que la organizacin podra gastar su
dinero
de
modo
que
no
fuera
en
un
proyecto
de
sistemas.
Los costos de implementacin incluyen comnmente el costo remanente de la

investigacin de sistemas (ara este propsito, los costos en los que ya se ha
incurrido no son relevantes), los costos de hardware y software, los costos de
operacin del sistema para su vida til esperada, y los costos de mano de obra,
material, energa, reparaciones y mantenimiento.
A travs del anlisis de costo/beneficio, la organizacin debe apoyarse en los
conceptos tradicionales de anlisis financiero y las herramientas como teora del
valor presente, anlisis de costos diferenciales y anlisis de flujos descontados.
Diagramas de UML
UML es una especificacin de notacin orientada a objetos. Se basa en las
anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide
cada proyecto en un nmero 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 esttica, 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 visin dinmica del sistema. Es decir, gracias al diseo de la parte dinmica
del sistema podemos darnos cuenta en la fase de diseo 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
28

clases continua siendo muy importante, pero se debe tener en cuenta que su
representacin es limitada, y que ayuda a disear un sistema robusto con partes
reutilizables, pero no a solucionar problemas de propagacin de mensajes ni de
sincronizacin o recuperacin ante estados de error. En resumen, un sistema
debe estar bien diseado, pero tambin debe funcionar bien.
UML tambin intenta solucionar el problema de propiedad de cdigo que se da
con los desarrolladores, al implementar un lenguaje de modelado comn para
todos los desarrollos se crea una documentacin tambin comn, 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 debera ser el
comportamiento de una parte del sistema, ya que solo especifica como deben
comportarse y no como estn implementadas las partes que define. Por ello es un
buen sistema de documentar partes del cdigo que deban ser reutilizables por
otros desarrolladores. El diagrama tambin puede ser utilizado para que los
expertos de dominio se comuniquen con los informticos 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:
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 relacin 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
Generalizacin: Es la tpica relacin de herencia.
Actores: se representan por un mueco. 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 representacin en forma general de cmo estar
compuesto el sistema indicando la trayectoria que se debe de seguir para trabajar
con cada uno de los mdulos que lo componen.
Base de datos
Dato
Un dato es la unidad o cantidad mnima de informacin no elaborada, sin sentido
en s misma, pero que convenientemente tratada se puede utilizar en la realizacin
de clculos o toma de decisiones. Es de empleo muy comn en el mbito
informtico.
(http://es.wikipedia.org/wiki/Dato)
Base de datos
30

Una coleccin compartida de datos lgicamente relacionados, junto con una
descripcin de estos datos, que estn diseados satisfacer las necesidades de
informacin de una organizacin.
Una base de datos es un repositorio centralizado posiblemente de gran tamao,
compuesto por datos que pueden ser utilizados simultneamente por mltiples
departamentos y usuarios. En lugar de disponer de una serie de archivos
desconectados con datos redundantes, todos los elementos de datos estn
integrados, mantenindose al mnimo de posibles duplicaciones.
(Sistemas de bases de datos, 4.ed. Thomas M. Connlly Pg.14)
Sistema de gestin de base de datos (SGBD)

El SGBD es el software que interacta con los programas de aplicacin 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
definicin de datos (DDL, Data Definicin 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 manipulacin 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, Pg.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 tpico bsico en PC
capaz de almacenar, ordenar y extraer datos para una gran diversidad de
aplicaciones. Access proporciona una interfaz grfica de usuario (GUI, Graphical
User Interface) para crear tablas, consultas, formularios o informes, as como
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 diseo de una aplicacin
de base de datos , llevando al usuario a travs de una serie de cuadros de
dialogo de tipo pregunta-respuesta. Tambin proporciona
generadores para
ayudar a cada usuario a construir expresiones sintcticamente correctas, como

por ejemplo las que se requieren en las instrucciones SQL.
Objetos
El usuario que interacta 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
terminologa 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 tambin pueden almacenarse y utilizarse como
origen de registro para formularios, informes y pginas de acceso de datos.
Formularios. Pueden utilizarse para diverso propsitos, como por ejemplo
crear formularios de introduccin de datos para aadir informacin 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 informacin corporativos, el ciclo de vida del desarrollo de sistema de
32

base de datos esta relativamente asociado con el de los propios sistemas de
informacin.
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 repeticin de las etapas anteriores a travs de lo que se denomina
bucles de realimentacin .por ejemplo, los problemas que se encuentran durante
el diseo de la base de datos puede necesitar una nueva labor de recopilacin y
anlisis 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 Pg.206
Etapa
Actividades Principales
Planificacin de la base de
datos
Planificacin del modo en que pueden llevarse a cabo las distintas

etapas del ciclo del vida de la forma ms eficiente y efectiva
Especificacin del mbito y los lmites del sistema de base de
Definicin del sistema
datos, incluyendo las principales vistas de usuario, tipos e usuario

y reas de aplicacin.
Recopilacin y anlisis de
requerimientos
Diseo de la base de datos
Recopilacin y anlisis de los requerimientos del nuevo sistema de

base de datos.
Diseo conceptual, lgico y fsico de la base de datos.
Seleccin del SGBD (Opcional) Seleccin de SGBD adecuado para el sistema de base de datos.
Diseo de la aplicacin
Prototipado (Opcional)
Diseo de la interfaz de usuario y de los programas de aplicacin

que sirvan para utilizar y procesar los datos de la base de datos.
Construccin de un modelo funcional del sistema de base de
33

datos que permite a los diseadores o usuarios visualizar y evaluar
el aspecto y la funcin del sistema final.
Creacin de las definiciones fsicas de la base de datos y de los
Implementacin
programas de aplicacin.
Carga de los datos del antiguo sistema en el nuevo, y siempre que
Conversin y carga de datos
sea posible, conversin 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 validacin de la
Pruebas
misma con respecto a los requerimientos especificados por los

usuarios
El sistema de base de datos esta completamente implementado,
despus de lo cual se lo monitoriza y mantiene de manera
Mantenimiento operativo
continua. Cundo sea necesario, se incorporaran nuevos requisitos

al sistema de base de datos aplicando de nuevo las etapas
precedentes del ciclo de vida.
34

Herramientas CASE
La primera etapa del ciclo de desarrollo de un sistema de base de datos, es la
especificacin de la base de datos, puede tambin implicar la seleccin 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 ingeniera de software. El personal de administracin de datos y de
la administracin 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 ms eficiente y efectiva posible.
El soporte CASE puede incluir:
Un diccionario de datos para almacenar informacin acerca de los datos del
sistema de base de datos;
Herramientas de diseo para soportar el anlisis de datos;
Herramientas que permita el desarrollo del modelo de datos corporativo y
de los modelos conceptual y lgico de los datos;
Herramientas que permitan el prototipado de aplicacin.
Las herramientas CASE Se dividen en tres categoras:
1. CASE de alto nivel que soporta las etapas iniciales del ciclo de
desarrollo de los sistemas de base de datos, desde la planificacin
hasta el diseo de la base de datos.
2. CASE de bajo nivel soportan las ultimas etapas del ciclo de vida
desde la implementacin 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.
35
Preguntas directrices
1. Existen antecedentes a cerca del sistema de matricula del colegio san
pablo?
2. Qu dificultades lleva a la secretaria el proceso de almacenamiento de
recibos?
3. Qu tipo de informacin almacenan al realizar la matricula?
4. El sistema agilizar la recepcin de matriculas?
36
Diseo Metodolgico
Para la recoleccin de los requisitos se utilizo las entrevistas. Construimos el
prototipo a travs del mtodo lineal.
Poblacin: La poblacin que utilizara el prototipo es una persona
Muestra: Como la poblacin consta de uno se selecciono al nico usuario del
prototipo.
Periodo De Estudio: El periodo abarca el primer semestre del ao 2007
Instrumento de recoleccin de informacin
Para reunir la informacin se realiz la siguiente entrevista con preguntas cerradas
a la encargada de secretaria del colegio san pablo de acuerdo al cuestionario
preestablecido.
Diseo
Las preguntas se realizaron en base a las caractersticas principales del prototipo:
La interfaz, sus beneficios, cumplimiento de los requerimientos del proceso de
matrcula .se redactaron preguntas cerradas para escribir las respuestas de la
entrevistada. Posterior a un anlisis y discusin de los resultados para su
interpretacin.
Fuentes primarias
Fuentes primarias: Personal de secretaria del colegio San Pablo, Libro de;
metodologa de la investigacin, anlisis y diseo de sistema, sistema de base de
datos
Fuentes secundarias: Internet
37
Resultados
El prototipo cumple en un 100% con los requerimientos del colegio en el
proceso de matrcula, ocupacin, centro de estudios, ubicacin ya que se
ajusta al formato de hoja de matricula
Esta bien estructurado en un 100% los catlogos e informes porque cumple
con las necesidades del colegio.
Las operaciones matricula y recibo estn apropiadas y fciles de usar en un
100% al rellenar un recibo de un estudiante y realizar matricula
Las pantallas son fciles de utilizar en un 100% porque tienen distintos

botones como: Agregar, eliminar y salir, ir a registro nuevo que le ayudan a
recorrer los registros
La interfaz esta sencilla pero se acomoda a las necesidades del colegio.
Con ms frecuencia examinara: Informe de listado de estudiante, recibo
de estudiantes por ao, listado de estudiantes por colegio.
Las modificaciones al prototipo no sern necesarias por su diseo factible,
adaptable y sencillo.
38
Anlisis y Discusin de resultados

El prototipo cumple con los requerimientos de usuario, ya que es adecuada la
interfaz; De manera sencilla el usuario
circula por las distintas pantallas de
entrada y salida; Adems los colores le dan realce y seriedad a las operaciones
que se realizan en el prototipo que son matricula y recibo y proporciona informes
de inters para evaluaciones mensuales sobre informe de recibo en el control
financiero.
39
Conclusiones
El sistema cumple con los requerimientos establecidos por el colegio san
pablo (pantallas de entradas de estudiantes y matrcula).
El sistema permite almacenar los registros de matrcula y estudiante como
una manera de respaldar a la informacin que se efectan anualmente,
para acceder a ella cuando sea adecuado.
El sistema permite el control de los proceso como matricula y recibo.
El sistema proporciona al usuario llevar a cabo: El control, manejo, de la
informacin de los estudiantes, los recibos, los centros que provienen los
distintos estudiantes estudios etc.) e informes (vista previa de recibo y de
matricula.), reportes de estudiantes por ao de manera: Rpida, efectiva y
segura.
40
Recomendaciones
1. Recibir capacitaciones sobre el uso de sistemas de base de datos

2. Creacin de copias de respaldo de la base de datos del sistema de
matrcula
3. Realizar el mantenimiento preventivo y correctivo del equipo para
mantenerlo protegido contra daos de hardware y software
4. Utilizacin del sistema segn los procedimientos que se establecen en el
manual de usuario
41
Bibliografa
Anlisis y diseo de sistemas (sexta edicin) Kendall & Kendall

Sistema de base de datos (4 edicin) Thomas M. Connolly,
Carolyn E. Begg
Metodologa de la investigacin cientfica (tercera edicin)
Hernandez Sampieri
Webgrafa:
(es.wikipedia.org/wiki/Sistema)
(http://es.wikipedia.org)
(http://www.monografias.com)
(http://www.monografias.com/cgibin/search.cgi?substring=0&bool=
and&query=diccionario+de+datos
(http://usuarios.lycos.es/oopere/uml.htm)
(http://es.wikipedia.org/wiki/Dato)
(http://www.monografias.com).
42
43

REPRESENTACION GRAFICA DEL PROCESO DE MATRICULA MANUAL
DEL COLEGIO SAN PABLO
Pasa con
Estudiante va ha
matricularse
La Secretaria
verifica que cumpla
con los requisitos
El estudiante
Pasa donde la
secretaria
La secretaria
Procede a
registrar al
estudiante
El estudiante
se marcha ya
matriculado
44
Diagrama de Flujo de Datos

Nivel 0
45

Nivel 1
Diagrama de Dilogo
46
Diagrama de Entidad Relacin del colegio san pablo
Matricula
Centroest
Estudiante
Recibos
Ocupacin
Ubicacin
47
Entidades del sistema de Matricula en el Diagrama E_R

Estudiante
Matricula
Centroest
Ocupacin
Recibo
Estudiante
Matricula
Centroest
Ocupacin
cod_ocupacion
1
nombre_m
cod_ocupacion
nombre_p
telfono
sexo
Edad
fecha_n
direccion_e
apellido2
apellido1
nombre1
nombre2
no_estudiante
ao_grado
Certificado_N
constancia_con
d
codcentroe
Modalidad
Cicloacad
Fecha
Partida_Nac
no_estudiante
Nomat
Nombre_
C
codcentro
e
Cod_ocupacio Cantida
n
d_N
Cantida
descripcin
d_L
Concept
o
Mes _
paga
Recibo
Ubicaci
n
No _ aula
no_estudi
ante
ao_grado
Ubicacin
48
Estudio de Factibilidad
Factibilidad Tcnica
Hardware:
Disco Duro : 40GB
Microprocesador : 1 GHz
Memoria Ram : 256MB
Unidad de CD : No tiene
Unidad de Disquete : 3 1/2 MB
Tarjeta Madre : Intel
Puerto USB: No tiene
Puerto PS/2: Activo
Mause: Activo
Teclado: Activo
Parlantes: Activo
Estabilizador: No tienen
Batera :Activo
Monitor
Clon 14P
Impresora
Software
matricial
Programas para bases de dato:

MICROSOFT VISUAL access
Factibilidad Econmica
Precio de Computadora: $400
Costo de impresora: $80
Costo de Monitor: $100
Precio de Licencia de Microsoft Office: $150
Costo del Sistema Anlisis, diseo, pruebas, prototipo e
implementacin: $200
Resma de Papel: C$ 15
Gasto total: $ 950.
49
DICCIONARIO DE DATO
A
Alias
: Ao
Nombre
: Ao que cursa
Tipo de Clave
: Alternativa
Descripcin
: Especifica el ao acadmico que cursa el estudiante,
independientemente de la modalidad ya sea preescolar, primaria o secundaria

Longitud
: 12
Tipo
: Carcter
Valor
Tablas en que Aparece :

Matrcula, Ubicacin, recibo
Observaciones
Alias
: Apellido1
Nombre
: Primer Apellido
Tipo de Clave
: Alternativa
Descripcin
: Especifica el primer apellido del estudiante
Longitud
: 20
Tipo
: Carcter
Valor
Tablas en que Aparece : Estudiante

Observaciones
Alias
: Apellido2
Nombre
: Segundo Apellido
Tipo de Clave
: Alternativa
Descripcin
: Especifica el Segundo apellido del estudiante
Longitud
: 20
Tipo
: Carcter
Valor
Tablas en que Aparece : Estudiante

Observaciones
50

C
Alias
: Cant_r_l
Nombre
: Cantidad de recibo en letra
Tipo de Clave
: Alternativa
: Especifica la cantidad en letra por cualquiera de los servicios
Descripcin
que requieren pago

Longitud
: 80
Tipo
: Carcter
Valor
Tablas en que Aparece : Recibo

Observacionais
Alias
: Cantidad_n
Nombre
: Cantidad numrica en letras
Tipo de Clave
: Alternativa
Descripcin
: Especifica la cantidad en letra por cualquiera de los servicios
que requieren pago

Longitud
: 80
Tipo
: Carcter
Valor
Tablas en que Aparece: Recibo

Observaciones
Alias
: Centro_est
Nombre
: Centro de procedencia
Tipo de Clave
: Alternativa
: Especifica el nombre del centro que procede el estudiante
Descripcin
nuevo y reingreso
Longitud
: 32
Tipo
: Carcter
Valor
Tablas en que Aparece : Centro_procedente

Observaciones
51

Alias
: Ciclo_acad
Nombre
: Ciclo acadmico
Tipo de Clave
: Alternativa
Descripcin
: Especifica el ao lectivo del estudiante
Longitud
: 6
Tipo
: Numrico
Valor
Tablas en que Aparece : Matricula, recibo y estudiante

Observaciones
Alias
: Cod_cp
Nombre
: Cdigo del centro de procedencia
Tipo de Clave
: principal
Descripcin
: Especifica el cdigo del centro de procedencia del que viene
el estudiante
Longitud
: 10
Tipo
: Carcter
Valor
Tablas en que Aparece: Centro de procedencia

Observaciones
Alias
: Concepto
Nombre
: Concepto de recibo
Tipo de Clave
: Alternativa
Descripcin
: Especifica el pago de matricula y el arancel de enero que
efecta un estudiante
Longitud
: 10
Tipo
: Carcter
Valor
Tablas en que Aparece : recibo

Observaciones
D
Alias
: Direccion_e
52

Nombre
: Direccin de estudiante
Tipo de Clave
: Alternativa
Descripcin
: Especifica la direccin domiciliar del estudiante
Longitud
: 50
Tipo
: Carcter
Valor
Tablas en que Aparece : Matrcula, estudiante

Observaciones
F
Alias
: Fecha_m
Nombre
: Fecha de matricula
Tipo de Clave
: Alternativa
Descripcin
: Especifica el dia, mes y ao en que se matricul el estudiante
Longitud
: 10
Tipo
: Fecha
Valor
Tablas en que Aparece : Matricula

Observaciones
Alias
: Fecha_n
Nombre
: Fecha de Nacimiento
Tipo de Clave
: alternativa
Descripcin
: Especifica el da, mes y ao que naci el estudiante
Longitud
: 12
Tipo
Valor
Tablas en que Aparece: Matricula, Estudiante

Observaciones
53

Alias
: Fecha_r
Nombre
: Fecha de recibo
Tipo de Clave
: Alternativa
Descripcin
: Especifica la fecha que se le entregara el recibo al estudiante
ya matriculado
Longitud
: 10
Tipo
: Carcter
Valor

Observaciones
M
Alias
: Mes _ paga
Nombre
: Mes de pago
Tipo de Clave
: Alternativa
Descripcin
: Especifica que mes cancela el estudiante
Longitud
: 12
Tipo
: Carcter
Valor
Tablas en que Aparece: Matricula, recibo

Observaciones
Alias
: Modalidad
Nombre
: modalidad del estudiante
Tipo de Clave
: Alternativa
Descripcin
: Especifica el nivel acadmico al que ingresa el estudiante
Longitud
: 12
Tipo
: Numrico
Valor
Tablas en que Aparece: Estudiante, Matricula

Observaciones
54

N
Alias
: No _ aulas
Nombre
: Numero de aula
Tipo de Clave
: Alternativa
Descripcin
: Especifica el numero de aula al que va el estudiante
Longitud
: 2
Tipo
: Carcter
Valor
Tablas en que Aparece: Ubicacin

Observaciones
Alias
: No _ estudiante
Nombre
: Numero del estudiante
Tipo de Clave
: Alternativa
Descripcin
: Especifica el orden en que fue anotado el estudiante
Longitud
: 2
Tipo
: Numrico
Valor
Tablas en que Aparece: Matricula

Observaciones
Alias
: No _ recibo
Nombre
: Numero del recibo
Tipo de Clave
: Alternativa
Descripcin
: Especifica el recibo que se le dar al estudiante matriculado
Longitud
: 16
Tipo
: Carcter
Valor

Observaciones
55
Alias
: Nombre_cp
Nombre
: cdigo del centro de procedencia
Tipo de Clave
: Alternativa
Descripcin
: Especifica la direccin del centro de procedencia del que
viene el estudiante
Longitud
: 10
Tipo
: Carcter
Valor
Tablas en que Aparece: Centro de procedencia

Observaciones
Alias
: Nombre_m
Nombre
: nombre de la madre
Tipo de Clave
: Alternativa
Descripcin
: Especifica el nombre de la madre del estudiante
Longitud
: 10
Tipo
: Carcter
Valor
Tablas en que Aparece: Estudiante

Observaciones
Alias
: Nombre_p
Nombre
: nombre del padre
Tipo de Clave
: Alternativa
Descripcin
: Especifica el nombre del padre del estudiante
Longitud
: 10
Tipo
: Carcter
Valor

Observaciones
56

Alias
: Nombre1
Nombre
: Primer nombre
Tipo de Clave
: Alternativa
Descripcin
: Especifica el primer nombre del estudiante
Longitud
: 10
Tipo
: Carcter
Valor

Observaciones
Alias
: Nombre2
Nombre
: Segundo nombre
Tipo de Clave
: Alternativa
Descripcin
: Especifica el segundo nombre del estudiante
Longitud
: 12
Tipo
: Carcter
Valor
Tablas en que Aparece: estudiante

Observaciones
O
Alias
: Ocupacion_m
Nombre
: Ocupacin de la madre
Tipo de Clave
: Alternativa
Descripcin
: Especifica la ocupacin de la madre del estudiante
Longitud
: 10
Tipo
: Carcter
Valor
Tablas en que Aparece: Ocupacin

Observaciones
57

Alias
: Ocupacion_p
Nombre
: Ocupacin de padre
Tipo de Clave
: Alternativa
Descripcin
: Especifica la ocupacin del padre del estudiante
Longitud
: 10
Tipo
: Carcter
Valor
Tablas en que Aparece: Ocupacin

Observaciones
S
Alias
: Seccin
Nombre
: Seccin
Tipo de Clave
: Alternativa
Descripcin
: Especifica la seccin al que el estudiante va
Longitud
: 2
Tipo
: Carcter
Valor

Observaciones
Alias
: Sexo
Nombre
: Sexo del estudiante
Tipo de Clave
: Alternativa
Descripcin
: Especifica el sexo del estudiante
Longitud
: 10
Tipo
: Carcter
Valor

Observaciones
58

T
Alias
: Telefono_e
Nombre
: Telfono del estudiante
Tipo de Clave
: Alternativa
Descripcin
: Especifica el numero del estudiante
Longitud
: 10
Tipo
: Numrico
Valor

Observaciones
Alias
: Turno_e
Nombre
: Turno del estudiante
Tipo de Clave
: Alternativa
Descripcin
: Especifica el turno del estudiante
Longitud
: 10
Tipo
: Carcter
Valor

Observaciones
U
Alias
: Ubicacin
Nombre
: Ubicacin
Tipo de Clave
: Alternativa
Descripcin
: Especifica la ubicacin del pabelln al que va el estudiante
Longitud
: 10
Tipo
: carcter
Valor
Tablas en que Aparece: Matricula

Observaciones
59
MANUAL DE USUARIO
Para manejar este prototipo
establecen a continuacin:
debe de seguir los siguientes pasos que se
Una vez que enciendes la computadora lo primero que debe de hacer es dar
doble clic en la carpeta del sistema de matricula que esta ubicado en mis
documentos. Debes dar doble clic en el archivo de access con el nombre
sistemacademico entonces te aparecer la siguiente pantalla de entrada al
sistema donde vamos ha poder acceder al llamado de todos los formularios y a si
hacer uso de cada una.
De clic en entrar y aparecer la siguiente pantalla que es la del men principal

donde podemos acceder a la siguiente pantalla que contiene el men principal
que son catlogos, operaciones, informes y salir
Damos clic en catlogos para ingresar al formulario estudiante que aparese en la

siguiente pantalla
60
En la pantalla estudiante das clic para hacer uso del formulario para ingresar a
cada estudiante que ser matriculado donde llenaras cada registro de manera
secuencial y si el estudiante es nuevo los vas agregar dando doble clic para
anexar uno nuevo.
En esta pantalla podrs anexar todos los datos de cada centro de estudio del cual
proviene cada estudiante esto lo hars llenando los formularios y dando clic en
agregar y listo queda almacena
61

En la pantalla ocupacin almacenara los datos de la ocupacin de los padres de
familia de cada estudiante y as llevar el control de cada registro existente y
nuevo.
En la pantalla de ubicacin almacenara la informacin de la ubicacin al que va

el estudiante ya sea seccin o pabelln as podrs controlar cada registro.
Esta pantalla presenta las operaciones de matricula, recibos y salir para que
estas sean llenadas de forma secuencial debes de dar clic a una para acceder a
la que tu decidas y a si poder anexar los datos.
62

En esta pantalla para acceder y agregar un registro nuevo debes de dar doble
clic en matricula lo anexas y listo agregaste un registro nuevo
En esta pantalla puedes generar los recibos que t quieras y si deseas imprimir
das clic en archivo seleccionamos la opcin imprimir y listo, y sino solo los
guardas.
Pantalla de informes
genera vista previa de todos los estudiantes ya
matriculados, vista previa de listado de estudiantes actuales, vista previa de
recibos y si lo deseas puedes imprimir matricula, imprimir listado de estudiantes
e imprime recibo
63
Esta barra de desplazamiento est ubicada en la parte inferior en todas las

pantallas; Podr recorrer todos los registros almacenados en cada formulario y al
mismo tiempo visualizarlos esto lo hace dando
clic en cada pestaa y
automticamente le mostrar los datos que tu desees ver
A continuacin les mostramos los siguientes comandos que se utilizaran en cada

una de las pantallas y su significado. En los cuales les mostrar: Estudiante,
Centro procedente, Ocupacin, Ubicacin, Matricula, y Recibo.
Agregar: Este comando nos permite agregar un registro nuevo a cada pantalla
Eliminar: Nos permite eliminar registros existentes en cada pantalla
Salir: Nos manda fuera de la pantalla del formulario ya ejecutado
64
Entrevista al usuario del sistema

1) El prototipo del sistema cumple con los requerimientos que
necesita el Colegio San Pablo?
2) Qu le parece la estructura de las pantallas de informes y
catlogos?
3) Est conforme con las operaciones matrcula y recibo que
realiza el sistema?
4) Son fciles de usar las pantallas del prototipo?
5) Le gust la interfaz del prototipo del sistema?
6) Optara por cambiar los colores de las pantallas del prototipo?
7) Qu consulta realizara en la con mas frecuencia?
8) Considera necesaria alguna modificacin al prototipo del sistema?
65

Sistema Colegio SAN PABLO

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema Colegio SAN PABLO

Cargado por

Copyright:

Formatos disponibles

Carrera: Licenciatura en Ciencias de la Computacin

Tutora: Sonia Rojas Fargas.

12 de octubre del 2007

Prototipo de sistema de control de matricula del colegio san pablo

matricula y recibo de acuerdo al establecido por el

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

Tema: Sistema de control de Matricula del colegio san pablo

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

tres modalidades de clases: preescolar, primaria,

laboratorio de informtica que es utilizado para dar clases de

Microsoft office no para el registro de matricula, se ven en

guardar la informacin por medio de registro manual, implica una problemtica de

nuevo y de reingreso ;as como tambin los requisitos que el

colegio les solicita a los estudiantes y el pago de matricula reflejado en el control

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

tecnologas computarizadas ofrecen

informacin en orden, llevar un mejor control y proporcionar integridad en los

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

sistemas se usa para analizar, disear e implementar

de los negocios que puedan hacer uso de los sistemas

anlisis y diseo de sistemas (sexta

edicin).El anlisis y diseo de sistema de informacin es enfoque se incluye en

Prototipo de sistema de control de matricula del colegio san pablo

1. Identificacin de problema, oportunidades y objetivos

Prototipo de sistema de control de matricula del colegio san pablo

El aprovechamiento de las oportunidades podra permitir a la empresa obtener

datos impresos y la aplicacin de cuestionarios, mtodos que no interfieren con el

Prototipo de sistema de control de matricula del colegio san pablo

directamente con los

Prototipo de sistema de control de matricula del colegio san pablo

recomendaciones sobre lo que se debe hacer. Si la administracin de la empresa

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

Prototipo de sistema de control de matricula del colegio san pablo

a los usuarios en el manejo del sistema. Parte de la

capacitacin la imparten los fabricantes, pero la supervisin de sta es

Prototipo de sistema de control de matricula del colegio san pablo

Modelo de construccin del prototipo

Reacciones del usuario

Sugerencia del usuario

del usuario: las reacciones son recopiladas

observaciones, entrevistas y formas de retroalimentacin diseadas para recoger

Prototipo de sistema de control de matricula del colegio san pablo

sistema, son capacidades nuevas del

prototpicas actuales aadiendo algo nuevo e

Prototipo de sistema de control de matricula del colegio san pablo

y salidas de la informacin en la organizacin bajo estudio,

los procedimientos existentes con la finalidad de

optimizarlos reflejndolos en el sistema propuesto.

Ventajas del enfoque del flujo de datos

Autor: Franklin Ramn Mendoza Salazar

Prototipo de sistema de control de matricula del colegio san pablo

Archivo maestro del estudiante

Prototipo de sistema de control de matricula del colegio san pablo