Documentacion de Software 2

INDICE
Agradecimiento
Dedicatoria
PARTE I FUNDAMENTOS TEORICOS
Capítulo 1
1. Perfil del proyecto
2. Introducción
3. Antecedentes
4. Descripción del problema
5. Situación problemática
6. Situación deseada
7. Objetivos
7.1Objetivo general
7.2Objetivo específicos
8. Justificación
9. Alcance
10. Metodología de desarrollo
Capítulo 2
2. La organización
2.1. Antecedentes
2.2. Situación actual
2.3. Servicios que presta
2.4. Metodología de trabajo
2.5. Estructura organizacional
PARTE II DESARROLLO DEL SISTEMA

Capítulo 3
3. Captura de requisitos
3.1. Lista de requerimientos
3.2. Modelo de negocio
3.2.1. Registrar inscripción
3.2.2. Registro de estudiantes
3.3. Captura de requisitos como caso de uso
3.3.1. Identificación de actores
3.4. Casos de usos
3.4.1. Registrar cliente
3.4.2. Registrar consulta
3.4.3. Registrar ventas
3.4.4. Generar recibo de ventas realizada
3.4.5. generar reporte de todas las ventas
3.4.6. gestionar información del proveedor
3.4.7. registrar producto
3.5. Modelo de casos de uso
Capitulo 4
4. Análisis del sistema
4.1. Introducción
4.2. Identificar paquetes de análisis (subsistema)
4.2.1. Diagrama de paquete
4.2.2. Subsistema actualizar inventario
4.2.3. Subsistema realizar reporte
4.2.4. Subsistema registrar venta
4.2.5. Subsistema registrar consulta
4.3. Diagrama de colaboración
4.3.1. Diagrama de colaboración; Realizar consultas
4.3.2. Diagrama de colaboración; registrar ventas
4.3.3. Diagrama de colaboración; actualizar inventario
4.3.4. Diagrama de colaboración; registrar producto
4.3.5. Diagrama de colaboración; registrar cliente
Capitulo 5
5. Desarrollo del sistema+
5.1. Introducción
5.2. Arquitectura del sistema
5.3. Diagrama de despliegue
5.4. Diagrama de secuencia
5.4.1. Diagrama registra venta
5.4.2. Diagrama abastecimiento de productos
5.4.3. Diagrama consultar producto
5.4.4. Diagrama registrar producto
5.5. Diagrama de clases
5.6. Diseño lógico de la base de datos
5.7. Diseño físico de la base de datos
PARTE I
FUNDAMENTOS
TEORICOS
CAPITULO 1
PERFIL DEL PROYECTO
CAPITULO 2
ORGANIZACION
PARTE II
DESARROLLO DEL
SISTEMA
CAPITULO 3
CAPTURA DE REQUISITOS
3.1 Introducción
La captura de requisitos es el primer paso para cumplir con el objetivo general descrito
anteriormente, el cual conlleva al desarrollo de una página web de gestión para el control de
inscripción de los estudiantes de la Finor.
Siguiendo la metodología descrita en el Proceso Unificado para el desarrollo del Software,
a continuación, se procede con la descripción y definición de los requerimientos del
sistema, a través del modelo de negocio de la Finor, donde indicaremos a los actores y
casos de uso, lo cuales proporcionan la funcionalidad del sistemas y los actores que
interactúan con el mismo
3.2 LISTA REQUERIMIENTOS

