Este documento presenta un plan para desarrollar un sistema de información para registrar la matrícula de estudiantes en la Universidad Privada Domingo Savio. El sistema permitirá registrar estudiantes, profesores, asignaturas, horarios de clases, calificaciones y emitir reportes. Se utilizará el proceso unificado de desarrollo y lenguaje UML para el análisis, diseño e implementación del sistema a lo largo de tres meses.

1. SISTEMA DE
INFORMACION
PARA REGISTRAR
MATRICULA EN LA
UNIVERSIDAD
Carlos R. Dorado Sosa
Modalidad
de
Grado

2. INTRODUCCION
 El presente documento es un Plan de Desarrollo para
el Registro de Materias de la Universidad Privada
Domingo Savio,para el mejor manejo de la
información de los estudiantes que acuden a dicha
universidad.

3. PLANTEAMIENTO DEL
PROBLEMA
 Una persona viene caracterizada por su CI, nombre, dirección y estado
civil, y ésta puede convertirse en estudiante al darse de alta como tal
en la universidad. Como estudiante podrá matricularse de las
asignaturas que se imparten en la universidad, que tendrán un código,
un nombre, un profesor responsable y un curso asignado. Una vez
matriculado, el estudiante podrá recibir una beca, y en su nueva
condición de becario tendrá asignado un nuevo código y se conocerá
el importe de la misma; al finalizar el curso, la condición de becario
acabará. Una vez el estudiante se matricula, tanto si recibe beca
como si no, deberá examinarse de las asignaturas en las que se
encuentra matriculado hasta que finalice el curso y vuelva a
matricularse de nuevo, o bien deje la universidad y con ello deje de ser
estudiante. Además, convendrá tener una serie de aplicaciones tales
como dar de alta a nuevas personas y asignaturas, llevar a cabo la
matriculación de estudiantes en asignaturas, registrar las notas
obtenidas por los estudiantes al examinarse de cualquier asignatura en
la que están matriculados y una serie de listados tales como los
alumnos matriculados en una asignatura, las asignaturas en las que se
ha matriculado un alumno y el listado de notas por asignatura (actas).

4. DELIMITACIONES
 Delimitación Científica:
Este sistema de información está relacionado y
basado en el estudio de: Base de Datos Relacional,
Sistema de información, Ingeniería de Software,
Aplicación de Proceso Unificado de Desarrollo
(PUD), Lenguaje Unificado de Modelado (UML),
Arquitectura Multicapas.

5.  Delimitación Espacial
La universidad Privada Domingo Savio está ubicada
en el tercer anillo esquina Av. Beni
 Delimitación Temporal
Desarrollo del software será de 3 meses teniendo
como fecha de inicio el 30/05/2013.
DELIMITACIONES

6. OBJETIVOS
 Objetivo General:
Desarrollar un sistema de información para el registro
de matrícula del estudiante.

7.  Objetivos Específicos:
 Identificar las funciones requeridas por el usuario
del sistema.
 Realizar el análisis de los requisitos del usuario.
 Diseñar los componentes bajo la arquitectura tres
capas, utilizando el lenguaje UML.
 Implementar los componentes diseñados.
 Diseñar e implementar las prueba de los
componentes del sistema.
 Elaborar un manual de usuario del sistema.

8. JUSTIFICACION
 Justificación Teórica:
En el desarrollo de este proyecto aplicaremos
conocimientos de base de datos relacionales, conceptos
de sistemas de información, ingeniería de software y
arquitectura de software.

9.  Justificación Metodológica
Se utilizará el Proceso Unificado de Desarrollo (PUD),
para organizar las diferentes etapas de trabajo para
el desarrollo de este proyecto, además de
proporcionar los artefactos que deben desarrollarse
en las diferentes fases. Para desarrollar los artefactos
utilizaremos el Lenguaje Unificado de Modelado
(UML) para especificar, construir, visualizar y
documentar los artefactos de un sistema de software
orientado a objeto.
Se justifica esta metodología porque reduce la
dificultad de coordinar las múltiples etapas:
Requerimiento, Análisis, Diseño, Implementación,
Prueba de trabajo de un proyecto de software.

10.  Justificación Practica:
Contribuir con la presentación de un plan de proyecto
como trabajo final de grado.
Asimismo, profundizar conocimientos en el área de
gestión de proyecto.

11. DISEÑO METODOLOGICO
 Tipo de Investigación:
Se ha seguido el tipo de investigación descriptiva
orientado a la gestión, desarrollo de modelos y
artefactos para sistemas de gestión.

