1

TECNOLÓGICO DE ESTUDIOS
SUPERIORES DE COACALCO

ESPECIFICACIÓN DE REQUISITOS SEGÚN EL ESTÁNDAR DE IEEE

Materia:

Ingeniera de software

Maestro:

Prado Oseguera Diana Marisol.

Integrantes del Proyecto:

Carlos Montes Leyva

Grupo:

3721

COACALCO DE BERRIOZABAL, MÉX. diciembre de 2017

1
 2

Contenido
................................................................................................................................ 1
Índice tablas ............................................................................................................ 6
Índice Imágenes ...................................................................................................... 6
Capítulo 1 ................................................................................................................ 8
1. Introducción...................................................................................................... 8
1.1. Problemática: ................................................................................................. 8
1.2 Justificación ....................................................................................................... 9
1.3 Objetivos ........................................................................................................... 9
1.3.1 Objetivo general ............................................................................................. 9
1.3.2 Objetivos específicos. ..................................................................................... 9
Funcionales: ........................................................................................................ 9
No funcionales ................................................................................................... 10
1.4 Alcances y Limitaciones ................................................................................... 11
1.4.1 Alcances ................................................................................................... 11
1.4.2 Limitaciones .............................................................................................. 11
1.5. Marco Teórico ................................................................................................ 11
1.6 Marco conceptual. ........................................................................................... 12
1.6.1 Antecedentes. ........................................................................................... 12
1.6.2 Definiciones. ............................................................................................. 12
1.6.3. Supuestos teóricos. ................................................................................. 13
1.6.4. Implementación de un Sistema Administrativo de Control Escolar .......... 13
1.6.5. Referencias. ............................................................................................. 14
1.7. Marco Metodológico ....................................................................................... 14
1.7.1 Cuadro Metodológico ................................................................................ 15
1.8. Modelo de desarrollo del software .................................................................. 16
1.8.1 Modelo de cascada ................................................................................... 16
1.8.1.1 Análisis de requisitos del software ..................................................... 16
1.8.1.2 Diseño del sistema ............................................................................. 17
1.8.1.3 Diseño del programa .......................................................................... 17
1.8.1.4 Codificación ........................................................................................ 19
1.8.1.5 Pruebas .............................................................................................. 19
1.8.1.6 Verificación ......................................................................................... 19
1.8.1.7 Mantenimiento .................................................................................... 20
2
 3

Grafica de Gantt .................................................................................................... 20

Capítulo 2 .............................................................................................................. 21
2. Análisis ........................................................................................................... 21
2.1 Diseño del Sistema...................................................................................... 22
2.2 Requerimientos. .......................................................................................... 26
Nivel Operativo. ................................................................................................. 26
Nivel Docente. ................................................................................................... 26
Nivel Administrativo. .......................................................................................... 27
2.3 Cuestionario .................................................................................................... 34
2.3.1 Tiempo y presupuesto .............................................................................. 34
2.3.2 Hosting y dominio ..................................................................................... 34
2.3.3 Antecedentes ............................................................................................ 34
2.3.4 Gustos y preferencias................................................................................... 35
2.3.5 Objetivos ...................................................................................................... 36
2.3.6 Necesidades................................................................................................. 36
2.4 Análisis que resuma los resultados obtenidos del cuestionario....................... 38
2.5 Modelo de negocios ........................................................................................ 38
Capítulo 3 .............................................................................................................. 40
3.1 Propósito ..................................................................................................... 40
3.2 Ámbito del Sistema ..................................................................................... 40
3.3 Definiciones, Acrónimos y Abreviaturas...................................................... 40
3.4 Referencias................................................................................................. 40
3.6 Visión General del Documento ................................................................... 41
3.7 Descripción General .................................................................................... 41
3.8 Perspectiva del Producto ............................................................................ 42
3.9 Funciones del Producto .............................................................................. 42
3.10 Características de los Usuarios ................................................................. 42
3.11 Restricciones ............................................................................................. 43
3.12 Suposiciones y Dependencias ................................................................... 44
3.13 Requisitos Futuros ..................................................................................... 44
3.14 Requisitos Específicos ............................................................................. 45
3.15 Interfaces Externas ............................................................................... 45
RQF_1: Requisito general de la interfaz de usuario ....................................... 45
RQF_1.1 Gestión de Usuarios – Operaciones con usuarios ...................... 45

3
 4

RQF_1.2 Gestión de Usuarios – Autenticación de usuarios ....................... 45

RQF_2 Gestión de Asignaturas .................................................................. 45
RQF_2.2 Gestión de Grupos ...................................................................... 45
RQF_2.3 Gestión de Aulas ......................................................................... 46
3.16 Interfaces hardware ....................................................................................... 46
3.17 Interfaces software ........................................................................................ 46
REQ07: Comunicación con otros módulos..................................................... 46
3.18 Interfaces de comunicación ........................................................................... 46
3.19 Funciones................................................................................................. 47
3.19.1 Entrada de información. .......................................................................... 47
3.19.2 Almacenamiento de información: ............................................................ 47
3.19.3 Procesamiento de la información: ........................................................... 47
3.19.4 Salida de información ............................................................................. 47
Alumno de nuevo ingreso:.............................................................................. 48
Alumno Inscrito: ............................................................................................. 48
Docente: ......................................................................................................... 48
Personal Administrativo.................................................................................. 48
4 CASO DE USO GENERAL ............................................................................ 49
Caso de uso. Gestión de Usuarios .................................................................... 50
Caso de uso Autenticación de Usuarios ......................................................... 51
Caso de uso Gestión deAsignaturas ................................................................. 52
Caso de uso Cursos .......................................................................................... 53
Caso de uso Citas .............................................................................................. 54
Caso de uso Mensajería ................................................................................. 55
Caso de uso Informes ........................................................................................ 56
Caso de uso asignación de grupos: ................................................................... 57
Caso de uso Aulas ............................................................................................. 58
Caso de uso Gestión de Notas/Calificaciones ...................................................... 59
4.1 REQUERIMIENTOS FUNCIONALES .......................................................... 59
4.2 INTERFACES DE USUARIO .......................................................................... 64
4.3 Diagrama de Secuencial por cada Escenario .................................................. 69
4.4 REQUERIMIENTOS DE RENDIMIENTO ........................................................ 70
4.5 RESTRICCONES DE DISEÑO ...................................................................... 71
4.6 ATRIBUTOS DEL SISTEMA ........................................................................... 71

4
 5

5. EXTRAS ............................................................................................................ 74
5.1 Diagrama de despliegue .............................................................................. 74
5.2 Diagrama de Estados ................................................................................. 75
Grafico # 20. Notas Supletorio ........................................................................... 75
Grafico # 21. Revisión de Libreta ....................................................................... 76
Grafico # 22. Ingreso de Notas .......................................................................... 77
Diagrama de Componentes................................................................................... 78
Diagrama de actividades ................................................................................... 79
REFERENCIAS ..................................................................................................... 80

5
 6

Índice tablas

Tabla 1 Cuadro metodológico.................................................................... pag. 13

Tabla 2 Grafica de Gantt............................................................................. pag. 18

Tabla 3 requerimientos funcionales ............................................................ pag. 30

tabla 4 requerimientos no funcionales ........................................................ pag. 31
Tabla 5 ERS................................................................................................ pag. 39
Tabla 6 Gestión de Usuarios – Tipos de usuarios...................................... pag. 58
Tabla 7 Gestión de Usuarios – Operaciones de usuarios…………………… pag. 59
Tabla 8 Gestión de Usuarios – Autenticación de usuarios………………….. pag. 59
Tabla 9 Gestión de Asignaturas .................................................................. pag 60
Tabla 10 Gestión de grupos........................................................................... pag 61
Tabla 11 Gestión de Aulas ........................................................................... pag 62

Índice Imágenes

Imagen 1 modelo de cascada................................... ...... ...... ...... ...... ........ pag 14

Figura 1. Inicio de sesión .................................... ...... ...... ...... ...... ...... ...... pag 20
Figura 2. Proceso de Inscripción de Alumnos ................ ...... ...... ...... ........ pag 21
Figura 3. Proceso de Inscripción de Alumnos Documentos........ ...... ...... ... pag 22
Figura 4. Proceso de Inscripción (control escolar)............. ...... ...... ...... ...... pag 22
Figura 5. Proceso de Inscripción Datos (control escolar)............................... pag 23
Figura 6. Registro de alumnos ...................................................................... pag 23
Figura 7. Registro de alumnos Datos escolares ........................................... pag 24

Ilustracion 1 Actores del sistema ................................................ pag 26

Figura 8 Bosquejo del Modelo ..................................................... pag 37

Imagen 1. Caso de uso general.................................................... pag 47

Ilustración 4: Diagrama 3 Gestión de Usuarios ........................ pag 48
Ilustración 5: Diagrama 4 Autenticación de Usuarios ................... pag 49
Ilustración 6: Diagrama 5 Gestión de Asignaturas ..................... pag 50
Ilustración 7: Diagrama 6 Gestión de Cursos .......................... pag 51
Ilustración 11: Diagrama 7 Gestión de Citas.............................. pag 52
Ilustración 12: Diagrama 11 Gestión de Mensajería .................. pag 53
Ilustración 13: Diagrama 12 Gestión de Informes ...................... pag 54
Ilustración 8: Diagrama 8 Gestión de Grupos ........................ pag 55
Ilustración 9: Diagrama 9 Gestión de Aulas ........................... pag 56
Ilustración 10: Diagrama 9 Gestión de Resultados Académicos........... pag 57