3.2.1. REQUISITOS FUNCIONALES
Cada requerimiento tiene una descripción breve que refleja lo que el sistema brinda a los
usuarios. En esta tabla se identificarán los requisitos funcionales que se estructuran
mediante los casos de uso.
Nº Requerimientos Descripción
R1 Registrar Estudiantes Registra los datos de los estudiantes
R2 Registrar Docentes Registra los datos de los docentes que trabajan en la Finor.
R3 Registrar Administrador Registra los datos del administrador
R4 Registrar Carreras Registra los tipos de carreras que hay en la Finor de la
ciudad de Montero.
R5 Registrar Materias Registra los datos de la materias según el tipo de carrera al
cual pertenezcan
R6 Registrar Horarios Registra las horas que se llegara a pasar cada materia.
R7 Registrar Gestión Registra el tipo de gestión que tendrá las carreras de la
Finor.
R8 Registrar Días Registra los días que se pasaran clases cada materias
R9 Registrar Aulas Registra las aulas donde se pasaran clases cada materias
R10 Registrar Grupo Registra los grupos que llegaran a ver en cada carrera de la
Finor
R11 Registrar Oferta de Materia
R12 Registrar Inscripción Registra los datos de las inscripciones que se realizan en
dicha gestión
3.2.2. REQUISITOS NO FUNCIONALES DEL SISTEMA
N° Nombre Descripción
R1 Lenguaje de Programación El Sistema será implementado en el lenguaje Visual
Studio.ASP.NET 2012
R2 Gestor de base de datos El sistema será implementado en el gestor de base de
datos SQL Server 2012
R3 Sistema Operativos Se utilizará Windows Server 2012 como server y
Windows 8 para las PC de los usuarios
R4 Seguridad Se realizará un estricto control en la seguridad de los
usuarios y bitácora del sistema.
3.3.2. MODELO DE NEGOCIO

El modelo de negocio lo representamos con el siguiente diagrama de actividades
organizado en calles.
Gestionar Inscripción
Gestionar Estudiante
Gestionar Docente
3.4. IDENTIFICACIÓN DE LOS ACTORES Y CASOS DE USO

En la Finor se identificaron las siguientes personas, los cuales son los actores del Sistema y
sus requerimientos solicitados podemos definirlos como Casos de Uso.
3.4.1. ACTORES DEL SISTEMA
Los actores identificados que interactúan con el sistema
A. ADMINISTRADOR
B. DOCENTE
C. ESTUDIANTE
ACTORES DESCRIPCION
Administrador Persona encargado de Registrar y dar Mantenimientos de los datos del
Estudiante, Docente, Materia, Horario, Día, Gestión, Grupo, Oferta de
Maestro, inscripción
Docentes Persona encargada de ingresar nota de sus Estudiantes de su respectiva
materia
Estudiantes Persona encargada de poder inscribir materias que va a cursar en dicha
gestión
3.4.2. CASOS DE USOS

Los casos de uso identificados en el Sistema
Caso de Uso Descripción

Gestionar Estudiante Registra los datos de los estudiantes que solicitan
inscribirse en la Finor
Gestionar Docente Registra los datos de los docentes que trabajan en la
Finor.
Gestionar Administrador Registra los datos del administrador que trabajan en la
Finor.
Gestionar Carrera Registra los tipos de carreras que hay en la Finor de la
ciudad de Montero.
Gestionar Materia Registra los datos de las materias según el tipo de
carrera al cual pertenezcan.
Gestionar Horario Registra las horas que se llegara a pasar cada materia.
Gestionar Gestión Registra el tipo de gestión que tendrá las carreras de
la Finor.
Gestionar Día Registra los días que se pasaran clases cada materias
Gestionar Aula Registra las aulas donde se pasaran clases cada
materias
Gestionar Grupo Registra los grupos que llegaran a ver en cada carrera
de la Finor
Gestionar Oferta de Materia
Generar Inscripción Registra los datos de las inscripciones que se realizan
en dicha gestión
3.5. PRIORIZACIÓN DE LOS CASOS DE USO
Caso de Uso Actores Prioridad

Gestionar Estudiante Administrador Primario
Gestionar Docente Administrador Primario
Gestionar Administrador Administrador Primario
Gestionar Carrera Administrador Primario
Gestionar Materia Administrador Primario
Gestionar Horario Administrador Primario
Gestionar Gestión Administrador Primario
Gestionar Día Administrador Primario
Gestionar Aula Administrador Primario
Gestionar Grupo Administrador Primario
Gestionar Oferta de Administrador Primario
Materia
Generar Inscripción Estudiante Primario
3.6. DESCRIPCION DE LOS CASOS DE USO