12.  Proceso Metodológico:
En el desarrollo del proyecto se seguirá los pasos que
plantea el ciclo de vida del Proceso Unificado, por su
característica: Dirigido por casos de uso, centrado en
su arquitectura, iterativo e incremental del
desarrollo del software, con sus fases de: Inicio,
Elaboración, Construcción y transición. En cada una
de estas fases existen cinco flujos de trabajo:
Requisitos, Análisis, Diseño, Implementación y
Prueba. El proceso unificado utiliza el Lenguaje
Unificado de Modelado (UML) para preparar todos
los esquemas de un sistema de información.

13. Para el presente proyecto se plantea las siguientes
fases y flujos:
Ilustración 1 Diagrama de Fases y Flujos
Fuente: IBM RUP Rational Unified Process.

14. Técnicas para recolección
de información.
 Las técnicas de utilizadas para la
recolección de datos son:
 Entrevista, cuestionario
 Observación
 Sondeo
 Prototipado u otros.

15. Artefactos de Diseño
 Seguidamente se muestra una lista de los
artefactos y herramientas utilizados en el
desarrollo del proyecto:
 Diagrama de actividades.
 Diagrama de casos de uso.
 Diagrama de Clases.
 Diagrama de despliegue.

16. Requerimientos
funcionales.
Nro. Requerimientos Funcionales
1 Registro de usuario
2 Gestionar estudiante
3 Gestionar profesor
4 Gestionar Persona
5 Gestionar Encargado de Registro
6 Gestionar matricula
7 Gestionar curso
8 Gestionar docentes que imparten los cursos inscritos
9 Gestionar Beca
10 Gestionar carreras que ofrece la universidad
11 Gestionar calificaciones de cursos inscritos
12 Emitir Boleta de Registro del estudiante
13 Generar Reporte Alumno Matriculado
14 Generar Asignatura Disponible
15 Generar Reporte de Notas por Estudiante
16 Generar Reporte de Notas por Asignatura

17. Requerimientos no
funcionales
Las Especificaciones Suplementarias contienen los requisitos
de sistema que no se contemplan en el documento de
Requerimientos de Software. Algunos de ellos son:
• Aplicación de estándares.
• Atributos de la calidad del sistema a construir, como la
facilidad de uso y la performance.
• Requisitos de entorno y sistema operativo, compatibilidad y
restricciones de diseño.
• Otros requisitos que no se contemplan en el documento de
requerimiento de software.

18. MODELO DE DOMINIOclass Modelo de dominio
Persona
- apellidoMaterno
- apellidoPaterno
- direccion
- id
- nombre
- telefono
Estudiante
- id
- idPersona
- /EstadoDocumentacion
Profesor
- id
- profesion
RegistrodeMateria
- id
- fecha
- /NotaFinal
Beca
- descuento
- id
Asignatura
- credito
- id
- nombre
- sigla
Modelo de Dominio
EncargadodeRegistro
- id
- idPersona
- usuario
- contrasena
Carrera
- id
- nombre
- descuento
InscripcionCarrera
- fecha
- id
Ev aluacion
- id
- nombre
AsignaturaHabilitada
- fechaFin
- fechaInicio
- idAula
- bloque
- id
- piso
Documentos
- CertificadoNacimiento
- Fotografia
- TituloBachiller
DetalleNota
- calificacion
- FechaEvaluacion
- porcentaje
MateriaporCarrera
- id
- idCarrera
- idAsignatura
- NroSemestre
Facultad
- id
- iddecano
- nombre
Especialidad
- id
- idProfesor
- nombre
Turno
- id
- nombre
- horario
1
Registra
*
1 *
1 dicta
*
1
1..*
*
* *
1
asigna
*
1
*
1
1
1
*
*
registra
1
*
recibe
0..1
1..*
1

19. Diseño Lógico
create database Registro
go
use Registro
go
create table persona
(
id varchar(10) primary key,
nombre varchar(20),
apellidoPaterno varchar(20),
apellidoMaterno varchar(20),
direccion varchar(20),
genero varchar(1),
telefono numeric(18,0)
)

20. Diseño Lógico
create table estudiante
(
id int primary key not null identity(1,1),
idPersona varchar(10),
estado varchar(20),
foreign key (idPersona) references persona (id)
)
create table encargadoRegistro
(
id int primary key not null identity(1,1),
idPersona varchar(10),
usuario varchar (10),
contrasena varchar (10),
foreign key (idPersona) references persona (id)
)

