Proyecto Sistema de Gestión de Notas

Académicas
Informe de Diseño del Sistema.
(Segundo Informe basado en la guía del SWEBOK edición 2004).

Ingeniería de software

Docente: Alejandro Corro Encina

Integrantes: Ignacio Soto Sánchez
Louis Rivas Jara
José Molina Martínez
 Índice

INTRODUCCION……………………………………………………………………………...... 3
1. Descripción del Sistema…………………………………………………………………...... 4
1.1. Descripción General………………………………………………………………. 4
1.2. Clientes y Usuarios………………………………………………………………...4
1.3. Modelo de Procesos………………………………………………………………. 5
2. Especificación de Requerimientos del Sistema…………………………………………... 6
2.1. Objetivos Generales………………………………………………………………. 6
2.2. Funciones del Sistema……………………………………………………………. 6
2.3. Atributos del Sistema……………………………………………………………... 6
2.4. Atributos por Función. ……………………………………………………………. 6
3. Diseño del Sistema…………………………………………………………………………... 7
3.1. Diagramas de Casos de Uso…………………………………………………….. 7
3.2. Para Cada Caso de Uso…………………………………………………………. 8
3.2.1. Caso de uso expandido……………………………………………….. 8
3.2.2. Diagrama de secuencia o colaboración……………………………… 12
3.2.3. Diagrama de Clases……………………………………………………. 13
4. Integración del Sistema……………………………………………………………………… 14
4.1. Diagrama de Clases de Diseño………………………………………………….. 14
4.2. Diagrama de Componentes……………………………………………………… 14
4.3. Modelo Entidad-Relación………………………………………………………… 15
5. Arquitectura del Sistema……………………………………………………………………. 16
5.1. Diagrama de Arquitectura. ………………………………………………………. 16
5.2. Especificación Técnica de Arquitectura………………………………………… 16
5.3. Especificaciones de Seguridad………………………………………………….. 16
6. Prototipos………………………………………………………………………………………17
6.1. Prototipos de GUI…………………………………………………………………. 17
6.2. Prototipos de Informes……………………………………………………………. 17
7. Pruebas del Sistema………………………………………………………………………… 21
7.1. Especificación de Pruebas………………………………………………………. 21
7.2. Casos de Pruebas………………………………………………………………… 21
8. Implementación del Sistema……………………………………………………………….. 22
8.1. Plan de Implementación…………………………………………………………. 22
9. Mantención del Sistema……………………………………………………………………. 24
9.1. Plan de Mantención…………………………………………..…………............. 24
CONCLUSIONES………………………………………………………………………………. 26
Bibliografía………………………………………………………………………………………. 27

Página 2 de 28
 Introducción
A continuación del informe anterior de gestión del proyecto, en este segundo informe se
realiza el diseño del sistema a implementar basado en la guía del Swebok versión 2004.
En donde nos basamos en la metodología de desarrollo del diseño del sistema de notas
académicas para el establecimiento “Buenas Peras”.

Esta consiste a grandes rasgos con la descripción del sistema en forma generalizada
usuarios que interactúan con el sistema y su modelo de procesos, especificación de
requerimientos sus objetivos generales, funciones y atributos, posteriormente se crea el
diseño del sistema y sus casos de uso mediante UML, diagrama de secuencias, de
clases, secuencia y colaboración, los diagramas de integración, la arquitectura del
sistema, los prototipos iniciales del software, también se realizan prueba de caja negra y
blanca para el aseguramiento de la calidad del producto, un plan de implementación y de
mantención.

A grandes rasgos esos son los puntos que se establecen y se desarrollan en este
segundo informe, para la entrega al cliente y la seguridad de la satisfacción del cliente y
sus requerimientos para el establecimiento anteriormente mencionado.

Página 3 de 28
1. Descripción del sistema.
1.1 Descripción General.

El colegio de Bicentenario de excelencia de Buenas Peras, es un colegio