Figura 1. Inicio de sesión .................................................................. pag 62

Figura 2. Proceso de Inscripción de Alumnos ................................ pag 63
Figura 3. Proceso de Inscripción de Alumnos Documentos............ pag 64

6
 7

Figura 4. Proceso de Inscripción (control escolar)...................... pag 64

Figura 5. Proceso de Inscripción Datos (control escolar)............ pag 65
Figura 6. Registro de alumnos .................................................... pag 66
Figura 7. Registro de alumnos Datos escolares ......................... pag 66

7
 8

Capítulo 1

1. Introducción

El sistema de control escolar para la universidad TESCo, tiene como función

proporcionar ayuda para poder tener un mejor control en los datos, registros,
administración de alumnos, docentes y personal que trabaja en la institución como
de igual forma tener el registro salones o áreas de trabajo.

1.1. Problemática:

En la actualidad las instituciones educativas a nivel primaria sufren de diversos

problemas ante la falta de conocimientos en las nuevas tecnologías de la
información y el uso de herramientas para la manipulación de datos, como sucede
en las escuelas primarias. En dicha institución no cuenta con procesos que permiten
organizar y administrar los recursos académicos de la en un entorno WEB. Estos
procesos manejan como recurso principal la información de los alumnos,
profesores, aulas, laboratorios, cursos y planes curriculares. Lo que se busca es
manejar los recursos ordenadamente e integrarlos para que se encuentren a
disposición del usuario final de toda institución educativa.

Dado esto se propone un sitio el cual se registre en una base de datos los periodos,
semestres, tipo de asignatura, aulas, grupos, docentes, estudiantes, horarios y
generar reportes, también se de realizar un apartado para que los docentes ejecuten
el proceso de gestión de calificaciones en tiempo y forma para evitar modificaciones
de notas a destiempo.

8
 9

1.2 Justificación
El jefe del departamento escolar de la primaria o dirección general, invierte una gran
cantidad de tiempo en gestionar las calificaciones de los estudiantes en la cual los
docentes asignan en un archivo de Excel de manera manual, por ello se ha de sea
desarrollado un sitio web, el cual no solo ayude a agilizar el tiempo del proceso de
la acreditación de las materias en la institución si no también permite una óptima
manipulación de la información de los docentes en formación junto con la regulación
de los tiempo para el registro de calificaciones en el departamento de control
escolar.

1.3 Objetivos

1.3.1 Objetivo general

Desarrollar un sitio web el cual permita facilitar el manejo de datos de los alumnos
y maestro como la asignación de aulas, para tener un mejor control en el sistema
de dirección general en la primaria .

1.3.2 Objetivos específicos.

Funcionales:

 Creación de un entorno WEB para los alumnos, docentes y personal

administrativo.
 Inscripciones y reinscripciones usando la plataforma en línea o entorno WEB
de la escuela.
 Recoger los requerimientos de las diferentes fuentes de información de los
aspirantes dentro de la institución.

9
 10

 proceso de construcción de horarios generados para los nuevos aspirantes.

 Presentar una propuesta para automatizar las tareas dentro de la
construcción de horarios por medios de flujos de procesos durante la fase de
concepción del proyecto. Esto permite finalmente la agilización del proceso.
 Acceso inmediato en la plataforma.
 Generar las altas de horarios en el periodo correspondiente.
 Asignar aulas y maestros mediante los procesos administrativos cada
jefatura o división de carrera.
 Proceso de titulación.
 Poder tomar y realizar un posgrado dentro de la institución (maestría o
especialidad).

No funcionales

 Implementar integridad en los datos validando lo que el usuario coloque en

el momento del registro.
 Programar un medio de seguridad el cual solo pueda ser manipulado por un
ser humano, así como diferenciar entre un humano y una computadora
(captcha).
 Generar una matriz de seguridad con los perfiles de usuarios y sus funciones
 Efectuar un cifrado con el proceso de la autentificación.
 Establecer los lineamientos adecuados en la página web.
 Originar un mensaje de confirmación de operaciones para el usuario cada
vez que ingrese.
 Integrar un manejo independiente de sesiones para cada perfil de usuario,
permitiendo la disposición de las operaciones correspondientes.

10
 11

1.4 Alcances y Limitaciones

1.4.1 Alcances
Dentro de los alcances que tiene este proyecto está la realización de una extensión
de la base de datos y sitio web para implementar un control de horas dentro de los
laboratorios de cualquier tipo de carrera, con un tiempo estimado en el proyecto de
6 a 8 meses de duración.

1.4.2 Limitaciones
Dentro de las limitaciones que se puedan manifestar en el proyecto está el tiempo
para la realización de la extensión en el sitio web. Sin descartar que dichas
extensiones se puedan realizar en algún futuro.

1.5. Marco Teórico

En este proyecto, se presenta una estructura adecuada para la creación e
implementación de un portal web, para las instituciones de educación primaria, ya
que resultara muy eficaz y útil para la recopilación de datos de los alumnos
inscritos en la escuela.
Algunos de nuestros documentos se tienen nuevas metodologías en base a
estándares ya establecidos por diversos autores, se nombran a continuación,
donde se entiende el objetivo de cada documento y las propuestas entregadas por
cada uno.

11
 12

1.6 Marco conceptual.

1.6.1 Antecedentes.

Hasta antes de 1992, las disposiciones normativas y la gran mayoría de los

servicios operativos inherentes a los procesos de control escolar de los centros
de trabajo que ofrecen servicios educativos se llevaban a cabo de manera
centralizada a través de oficinas y dependencias de la Secretaría de Educación
Pública, ubicadas en el centro del país.
En ellas se establecían los criterios para realizar las funciones de planeación
y organización, así como el resguardo de los registros de los estudiantes inscritos
y su historial académico.
Ante esa situación, los usuarios, personal administrativo y directivo de los
centros de trabajo ubicados en las diferentes entidades federativas, tenían la
necesidad de trasladarse a la Ciudad de México para realizar diferentes trámites
administrativos y de operación, entre ellos los correspondientes al control escolar.
Vista la magnitud del universo de atención que debía brindar una sola
dependencia, en este caso la Secretaría de Educación Pública, además de las
complicaciones que se vivían para tener acceso los servicios centralizados, se
tomó
la decisión de acercarlos a través de organismos descentralizados en cada una de
las entidades federativas, desconcentrando así las facultades administrativas y
operativas de los servicios de educación básica y normal.

1.6.2 Definiciones.

Es común que el individuo tenga, considerando su experiencia y particular punto

de vista, un concepto personal y heterogéneo de lo que es el control escolar.
Esto porque no existe un criterio único, aún cuando se cuenta con diversidad de
documentos normativos y de procedimientos aplicables a los diferentes niveles
educativos.
En los servicios educativos se realizan actividades de control escolar que difieren
12
 13

debido a las necesidades y características particulares de las instituciones a las

que pertenecen. Sin embargo, de manera general aplican prácticamente los
mismos procesos de atención para la población estudiantil, desde el registro,
cuando es inscrito, hasta la expedición de documentos de certificación, una vez
concluido total o parcialmente el plan de estudios cursado.

1.6.3. Supuestos teóricos.

Es obligación del director del centro de trabajo, verificar que la evaluación

del aprendizaje de los estudiantes se realice de conformidad a las
condiciones establecidas en los planes y programas de estudios autorizados
por la Coordinación de Educación Media Superior, Superior y Tecnológica.

La acreditación debe realizarse en los periodos ordinarios o a través de exámenes

extraordinarios de regularización, de conformidad a lo establecido en el presente
documento.

Las calificaciones parciales, registradas en la lista de asistencia y evaluación,

deben resultar de las condiciones establecidas en los planes y programas de
estudio autorizados por la Coordinación de Educación Media Superior,
Superior y Tecnológica.

1.6.4. Implementación de un Sistema Administrativo de Control Escolar

La acreditación de estudios se realizará exclusivamente en el plantel

donde se encuentra inscrito el estudiante.
El plan de estudios en la modalidad escolarizada obliga la asistencia de los
studiantes para cursar y acreditar las materias correspondientes al módulo en
turno. Para que el estudiante tenga derecho a la acreditación debe acumular por lo
menos:
• 80 por ciento para calificación en periodo ordinario, y

13
 14

• 70 por ciento para calificación en periodo de examen

extraordinario de regularización.

El estudiante que acumule menos del 70 por ciento de asistencias, debe

cursar nuevamente la materia.

1.6.5. Referencias.

Tomando como referencia diferentes definiciones de la administración, en

este trabajo se considera como el conjunto de principios, técnicas y prácticas
ordenadas y sistematizadas, generadas con la finalidad de apoyar la creación y
consecución de los objetivos de una organización a través de la provisión de los
medios necesarios para obtener los resultados con la mayor eficiencia, eficacia y
congruencia, así como la óptima coordinación y aprovechamiento del personal y
los recursos técnicos, materiales y financieros.

1.7. Marco Metodológico

14
 15

1.7.1 Cuadro Metodológico