De la lista de requerimientos mencionados, se identifican los Casos de Uso en un
Formato de presentación para la especificación de cada caso de uso basado en el formato
propuesto por Craig Larman. A continuación se detallan los siguientes Casos de Uso.
CASO DE USO: GESTIONAR ESTUDIANTE

La especificación de este caso de uso
GESTIONAR ESTUDIANTE
Actores Administrador
Propósito Registra los datos de los estudiantes que
solicitan inscribirse en la Finor
Resumen Es iniciado por el estudiante cuando solicita
inscribirse en la Finor.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR DOCENTE
GESTIONAR DOCENTE
Propósito Registrar los datos de los Docentes.
Resumen El administrador registra los datos de los
docentes que trabajan en la Finor.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR CARRERA

GESTIONAR CARRERA
Propósito Registrar las carreras de la Finor de la ciudad
de Montero.
Resumen El administrador registra la carrera.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR MATERIA
GESTIONAR MATERIA
Propósito Registrar las materias que correspondan a
dicha carrera.
Resumen El administrador debe registrar las materias
que les corresponda en dicha carrera.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR HORARIO

GESTIONAR HORARIO
Propósito Registrar las materias que correspondan a
dicha carrera.
Resumen El administrador debe registrar las materias
que les corresponda en dicha carrera.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR GESTION

GESTIONAR GESTION
Propósito Registrar el tipo de gestión que corresponda a
la carrera.
Resumen El administrador debe registrar el tipo de
gestión que corresponda a la carrera.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR DIA

GESTIONAR DIA
Propósito Registra el día en el que pasara clases cada
materia.
Resumen El administrador debe registrar en el día que
pasara clases cada materia.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR AULA

GESTIONAR AULA
Propósito Registra el aula donde se pasara clases cada
materia.
Resumen El administrador debe registrar el día que
pasara clases cada materia.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR GRUPO

GESTIONAR GRUPO
Propósito Registra los grupos existentes en una carrera.
Resumen El administrador debe registrar los grupos
existentes en una carrera.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR OFERTA DE MATERIA

GESTIONAR OFERTA DE MATERIA

Propósito Registra las ofertas de materia que hay
disponible en la carrera en una determinada
gestión.
Resumen El administrador debe registrar la oferta de
materia disponibles en una carrera de una
determinada gestión.
Tipo Primario
Flujo
CASO DE USO: GESTIONAR INSCRIPCION
GESTIONAR INSCRIPCION
Actores Administrador, Estudiante
Propósito Registra los datos de las inscripciones que se
realizan en dicha gestión.
Resumen El administrador y el estudiante pueden
realizar una inscripción en una determinada
gestión.
Tipo Primario
Flujo
3.7. DIAGRAMAS GENERAL DE CASOS DE USO

En el modelo de casos de uso se describen los procesos de inscripción, en términos de un
diagrama de casos de uso que sirve para comprender el contexto del Sistema.
CAPITULO 4
ANALISIS DEL SISTEMA
El objetivo de este capítulo es analizar los requerimientos descritos en la captura de
requisitos, detallándolos para así obtener un modelo de análisis completo, bien definido,
utilizando los diagramas necesarios para su desarrollo, los cuales serán el punto de partida
en la fase de diseño.
2.1. IDENTIFICACIÓN DE LOS PAQUETES
2.1.1. SUBSISTEMA ADMINISTRACION

En este paquete se realiza todo lo relacionado con la Administración del Sistema, como ser
2.2. ESPECIFICACIÓN DE LOS CASOS DE USO DE ANÁLISIS