reconocido del país, el cual ha solicitado un sistema que permita la gestión de
notas de sus alumnos. El colegio consta de cursos desde primero básico hasta
cuarto medio, y cada curso tiene 3 secciones (A, B y C). El sistema cumplirá la
función de entregar informes para los 4 bimestres lo que permitirá cerrar el
promedio de cada alumno. El sistema solo manejará información del año en
curso, permitiendo solicitar información de notas de los alumnos de cualquier
bimestre cursado durante el año. Además, el sistema controla la información
relacionada con profesores asignados a cada curso y materia, lo que le
permitirá al área de Recursos Humanos administrar la tabla de sueldos.

1.2 Clientes y Usuarios.

El siguiente punto hace referencia a los entes que tendrán relación o

interacción con el sistema, los cuales realizarán las acciones según lo
especificado por el cliente en la etapa de toma de requerimientos.

 Oficina de Registros: esta entidad desarrollará gran parte de la

interacción con el sistema. Será la que solicitará los informes
bimestrales, relación cursos/profesores, cierres de bimestre, etc.
 Oficina de Recursos Humanos: esta entidad tendrá la única interacción
en el sistema que le permitirá administrar la tabla de sueldos de los
profesores.
 Profesores: Los profesores podrán ejecutar la acción de registrar las
notas parciales que tenga cada alumno durante el bimestre.

Página 4 de 28
1.3 Modelo de Procesos.

El software estará desarrollado según el proceso RUP, dejando en claro los

principios calve en los que se basa:

 Adaptar el proceso: El proceso deberá adaptarse a las necesidades del

cliente ya que es muy importante interactuar con él. Las características
propias del proyecto. El tamaño del mismo, así como su tipo o las
regulaciones que lo condicionen, influirán en su diseño específico. También
se deberá tener en cuenta el alcance del proyecto.

 Equilibrar prioridades: Los requisitos de los diversos participantes pueden

ser diferentes, contradictorios o disputarse recursos limitados. Debe
encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este
equilibrio se podrán corregir desacuerdos que surjan en el futuro.

 Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de

un modo interno, en etapas iteradas. En cada iteración se analiza la
opinión de los inversores, la estabilidad y calidad del producto, y se refina
la dirección del proyecto así como también los riesgos involucrados.

 Colaboración entre equipos: El desarrollo de software no lo hace una única

persona sino múltiples equipos. Debe haber una comunicación fluida para
coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

 Enfocarse en la calidad: El control de calidad no debe realizarse al final de

cada iteración, sino en todos los aspectos de la producción. El
aseguramiento de la calidad forma parte del proceso de desarrollo y no de
un grupo independiente.

 Elevar el Nivel de Abstracción: Este principio dominante motiva el uso de

conceptos reutilizables tales como patrón del software, lenguajes 4GL o
esquemas (frameworks) por nombrar algunos. Estos se pueden acompañar
por las representaciones visuales de la arquitectura, por ejemplo con UML.

Página 5 de 28
2. Especificación de Requerimientos del sistema.

2.1. Objetivos generales.

A solicitud del cliente se hace hincapié en la implementación del módulo de sistema de

notas del establecimiento “Buenas Peras” ya que no existe uno propiamente tal, este se
relacionara con los sistemas pre-existentes de acuerdo a la relación directa o
indirectamente que tenga con los demás sistemas, estos son:

 RRHH: Sistema de Sueldo a profesores.

 Oficina de Admisiones: Sistema de procedimientos y funciones de las matriculas al
alumnado.
 Oficina de registro: Sistema de asignación de cursos de acuerdo a horario, según
materias, secciones y salas para el docente.
 Sistema de ejecución de inicio entrega la información de la materias, cursos,
profesores y secciones que se cargara al inicio de la ejecución del sistema
principal y que es administrada por otro programa.
El módulo de sistema de notas será una tarea a anexar al resto de los sistemas y tendrá
como objetivos generales el cálculo de las notas parciales, su promedio y la entrega de
boletines bimestrales para la utilización pertinente de la oficina de registros.

2.2. Funciones del sistema.

 Calculo de ponderación de notas parciales.

 Calculo de promedio de notas cada bimestre.
 Restricción de acceso, de tipo administrativo, docente y alumnado, al sistema de