TÉCNICAS HERRAMIENTAS OBJETIVOS TIEMPO
Sistema web Adobe Dw Desarrollar el Tiempo de avance
maquetado del por fases es de un
sistema web que mes para
permita gestionar completar su
las operaciones desarrollo.
administrativas de
un sistema de
control escolar.
Aplicación web Manejo de HTML5 Implementar el Entre 1 a dos
dinámica Y CSS3 uso de las semanas.
Lenguaje HTML tecnologías
Búsqueda de Lenguaje HTML5 Proporcionar un Dependerá la
diferentes Y CSS3 con ID sistema que búsqueda y la
complementos Adobe Dw simplifique nueva
para HTML 5 procesos sobre los implementación.
servicios del
control escolar

Hacer un análisis Poder analizar Generar un Tiempo estimado

de otros sitios web luso detalles de ambiente grafico de 3 a 5 días.
del sistema de las diferentes amigable para
control escolar. paginas buscadas. usuarios.

Manejar con Manipular el Obtener Todos los días

frecuencia el sistema web resultados más
sistema específicos sobre
los servicios.

Tabla 1 Cuadro metodológico

15
 16

1.8. Modelo de desarrollo del software

Imagen 1 modelo de cascada

1.8.1 Modelo de cascada

El modelo del desarrollo del software es efectuado y aplicado con el modelos de

cascada ya que nos permitira poder definir los requerimientos, analisar el diseño
del software, implementyar pruebas, Integracion y pruebas al sistema y por ultimo
la oparacion y mantenimiento al mismo.

1.8.1.1 Análisis de requisitos del software

Los requisitos serán dividas en 4 diferentes casos los cuales son:

Alumno: Permitirá poderse inscribir, reinscribir, poder crear sus horarios y

descargar su historial académico.

Docente: Permitirá poder ver que horario se le fue asignado, gestionar calificación
y descargar lista de sus grupos asignados.

16
 17

Jefe de división: Permitirá gestionar a sus maestros en las asignaturas que se les
fue correspondidas y asignadas como gestionar alumnos y personal administrativo
trabajando en el área.

Administrador: Permitirá controlar la mayor parte de los alumnos y docentes ya

que este usuario será el que se encuentre en control escolar de la escuela.

1.8.1.2 Diseño del sistema

Este es un proceso mediante el cual se traducen los requisitos en una

representación de software. Inicialmente, la representación describe una visión
holística del software. Posteriores refinamientos conducen a una representación de
diseño que se acerca mucho al código fuente. En el diseño se realizan dos pasos.
El diseño preliminar se centra en la transformación de los requisitos en los datos y
arquitectura del software. El diseño detallado se ocupa del refinamiento de la
representación arquitectónica que lleva a una estructura de datos detallada y a las
representaciones algorítmicas de lo que será nuestro sistema final. Dentro del
contexto de los diseños preliminar y detallado, se llevan a cabo varias actividades
de diseño diferentes. Además del diseño de datos, del diseño arquitectónico y del
diseño procedimental, muchas aplicaciones requieren de un diseño de la interfaz.

1.8.1.3 Diseño del programa

 Permitir la aplicación práctica de metodologías estructuradas, las cuales al

ser realizadas con una herramienta se consigue agilizar el trabajo.

 Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.

17
 18

 Simplificar el mantenimiento de los programas. Mejorar y estandarizar la

documentación.

 Aumentar la portabilidad de las aplicaciones. Facilitar la reutilización de

componentes software.

 Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante

la utilización de gráficos.

 Mejorar la productividad en el desarrollo y mantenimiento del software.

Aumentar la calidad del software.

 Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas

informáticos.

 Mejorar la planificación de un proyecto.

 Aumentar la biblioteca de conocimiento informático de una empresa

ayudando a la búsqueda de soluciones para los requisitos.

 Automatizar, desarrollo del software, documentación, generación de código,

pruebas de errores y gestión del proyecto.

 Ayuda a la reutilización del software, portabilidad y estandarización de la

documentación.

 Gestión global en todas las fases de desarrollo de software con una misma
herramienta.

18
 19

 Facilitar el uso de las distintas metodologías propias de la ingeniería del

software.

1.8.1.4 Codificación

Es la fase en donde se implementa el código fuente, haciendo uso de prototipos

así como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje
de programación y su versión se crean las bibliotecas y componentes reutilizables
dentro del mismo proyecto para hacer que la programación sea un proceso mucho
más rápido.

1.8.1.5 Pruebas

Revisión del diseño y desarrollo.

Cada revisión hecha en la etapa de diseño y desarrollo debe documentarse para
su futura verificación y validación, así como sus posibles cambios.

1.8.1.6 Verificación

Verificación del diseño y desarrollo.

En esta etapa se tiene que comparar los resultados con lo deseado así veremos
si las especificaciones antes dadas se cumplen.

Validación del diseño y desarrollo. Una vez verificado los resultados obtenidos se
hacen las pruebas con el cliente quien es el que tiene la decisión final y nos dará
su validación que el prototipo cumple con los requisitos necesarios, si no se
cumplen se tendrán que hacer los cambio pertinente.

Control de cambios dl diseño y desarrollo. Si no se cumplieron con los requisitos

se tendrán que hacer los cambios en el diseño o en el desarrollo.

19
 20

1.8.1.7 Mantenimiento

 Establecer las acciones preventivas conforme a las posibles causas de no

conformidad.
 Establecer periodo de revisión y mantenimiento del las no conformidades.
 Enviar al responsable del área para que realice las acciones preventivas.
establecidas previamente.
 Realizar la acción correctiva establecida previamente.
 Se le da seguimiento a la opción propuesta y se registra los resultados de la
misma.

Grafica de Gantt

ACTIVIDADES Horas Semana

1 2 3 4 5 6 7 8 9 10 11 12
1 Elaboración de cronograma 2
2 Planeación general del proyecto 3
Definir requerimientos necesarios de
3
desarrollo 4
4 Definir requerimientos necesarios 2
5 Búsqueda de modelos a implementar 3
Investigación previa de punto de
6
conocimientos 4
7 Diseño y estructura 5
8 Segunda fase de documentación 4
Verificar y acoplar requerimientos
9
solicitados 5
Análisis e implementación de
10
información ) 3
Definir caratula y presentación de
11
proyecto 2
Definir caratula y presentación de
12
proyecto 5
13 Definir encuestas necesarias 2
14 Faces finales de la documentación 30 minutos
Tabla 2 Grafica de Gantt

20
 21

Capítulo 2
2. Análisis

Dentro del análisis podemos considerar varios componentes, entre los que se
destacan:

 Símbolos gráficos: sirven para identificar y describir los componentes de un

sistema y las relaciones entre estos.
 Diccionarios de datos: Descripciones de todos los datos utilizados en el
sistema pueden ser manual o automatizado.
 Descripciones de procesos y procedimientos: emplean técnicas y lenguajes
que permiten describir actividades del sistema.
 Reglas: Estándares par describir y documentar el sistema en forma correcta
y completa.

Por otra parte dentro de las herramientas de análisis podemos emplear:

 Diagrama de flujo de datos: son la herramienta más importante y la base en

donde se desarrollan otros componentes.
 Diccionario de datos: contienen las características lógicas de los lugares
donde se almacenan los datos del sistema, incluyendo nombre, alias,
descripción, contenido y organización.
 Diagrama de estructuras de datos: este es una descripción de la relación
entre entidades (personas, lugares, eventos y objetos) y el conjunto de
información relacionado con la entidad.
 Gráfica de estructura: es la herramienta del diseño que muestra con
símbolos la relación entre los módulos de procesamiento y el software.

21
 22

2.1 Diseño del Sistema

Figura 1. Inicio de sesión

22
 23

Figura 2. Proceso de Inscripción de

Alumnos

23
 24

Figura 3. Proceso de Inscripción de

Alumnos Documentos

Figura 4. Proceso de Inscripción

(control escolar).

24
 25

Figura 5. Proceso de Inscripción Datos

(control escolar).

Figura 6. Registro de alumnos

25
 26

Figura 7. Registro de alumnos Datos

escolares

2.2 Requerimientos.

Para establecer los requerimientos del sistema previamente se analizaron los

procesos esenciales en la administración y gestión del Control Escolar. Dentro de
estos, divididos en tres niveles tenemos los siguientes:
Básicamente dividimos estos tres niveles en Nivel Operativo, Docente y
Administrativo. A continuación se explica el campo de aplicación para cada uno de
ellos.

Nivel Operativo.
En este nivel se contemplan los procesos esenciales del Control Escolar dirigidos a
los alumnos de la Institución, como lo es el caso de la Información General, la
gestión en la Entrega de documentación y la Inscripción para el caso de alumnos
de nuevo ingreso, la Reinscripción de alumnos que ya se encuentran cursando un
semestre, la Asignación de grupos y los procesos mas comunes como la Inscripción
a Exámenes, la Renuncia de calificaciones y la consulta de las mismas vía Web
bajo criterios de acceso establecidos.

Nivel Docente.
El Nivel Docente esta encaminado a facilitar la gestión de los profesores o titulares
de una materia. Procesos como la Entrega de Listas, Evaluaciones parciales,
semestrales e impresión de Actas por grupo, son parte de este Nivel.

Nivel Jefe de división:

26
 27

El nivel jefe de división esta de ser encarado de gestionar a los profesores dentro
del área donde se encuentran de igual forma gestionar a los alumnos que se
encuentran en dicha carrea.