En el modelo de caso del análisis del sistema del sistema de control de Servicios Técnicos
(Sistema SERVITEC) se realizarán las especificaciones de cada caso de uso a partir del
modelo de negocio descrito en la captura de requisitos.
Los Casos de Uso encontrados durante el flujo de trabajo del análisis, serán especificados
según el formato de especificaciones de casos de uso que se muestran en la tabla 2.1, la que
detallan las descripciones de cada especificación para su mejor comprensión.
CASO DE USO Describe el nombre de un Caso de Uso, que es

una pieza de funcionalidad bien delimitada y
reutilizable que da valor a los ACTORES que
interactúan con el SISTEMA en discusión.
Representa siempre una visión externa del
SISTEMA, desde el punto de vista de las
necesidades de los ACTORES. El conjunto de
casos de uso configura el mapa de la
funcionalidad de una aplicación.
ACTOR Persona o subsistema o clase que interactúan
directamente con el sistema, que hacen posible
la realización del caso de uso.
ACTIVACIÓN Indicar quién es el responsable de activar este
CU. 1.- A discreción de uno o varios
ACTORES (CU Principal); 2.- Otro CU que lo
incluye en su funcionalidad; 3.- Otro caso de
uso que lo invoca para extender su
funcionalidad en determinadas condiciones.
PROPÓSITO Describir brevemente cual es la razón de ser de
este caso de uso. Que cadena de valor
suministra a los ACTORES. Evitar referirse a
la funcionalidad que ha sido subcontratada (vía
incluye o extiende) a otros casos de uso.
El propósito puede redactarse como un
resumen de las actividades de un proceso de
negocio que posteriormente serán ordenadas
en el respectivo flujo de eventos ACTOR-
SISTEMA, o bien en forma de declaración de
una regla de negocio.
PRECONDICIONES Son las tareas que tienen que ser realizada
antes de activar un caso de uso.
FLUJO PRINCIPAL DE EVENTOS DEL Relación de eventos de negocios motivados
ACTOR por las tareas y responsabilidades de un
ACTOR (Agente que interactúa con el
SISTEMA con un ROL concreto; entra,
manipula o recibe información). Puede ser una
persona o un subsistema siempre que cumpla
la condición de ser elemento externo al
SISTEMA.
FLUJO PRINCIPAL DE EVENTOS DEL Relación de eventos motivados por la reacción
SISTEMA del SISTEMA en discusión ante el
comportamiento de un ACTOR.
Posteriormente, traduciremos las distintas
reacciones del SISTEMA en una interacción de
objetos.
VARIACIONES Y EXTENSIONES Todas aquellas variaciones que decidimos
añadir a un evento como opciones posibles
para ampliar el comportamiento general del
caso de uso. Si la decisión implica
subcontratar a otro caso de uso para que se
responsabilice de dicha funcionalidad,
entonces indicamos que en el evento concreto
hay un punto de extensión que activará a otro
caso de uso.
EXCEPCIONES Todas aquellas perturbaciones que tienen una
cierta probabilidad de aparecer en un evento y
pueden romper el flujo de actividades sin dejar
terminar correctamente el caso de uso.
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR ESTUDIANTE

Se realiza la especificación del caso de uso Gestionar Estudiante
CASO DE USO Gestionar Estudiante

ACTOR Administrador
ACTIVACIÓN Es activador por el Administrador. La cual
registrará todos los datos de los Estudiantes.
PROPÓSITO Tener un registro de todos los Estudiantes
PRECONDICIONES Guardar, Modificar: Que el registro no exista.
Eliminación: Que el registro no tenga ninguna
relación
FLUJO PRINCIPAL DE EVENTOS DEL El administrador es el encargado de registrar
ACTOR los datos de los estudiantes, modificar,
eliminar y buscar a los estudiantes.
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos del estudiante,
SISTEMA modifica, elimina y busca los datos de los
estudiantes.
VARIACIONES Y EXTENSIONES
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR DOCENTE
Se realiza la especificación del caso de uso Gestionar Docente
CASO DE USO Gestionar Docente