notas.
2.3. Atributos del Sistema.

Atributos definidores: calculo de ponderación de notas y promedio de notas.

Atributos concomitantes: seguridad del sistema de acceso.

2.4. Atributos por función.

Promedio notas: con el resultado de las cuatro notas y sus ponderaciones, ingresadas por
el docente al sistema.

Seguridad del sistema con los atributos Administrativo, Docente y Alumno.

Página 6 de 28
3. Diseño del Sistema:

3.1. Diagramas de casos de uso:

Diagrama Profesor:

Diagrama Alumno:

Página 7 de 28
Diagrama Administrativo:

3.2. Para cada Caso de Uso.

3.2.1 Casos de uso expandidos:

Caso de uso Profesor

Caso de uso Diagrama profesor

Actores Profesor
Resumen En este caso de uso el profesor ingresa
al sistema con su determinada cuenta, si
el número es válido podrá consultar notas
de estudiantes, ingresar, eliminar o
modificar notas, este último solo si el
semestres no está cerrado.

Página 8 de 28
Curso normal de los eventos:

1 Este caso 2 Este comprueba la

comienza cuando identificación, si es
el profesor ingresa correcta dará
al sistema con su opciones al
identificación profesor
3 El profesor ingresa 4 El sistema por otra
si desea parte le señala los
a) Ingresar datos pertinentes.
notas.
b) Modificar
notas
c) Consultar
notas
d) Eliminar
notas

Cursos alternativos

Línea 1 Número de identificación no válido; no se

permitirá acceso al sistema.
Línea 4 No entrega datos, si la opción es distinta o
está fuera de rango. (Ej.: Si el semestre está
cerrado no se puede modificar una nota).

Caso de uso Alumno

Caso de uso Diagrama Alumno

Actores Alumno
Resumen En este caso el alumno con su RUN
puede ingresar al sistema, seleccionar
algún bimestre o semestre de notas del
año actual, para ver sus notas.

Página 9 de 28
Curso normal de los eventos:

1 Este caso 2 El sistema en

comienza cuando cuestión
el alumno ingresa comprueba la
al sistema con su identificación, si es
RUN correcta dará la
opción de ver notas
por asignaturas.
3 El Alumno ingresa 4 El sistema por otra
si desea parte le señala los
a) Consultar datos pertinentes.
notas por
asignatura
b) Consultar
por
bimestre/
semestre

Cursos alternativos

Línea 1 Número de identificación no válido, no se

permitirá acceso al sistema.
Línea 4 No entrega datos o selecciona un semestre /
bimestre de años anteriores.

Caso de uso Administrativo

Caso de uso Diagrama Administrativo

Actores Administrativo
Resumen En este caso el administrativo con sus
datos puede ingresar al sistema,
seleccionar algún bimestre o semestre de
notas del año actual, para ver notas e
imprimirlas.

Página 10 de 28
Curso normal de los eventos:

1 Este caso 2 Este comprueba la

comienza cuando identificación, si es
el administrativo correcta dará las
ingresa al sistema opciones
del colegio con sus pertinentes
datos.
3 Ingresa al nuevo 3 Arroja los datos
sistema de notas pertinentes
(opciones del
sistema de notas).
4 El administrador 5 El sistema por otra
ingresa a parte le señala los
a) Leer el datos pertinentes.
boletín de
notas
b) Imprimir
boletín de
notas

Cursos alternativos

Línea 1 Número de identificación no válido, no se

permitirá acceso al sistema.
Línea 4 No entrega datos o selecciona un semestre /
bimestre de años anteriores.

Página 11 de 28
3.2.2 Diagramas de secuencia:

Diagrama Profesor:

Diagrama Alumno:

Página 12 de 28
Diagrama Administrativo:

3.2.3 Diagrama de Clases:

Página 13 de 28
4. Integración del Sistema.
4.1. Diagrama de Clases de Diseño.

4.2. Diagrama de Componentes.

Página 14 de 28
4.3. Modelo Entidad-Relación.

Página 15 de 28
5. Arquitectura del Sistema.

5.1. Diagrama de Arquitectura.