Nivel Administrativo.
En el tercer Nivel, el Administrativo, se llevan a cabo los procesos que facilitan la
organización en la Creación de grupos, la Apertura y Planeación de nuevos
períodos, Generación de Horarios para Nuevo Ingreso y semestres consecuentes,
así como la Administración de la Solicitud y Entrega de Documentación que en su
momento se requiera para un alumno en particular o un docente, según sea el caso.
En este modelo se trata de contemplar a todo el Control Escolar, de tal forma que
se pueda asegurar la gestión de forma eficaz y eficiente, incluyendo en este los
procesos esenciales del día a día que apliquen para cada caso.

2.2.1 Funcionales

El sistema pretende informatizar la gestión de la comunicación en un centro escolar.

El sistema ha de contemplar de manera integral los procesos relacionados con el
control de las entradas y salidas de información de áreas como comunicación de
asignaturas, información sobre citaciones, tareas, informes académicos,
pedagógicos, mensajería.
Para la toma de requerimientos funcionales del sistema, se ha contado con la
participación activa de gente experta en el mundo de la educación, quienes han
detallado cómo es un centro escolar, sus diversos mecanismos de gestión interna y
sus normativas vigentes, y de los propios padres y alumnos que también han
facilitado información acerca del comportamiento cotidiano, y los procesos que se
llevan a cabo en un centro escolar.

Los usuarios finales no poseen un gran conocimiento técnico informático previo a la

implantación del sistema, por ello se persigue diseñar un interfaz amigable y fácil de
entender, para que no suponga un trabajo añadido al que realizan. Los usuarios
finales del sistema serán los propios profesores, el personal administrativo, los
alumnos matriculados en el centro y los padres de dichos alumnos que estén
registrados como tal en la herramienta administrativa del centro escolar. Por lo tanto,
la organización de los usuarios del sistema atendiendo a su perfil es:

27
 28

SISTEMA

USUARIO

PROFESOR ADMINISTRATIVO Jefe de carera ALUMNO

Ilustración 1 ‐ Actores del Sistema

A continuación se proceden a enumerar y catalogar los requerimientos funcionales,

que debe cumplir el sistema:

REQUERIMIENTOS FUNCIONALES
IDENTIFICADOR DESCRIPCIÓN

Gestión de Usuarios – Tipos de usuarios:

‐ Administrativo
RQF_1 ‐ Profesor
‐ Padre
‐ Alumno

28
 29

Gestión de Usuarios – Operaciones con usuarios: el

sistema debe permitir las operaciones de gestión de los
distintos usuarios del sistemas (control total para
administrativos, y sólo “consulta de su propio usuario”
RQF_1.1 para profesores, padres y alumnos):
‐ Crear un nuevo usuario
‐ Modificar un usuario
‐ Eliminar un usuario
‐ Consultar usuario/s

Gestión de Usuarios – Autenticación de usuarios: El

RQF_1.2 sistema deberá exigir al usuario una identificación para
entrar al sistema (usuario y contraseña).

Gestión de Asignaturas: El sistema permitirá a los

administrativos crear los registros de las asignaturas por
cursos, y a los profesores consultarlas. Las funciones a
realizar son:
RQF_2
‐ Nueva asignatura
‐ Modificar asignatura
‐ Eliminar asignatura
‐ Consultar asignatura/s

29
 30

Gestión
registros
continuación
Sistema
‐
‐

de Cursos: Se permitirá a los administrativos

crear los
de los cursos (en una tabla de “CURSOS”). A
se describen los cursos existentes en el actual
RQF_2.1
‐ Educación Secundaria Obligatoria (ESO):
comprende 4 cursos escolares, entre los 12 y los
16 años, y es una etapa obligatoria y gratuita.
Los cursos se identificaran por las siguiente
siglas: o 1_ESO o 2_ESO o 3_ESO o 4_ESO

30
 31

‐ Bachillerato: es la última etapa de la Educación

Secundaria, tiene carácter voluntario y su
duración es de 2 cursos, normalmente entre los
16 y los 18 años.

Los cursos se identificaran por las siguiente siglas: o

1_BACH o 2_BACH

Gestión de Grupos: Se permitirá a los administrativos

crear los registros de los grupos de la escuela en general
RQF_2.2
(en una tabla de “GRUPOS”). Los grupos se enumerarán
de manera alfabética.

Gestión de Aulas: Se permitirá a los administrativos crear

los registros de las aulas de la escuela (en una tabla de
“AULAS”). Las aulas se identifican con un número natural
RQF_2.3 para la planta del edificio (0, 1, 2, 3), un punto y otro número
natural, indicando el aula de esa planta (empezando en 1).
Por ejemplo, el aula 1.2 estaría en la planta 1 y sería la 2ª
aula.

Gestión de Notas/Calificaciones: El sistema permitirá el

acceso a la información de resultados académicos de los
alumnos a cada uno de los usuarios del sistema, siendo
filtrada en función de quién sea el que la consulte (control
total para administrativos y profesores, y sólo “consulta”
RQF_3
para padres y alumnos). Las funciones a realizar son:
‐ Nueva calificación de asignatura
‐ Modificar calificación de asignatura
‐ Eliminar calificación de asignatura ‐ Consultar
calificación/es

Gestión de la Citas: El sistema debe facilitar una

herramienta que permita a un usuario (Administrativo,
profesor o padre), gestionar las citas entre profesores y
padres. Las funciones a realizar son:
RQF_4
‐ Nueva Cita
‐ Modificar Citas
‐ Eliminar Citas
‐ Consultar Citas

31
 32

Gestión de Mensajería: El sistema permitirá el intercambio

de mensajes internos y privados entre los diferentes
usuarios del sistema, y la gestión de dichos mensajes. Las
funciones a realizar son:
RQF_5
‐ Nuevo mensaje
‐ Modificar mensaje
‐ Eliminar mensaje
‐ Consultar mensaje/s

Gestión de Informes: El sistema permitirá generar

informes de diferentes tipos por parte de los administrativos
y profesores, para documentar información sobre los
alumnos, poder almacenarlos y enviarlos a los padres. Las
RQF_6 funciones a realizar son:
‐ Nuevo informe
‐ Modificar informe
‐ Eliminar informe
‐ Consultar informe/s

Tabla 1 ‐ REQUERIMIENTOS FUNCIONALES

3.1.2 No Funcionales

Sin llegar al grado de formalismo que presenta la Norma ISO‐9126, que presenta el
modelo de calidad que clasifica los atributos de la calidad del software en seis
características, se muestran los requisitos utilizando como base la estructura que
muestra dicha norma. Se han tenido en cuenta las características más interesantes
para el proyecto tratado.

A continuación se proceden a enumerar y catalogar los requerimientos no

funcionales que debe cumplir el sistema:

REQUERIMIENTOS NO FUNCIONALES
IDENTIFICADOR DESCRIPCIÓN
Idoneidad: La aplicación debe proporcionar opciones
claras para los usuarios. El manejo de la aplicación tiene
RQNF_1 que resultar lo más intuitivo posible, es decir la
navegación por la aplicación tiene que ser clara para
facilitar la operatividad al usuario.

Sencillez: El acceso al sistema deberá ser sencillo, ya

RQNF_2 que los usuarios no disponen de grandes conocimientos
técnicos en informática.

32
 33

Precisión: La aplicación debe proporcionar al usuario

RQNF_3 opciones que permitan realizar el trabajo, y deben estar
correctamente descritas.

Seguridad: Acceso restringido a la aplicación mediante

autenticación por usuario y contraseña. El sistema
RQNF_4 tendrá que evitar que el personal no autorizado, o sin
permisos, pueda acceder a los datos privados de los
usuarios, así como el acceso al sistema.

Confiabilidad: La aplicación y los servicios web deben

mantener su nivel de ejecución bajo condiciones
RQNF_5 distintas a las que han sido concebidos. Madurez y
tolerancia a fallos (el software debe de seguir su
funcionamiento aún en el caso de producirse errores).

Compatibilidad: El nuevo sistema deberá funcionar en

cualquier ordenador que disponga de conexión a
Internet y un explorador de gran difusión en el mercado.
No importará su ubicación física o el ordenador en
RQNF_6 particular desde el que se conecté. La aplicación web
debe visualizarse correctamente por lo menos en los
navegadores más extendidos (Internet Explorer, Google
Chrome y Mozilla
Firefox).

Facilidad y optimización de uso: La aplicación web

debe brindar una experiencia de uso cercana a las
RQNF_7
aplicaciones de escritorio, reduciendo lo posible los
refrescos de cada pantalla.
Base de datos óptima: El diseño de la base de datos
ha de estar orientado a facilitar el manejo de la
RQNF_8 información necesaria para el correcto funcionamiento
de los procesos de la manera más directa, rápida y
sencilla posible.
Tabla 2 ‐ REQUERIMIENTOS NO FUNCIONALES

33
 34

2.3 Cuestionario

2.3.1 Tiempo y presupuesto

 ¿Cuánto está dispuesto a invertir en este proyecto?

Entre 15 mil pesos a 20 mil pesos.

 ¿Existe un límite de tiempo para desarrollar el sitio?

Si de 4 a 6 meses

 ¿El lanzamiento del sitio coincide con el lanzamiento de un producto o servicio?

No

2.3.2 Hosting y dominio

¿Tiene un dominio?

Si pero es publico.

¿Tiene control sobre el dominio?

No por el momento esta dado de baja

¿Tiene un hosting?

No
¿Cuál es su empresa de hosting?

Ninguna

¿Tiene acceso al servidor Web?

Si, pero es interno

