CAPITULO 1 MARCO LOGICO 1.

1 INTRODUCCION En este tiempo los sistemas basados en computadora son ms necesarios para las actividades de las empresas e instituciones, para administrar grandes volmenes de informacin que cada da van creciendo. El fortalecimiento de los recursos humanos en un pas tiene como una de sus bases la educacin. La constante evolucin de la tecnologa informtica y el consecuente incremento de la necesidad de aplicaciones computacionales en organizaciones e instituciones, hace trascendental la necesidad de construir sistemas de informacin oportunos y confiables, que permitan mantener a las instituciones, tecnolgica y cientficamente informadas para una mejora en la toma de decisiones. El Colegio Particular Tokio CPT no est al margen de la utilizacin de esta nueva tecnologa, puesto que la adecuada administracin de la informacin es fundamental para la toma de decisiones. Respondiendo a sta necesidad de contar con un sistema de informacin, que apoye y agilice al trabajo habitual del colegio para lograr un buen desempeo en las labores acadmicas y administrativas, se planteo el Sistema de gestin de Informacin de manejo de informacin actualizada de los alumnos del CPT . Desde la inscripcin, pago y control de pensiones y un seguimiento acadmico del alumno. 1.1.1 ANTECEDENTES

Utilizar sistemas de informacin para apoyar las tareas de administracin de control de pago de pensiones del colegio mencionado. Ya se dio con anterioridad en nuestro medio por lo que se toma como referencia proyectos que proponen un modelo para la incorporacin de un sistema de informacin para apoyar a la administracin de control de pago de pensiones. El colegio se encuentra ubicado en la ciudad de La Paz, Zona Bella Vista, que nace en Marzo del 2007 gracias al Sr. Paz que acepta el desafo de crear un lugar de educacin para nios y jvenes de la zona. Actualmente el sistema utilizado en el CPT es manual, el problema radica en el tratamiento de la informacin a inicio de gestin con las inscripciones y a final de cada gestin con la actualizacin de notas en el kardex del alumno y la posterior entrega de libretas, lo cual retrasa la informacin Muchos colegios hacen uso de Sistemas de Informacin, por la gran ayuda que brinda en la Administracin.

Sistema de Control y seguimiento acadmico para colegios Caso de estudio: Colegio La Salle8 elaborado por Rudy Oliver Saavedra Pereira. El sistema est orientado para que los padres de familia, directores, profesores y psiclogos, puedan realizar el control y seguimiento acadmico de los estudiantes en distintas reas de aprendizaje. El Colegio Particular Tokio CPT como unidad educativa, no escapa a esta situacin, por esto surge la necesidad de un Sistema de gestin de Informacin acadmica y administrativa, de tal forma que se pueda tener Informacin Almacenada y gestionada de manera ptima. Actualmente cuenta con un proceso de almacenamiento digital, pero que no satisface todas las necesidades tanto de profesores como del personal administrativo, ya que

algunos de los procesos siguen siendo manuales.

1.1.2

IDENTIFICACION DEL PROBLEMA

El Colegio Particular Tokio tropieza con dificultades en cuanto al manejo de informacin debido a la aplicacin de mtodos tradicionales que no dan solucin a los problemas que se mencionan a continuacin: Generacin de informacin inadecuada e inoportuna, del movimiento econmico del colegio. El acceso a la informacin acadmica es restringido. Falta de un kardex por alumno y personal del colegio. Falta de un historial del alumno Dificultad en la elaboracin de informes en los procesos de consultas, inscripciones, pago de pensiones, pago de sueldos. Carencia de informacin capaz de generar datos confiables y rpidos de los alumnos, ocasionando inseguridad en la toma de decisiones. PLANTEAMIENTO DEL PROBLEMA

1.1.3

En consideracin a lo mencionado se propone lo siguiente: Desarrollar y aplicar un Sistema de Gestin de Informacin Acadmica y Administrativa, minimizar y descongestionar el accionar operativo en lo que respecta al tiempo y los recursos humanos? 1.1.4 ARBOL DE PROBLEMAS 1.1.5 ARBOL DE OBJETIVOS OBJETIVOS 1.2.1 OBJETIVO GENERAL Disear un sistema de informacin que sirva para la administracin del colegio CPT , para minimizar y descongestionar el accionar operativo en lo que respecta al tiempo y los recursos humanos en los procesos de administracin de informacin, que permita mejorar el tiempo de espera en el proceso de inscripciones y agilizar los procesos administrativos proporcionando de esta manea informacin eficiente, estadstica confiable y oportuna. 1.2.2 OBJETIVOS ESPECIFICOS Implementar un historial acadmico del alumno. Implementar un kardex por alumno, por personal del colegio. Automatizar los procesos de inscripciones, seguimiento acadmico del estudiante, generacin de reportes institucionales. Automatizar los procesos de pagos de pensiones Obtener un nivel de calidad satisfactorio para el usuario.