ACTOR Administrador
registrará los datos de los Docentes.
PROPÓSITO Tener un registro de todos los Estudiantes
relación
ACTOR los datos de los docentes, modificar, eliminar y
buscar a los docentes.
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos del docente,
SISTEMA modifica, elimina y busca los datos de los
docentes.
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR CARRERA

Se realiza la especificación del caso de uso Gestionar Carrera
CASO DE USO Gestionar Carrera

ACTOR Administrador
registrará los datos de la Carrera.
PROPÓSITO Tener un registro de dato de la Carrera
relación
ACTOR los datos de la carrera, modificar, eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos de la carrera,
SISTEMA modifica, elimina.
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR GESTION

Se realiza la especificación del caso de uso Gestionar Gestión
CASO DE USO Gestionar Gestión

ACTOR Administrador
registrará el tipo de gestión que tendrá la
Carrera.
PROPÓSITO Tener un registro del tipo de gestión de la
Carrera
relación
FLUJO PRINCIPAL DE EVENTOS DEL El administrador es el encargado de registrar el
ACTOR tipo de gestión de la carrera, modificar,
eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos de la gestión,
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR GRUPO

Se realiza la especificación del caso de uso Gestionar Grupo
CASO DE USO Gestionar Grupo

ACTOR Administrador
registrará los Grupos existentes en una carrera.
PROPÓSITO Tener un registro de los Grupos existente en la
carrera
relación
ACTOR los Grupos existentes de una carrera,
modificar, eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos de los Grupos,
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR MATERIA

Se realiza la especificación del caso de uso Gestionar Materia
CASO DE USO Gestionar Materia

ACTOR Administrador
registrará los datos de cada Materias
dependiendo de la carrera.
PROPÓSITO Tener un registro de dato de cada Materia
dependiendo de la carrera
relación
ACTOR cada dato de las Materias dependiendo la
carrera, modificar, eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos de cada Materia
SISTEMA dependiendo la carrera, modifica, elimina.
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR DIA

Se realiza la especificación del caso de uso Gestionar Día
CASO DE USO Gestionar Día

ACTOR Administrador
registrará los Días que pasaran clases dicha
materia.
PROPÓSITO Tener un registro de los Días de clases de
dichas materias
relación
ACTOR los Días que correspondan a las materias,
modificar, eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos de los días,
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR HORA

Se realiza la especificación del caso de uso Gestionar Hora
CASO DE USO Gestionar Hora

ACTOR Administrador
registrará las Horas de las materias.
PROPÓSITO Tener un registro de las Horas de las materias
relación
ACTOR las Horas de las materias, modificar, eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda las horas de las materias,
EXCEPCIONES
2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR AULA

Se realiza la especificación del caso de uso Gestionar Aula
CASO DE USO Gestionar Aula

ACTOR Administrador
registrará el Aula.
PROPÓSITO Tener un registro de todas las aulas disponibles
relación
ACTOR todas las aulas, modificar, eliminar
FLUJO PRINCIPAL DE EVENTOS DEL El sistema guarda los datos de las aulas,
EXCEPCIONES
4.1. DIAGRAMA DE COLABORACION
En este punto se analiza cada caso de uso tomando en cuenta su comportamiento para
analizar la forma en que interactúa con el Sistema; identificar las clases de objetos
necesarios para llevar a cabo el flujo de sucesos en la interacción con el Sistema.
CASO DE USO DEL ANÁLISIS: GESTIONAR CARRERA
CASO DE USO DEL ANÁLISIS: GESTIONAR MATERIA
CASO DE USO DEL ANÁLISIS: GESTIONAR GRUPO

CASO DE USO DEL ANÁLISIS: GESTIONAR DIA
CASO DE USO DEL ANÁLISIS: GESTIONAR GESTION
CASO DE USO DEL ANÁLISIS: GESTIONAR HORARIO
CASO DE USO DEL ANÁLISIS: GESTIONAR AULA