¿Registró usted el dominio?

No, fue el personal de TIC

2.3.3 Antecedentes

34
 35

¿Ha estado presente en el proceso antes, durante y después del diseño de su

pagina?

No

¿Tiene actualmente un sitio Web?

Si pero solo es interno.

¿Cuándo fue la última vez que actualizó el sitio?

Hace 4 meses

¿Tiene su sitio aplicaciones interactivas?

Si.

¿El desarrollador original sigue disponible?

Si tenemos una copia activa en PHP

2.3.4 Gustos y preferencias

¿Conoce algún (s) sitios Web que le gustan como referencia?

No.

¿Cuáles sitios Web considera agradables estéticamente?

Personalmente creo que nuestro sitio es muy estable.

¿Cuál es el estilo del sitio Web que está buscando?

Que pueda ser mas interactivo con los alumnos y personal del la escuela, sea mas
visualmente atractivo.

¿Cómo usuario, qué le molesta más sobre los sitios Web?

Lo visual que sea muy básico.

¿Tiene alguna idea a nivel creativo para desarrollar el sitio Web?

Si.

35
 36

2.3.5 Objetivos

¿Cuál es el mensaje principal que desea trasmitir?

Que el alumno pueda ver que el sitio es una forma mas fácil de manejar para que
pueda hacer procesos que antes solo se podían hacer en el sistema de control
escolar.

¿Quién es su público meta específico?

Alumnos, docentes y jefes de carreas.

2.3.6 Necesidades

¿Qué funciones debe cumplir su sitio Web?

El sitio debe poder al alumno, registrarse para hacer su examen de ingreso, debe
poder inscribirlo directamente en la página y podrá ver su horario, historial
académico y convocatorias.

Para el docente deberá poder gestionar calificación, ver posgrados que puede
cursar, cursos y horaios.

Jefe de división deberá tener control administrativo en su área.

Administrador podrá hacer su proceso normal que se lleva acabo en control escolar.

¿Tiene alguna especificación?

Si, pero esas estarán en las normas que se te asignaran.

¿Cuántas páginas necesita?

Una pero multifuncional

¿Necesita motores de búsqueda dentro de su sitio?

Si claramente es necesario.

¿Con qué frecuencia necesita actualizar el sitio?

Cada 6 meses.

¿Necesita un sistema de manejo de contenido, que le permita automatizar su sitio?

Si.

36
 37

¿Necesita un formulario de contacto?

Si para cada uno de los usuarios.

¿Qué aplicaciones interactivas requiere para su sitio?

boletines, formularios, galerías, blog, chat, foros, vox puopuli, etc

¿Qué tan importante es la personalización de su sitio?

Básico ya que me importa mas la calidad que la cantidad.

¿Usted desearía o necesitaría ayuda para hacer cambios? Si es así, ¿necesitaría

ayuda de forma rutinaria?

Si cada 4 meses

¿Necesita comercializar productos desde su sitio?, ¿utilizaría Paypal, tarjeta de

crédito y otra forma de pago?

No.

¿Existe alguna función específica que necesite en el sitio?

Si que pueda imprimir ordenes de pagos de la sep.

¿Cómo se maneja el correo electrónico en su empresa?

Hosting

¿Necesita que hayan áreas protegidas dentro del sitio?

Totalmente para cada usuario.

¿Desea que su sitio tenga incorporadas redes sociales como Digg, Facebook,
Twitter?

Si como complemento.

¿Necesita que el sitio Web se vincule a un otro sitio en particular??

Aun no tengo pensado eso.

¿Tiene el contenido del sitio listo?

37
 38

Parte de…

2.4 Análisis que resuma los resultados obtenidos del cuestionario

Como pudimos aprecian en el resultado del cuestionario el cliente requiere de un

sistema de control escolar actualizado, pero en este caso lo quiere a través de un
portal web para que el Alumno, Docente y personal administrativo pueda acceder
a él, pero cada uno de los usuarios tendrá diferente función dentro del sitio ya que
es diferente los privilegios de cada uno.

El portal web será divido en 2 faces ya que contamos con un sitio para el alumno
docente y jefe de carrea y la otra parte para el personal administrativo de control
escolar.

Con base a los visto el cliente requiere de una plataforma web la cual pueda
registrar usuarios nuevo es decir alumnos de nuevo ingreso pero de igual forma
que cada usuario tenga un protección adecuada ya que si no es así podrá tener
errores futuros.

2.5 Modelo de negocios

Para nuestro Modelo de negocio en el Sistema de Control Escolar tenemos
como base el siguiente Diagrama Estructurado por Niveles, en el que se
representan los principales procesos que involucran la gestión del día a día en
el Control Escolar de Alumnos.

38
 39

FIG. 1 Bosquejo del Modelo

39
 40

Capítulo 3
3.1 Propósito

El sistema está dirigido para el personal de administración de la universidad

(TESCo), para facilitar la administración y registros tanto del personal docente,
personal administrativo, alumnos y áreas de trabajo para cada uno de los
mencionados.

3.2 Ámbito del Sistema

En esta subsección:
 El sistema tendrá como nombre: Sistema de control Escolar Online.
 El sistema podrá realizar acciones de registro online en un sitio web ya que
esta dedicado para la institución, estas acciones son: Registrar alumnos,
Docentes y personal administrativo ya que esta conectado a una base de
datos.
 El sistema no podrá realizar acciones de eliminar por parte del usuario si no
es ejecutado por algún administrador con derechos de super usuario ya que
algunos administradores solo podrán ejecutar acciones determinadas
dependiendo su área de trabajo.
 El sistema proporcionara ayuda administrativa para la institución ya que
alojara toda la información de registros en general en una base de datos
que podrá ser revisada, modificada y actualizada en cualquier comento que
la universidad lo desee ayudando a optimizar el tiempo.
 El sistema se ejecutará en un servidor virtual conectado con una base de
datos de MySQL para poder tener el registro e información de la
universidad.

3.3 Definiciones, Acrónimos y Abreviaturas

En el sistema realizado no se encuentran abreviaturas técnicas en cuyo en

versiones futuras.

3.4 Referencias

En esta subsección se mostrar una lista completa de todos los documentos

referenciados en la ERS.

1.Documento Justificación del proyecto

2.Documento Mapa Mental Técnicas de Elicitación
3.Documento Caso de uso y descripción

40
 41

4.Documento Requerimientos de caso de usos

5.Software Maqueta de Software
6.Documento Diagrama de clases
7.Documento Diagrama Relacional
Tabla ERS

3.6 Visión General del Documento

El sistema esta dividió en varias partes ya que cuenta con diferentes acciones que
tiene los usuarios en el sitio, esto determinara la descripción de cada uno de sus
procesos que conllevaran a determinadas opciones en el sistema.

3.7 Descripción General

Como objetivo general es llevar administrativa-mente los procesos de la escuela

empezando desde la admisión de los estudiantes como en las asignaciones de la
materia o módulos durante el semestre ya que con ello se podrá recabar la
información necesaria de los alumnos como de los maestros para crear los grupos
y horas de trabajo en clase.
Unos de los objetivos a tomar en cuentas es el dar soporte a los encargados o
personal administrativo a la construcción de horarios y asignación de maestros
como de aulas ya que con ello se tiene que recabar y constatar las matricula de
alumnos tanto de nuevo ingreso como los alumnos ya inscritos en el plantel.
También al momento de crear secciones y asignar horarios se incluirán los cursos
extra curriculares que se dictarán en el siguiente ciclo (actividades
complementarias e inglés).
De igual forma se tendrá que controlar la información relacionada a la
disponibilidad de profesores y aulas para realizar la construcción de horarios y
mostrar información adicional a lo largo del proceso que ayude al usuario en la
toma de decisiones dentro del sistema. Además, la asignación de áreas y cursos a
los profesores. Como ordenar la información relacionada a las notas del ciclo
actual de los alumnos, sus cursos aprobados y el plan curricular en vigencia para
obtener información valiosa como la cantidad aproximada de alumnos hábiles por
curso y cantidad de cruces de alumnos entre los cursos.
Desplegar el producto software en los servidores de la escuela en la fase de
Transición para el área de Sistemas Computacionales, así como también la
creación de una página web para que el docente puede ver en cualquier momento
el horario que se le fue asignado.
Otro punto a tomar en cuenta es de que en este entorno web o sitio el alumno
podrá tener la facilidad de poder verificar el proceso de titulación ya que con esto
podrá facilitar el proceso y así tener un mejor control de datos del egresado como
la reducción de tiempo que se lleva en solicitar la documentación en la institución
ya que el alumno (egresado) podrá hacerlo directamente con su ID accediendo en
la plataforma y pestaña correspondiente.

41
 42

También se tiene contemplado el poder tomar los posgrados (Especialidad o

maestría) que la universidad tenga disponible, de igual manera respetando el
protocolo de admisión en dicha selección de posgrado.
Finalmente, al concluir el proyecto, se verificar que el Sistema de control escolar
pueda cumplir y abarcar todos los requerimientos y objetivos planteados, se usara
el producto para la asignación de matrículas, construir grupos, creación de los
horarios del ciclo escolar correspondiente, los cuales fueron probados y aprobados
por la escuela a cargo del control del horario y jefatura dependiendo la carrera de
elección.

3.8 Perspectiva del Producto

El sistema esta diseñado paras poder aplicar modificaciones en la base de datos