5.2. Especificación Técnica de Arquitectura.

Para la implementación del sistema propuesto y su especificación técnica podemos decir

lo siguiente, el servidor web del sistema de notas será conectado vía Ethernet al servidor
principal del sistema global del establecimiento, este extenderá su acceso a los usuarios
que se muestran en el diagrama estos son el alumno con permisos de solo lectura, el
docente con permiso de lectura, escritura, actualización y eliminación de notas y como
último usuario la oficina de registro que tendrá acceso de lectura y de impresión de
boletines bimestrales en su formato particular.

5.3. Especificaciones de Seguridad.

El acceso será restringido para darla uso a los tres actores involucrados en el proceso de
gestión de notas, comenzando por el docente que tendrá permisos CRUD, la oficina de
registro que tendrá permisos de lectura e impresión de notas bimestrales, y el alumno que
tendrá permisos de lectura.

Al momento de calcular el promedio de cada bimestre, la modificación de las notas

parciales es bloqueada e inaccesible.

Página 16 de 28
6. Prototipos

6.1 Prototipos de GUI, 6.2 Prototipos de informes.

Para ingresar al sistema cualquier usuario deberá introducir sus datos, ya sea en el caso
del estudiante su RUN. El profesor y administrativo podrán entrar con su usuario y
contraseña.

De este ingreso se puede generar el correcto acceso a la siguiente pantalla, o se puede

generar un informe de error:

Página 17 de 28
En caso de acceder correctamente, se mostrarán las siguientes ventanas, dependiendo
del usuario que solicito el login.

En el caso del alumno se mostrará la ventana mostrando las notas por asignatura o las
notas por bimestre, los cuales son 4. Sólo podrá acceder a información del año actual.

Los informes saldrán en la misma ventana, indispensablemente pueden variar en la

generación final. El alumno como tal manipulara el combobox Asignatura, que en este
caso está seleccionada Historia y el combobox Bimestre, dividido en 4.

Página 18 de 28
El profesor en su ventana podrá ingresar notas, modificarlas en el caso que el bimestre
siga abierto, eliminarlas o simplemente consultar. La generación de informe se puede
apreciar también ya que al seleccionar un curso en el combobox (en este caso 1°A, como
ejemplo), se mostrarán los alumnos, notas, promedios y ponderaciones en el caso de ser
tal. El profesor haciendo doble click sobre una nota o un casillero vacío, podrá hacer las
modificaciones pertinentes. El presionar cerrar bimestre el promedio se calculará de
manera automática y no se podrán modificar posteriormente.

Página 19 de 28
Para el administrativo variará un poco su ventana ya que tiene acceso al sistema del
colegio como tal y al sistema de notas que estamos implementando. El podrá en nuestro
sistema ingresar el RUN de un estudiante y seleccionar un bimestre que esté dentro del
año. El reporte saldrá en la misma ventana, con cada ramo del estudiante, notas y
respectivo promedio. Además podrá imprimir el boletín directamente pulsando el botón de
la pantalla.

Página 20 de 28
7. Pruebas del Sistema.

7.1. Especificación de Pruebas.

De acuerdo a los niveles de prueba, se hace sobre el marco de la prueba de unidad del
módulo de sistema de notas, se hace un test case para determinar si la aplicación es
satisfactoria de acuerdo requerimientos y a los casos de uso diseñados a petición del
cliente.

Se hace uso de los tipos de las pruebas según lo que conocemos que son la caja blanca,
donde se hace reconocimiento del funcionamiento del código en sí y las variantes que se
pudiesen producir. Dentro de las pruebas de caja negra se hacen pruebas de ingreso de
distintos tipos de ingreso de datos válidos y no validos como también la medida del largo
máximo permitido y la validación de las ventanas de diálogos para cada uno de los
errores de los campos de cada acceso distinto por cado tipo de usuario aceptado.

7.2. Casos de Pruebas.

Según los accesos de caso uno de los usuarios que interactúan con el sistema de notas y
sus roles, estos son los resultados finales:

Usuario Docente
Caja Caja
Funciones negra blanca
Ingreso al sistema OK OK
Ingreso de notas OK OK
Consulta de notas OK OK
Eliminación de notas OK OK
Usuario Alumno
Caja Caja
Funciones negra blanca
Ingreso al sistema OK OK
Consulta de notas OK OK
Usuario Administrativo
Caja Caja
Funciones negras blanca
Ingreso al sistema de notas OK OK
Consulta de notas OK OK
Impresión de boletín de
notas OK OK

Página 21 de 28
8. Implementación del sistema:

8.1 Plan de implementación:

El nuevo software de sistema de notas podrá agilizar en gran medida los procesos
actuales de la institución. De hecho muchos colegios, universidades, institutos, en la
actualidad, funcionan casi por completo con sistemas tecnológicos.

En la actualidad la tecnología o software en sí, está tomando un rol importante dentro de

la sociedad, se ahorra dinero, espacio, tiempo, entre grandes variedades de ventajas.

Ahora bien cuando en una organización se plantea un cambio, de cualquier tipo, en este
caso del sistema de notas, es habitual encontrarse con una resistencia al cambio por
parte del cuerpo docente, estudiantes, etc. Puesto que los humanos nos acomodamos a
una forma de actuar y nos resulta bastante molesto tener que modificarla.

Lo anterior se agudiza considerablemente si el cambio que se pretende realizar afecta al

sistema de información de dicha organización.

Por lo que se planteará un plan de implementación para que esto se realice de una forma
más ordenada y correcta. Además de disipar todos los posibles temores que dicho cambio
pudiera plantear a los afectados, así como evitar posibles inconvenientes que puedan
surgir en el cambio de software.

Las premisas básicas para este nuevo sistema serán las siguientes:

1. Que no se pierda ningún material del cual dispongan los usuarios actualmente, es
decir, que las notas estén en el sistema, de tal forma que los profesores no deban
migrar todo a mano o que el administrativo pueda seguir con su formato de
impresión.
2. Lo ideal, además es que cada miembro del personal a ocupar el sistema cuente
con un equipo (notebook, pc) ya que lo ayudará a sentirse más cómodo trabajando
con algo que conoce, es decir, que no tenga que pedir, esperar, para ocupar el
sistema.

Estas premisas se deberán cumplir sin dificultad alguna.

Breve referencia al software:

En pocas palabras el software es el complemento necesario al hardware, para conseguir

que el computador funcione. A los efectos del usuario final, la única capa de interés es la
más externa, puesto que es la que recoge las aplicaciones que él emplea; sin embargo,
de la calidad y las características de las capas subyacentes dependerán de la velocidad
de funcionamiento y las prestaciones generales del sistema. Es preciso la modificación de
hardware, aunque los usuarios finales sólo perciban el aspecto de la pantalla cuando
ingresen al sistema (en caso de ser necesaria tal modificación).

Página 22 de 28
Usuario:

Es preciso disponer para los usuarios un usuario y contraseña, para ingresar al sistema
que sea fácil de recordar para ellos, así se sentirán menos ajenos a la hora de acceder.

Además como plan de implementación:

Se deben conocer las áreas organizativas afectadas, en principio:

a) Administración.
b) Claustro de profesores.
c) Estudiantes.

El número de computadores a modificar con el sistema de notas.

Plan de información y formación:

Es imprescindible, con el fin de garantizar el éxito del cambio de informar a los afectados
de los planes a desarrollar, así como el procedimiento y el calendario previsto, porque las
personas informadas colaborarán más activamente, interesadas en adquirir la valiosa
experiencia durante el cambio.

Es necesario elaborar breves documentos con las instrucciones para el acceso al nuevo
sistema. Además de alguna clase práctica de demostración consolidada entre el colegio y
nuestra empresa.

Prueba piloto:

Evidentemente, antes de proceder a realizar la integración del sistema, parece lógico

realizar una prueba piloto o varias, en función de las dificultades que se encuentren en la
primera, con el fin de identificar las posibles dificultades prácticas que existen en el
acceso.

Dado esto se podría constituir la documentación adecuada que será expuesta a la