1.2

Mejorar el proceso de inscripciones en el colegio CPT utilizando la metodologa RUP (Proceso Unificado para Desarrollo de Software).

Mejorar la manipulacin de informacin y que la misma sea precisa, oportuna, coherente y de alta calidad.

1.3

ALCANCE Los lmites del presente proyecto estn enmarcadas dentro de las necesidades encontradas al momento de haber realizado el estudio respectivo y llegando a la conclusin de realizar una base de datos para el proceso de inscripciones y tomar los diferentes mdulos como ser: - Modulo de inscripciones. Permitir la actualizacin de informacin en el sistema solo a usuarios autorizados para tal propsito. - Modulo de pago y control de pensiones, Control de ingresos y egresos econmicos del colegio. - Modulo acadmico. - Un seguimiento acadmico a cada estudiante de los diferentes cursos del colegio. - Los padres de familia podrn consultar las notas de sus hijos de cada gestin acadmica, su record acadmico, horarios, fecha de inscripcin, inicio de clases y la informacin necesaria. JUSTIFICACION El desarrollo de un sistema de administracin de informacin para colegios traer un gran beneficio a las personas involucradas directamente con el Colegio Particular Tokio. 1.4.1 JUSTIFICACION TECNICA El desarrollo del presente proyecto, se basar en el uso de la tecnologa actual existente de carcter gratuito para el desarrollo de gestin de base de datos remota, permitiendo, herramientas de gestin, anlisis o investigacin se justifica tcnicamente 1.4.2 JUSTIFICACION ECONOMICA Ahorro en los gastos, pues se cuenta con el hardware necesario, y de licencias de las distintas herramientas que se utilizar para la implantacin del sistema como ser PHP, Smarty, ADOdb, MySQL, porque stas ltimas son de carcter gratuito, se justifica econmicamente. 1.4.3 JUSTIFICACION SOCIAL El profesor obtendr la informacin acadmica de sus alumnos desde una terminal conectada a la Intranet. El contador obtendr la informacin de pagos de salarios al personal del colegio y el pago de las pensiones de los estudiantes, el personal administrativo actualizar la informacin acadmica de los estudiantes, en ambos casos previa autenticacin del usuario, se justifica socialmente.

1.4

1.5

METODOS DE INVESTIGACION Y HERRAMIENTAS La herramienta que se utilizara en la parte de anlisis es realizando visitas al colegio, realizando una investigacin cuantitativa estadsticamente analizaremos los datos extrados por medio de encuestas ,y observando el entorno la cual nos ayudara a obtener informacin de los problemas que existen en el control de esta informacin obtenida que nos permitir solucionar y mejorar los problemas. Para la elaboracin de este proyecto se utilice lo siguiente: Se utilice como metodologa de desarrollo unificado Racional RUP, que es proceso de desarrollo de software que transforma los requisitos de un usuario en un sistema software,

que permite definir la arquitectura del sistema que est dirigida por los casos de uso y se caracteriza por ser iterativa e incremental. El cual hara uso de la herramienta de modelado de datos UML (Unified Modeling Language), para el modelado de datos, componentes y flujos de trabajo del sistema y documentar los elementos que conforman el software orientado a objetos y clases. Segn RUP y UML se utilizara para modelar los requerimientos Anlisis, Diseo, implementacin y pruebas, cada uno ser desarrollado con diagramas de acuerdo a la notacin UML (lenguaje Unificado de construccin de modelos). Se lo realizara en el diseo de tres capas que son la interfaz de usuario y la interfaz de aplicacin que ser utilizada por el mtodo que ser utilizada por el mtodo de programacin visual tomando como herramienta el lenguaje PHP, para la implementacin, utilizando el ambiente Windows 98\ Milenium /NT/ XP /2000 y la interfaz de base de datos ser implementada por el motor de base de datos MySql que se empleara para el almacenamiento de datos del sistema.

CAPITULO 2 MARCO TEORICO