que se tiene dentro de la institución, de igual forma se podrán aplicar
actualizaciones en el sistema y en el sitio web para poder tener un mejor proceso
en la parte del software y así pode reducir el tiempo en ejecución de cada uno de
ellos.

3.9 Funciones del Producto

El sistema contara con distintas partes que optimizaran el tiempo administrativo

que se lleva acabo en las siguientes secciones:

 Inscripción: Datos personales de los alumnos

 Reinscripción: Registro en la base de datos para reutilizar su información.
 Personal Docente: Datos del personal docente trabajando en la institución
según las materias a impartir.
 Personal Administrativo: Datos del personal que labora en la institución.

3.10 Características de los Usuarios

Los usuarios en el sistema son:

Alumno: El usuario alumno podrá ingresar al portal con su ID y Password

asignado por el sistema y podrá ver:

 Horario del semestre cursando

 Documento que el sistema muestre en el sistema.
 Promedio de calificaciones por nivel académico
 Promedio de calificaciones por semestre
 Promedio de calificaciones por grupo
 Promedio de calificaciones por materia

42
 43

 Promedio de calificaciones por alumno

 Promedio de alumnos por materia
 Promedio de materias por semestre

Docente: EL usuario docente (Maestro) tiene como finalidad en la en el sitio web:

 Habilitar su horario asignado.
 Subir calificaciones por alumno (Carrera, Grupo, Grado).

Personal Administrativo: El usuario Administrativo es aquel que tiene derecho

Súper Usuario para poder:

 Agregar
 Editar
 Modificar
 Eliminar

3.11 Restricciones

 Seguridad control de acceso encriptación de los datos respaldo de los datos

 Restauración de los datos integridad confiabilidad eficiencia
 La seguridad del Sistema integral de Control Escolar es crítica, por lo que
desean que el servidor pueda proporcionar una seguridad alta.
 Los datos también deben ser protegidos, estableciéndose los sistemas de
recuperación y respaldo necesarios para proporcionar la máxima integridad
de datos, procurando la mínima intervención del operador.
 Tanto el número de alumnos, docentes, administrativos y directivos, así
como las transacciones que deberá realizar el sistema, (entradas de datos,
consultas, reportes), deben ser tomadas en cuenta para que el hardware
del servidor no presente limitaciones o inconvenientes para su desempeño.
 La capacidad de almacenamiento debe considerarse no sólo para el
número actual de transacciones sino incluir el crecimiento de la Universidad
y que el hardware tenga la capacidad de adaptarse a este incremento.
 El sistema operativo de servidor debe ser compatible con el desarrollo del
Sistema Integral de Control Escolar.
 Los conocimientos del personal, en cuanto al uso y administración de
servidores es alto, aunque nunca han tenido un proyecto de este tipo, y su
experiencia sólo se centra en aplicaciones de servidores de tipo comercial,
por lo que no existe experiencia ni un conocimiento experto en aplicaciones
de servidores de tipo software libre, y en caso de optar por éste, la asesoría
y soporte técnico serán indispensables.

43
 44

 Los factores que explícitamente no han sido considerados en la propuesta

de selección e implementación del servidor se considerarán irrelevantes

3.12 Suposiciones y Dependencias

Los requisitos descritos en este documento pueden cambiar, pues los procesos
son dinámicos y por lo tanto cambia los requisitos del software y del sitio web,
para lo cual es necesario que las fases de análisis y diseño estén bien
documentadas y además definir una fase y metodología de mantenimiento del
sistema.

El sistema de información “Control escolar” funciona con una conexión a SQL pero
solamente para administrar los datos e información de la escuela, pero el sistema
no necesita de comunicarse con otros software externos, por lo que no hay
dependencias respecto de otros sistemas.

3.13 Requisitos Futuros

1. El sistema web podrá cambiar de gestor de base de datos dependiendo el

sistema que se requiera en el futuro.
2. El sistema web podrá ser modificado en el aspecto visual.
3. El sistema puede tener una copia de seguridad de datos en la nube.
4. El sistema podrá permitir al usuario sea registrado en el sitio web
directamente.
5. El usuario podrá inscribirse virtualmente usando la página.
6. Cada usuario podrá tener un chat independiente para comunicarse con
otros de sus compañeros usando su ID.
7. Al usuario se le podrá generar un correo institucional.
8. El docente (Maestro), Podrá capturar Calificaciones directamente en el sitio
sin usar un programa o componente extra.
9. El docente Podrá habilitar horas libre durante su jornada para asesorías.
10. El docente podrá habilitar cursos o talleres extra clases.

44
 45

3.14 Requisitos Específicos

En este apartado se presentan los requisitos funcionales que deberán ser

satisfechos por el sistema. Todos los requisitos aquí expuestos son ESENCIALES,
es decir, no sería aceptable que el sistema no satisfaga alguno de los requisitos
aquí presentados. Estos requisitos se han especificado teniendo en cuenta, entre
otros, el criterio de testabilidad : dado un requisito, debería ser fácilmente
demostrable si es satisfecho o no por el sistema.

3.15 Interfaces Externas

RQF_1: Requisito general de la interfaz de usuario

La interfaz de usuario diseñada deberá tener alto grado de usabilidad y ser

sencilla, cumpliendo todos los requisitos especificados:

 Alumno.
 Docente
 Jefe de división
 Administrador

RQF_1.1 Gestión de Usuarios – Operaciones con usuarios

La interfaz deberá ser diferente para cada usuario ya que si no es así podrá tener
múltiples errores en cada una de la sesión a acceder.

RQF_1.2 Gestión de Usuarios – Autenticación de usuarios

La interfaz deberá de consistir en una serie de divisiones dependiendo la usuario y

contraseña.

RQF_2 Gestión de Asignaturas

El sistema permitirá a los administrativos crear los registros de las asignaturas por
cursos, y a los profesores consultarlas.

RQF_2.2 Gestión de Grupos

Se permitirá a los administrativos crear los registros de los grupos de la escuela en

general (en una tabla de “GRUPOS”). Los grupos se enumerarán de manera
alfabética empezando y se utilizarán para cada uno de los cursos.

45
 46

RQF_2.3 Gestión de Aulas

Se permitirá a los administrativos crear los registros de las aulas de la escuela (en
una tabla de “AULAS”). Las aulas se identifican con un número natural para la planta
del edificio (0, 1, 2, 3), un punto y otro número natural, indicando el aula de esa
planta (empezando en 1). Por ejemplo, el aula 1.2 estaría en la planta 1 y sería la
2ª aula.

3.16 Interfaces hardware

No se han definido.

3.17 Interfaces software

REQ07: Comunicación con otros módulos

La comunicación con los datos se realizará mediante protocolos basados en

estándares que permitan cumplir los demás requisitos del sistema en este caso será
servidor cliente ocupado motores de base de datos como Sql o Mysql.

3.18 Interfaces de comunicación

Red Externa: Es una red de computadoras interconectados, capaz de compartir

información y que permite comunicar a usuarios sin importar su ubicación
geográfica.

Red Interna: una red privada se definiría como una red que puede usarla solo
algunas personas y que están configuradas con clave de acceso personal.

Red de área local (LAN): una red que se limita a un área especial relativamente
pequeña tal como un cuarto, un solo edificio, una nave, o un avión. Las redes de
área local a veces se llaman una sola red de la localización. Un Workgroups es un
grupo de las computadoras que comparten un sistema común de recursos dentro
de un LAN.

46
 47

Red del área del campus (CAN): Se deriva a una red que conecta dos o más LANs
los cuales deben estar conectados en un área geográfica específica tal como un
campus de universidad, un complejo industrial o una base militar.

Red de área metropolitana (MAN): una red que conecta las redes de un área dos o
más locales juntos pero no extiende más allá de los límites de la ciudad inmediata,
o del área metropolitana.

3.19 Funciones

El sistema de control escolar contara con un sistema de Información realiza en

cuatro actividades básicas:

3.19.1 Entrada de información.

Proceso en el cual el sistema toma los datos del usuario que requiere para
procesar la información, por medio de gestores de base de datos el cual nos
permitirá almacenar todo tipo de información que sea requerida para el sistema.

3.19.2 Almacenamiento de información:

Es una de las actividades más importantes que tiene un sistema de control

escolar, a través de esta propiedad el sistema puede recordar la información
guardada en la sesión o proceso anterior esto nos servirá para poder reocupar
información de los alumnos, docentes y personal administrativo y reducir el tiempo
de recopilación de datos.

3.19.3 Procesamiento de la información:

Esta característica de los sistemas permite la transformación de los datos fuente

en información que puede ser utilizada para la toma de decisiones, lo que hace
posible, que un tomador de decisiones genere una proyección a partir de los datos
que contiene un reporte o una salida.

3.19.4 Salida de información

Es la capacidad de un SI para sacar la información procesada o bien datos de

entrada al exterior, presentada más comúnmente como reportes. Esto podrá
verse reflejado en todos los módulos del sistema como son:

47
 48

Alumno de nuevo ingreso:

Permitirá ver el resultado de su convocatoria de ingreso.

Alumno Inscrito:

Permitirá ver su horario asignado e historial académico.

Docente:

Permitirá ver horario asignado y lista de alumnos.

Personal Administrativo.

Permitirá gestionar reportes de diversos tipos para el tipo de acción empleada.

48
 49

4 CASO DE USO GENERAL

Jefe de division

Imagen 1. Caso de uso general

49
 50