comunidad con las consultas comunes.

Página 23 de 28
9. Mantención del sistema.

9.1. Plan de mantención.

Mantención general:

Esta tarea la deberán realizar los usuarios del sistema de forma diaria. Será de fácil
ejecución y puede que no les tome tiempo.

Cuando un usuario utilice el sistema durante el día o en el transcurso de este, deberá

percatarse si el sistema arroja algún tipo de error o mensaje inesperado. En caso de
suceder así, deberá llenar el siguiente documento.

Mantención
Inspección diaria (sólo de ser necesaria)
Fecha _________________
Nombre del usuario: ____________________________________
Hora del suceso: __________________
Riesgos del trabajo: Ninguno.

Tipo de error (escribir el código, palabra del mensaje):

________________________________________________________________
________________________________________________________________

__________________
Firma

Página 24 de 28
Con este documento podremos distinguir si el sistema sufre errores, que tipo de errores y
qué medidas tomar en caso de que sea algo de menor o mayor impacto.

Nuestra central estará atenta al software de manera continua.

De todas formas se implementarán tareas a realizar para mantener el software

completamente funcional:

 Se harán limpiezas mensuales de archivos “temporales” que de alguna forma

llegaron al sistema o fueron una generación de este. De todas formas al ser la
última opción se investigará porque sucede esto y se solucionará.
 Mantenimiento de la base de datos del sistema.
 Optimización de los equipos, ya sea limpieza de registro, desfragmentación,
entren otras.
 Revisión de seguridad en los equipos (actualización de antivirus, escaneos de
discos, etc.).

Además cada vez que el sistema sufra algún percance, daño, mejora, limpieza, etc. Se
documentará cada suceso, que refleje de la mejor forma el tipo de mantenimiento.

Mantenimiento preventivo:

Los equipos con el sistema de notas, se monitorizarán mediante herramientas de

diagnóstico, lo que nos permitirá comprobar el estado de los componentes del sistema sin
detener su ejecución. En caso de que se vea que el equipo está teniendo algún daño
potencial que pueda dejar inoperativo el software, se realizará un aviso y posteriormente
se plantearán soluciones. El sistema en sí, también se monitorizará para saber si sufre
percances que lo puedan deshabilitar a futuro.

La tarea de mantenimiento será en común acuerdo con el colegio buenas peras y se

estimará el tiempo entre uno y otro dependiendo de su solicitud o común acuerdo.

Página 25 de 28
 Conclusiones
Luego de diseñar el sistema usando como parámetros los métodos de desarrollo de la
guía del Swebok, se confecciona satisfactoriamente y a cabalidad todos los puntos
establecidos, con esto se logramos un diseño elegante de la interfaz para el software
desarrollado, con la fundamentación de las pruebas que avalan su calidad, seguridad,
robustez y eficiencia que por cierto también va acompañado de su uso intuitivo de fácil
utilización para el usuario con la consecuente agilización de los procesos de mayor
importancia para el sistema del establecimiento “Buenas Peras” y su utilización de fácil
manejo que es lo que se requiere dentro de lo principal.

Para todo esto el trabajo en equipo fue fundamental y se puede observar un informe de
calidad con todo lo que se requirió para el cliente, para una segunda etapa de entrega se
lograra un avance incremental del desarrollo del software en el cual, el control de cambios
posteriores podría ser factible de acuerdo a contrato pre-establecido, se revisara junto al
cliente el producto y se considerara cualquier duda o consulta pertinente.

Esperamos lograr la cobertura en demasía de acuerdo a los requerimientos del cliente, el

trabajo que se hace en este informe demuestra la calidad profesional de este grupo
humano redactado en este informe para la adecuada interpretación del cliente y su
posterior documentación del mismo.

Página 26 de 28
 Bibliografía

Fundamentos de la Dirección de Proyectos, 4ª. Edición. (Guía del PMBOK®)

Modelo de proceso:

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

Arquitectura del sistema:

https://bittacorp.wordpress.com/2008/11/22/diagrama-de-arquitectura-del-sistema/

Página 27 de 28
Página 28 de 28