2.1 ANTECENDENTES DE LA ORGANIZACION El Colegio Particular Tokio, como unidad de formacin acadmica, es un caso de requerimiento de tecnologas que manejen y optimicen el tiempo de gestin que realiza un usuario, para la manipulacin de la informacin, y as asegurar la calidad de la misma, para lo cual se ha pensado en un sistema de Gestin de Informacin Acadmica y administrativa, lo cual permitir interactuar con los usuarios procesando sus peticiones. Se utilizar el organigrama para mostrar en que nivel dentro de la estructura jerrquica se encuentra el rea en el cual se desarrolla el sistema de Gestin de Informacin Acadmica y administrativa del colegio particular Tokio. La estructura organizativa del Colegio Particular se halla configurada de la siguiente manera:

Direccin general

Direccion Academica

Secretara y Kardex

Contabilidad

Coordinador General

Administrativos

Coordinador primaria

Coordinador Secundaria

Profesores Inicial

Profesores Primaria

Profesores Secundaria

2.1.1 Descripcin de funciones de cada rea A continuacin se describen las funciones de las reas en las cuales se desarrolla el Sistema de Gestin de Informacin acadmica y Administrativa. Direccin Acadmica Est encargada de manejar la parte acadmica del colegio tiene como objetivo organizar y planificar la ejecucin de las actividades acadmicas del colegio en todas las reas. Entre las funciones que desempea se puede sealar: Elaboracin del calendario de clases Control y evaluacin de profesores Asignacin de aulas Asignacin de horarios, cursos y paralelos. Coordina el inicio y finalizacin de las clases con la direccin general. Seguimiento acadmico de los estudiantes.

Secretara y kardex Contribuye al normal desarrollo de los procesos acadmicos-administrativos. Entre las funciones que desempea se puede sealar: Inscripcin de estudiantes de acuerdo al calendario establecido por la direccin acadmica. Atender reclamos durante las inscripciones. Proporcionar informacin acadmica a profesores. Emisin de listas de alumnos por curso. Emisin de boletines de calificaciones trimestrales y anuales por alumno Emisin de centralizadores trimestrales y anuales por curso

Elaborar certificados de notas para estudiantes que concluyeron sus estudios en el colegio. - Emisin de informes del rendimiento acadmico estudiantil. Contabilidad Est encargada de manejar los recursos econmicos del colegio. Entre las funciones que

desempea se puede sealar: Cobro de pensiones de los estudiantes Cobro de cuotas de refrigerios de los estudiantes Venta de materiales escolares (uniformes, libros, tiles en general) Pago de salarios a profesores y administrativos

2.1.2 Descripcin de procesos de cada rea A continuacin se detalla los procesos relevantes para el sistema, para los que se requiere dar una solucin.

Direccin Acadmica a) Asignacin de horarios Al inicio de cada gestin acadmica se tiene que elaborar los horarios de clases para cada curso del colegio, de acuerdo a la disponibilidad de horarios de los profesores, una vez terminado esto se registra los horarios acordados por los profesores y se entrega en rea de kardex para ser registrado.

b) Coordina el inicio y finalizacin de las clases con la direccin general Se elabora el cronograma de actividades acadmicas y de acuerdo a ste se realiza el proceso de inscripciones, la entrega de notas de los profesores, entrega de notas a los padres de los estudiantes del colegio. c) Seguimiento acadmico de los estudiantes. Se realiza en el transcurso de la gestin acadmica, para lo que se requiere realizar consultas de la informacin acadmica de cada estudiante. Secretara y kardex d) Inscripcin de estudiantes de acuerdo al calendario establecido por la direccin acadmica De acuerdo al cronograma de actividades acadmicas elaborado por la direccin acadmica se realiza la inscripcin de los estudiantes. El proceso comienza con la solicitud del padre de familia que desea inscribir a su hijo(a),

para lo cual brinda los datos personales requeridos, dicha informacin es llenada en un formulario por el encargado de realizar la inscripcin, una vez terminada esta operacin se hace entrega de la boleta de inscripcin del alumno. e) Proporcionar informacin acadmica a profesores. Los profesores para cumplir sus actividades solicitan la informacin de sus alumnos, la cual consiste en listados de alumnos por cursos, telfonos de sus alumnos, nombres de padres de alumnos, dicha informacin puede es entregada en forma impresa. f) Emisin de listas de alumnos por curso Estos listados de alumnos son requeridos para el control de asistencia de los alumnos, los cuales son impresos. g) Emisin de boletines de calificaciones trimestrales y anuales por alumno Se emite cada fin de trimestre y cada fin de ao, esto es para ser entregado a los padres de los estudiantes, para que puedan ver el aprovechamiento acadmico de sus hijos. h) Emisin de centralizadores trimestrales y anuales por curso Se emite cada fin de trimestre y cada fin de ao, esto es para ser entregado a la distrital departamental de educacin, el centralizador es impreso y generado en formato digital. i) Elaborar certificados de notas para estudiantes que concluyeron sus estudios en el colegio. El alumno de secundaria que termin el colegio solicita sus certificados de notas, para realizar sus trmites personales, una vez verificada la informacin del alumno se emite el certificado del alumno.