CASO DE USO DEL ANÁLISIS: GESTIONAR ESTUDIANTE
CASO DE USO DEL ANÁLISIS: GESTIONAR DOCENTE
CAPITULO 5
DISEÑO DEL SISTEMA
DISEÑO DEL SISTEMA
4.2. INTRODUCCION
El propósito del diseño es especificar una solución que trabaje y pueda ser
fácilmente convertida en código fuente para poder construir una arquitectura
simple y extensible. Además podemos capturar las interfaces de los
subsistemas.
El modelo de diseño incluye varios artefactos; clase de diseño, realización
de los casos de uso, subsistemas del diseño, interfaz, modelo de
despliegue y descripción de la arquitectura.
4.3. DIAGRAMA DE DESPLIEGUE
Esto diagramas se utilizan para modelar la vista de despliegue estática
en un sistema. La mayoría de las veces, esto implica modelar la parte
hardware sobre el que se ejecuta el sistema
4.1. DIAGRAMA DE CLASES

4.2. DISEÑO LOGICO DE LA BASE DE DATOS
5. DISEÑO FISICO DE LA BASE DE DATOS

Documentacion de Software 2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Documentacion de Software 2

Загружено:

Авторское право:

Доступные форматы

INDICE

PARTE II DESARROLLO DEL SISTEMA

3.2 LISTA REQUERIMIENTOS

3.2.2. REQUISITOS NO FUNCIONALES DEL SISTEMA

3.3.2. MODELO DE NEGOCIO

3.4. IDENTIFICACIÓN DE LOS ACTORES Y CASOS DE USO

3.4.2. CASOS DE USOS

Caso de Uso Descripción

3.5. PRIORIZACIÓN DE LOS CASOS DE USO

Caso de Uso Actores Prioridad

3.6. DESCRIPCION DE LOS CASOS DE USO

CASO DE USO: GESTIONAR ESTUDIANTE

CASO DE USO: GESTIONAR CARRERA

CASO DE USO: GESTIONAR HORARIO

CASO DE USO: GESTIONAR GESTION

CASO DE USO: GESTIONAR DIA

CASO DE USO: GESTIONAR AULA

CASO DE USO: GESTIONAR GRUPO

CASO DE USO: GESTIONAR OFERTA DE MATERIA

GESTIONAR OFERTA DE MATERIA

3.7. DIAGRAMAS GENERAL DE CASOS DE USO

2.1.1. SUBSISTEMA ADMINISTRACION

2.2. ESPECIFICACIÓN DE LOS CASOS DE USO DE ANÁLISIS

CASO DE USO Describe el nombre de un Caso de Uso, que es

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR ESTUDIANTE

CASO DE USO Gestionar Estudiante

CASO DE USO Gestionar Docente

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR CARRERA

CASO DE USO Gestionar Carrera

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR GESTION

CASO DE USO Gestionar Gestión

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR GRUPO

CASO DE USO Gestionar Grupo

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR MATERIA

CASO DE USO Gestionar Materia

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR DIA

CASO DE USO Gestionar Día

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR HORA

CASO DE USO Gestionar Hora

2.2.1. CASO DE USO DEL ANÁLISIS: GESTIONAR AULA

CASO DE USO Gestionar Aula

4.1. DIAGRAMA DE COLABORACION

CASO DE USO DEL ANÁLISIS: GESTIONAR CARRERA

CASO DE USO DEL ANÁLISIS: GESTIONAR MATERIA

CASO DE USO DEL ANÁLISIS: GESTIONAR GRUPO

CASO DE USO DEL ANÁLISIS: GESTIONAR GESTION

CASO DE USO DEL ANÁLISIS: GESTIONAR HORARIO

CASO DE USO DEL ANÁLISIS: GESTIONAR AULA

CASO DE USO DEL ANÁLISIS: GESTIONAR DOCENTE

4.1. DIAGRAMA DE CLASES

Вам также может понравиться