Caso de uso. Gestión de Usuarios

Crearnuevousuario

Modificarusuario

ADMINISTRATIVO PADR
E
Eliminarusuario

Consultarusuarios

PROFESO ALUMNO
R
Ilustración 4: Diagrama 3 Casos de Uso: RQF_1.1 – Gestión de Usuarios

50
 51

Caso de uso Autenticación de Usuarios

Accesoa la Aplicación

Jefe de PROFESOR
división

Modificar contraseña

Alta de nuevo usuario

ALUMNO ADMINISTRATIVO

Ilustración 5: Diagrama 4 Casos de Uso: RQF_1.2 – Autenticación de Usuarios

51
 52

Caso de uso Gestión deAsignaturas

NuevaAsignatura

Modificar Asignatura

Eliminar Asignatura

ADMINISTRATIVO
ConsultarAsignatura/s

PROFESOR

Ilustración 6: Diagrama 5 Casos de Uso: RQF_2 – Gestión de Asignaturas

52
 53

Caso de uso Cursos

NuevoCurso

Modificar Curso

EliminarCurso

ADMINISTRATIVO
ConsultarCurso/s

Ilustración 7: Diagrama 6 Casos de Uso: RQF_2.1 – Gestión de Cursos

53
 54

Caso de uso Citas

NuevaCita

ADMINISTRATIVO

Modificar Cita

Eliminar Cita

ConsultarCitas

PROFESOR Alumno

Ilustración 11: Diagrama 10 Casos de Uso: RQF_4 – Gestión de Citas

54
 55

Caso de uso Mensajería

NuevoMensaje

ADMINISTRATIVO ALUMNO

Modificar Mensaje

EliminarMensaje

ConsultarMensaje/s

PROFESOR Jefe

Ilustración 12: Diagrama 11 Casos de Uso: RQF_5 – Gestión de Mensajería

55
 56

Caso de uso Informes

NuevoInforme

Modificar Informe

ADMINISTRATIVO PROFESOR

EliminarInforme

ConsultarInforme/s

ALUMNO

Ilustración 13: Diagrama 12 Casos de Uso: RQF_6 – Gestión de Informes

56
 57

Caso de uso asignación de grupos:

NuevoGrupo

Modificar Grupo

EliminarGrupo

ADMINISTRATIVO
ConsultarGrupo/s

Ilustración 8: Diagrama 7 Casos de Uso: RQF_2.2 – Gestión de Grupos

57
 58

Caso de uso Aulas

NuevaAula

Modificar Aula

EliminarAula

ADMINISTRATIVO
ConsultarAula/s

Ilustración 9: Diagrama 8 Casos de Uso: RQF_2.3 – Gestión de Aulas

58
 59

Caso de uso Gestión de Notas/Calificaciones

NuevaCalificación

ModificarCalificación

PROFESOR EliminarCalificación ADMINISTRATIVO

ConsultarCalificación/es

ALUMNO Jefe de División

Ilustración 10: Diagrama 9 Casos de Uso: RQF_3 – Gestión de Resultados Académicos

4.1 REQUERIMIENTOS FUNCIONALES

CU- RQF_1 Gestión de Usuarios – Tipos de usuarios:

Versión 1.0 (25/07/2009)

Dependencias N/A
Precondición Gestión de Usuarios – Tipos de usuarios:

Descripción Es la interfaz de acceso al sistema de control escolar teniendo 4 tipos de

usuarios: Administrativo, Profesor, Padre, Alumno.

Secuencia Normal Paso Acción

1 El usuario accede al sistema de control escolar

59
 60

2 Selección el tipo de usuario que es:

2.1 Administrativo

2.2 Profesor

2.3 Padre

2.4 Alumno

3 Ingresa: con usuario y contraseña

4 Autentifica al usuario y accede al sistema.

Pos condición

Excepciones Paso Acción

3 Si cualquier tipo de usuario excede el número de intentos al

ingresar al sitio se bloqueara temporalmente su sesión por
cuestiones de seguridad.

E.1 El sistema informara mediante un mensaje que el

usuario o la contraseña son incorrectos.

E.2 El sistema después de 3 intentos bloqueara la

cuenta del usuario y mandara un mensaje al correo
electrónico del propietario.

Comentarios El sistema mandara un mensaje de error si el usuario o contraseña es

incorrecta.

Tabla 6 Gestión de Usuarios – Tipos de usuarios.

CU- RQF_1.1 Gestión de Usuarios – Operaciones con usuarios
Versión 1.0 (25/07/2009)
Dependencias RQF_1
Precondición Operaciones con usuarios
Descripción el sistema debe permitir las operaciones de gestión de los
distintos usuarios del sistemas (control total para
administrativos, y sólo “consulta de su propio usuario” para
profesores, padres y alumnos).
Secuencia Paso Acción
Normal 1 Crear un nuevo usuario
2 Modificar un usuario
2.1 Administrativo
2.2 Profesor
2.3 Padre
2.4 Alumno

60
 61

3 Eliminar un usuario
4 Consultar usuario/s.

Pos condición
Excepciones Paso Acción
3 La operaciones en este proceso solo se le dará
permiso al administrador del sistema
E.1 Le permitirá modificar a todos los tipos de
usuarios que se encuentre en el sistema.
E.2
Comentarios Solo será ocupado por el Administrador.
Tabla 7 Gestión de Usuarios – Operaciones de usuarios.

RQF_1.2 Gestión de Usuarios – Autenticación de usuarios

Versión 1.0 (25/07/2009)
Dependencias  RQF_1
 RQF_1.1
Precondición Operaciones con usuarios
Descripción El sistema deberá exigir al usuario una identificación para entrar al
sistema (usuario y contraseña).
Secuencia Paso Acción
Normal 1 Selección de usuario
2 Tipo de usuarios existentes:
2.1 Administrativo
2.2 Profesor
2.3 Padre
2.4 Alumno
3 Introducir usuario y contraseña correctos

Pos condición El usuario siempre deberá seleccionar que tipo de privilegios

tiene.
Excepciones Paso Acción
3 En caso de seleccionar mal el usuario, el sistema
informara que no corresponde los campos.
E.1 El sistema de control escolar mandara
sugerencias de las acciones que se están
tomando al ingresar.
E.2
Comentarios Solo será ocupado por el Administrador.
Tabla 8 Gestión de Usuarios – Autenticación de usuarios

61
 62

RQF_2 Gestión de Asignaturas

Versión 1.0 (25/07/2009)
Dependencias  N/A
Precondición Gestión de Asignaturas
Descripción El sistema permitirá a los administrativos crear los registros de las
asignaturas por cursos, y a los profesores consultarlas.
Secuencia Paso Acción
Normal 1 Nueva asignatura
2 Modificar asignatura
2.1 Maestro
2.2 Salón
2.3 Grado
2.4 Grupo
3 Eliminar asignatura
4 Consultar asignatura/s

Pos condición Solamente el administrador podrá modificar y seleccionar el

tipo de asignaturas.
Excepciones Paso Acción
3 En caso de que el administrador coloque repetidas
veces asignaturas el sistema informara que ya están
agregadas.
E.1 El sistema sugerirá las asignaturas que
faltan por agregar.
E.2
Comentarios Solo será ocupado por el Administrador.
Tabla 9 Gestión de Asignaturas

RQF_2.2 Gestión de Grupos

Versión 1.0 (25/07/2009)
Dependencias  RQF_2.1
Precondición Gestión de Grupos
Descripción Se permitirá a los administrativos crear los registros de los grupos
de la escuela en general (en una tabla de “GRUPOS”). Los grupos se
enumerarán de manera alfabética empezando por A (ejemplo: A, B,
C, D,…), y se utilizarán para cada uno de los cursos.
Secuencia Paso Acción
Normal 1 Nueva grupo
2 Modificar grupo
2.1 Maestro
2.2 Salón
2.3 Grado

62
 63

2.4 Grupo
3 Eliminar grupo
4 Consultar grupos

Pos condición Solamente el administrador podrá modificar y seleccionar los

grupos.
Excepciones Paso Acción
3 En caso de que el administrador coloque repetidas
veces grupos el sistema informara que ya están
ocupados.
E.1 El sistema sugerirá que grupos puede
generar.
E.2 Los grupos a agregar solo tendrán un
número máximo de 30 niños.
Comentarios Solo será ocupado por el Administrador.
Tabla 10 Gestión de grupos.

RQF_2.3 Gestión de Aulas

Versión 1.0 (25/07/2009)
Dependencias  RQF_2.1
 RQF_2.2
Precondición Gestión de Grupos
Descripción Se permitirá a los administrativos crear los registros de las aulas de
la escuela (en una tabla de “AULAS”). Las aulas se identifican con un
número natural para la planta del edificio (0, 1, 2, 3), un punto y
otro número natural, indicando el aula de esa planta (empezando
en 1). Por ejemplo, el aula 1.2 estaría en la planta 1 y sería la 2ª
aula.
Secuencia Paso Acción
Normal 1 Nueva Aula
2 Modificar Aula
2.1 Maestro
2.2 Salón
2.3 Grado
2.4 Grupo
3 Eliminar Aula
4 Consultar Aula

Pos condición Solamente el administrador podrá modificar y seleccionar las

aulas.
Excepciones Paso Acción

63
 64

3 En caso de que el administrador coloque repetida