21. Diseño Lógico
create table especialidad
(
id int primary key not null identity(1,1),
idProfesor int,
nombre varchar(20),
)
create table profesor
(
id int primary key not null identity(1,1),
idPersona varchar(10),
profesion varchar(20),
idEspecialidad int,
foreign key (idPersona) references persona (id),
foreign key (idEspecialidad) references
especialidad (id)
)

22. Diseño Lógico
create table documento
(
id int primary key not null identity(1,1),
nombre varchar(10)
)
create table detalleDocumento
(
idEstudiante int,
idDocumento int,
estado char(1),
foreign key (idEstudiante) references estudiante (id),
foreign key (idDocumento) references documento (id),
CONSTRAINT [pk_detalleDocumento] PRIMARY KEY CLUSTERED
(
[idEstudiante] ASC,
[idDocumento] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

23. Diagrama de Secuencia
sd Diagrama de Secuencia
Encargado de Registro
FrmRegistroAsignatura RegistrodeAsignatura Estudiante AsignaturaHabilitada
BtnNuevo_click()
limpiar()
TxidEstudiante_TabIndexChanged()
Listar()
CbxAsignatura_SelectionChangeCommitted()
Listar()
BtnGuardar_click()
sw= validar() : Boolean
[sw=true] : Guardar()
[sw = false] : Mensaje()

24. Diagrama de Clasesclass Modelo de diseño
asignatura
«column»
*PK id: int
nombre: varchar(10)
credito: varchar(10)
sigla: varchar(10)
descripcion: varchar(30)
«PK»
+ PK__asignatu__3213E83F398D8EEE(int)
asignaturaHabilitada
«column»
*PK id: int
FK idAsignatura: int
FK idProfesor: int
FK idAula: int
FK idTurno: int
gestion: varchar(10)
fechaInicio: date
fechaFin: date
«PK»
+ PK__asignatu__3213E83F46E78A0C(int)
«FK»
+ FK__asignatur__fecha__48CFD27E(int)
+ FK__asignatur__idAul__4AB81AF0(int)
+ FK__asignatur__idPro__49C3F6B7(int)
+ FK__asignatur__idTur__4BAC3F29(int)
aula
«column»
*PK id: int
nombre: varchar(10)
bloque: varchar(10)
piso: varchar(10)
«PK»
+ PK__aula__3213E83F31EC6D26(int)
beca
«column»
*PK id: int
nombre: varchar(10)
FK idInscripcionCarrera: int
descuento: int
«PK»
+ PK__beca__3213E83F2D27B809(int)
«FK»
+ FK__beca__descuento__2F10007B(int)
carrera
«column»
*PK id: int
nombre: varchar(10)
FK idFacultad: int
«PK»
+ PK__carrera__3213E83F22AA2996(int)
«FK»
+ FK__carrera__idFacul__24927208(int)
detalleDocumento
«column»
*pfK idEstudiante: int
*pfK idDocumento: int
estado: char(1)
«PK»
+ pk_detalleDocumento(int, int)
«FK»
+ FK__detalleDo__idDoc__1B0907CE(int)
+ FK__detalleDo__idEst__1A14E395(int)
detalleNota
«column»
*pfK idTipoEvaluacion: int
*pfK idRegistroMateria: int
fechaEvaluacion: date
porcentaje: int
calificacion: int
«PK»
+ pk_detalleNota(int, int)
«FK»
+ FK__detalleNo__idReg__5629CD9C(int)
+ FK__detalleNo__idTip__5535A963(int)
documento
«column»
*PK id: int
nombre: varchar(10)
«PK»
+ PK__document__3213E83F164452B1(int)
encargadoRegistro
«column»
*PK id: int
FK idPersona: varchar(10)
usuario: varchar(10)
contrasena: varchar(10)
«PK»
+ PK__encargad__3213E83F07F6335A(int)
«FK»
+ FK__encargado__idPer__09DE7BCC(varchar)
especialidad
«column»
*PK id: int
nombre: varchar(20)
«PK»
+ PK__especial__3213E83F0CBAE877(int)
estudiante
«column»
*PK id: int
FK idPersona: varchar(10)
estado: varchar(20)
«PK»
+ PK__estudian__3213E83F03317E3D(int)
«FK»
+ FK__estudiant__idPer__0519C6AF(varchar)
facultad
«column»
*PK id: int
nombre: varchar(10)
FK idDecano: int
«PK»
+ PK__facultad__3213E83F1DE57479(int)
«FK»
+ FK__facultad__idDeca__1FCDBCEB(int)
inscripcionCarrera
«column»
*PK id: int
FK idEstudiante: int
FK idCarrera: int
fecha: date
«PK»
+ PK__inscripc__3213E83F276EDEB3(int)
«FK»
+ FK__inscripci__idCar__2A4B4B5E(int)
+ FK__inscripci__idEst__29572725(int)
materiaCarrera
«column»
*PK id: int
FK idCarrera: int
FK idAsignatura: int
nroSemestre: varchar(10)
«PK»
+ PK__materiaC__3213E83F3D5E1FD2(int)
«FK»
+ FK__materiaCa__idAsi__403A8C7D(int)
+ FK__materiaCa__nroSe__3F466844(int)
persona
«column»
*PK id: varchar(10)
nombre: varchar(20)
apellidoPaterno: varchar(20)
apellidoMaterno: varchar(20)
direccion: varchar(20)
genero: varchar(1)
telefono: numeric(18)
«PK»
+ PK__persona__3213E83F7F60ED59(varchar)
profesor
«column»
*PK id: int
FK idPersona: varchar(10)
profesion: varchar(20)
FK idEspecialidad: int
«PK»
+ PK__profesor__3213E83F108B795B(int)
«FK»
+ FK__profesor__idEspe__1367E606(int)
+ FK__profesor__idPers__1273C1CD(varchar)
registroMateria
«column»
*PK id: int
FK idEncargadoRegistro: int
FK idInscripcionCarrera: int
FK idAsignaturaHabilitada: int
fecha: date
notaFinal: int
«PK»
+ PK__registro__3213E83F4E88ABD4(int)
«FK»
+ FK__registroM__idAsi__52593CB8(int)
+ FK__registroM__notaF__5070F446(int)
+ FK__registroM__idIns__5165187F(int)
sysdiagrams
«column»
* name: sysname
* principal_id: int
*PK diagram_id: int
version: int
definition: varbinary(max)
«PK»
+ PK__sysdiagr__C2B05B6159FA5E80(int)
«unique»
+ UK_principal_name(int, sysname)
tipoEvaluacion
«column»
*PK id: int
nombre: varchar(10)
«PK»
+ PK__tipoEval__3213E83F35BCFE0A(int)
turno
«column»
*PK id: int
nombre: varchar(10)
horario: varchar(10)
«PK»
+ PK__turno__3213E83F4316F928(int)
0..*
(idPersona = id)
1
0..*
(idAula = id)
1
0..*
(idProfesor = id)
1
0..*
(idTurno = id)
1
0..*
(idInscripcionCarrera = id)
1
0..*
(idFacultad = id)1
0..*
(idDocumento = id)
1
0..*
(idEstudiante = id)
1
0..*
(idRegistroMateria = id)
1
0..*
(idAsignatura = id)
1
0..*
(idPersona = id)
1
+FK__registroM__idIns__5165187F
0..*
(idInscripcionCarrera = id)
1
0..*
(idDecano = id)1
0..*
(idCarrera = id)
1
0..*
(idEstudiante = id)
1
0..*
(idAsignatura = id)
1
0..*
(idCarrera = id)
1
0..*
(idEspecialidad = id)
1
0..*
1
0..*
(idAsignaturaHabilitada = id)
1
0..*
(idEncargadoRegistro = id)
1
0..*
(idTipoEvaluacion = id)
1

25. Diagrama de
Componentescmp Modelo de implementación
«boundary»
Capa de Presentacion
«l i brary»
Capa de Negocios
«l i brary»
Capa de acceso a Datos
«executabl e»
Sistema de Registro de
Asignatura
«boundary»
Reportes
«Database»
DbEstudiante
«use»
«use»
«use»
«use»
«use»

26. Conclusiones
 Conforme a los resultados obtenidos del
sistema se puede concluir, en primer lugar,
que si cumple con el objetivo general de
estudio. Puesto que se logró crear el diseño
de un nuevo sistema de información para el
registro de Materias para elaborarlo e
implementarlo en un la Universidad.
 En el desarrollo del nuevo sistema de
información para el registro de Materia, se
logró a lo largo de este estudio cumplir con
los requerimientos del cliente, obteniendo los
resultados que el cliente requería.

27. Recomendaciones
 Algunas sugerencias para el que administre e
interactúa con el sistema, es que haga un
backup diario de la base de datos.
 Se necesita un mejor método de seguridad de la
web, puede ser usando https.

28. GRACIAS.