j) Emisin de informes del rendimiento acadmico estudiantil. Se emite cada cierto tiempo o a requerimiento de la direccin acadmica para ver el aprovechamiento acadmico de los alumnos. Contabilidad k) Cobro de pensiones de los estudiantes El padre de familia solicita pagar la pensin de su(s) hijo(s), primero el encargado verifica si tiene deudas, una vez verificadas las deudas se registra el mondo recibido y se emite un recibo de pago. l) Cobro de cuotas de refrigerios de los estudiantes

El padre de familia solicita pagar el refrigerio de su(s) hijo(s), primero el encargado verifica si tiene deudas, una vez verificadas las deudas se registra el monto recibido y se emite un recibo de pago. m) Venta de materiales escolares (uniformes, libros, tiles en general) El padre de familia o estudiante solicita la venta de un material, se realiza el pago correspondiente, una vez realizada esta operacin se emite un recibo de pago. n) Pago de salarios a profesores y administrativos Al finalizar cada mes se realiza el pago de salarios al personal del colegio, una vez realizado el pago se recibe la factura correspondiente.

2.2 METODOLOGIAS 2.2.1 RUP 2.2.2 UML 1.- Introduccin al UML. UML surge como respuesta al problema de contar con un lenguaje estndar para escribir planos de software. Muchas personas han credo ver UML como solucin para todos los problemas sin saber en muchos casos de lo que se trataba en realidad. El Lenguaje Unificado de Modelado, UML es una notacin estndar para el modelado de sistemas software, resultado de una propuesta de estandarizacin promovida por el consorcio OMG (Object Management Group), del cual forman parte las empresas ms importantes que se dedican al desarrollo de software, en 1996. UML representa la unificacin de las notaciones de los mtodos Booch, Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de otros metodlogos entre los que se pueden incluir a Peter Coad, Derek Coleman, Ward Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs- Brock y Ed Yourdon. En Septiembre de 2001 se ha publicada la especificacin de la versin 1.4. Es importante recalcar que slo se trata de una notacin, es decir, de una serie de reglas y recomendaciones para representar modelos. UML no es un proceso de desarrollo, es decir, no describe los pasos sistemticos a seguir para desarrollar software. UML slo permite documentar y especificar los elementos creados mediante un lenguaje comn describiendo modelos. En la figura 12 se puede observar el desarrollo de UML y sus versiones en los aos dados, sufriendo revisiones menores, y ciertos participantes en las diversas versiones. 2.-Desarrollo de UML, con sus versiones

3.- Descripcin del lenguaje UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows). En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los grandes diseadores de coches preparan modelos en sistemas existentes con todos los detalles y los ingenieros de software deberan igualmente construir modelos de los sistemas software. Un enfoque sistemtico permite construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamao. Cuando se trata de un programa de cincuenta, cien lneas, la utilidad del modelado parece discutible pero cuando involucramos a cientos de desarrolladores trabajando y compartiendo informacin, el uso de modelos y el proporcionar informacin sobre las decisiones tomadas, es vital no slo durante el desarrollo del proyecto, sino una vez finalizado ste, cuando se requiere algn cambio en el sistema. En realidad, incluso en el proyecto ms simple los desarrolladores hacen algo de modelado, si bien informalmente. Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los dems, por lo cual con un nico modelo no tenemos bastante. 3.1.- Inconvenientes en UML

Como todo en el desarrollo de software UML presenta ciertos inconvenientes, entre los cuales se pueden mencionar: Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc., los ejemplos aislados, el monopolio de conceptos, tcnicas y mtodos en torno a UML. 3.2.- Perspectivas de UML Tambin se prev varias perspectivas de UML ya que por ser un lenguaje de propsito general ser un lenguaje de modelado orientado a objetos estndar predominante los prximos aos, esto se basa en las siguientes razones: Participacin de metodlogos influyentes Participacin de importantes empresas Aceptacin del OMG como notacin estndar Tambin se muestran las siguientes evidencias que apoyan lo antes dicho: Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc. 3.3.- Descripcin de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos. 3.4.- Relaciones de enlaces entre modelos

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de enlaces entre los diferentes modelos (figura). Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve diagramas que, para representar las distintas vistas de un sistema. Estos diagramas de UML se presentan en la figura 14 y se describen a continuacin: 3.5.- Diagramas, partes de un modelo

a) Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en descripciones de acciones ejecutadas por un sistema para obtener un resultado. b) Diagrama de Clases: muestra las clases (descripciones de objetos que comparten caractersticas comunes) que componen el sistema y cmo se relacionan entre s. c) Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. d) Diagramas de Comportamiento: dentro de estos diagramas se encuentran: Diagrama de Estados: modela el comportamiento del sistema de acuerdo con eventos. Diagrama de Actividades: simplifica el Diagrama de Estados modelando el comportamiento mediante flujos de actividades. Tambin se pueden utilizar caminos verticales para mostrar los responsables de cada actividad. Diagramas de Interaccin: Estos diagramas a su vez se dividen en 2 tipos de diagramas, segn la interaccin que enfatizan: Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los mensajes que intercambian entre s junto con el orden temporal de los mismos. Diagrama de Colaboracin: igualmente, muestra la interaccin entre los objetos resaltando la organizacin estructural de los objetos en lugar del orden de los mensajes intercambiados. e) Diagramas de implementacin Diagrama de Componentes: muestra la organizacin y las dependencias entre un conjunto de componentes. Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribucin en el mismo. 3 .- Enlace del RUP con el UML Conociendo los estereotipos utilizados para la representacin de las clases (Entidad, Control y Frontera), ahora podemos explicar la interrelacin que existe entre el UML y RUP describiendo los diagramas que describe UML y como se convierten en diagramas del RUP que utilizan estos estereotipos. El UML proporciona los diagramas de Caso de Uso, al mismo tiempo que el RUP, la nica diferencia es la forma de dibujar los estereotipos, ya que en el RUP son una elipse con una

diagonal al lado derecho (pero esto es para casos de uso de negocio, los de sistema no tienen la diagonal), y en UML solamente una elipse, pero en el RUP significa lo mismo a lo que se refiere en UML. En la figura 16 se muestra lo descrito anteriormente, aunque no nos importa en este caso el motivo por el cual se hicieron los diagramas, o la utilizacin que se les dio, ya que nicamente nos interesa conocer la forma de dibujar ambos diagramas para conocer sus diferencias: 4.1.- Comparacin entre diagramas de casos de uso (a) RUP (b) UML

(a) (b) Los diagramas de Clases tienen la misma lgica para lo cual fueron creados en ambos lenguajes, solamente con las diferencias en la forma de dibujar los cuadros que indican las clases, por ejemplo se pueden observar en las siguientes figuras 17(a) y 17(b), que en el RUP se dibujan los cuadros con una pestaa inferior derecha doblada, y en UML solamente rectngulos con ngulos rectos; otra caracterstica que se puede observar es que a la hora de ejemplificar las relaciones uno a uno, uno a muchos etc., se realizan de diferente manera. Pero en ambos lenguajes se puede observar que los diagramas de clases son lo ms cercano a la elaboracin de un modelo Entidad Relacin para la puesta en prctica de la finalizacin del proyecto de software. 4.2.- Comparacin entre diagramas de clases 17 (a) RUP 17 (b) UML

(a)

Los diagramas de objetos, difieren nicamente en la forma como se dibujan los objetos o instancias de las clases, ya que en el RUP se dibujan crculos con una diagonal en la parte inferior derecha, y en UML como rectngulos con las esquinas redondeadas, tambin en RUP no se colocan flechas indicativas, y en UML s. En las siguientes figuras se presentan las diferencias planteadas anteriormente, es importante mencionar que la lgica de cada figura no nos importa en este momento, solamente deseamos representar la forma en que se dibujan los objetos, esto ya que cada una de las figuras 18(a) y 18(b) se refieren a distintos ejemplos. 4.3.- Comparacin entre diagramas de objetos (a) RUP (b) UML

(a) 3.1PARADIGMAS DE DESARROLLO 3.1.1 ANALISIS ESTRUCTURADO 3.1.2 PAARADIGMA ORIENTADO A OBJETOS 3.2TEORIA ACERCA DEL ANALISIS Y DISENO DE SISTEMAS DE INFORMACION CAPITULO 3 DESARROLLO 3.1FASE DE INICIO 3.1.1 MODELO AMBIENTAL 3.1.1.1 DECLARACION DE PROPOSITOS 3.1.1.2 DIAGRAMA DE CONTEXTO 3.1.1.3 LISTA DE ACONTECIMIENTOS 3.2K

(b)