vez la misma Aula que ya fue asignada el sistema
informara que ya están ocupados.
E.1 El sistema sugerirá que el aula ya ha sido
ocupada.
E.2 El sistema tendrá que validar cuantas
aulas hay dentro de la escuela
Comentarios Solo será ocupado por el Administrador.
Tabla 11 Gestión de Aulas.

4.2 INTERFACES DE USUARIO

Figura 1 Loguearse

64
 65

Figura 2. Proceso de Inscripción de

Alumnos

65
 66

Figura 3. Proceso de Inscripción de

Alumnos Documentos

Figura 4. Proceso de Inscripción

(control escolar).

66
 67

Figura 5. Proceso de Inscripción Datos

(control escolar).

Figura 6. Registro de alumnos

67
 68

Figura 7. Registro de alumnos Datos

escolares

68
 69

4.3 Diagrama de Secuencial por cada Escenario

69
 70

4.4 REQUERIMIENTOS DE RENDIMIENTO

Los requerimientos básicos del sistema se extiende para considerar un conjunto de
atributos de guías de costo que pueden agruparse en cuatro categorías principales:
a) Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la
base de datos, y complejidad del producto).
b) Computadora (por ej. Restricciones en el tiempo de ejecución y
almacenamiento).
c) Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en
lenguajes de programación y capacidad del programador)
d) Proyecto (por ej. Uso de practicas modernas de programación, uso de
herramientas de software y requerimiento de un plan de desarrollo).

En cada nivel de aplicación están definidos para tres tipos de proyectos de software:
1) Modo orgánico, proyectos de software relativamente pequeños y sencillos en
los que pequeños equipos con buena experiencia en la aplicación trabajan en un
conjunto de requerimiento poco rígidos.
2) Modo semi-acoplado (semi-detached), un proyecto de software intermedio en
tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe
satisfacer requerimientos poco y medio rígidos
3) Modo acoplado( detached), un proyecto de software que debe ser
desarrollado dentro un conjunto estricto de hardware, software y de restricciones
operativas.

En el apartado del Proyecto evaluamos el uso de técnicas de programación y de

herramientas de desarrollo de software entre otros aspectos.

Para este caso evaluamos el uso de Herramientas de Desarrollo y como se vio en

capítulos previos el uso de ellas es masivo, como se expuso con el App-Modeler y
en este caso, con el Costar.

70
 71

FIG. 8 Calificación de las Herramientas para la construcción del Sistema.

4.5 RESTRICCONES DE DISEÑO

 Implementar integridad en los datos validando lo que el usuario coloque en

el momento del registro.
 No usar colores fuertes para los ojos
 Programar un medio de seguridad el cual solo pueda ser manipulado por un
ser humano, así como diferenciar entre un humano y una computadora
(captcha).
 Generar una matriz de seguridad con los perfiles de usuarios y sus
funciones
 Efectuar un cifrado con el proceso de la autentificación.
 Establecer los lineamientos adecuados en la página web.
 Originar un mensaje de confirmación de operaciones para el usuario cada
vez que ingrese.
 Integrar un manejo independiente de sesiones para cada perfil de usuario,
permitiendo la disposición de las operaciones correspondientes.

4.6 ATRIBUTOS DEL SISTEMA

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo -
bajo - nominal - alto - muy alto - extremadamente alto

El significado de los atributos es el siguiente:

De software o RELY: garantía de funcionamiento requerida al
software. Indica las posibles consecuencias para el usuario en el caso

71
 72

que existan defectos en el producto. Va desde la sola inconveniencia de

corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas
(extremadamente alto)
o DATA: tamaño de la base de datos relación con el tamaño del
programa. El valor del modificador se define por la relación: D / K,
donde D corresponde al tamaño de la base de datos en bytes y K es
el tamaño del programa en líneas de código.
o CPLX: complejidad del producto
De hardware o TIME: limitaciones en el porcentaje
del uso de la CPU. o STOR: limitaciones en el
porcentaje del uso de la memoria. o VIRT:
volatilidad de la máquina virtual.
o TURN: tiempo de respuesta.
De personal o ACAP:
calificación de los analistas.
o AEXP: experiencia del personal en aplicaciones similares. o

PCAP: calificación de los programadores. o VEXP:

experiencia del personal en la máquina virtual.
o LEXP: experiencia en el lenguaje de programación a usar.
De proyecto o MODP: uso de prácticas
modernas de programación. o TOOL: uso
de herramientas de desarrollo de software.
o SCED: limitaciones en el cumplimiento de la planificación.

El valor de cada atributo dependiendo de su calificación es:

72
 73

FIG. 13 Tabla de calificación de Atributos

73
 74

5. EXTRAS
5.1 Diagrama de despliegue

74
 75

5.2 Diagrama de Estados

Grafico # 20. Notas Supletorio

Si termina periodos
Normales
Completos
y la suma total
Aprobados
Ingresar notas
nuevas

Supletorios

No aprobados

Aprobados
Si cumple
con la suma total

Completos
Todos los estudiantes que tienen que tener las notas completadas de todos los
periodos sin tener pendiente algún periodo.

Aprobados
Los estudiantes han culminado su año lectivo aprobando al siguiente año.

Supletorio
Cada alumno tendrá derecho a un examen supletorio como última oportunidad para
poder pasar al siguiente año lectivo.

No aprobados
El estudiante pierde el año ya que el estudiante no saca la nota mínima para poder
pasar al siguiente año lectivo.

75
 76

Grafico # 21. Revisión de Libreta

Ingresa el estudiante Registrado

al sistema

Revisa sus
notas
indica Representante
Años Lectivos
los representantes
en esos años

Indicar los años

lectivos aprobados
Aprobados

Registrado
El estudiante para poder consultar su nota a través del sistema debe estar
registrado como estudiante de la institución.

Años Lectivos
El administrador habilitara las notas para que los estudiantes puedan consultarla
en el año lectivo actual.

Representante
El padre de familia o representante es el que va a tener permiso para pedir la
libreta del estudiante.

Aprobados.

76
 77

Es cuando después de averiguar la nota este aprueba el año lectivo

.
Grafico # 22. Ingreso de Notas

Ingreso al modulo Inactivo

de calificación Año Lectivo

Revisar Notas
Activo

Calificación

No calificado

Activo

Ingresar notas del Calificado

parcial

Año Lectivo
Es el año Lectivo el actual.
Inactivo
El año lectivo puede estar inactivo cuando se hayan terminado todo.
Revisar Nota
Se podrá consultar la nota de los años anteriores aun estando inactivo pero este
tramite solo lo puede hacer el administrador.
Calificar
Se podrá calificar a los estudiantes habiendo pasado los demás estado, como el
año lectivo este activado y activo.

77
 78

Diagrama de Componentes

Sistema Escolar

78
 79

Diagrama de actividades

Un diagrama de actividades ha sido diseñado para mostrar una visión simplificada

de lo que ocurre durante una operación o proceso.

Un diagrama de actividades representa los flujos de trabajo paso a paso de

negocio y operacionales de los componentes en un sistema. Un Diagrama de
Actividades muestra el flujo de control general.

El siguiente diagrama muestra el Diagrama de Actividades para el Sistema de

Control Escolar:

Inscripción al periodo escolar

Alumno Nuevo

Registro de datos básicos

Alumno

Registra horarios y grupos Apertura de expediente

No disponible

Disponible

Inscribe al grupo

Cosulta calificaciones

Reprueba

Inscribe a extraordinarios o ETS

Aprueba

FIG. 14 Diagrama de Actividades del Sistema de Control Escolar

79
 80

REFERENCIAS

- Jesús García Molina, M144. José Ortín, Begoña Moros, Joaquín Nicolás,
Ambrosio Toval. Grupo de Investigación de Ingeniería del Software2. Departamento
de Informática y Sistemas. Facultad de Informática.

Universidad de Murcia C.P. 30.071 Campus de Espinardo, Murcia, Spain {jmolina,

mjortin, bmoros, jnr, atoval}@um.es. De los Procesos del Negocio a los Casos de
Uso1.

- “Análisis, Diseño e Implementación de un Sistema Académico para el Centro

Educativo de Desarrollo Infantil Bilingüe Angelitos de luz, utilizando el Lenguaje de
programación visual Fox pro 8.0”. Juan Francisco González

Pinzón. 2004

- Wikipedia. “Lenguaje PHP”.

http://es.wikipedia.org/wiki/PHP#

- Wikipedia. “Modelo Entidad – Relación”.

http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

- Wikipedia. “PostgreSQL”.
http://es.wikipedia.org/wiki/PostgreSQL

- 2.uah “Diagramas de Casos de Uso”

http://www2.uah.es/jcaceres/uploaded/capsulas/DiagramaCasosDeUso.pdf

- Wikipedia. “Licencia BSD”.

http://es.wikipedia.org/wiki/Licencia_BSD

80
 81

- GestióPolis. “Métodos y técnicas de Investigación”. 2008

http://www.gestiopolis.com/metodos-y-tecnicas-de- investigacion.htm

- “Guia de Vistas - SQL”. Guia Basica utilizando Postgresql, escrito por

Marcelo O. Segura Septiembre del 2003, marcelosaez@hotmail.com

- “Manual de PHP.pdf” desarrolado por Hector Mero. Desarrollador Web

UDG – PROTCOM 2002 2003

- “Manual de Usuario de Postgresql”, editado por Thomas Lockhart. Marca

registrada © 1996 – 9 por el Posgres Gloval Development Group.

81