UNIDAD ACADÉMICA DE INGENIERÍA CIVIL CARRERA DE...

I

UNIDAD ACADÉMICA DE INGENIERÍA CIVIL

CARRERA DE INGENIERÍA DE SISTEMAS

TEMA: ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR LOS CURSOS DE

DOCTORADO DE LA ESCUELA POLITÉCNICA AMAZÓNICA

TRABAJO PRÁCTICO DEL EXAMEN COMPLEXIVO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO DE SISTEMAS

AUTOR EDINSON PAUL RUIZ SALINAS

MACHALA – EL ORO

II

ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA

GESTIONAR LOS CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA AMAZÓNICA”

AUTORÍA:

Yo, Ruiz Salinas Edinson Paul, como autor del presente trabajo probatorio del

componente práctico del Examen de Grado de Carácter Complexivo, soy responsable

de las ideas, conceptos, procedimientos y resultados vertidos en el mismo.

…………….……………………………….

Ruiz Salinas Edinson Paul

C.I.: 0703704122

Correo electrónico:

[email protected]

MACHALA, NOVIEMBRE DE 2015

III

RESUMEN

ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA

GESTIONAR LOS CURSOS DE DOCTORADO DE

LA ESCUELA “POLITÉCNICA AMAZÓNICA”

Autor: Edinson Paul Ruiz Salinas

El desarrollo del presente informe tiene como propuesta el análisis de un sistema informático para gestionar cursos de doctorado, analizar el proceso que se realizan manualmente dentro de la Escuela para la creación, organización de los cursos de doctorado y diseñar las especificaciones funcionales y no funcionales, la estimación del proyecto de software, la elaboración de un diagrama conceptual, la elaboración de los casos de uso extendido y el diagrama de caso de uso del problema. Determinar una solución que permita el proceso de forma rápida y eficiente el proceso de la creación de cursos de doctorado de la Institución educativa “Escuela Politécnica Amazónica”. Dentro del trabajo utilizamos la metodología, basada en la Metodología de Análisis Orientado a objetos, y la metodología OpenUP. Se consideró OpenUp porque se puede utilizar de manera práctica, tiene una filosofía ágil dirigida a lo colaborativa del proceso, y también nos da bastante adaptabilidad a las necesidades de un proyecto particular. Dentro de los resultados obtenidos tenemos que el proceso de gestionar cursos de doctorado se va a realizar con mayor eficiencia y se descongestionara el proceso de matriculación a dichos cursos, también se evitara la confusión al momento de asignar las aulas, horario, temarios y también la asignación de tutores para los alumnos matriculados.

Palabras Clave: OpenUP, Ingeniería de Requisitos, Análisis Orientado a Objetos, Metodología de desarrollo de Software, Gestión de Cursos de Doctorado.

IV

ABSTRACT

ANALYSIS OF A COMPUTER SYSTEM TO MANAGE DOCTORAL COURSES “POLYTECHNIC FOR THE AMAZON”

Author: Edinson Paul Ruiz Salinas

The development of this report is the analysis of a proposed system to manage doctoral programs, analyze the process manually conducted within the School for creating, organizing doctoral courses and design the functional and non-functional specifications, the estimate of the software project, the development of a conceptual diagram, making widespread use cases and use case diagram of the problem. Determining a solution that enables the process quickly and efficiently the process of creating courses PhD School "Polytechnic Amazon". Within the work we use the methodology based on the methodology of object-oriented analysis, and OpenUP methodology. OpenUP it considered because you can use a practical, agile philosophy has led to the collaborative process, and also gives us quite adaptable to the needs of a particular project. Among the results we need to manage the process of doctoral courses will be done more efficiently and enrollment process to decongest such courses, will also avoid confusion when assigning classrooms, schedule, agendas and the assigning mentors to students enrolled. KeyWords: OpenUP, Software engineering, Object-Oriented Analysis, Software development methodology, Doctoral Course Management

V

ÍNDICE DE CONTENIDO

CESIÓN DE DERECHOS DE AUTOR…………………………………………. II

RESUMEN………………………………………………………………………….

III

INDICE DE CONTENIDO………………………………………………………… V

INDICE DE FIGURAS……………………………………………………………. VII

1. INTRODUCCIÓN…………………………………………………….……… 8

1.1 MARCO CONTEXTUAL……………………………………………………. 8

1.2 PROBLEMA………………………………………………………………….. 9

1.3 OBJETIVO GENERAL……………………………………………………… 9

2. DESARROLLO 9

2.1 MARCO TEÓRICO…………………………………………………………. 9

2.1.1 Ingeniería de Requisitos…….……………………………………….……. 9

2.1.2 Especificaciones de Requisitos de Software (ERS)………………….... 10

2.1.3 Estimación de Proyecto de Software……………….………………..…. 10

2.1.4 Análisis Orientado a Objetos……………………………………………. 10

2.1.5 Metodología OpenUP……………………………………………………… 10

2.1.6 Diagrama de casos de uso……………………………………………… 11

2.1.7 Diagrama Conceptual……..………………………………………..…….. 11

2.1.8 Diagrama de Clases……………………………………………………….. 11

2.1.9 Modelo Entidad – Relación………………………………………………... 11

2.1.10 Diccionario de Datos……………………………………………………… 11

2.2 MARCO METODOLÓGICO………………………………………………… 11

2.2.1 Estándar IEEE 830 (1998)…..…………………………………..………. 12

2.2.2 Metodología de Desarrollo de Software OpenUP……………..……….. 12

VI

2.2.2.1 Principios………………………………………………………………….. 12

2.2.2.2 Ciclo de Vida ……………………………………………………………. 12

2.3 RESULTADOS…………………………………………………..…………… 13

3. CONCLUSIÓN………………………………………………….………………. 14

4. REFERENCIAS BIBLIOGRAFICAS…………………………………………. 15

ANEXOS…………………………………………………………………………… 16

VII

ÍNDICE DE FIGURAS

Ilustración 1: Principios de OpenUP ......................................................................... 12

8

1. INTRODUCCIÓN

El presente trabajo es la presentación de una aplicación metodología llamada OpenUp es una metodología de software, basada en RUP (Rational Unified Process), que dentro de la metodología hay un conjunto mínimo de prácticas que nos benefician para la elaboración del análisis y desarrollo del software. OpenUp, es un proceso unificado, iterativo e incremental, está preparada para ser incluida en la propuesta de desarrollo de implementación de un Sistema Informático para gestionar los cursos de doctorado para la Escuela Politécnica Amazónica. Ya que los Sistemas de Información y las Tecnologías de Información han modificado la expectativa y el orden que se operan las organizaciones actualmente. A través de su uso se puede logar mejorar muchos puntos importantes, ya que se pueden automatizar muchos procesos operativos, y lo más relevante es que su implantación puede lograr muchas ventajas competitivas.

Este trabajo provee una visión general del proceso de desarrollo propuesto. Como primer paso nos centraremos en el estudio de los procesos y actividades que están inmersos en la actividad educativa de la “Escuela Politécnica Amazónica”, de la cual identificaremos los puntos más críticos donde la intervención manual en ciertos procesos, pueden ser transformados a procesos automatizados para optimizar recursos y tiempo en la ejecución de tales procesos. Como segundo paso se describirá la alternativa de solución para la implementación del sistema informático la gestión de cursos de doctorado.

1.1 MARCO CONTEXTUAL

En la Escuela Politécnica Amazónica no cuenta con un sistema informático para la gestión de cursos de doctorado, por ende al momento de realizar el ingreso de estudiantes a los cursos de doctorado que ofrece dicha institución, causa lentitud en el proceso, también dentro de la institución hay mucha confusión al momento de asignar las aula, temarios y horarios respectivos para poder impartir las clase correspondiente a la promoción.

Al momento en la institución no cuenta con un sistema informático para la creación de cursos de doctora, previamente en este trabajo se realizó un análisis para desarrollar a fututo el sistema, para poder cumplir con todo los requisitos necesarios y a la vez optimizar el proceso que se realiza.

9

1.2 PROBLEMA

¿Cómo mejorar el proceso de Gestión de cursos de doctorado en la “Escuela Politécnica Amazónica”?.

1.3 OBJETIVO GENERAL Analizar y Diseñar un sistema informático mediante la definición de los requerimientos, estimación de costos y el lenguaje UML, para mejorar el proceso de gestión de cursos de doctorado. 2. DESARROLLO

2.1 MARCO TEÓRICO

2.1.1 Ingeniería de Requisitos Conceptos.

Requisitos.- Propiedad que se muestra por un software para lograr hallar la resolución de algún problema en particular. Ingeniería de Requisitos: Se trata de un conjunto de actividades que sirven para lograr el objetivo que es de poder descubrir, tener los documentos y por ultimo poder mantener un grupo de requisitos necesarios.

Tipos de Requisitos Requisitos Funcionales Los requisitos funcionales son los que describen las funciones que va a realizar el software, también el comportamiento ante las entradas y como debe actuar en situaciones especiales o particulares. Depende de:

El tipo de software

La perspectiva que tengan los usuarios

Requisitos No Funcionales Impedimentos sobre las funciones que ofrecerá el sistema.

Muestran cualidades o tributos que encierra el sistema.

Proponen impedimentos del producto desarrollado.

Generalmente no se relaciona con las funciones del sistema.

10

2.1.2 Especificación de Requisitos de Software (ERS) Se trata de la creación de un documento, que se puede revisar, evaluar y aprobar de acuerdo a los requerimientos necesarios. Especificación: Documento que precisa y verifica, los requisitos, el diseño, el proceder de un sistema. Software: Es un conjunto de programas y procesos que contiene documentación que se asocian a la operación que necesita un sistema informático.

2.1.3 Estimación de Proyecto de Software La estimación es una de las actividades más importantes en el Proceso de Desarrollo de productos de software. “El objetivo de la Estimación es predecir las variables involucradas en el proyecto con cierto grado de certeza, trata de aportar una predicción de algún indicador importante para la gestión de proyectos de software tiempo, esfuerzo, cantidad de defectos esperados entre otros sin dejar de tener en cuenta que la incertidumbre y el riesgo son elementos inherentes.” (Salazar, 2009) Técnicas de Estimación (Salazar, 2009) “El objetivo de esta técnica es medir la cantidad de funcionalidad a partir de la especificación de un sistema, con independencia de la tecnología con la que pudiera ser desarrollado. Lo primero es calcular los puntos de función (PF) sin ajustar para lo cual que se requiere determinar” (Salazar, 2009): Puntos de Función (Salazar, 2009) “Es una métrica que permite traducir en un número el tamaño de la funcionalidad que brinda un producto de software desde el punto de vista del usuario, a través de una suma ponderada de las características del producto” (Salazar, 2009).

2.1.4 Análisis Orientado a Objetos.

“Es un método que analiza los requerimientos tomando en cuenta las clases y objetos que se puede encontrar dentro del vocabulario del dominio o también llamado problema” (López, 2008).

2.1.5 Metodología OpenUP

“Es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software basados en desarrollo iterativo, ágil e incremental apropiado para proyectos pequeños y de bajos recursos” (Santiago Ríos).

11

2.1.6 Diagramas de caso de usos

“En un diagrama de casos de uso no se muestran los casos de uso en detalle; solamente se resumen algunas de las relaciones entre los casos de uso, los actores y los sistemas. En concreto, en el diagrama no se muestra el orden en que se llevan a cabo los pasos para lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros diagramas y documentos, que pueden vincularse a cada caso de uso” (Microsoft, 2015).

2.1.7 Diagrama Conceptual “Se describe los conceptos que se encuentren presentes en el dominio del problema. Para descubrirlos tenemos que analizar las características que se pueda describir textualmente del dominio, por lo tanto se trata de poder describir el sistema mediante los requerimientos y casos de uso” (Fernández, s.f.).

2.1.8 Diagrama de Clases

“El diagrama de clases es para describir la estructura del sistema. Las clases son abstracciones que especifican la estructura y el comportamiento común de un conjunto de objetos”. (K, 2011)

2.1.9 Modelo entidad relación “Los elementos que conforman un sistema organizacional se pueden denominar entidades. Una entidad puede ser una persona, un lugar o una cosa, o bien una entidad puede ser un evento, como el fin de mes, un periodo de ventas o el tiempo de inactividad de una máquina. Una relación es la asociación que describe a la interacción entre las entidades”. (K, 2011)

2.1.10 Diccionario de Datos

“Es una versión especializada de los diccionarios que se utilizan como referencia en la vida cotidiana, es una obra de consulta de información sobre los datos”. (K, 2011)

2.2 MARCO METODOLÓGICO

2.2.1 Estándar IEEE 830 (1998)

En el presente trabajo para la especificación de Requisitos de Software se usó el estándar IEEE 830 (1998).

2.2.2 Metodología de Desarrollo de Software OpenUP

OpenUP es un Proceso Unificado, utiliza ágilmente y a la vez de enfoca en la colaboración durante el desarrollo del software.

12

2.2.2.1 Principios

Los principios básicos en los que se fundamenta OpenUP se muestran en la ilustración 1:

Ilustración 1: Principios de OpenUP

2.2.2.2 Ciclo de vida

El ciclo de vida de un proyecto, según la metodología OpenUP, permite que los integrantes del equipo de desarrollo aporten con micro-incrementos, que pueden ser el resultado del trabajo de unas pocas horas o unos pocos días. El progreso se puede visualizar diariamente, ya que la aplicación va evolucionando en función de estos micro-incrementos. Fase de inicio: En esta fase, las necesidades de cada participante del proyecto son tomadas en cuenta y plasmadas en objetivos del proyecto. Se definen para el proyecto: el ámbito, los límites, el criterio de aceptación, los casos de uso críticos, una estimación inicial del coste y un boceto de la planificación. Fase de elaboración: En esta fase se realizan tareas de análisis del dominio y definición de la arquitectura del sistema. Se debe elaborar un plan de proyecto, estableciendo unos requisitos y una arquitectura estables. Por otro lado, el proceso de desarrollo, las herramientas, la infraestructura a utilizar y el entorno de desarrollo también se especifican en detalle en esta fase. Al final de la fase se debe tener una definición clara y precisa de los casos de uso, los actores, la arquitectura del sistema y un prototipo ejecutable de la misma. Fase de construcción: todos los componentes y funcionalidades del sistema que falten por implementar son realizados, probados e integrados en esta fase. Los resultados obtenidos en forma de incrementos ejecutables deben ser

OpenUp

Balancear las prioridades

competitivas para maximizar el valor de los participantes del

proyecto.

desarrollar una arquitectura, al inicio

del proceso, con la finalidad de minimizar riesgos y planificar el

desarrollo.

evolucionar para obtener

retroalimentación continua en aras de

una mejora constante.

promover la colaboracion para

alinear los intereses comunes, difundir el

conocimiento sobre el proyecto, y generar

un entorno de trabajo saludable.

13

desarrollados de la forma más rápida posible sin dejar de lado la calidad de lo desarrollado. Fase de transición: Esta fase corresponde a la introducción del producto en la comunidad de usuarios, cuando el producto está lo suficientemente maduro. La fase de la transición consta de las subfases de pruebas de versiones beta, pilotaje y capacitación de los usuarios finales y de los encargados del mantenimiento del sistema. En función de la respuesta obtenida por los usuarios puede ser necesario realizar cambios en las entregas finales o implementar alguna funcionalidad más.

2.3 RESULTADOS Los resultados obtenidos se los identificara mediante la resolución del trabajo práctico, que contiene diversos métodos aplicados y modelados. En el siguiente cuadro se describe todas las fases de la metodología, conjuntamente con la integración de los diferentes diagramas.

METODOLOGÍA OPENUP

FASES DISEÑO DE DIAGRAMAS

RESULTADO

Fase 1: Inicio

Especificación de

Requisitos

Ver Anexo1

Se identifican todos los

involucrados del proyecto

Ver Anexo 3

Fase 2: Elaboración

Diagrama Conceptual

Ver Anexo 4

Casos de uso extendido

Ver Anexo 5

Diagrama de Casos de

Uso

Ver Anexo 6

Adicionales

Diagrama de Clase

Ver Anexo 7

Diagrama Entidad-

Relación

Ver Anexo 8

Diccionario de Datos

Ver Anexo 9

Base de Datos

Ver Anexo 10

14

Estimación de Proyecto

Ver Anexo 2

3. CONCLUSIONES

Con el análisis del sistema de Gestión de cursos para doctorado se soluciona el exceso de tiempo que se usa para realizar los procesos de los cursos.

La correcta interpretación de los modelados llevara a una construcción correcta del sistema de gestión de cursos de doctorado

Una de las ventajas, es ofrecer o mejorar la rapidez que se realiza en el procedimiento y manejo de datos, esto causa que se pueda conseguir también la agilidad de generar reportes en el menor tiempo disponible, también se ofrece mayor seguridad de los datos, ofreciendo una interfaz fácil de usar tanto para el usuario como para el administrador.

La mala manipulación del sistema por usuarios inexpertos en el sistema trayendo como consecuencia la pérdida o eliminación de registros accidentalmente, fallas eléctricas muy largas.

Las políticas se ven afectadas por la decisión del plantel, el sistema solo podrá manipular las personas autorizadas por el Departamento Administrativo Docente que este encargado del sistema.

El sistema ayudara a facilitar el proceso de asignar los cursos correspondientes, evitando así la pérdida de tiempo.

15

4. REFERENCIAS BIBLIOGRÁFICAS

830, I. S. (1998). IEEE Standar 830. Amescua Seco, A. (1995). Ingeniería del software de gestión. Análisis y diseño de

aplicaciones. Madrid: Paraninfo. Obtenido de http://www.um.es/docencia/barzana/IAGP/Iagp1.html

Fernández, L. A. (s.f.). Obtenido de https://msdn.microsoft.com/es-es/library/bb972214.aspx

K, K. (2011).

López, J. D. (2008). Ingeniería de Programación: Análisis Orientado a Objetos . En J. D. López, Ingeniería de Programación: Análisis Orientado a Objetos (pág. 9). Santander.

Microsoft. (2015). Microsoft, Developer Network. Obtenido de https://msdn.microsoft.com/es-ec/library/dd409432.aspx

Odell, J. M. (1994). Analisis y Diseño Orientado a Objetos. Prentice Hall. S.A., I. E. (2105). www-03.ibm.com. Obtenido de http://www-

03.ibm.com/software/products/es/enterprise

Salazar, G. (5 de Junio de 2009). Ingeniería y Ciencia. Obtenido de http://publicaciones.eafit.edu.co/index.php/ingciencia/article/viewFile/470/437

Santiago Ríos, C. H. (s.f.). Obtenido de http://repositorio.espe.edu.ec/bitstream/21000/6316/1/AC-SISTEMAS-ESPE-047042.pdf

Somerville, I. (1998). Ingeniería del software. Wilnington: Addison Wesley Iberoamericana.

Wells, D. (8 de Octubre de 2013). Extreme Programming. Obtenido de Copyright (c) 1999, 2000, 2001, 2004, 2009 Don Wells: http://www.extremeprogramming.org/

Anexo 1

Especificación de Requisitos de Software

Utilizando el Estándar IEEE Práctica Recomendada para

Especificaciones de Requisitos Software ANSI/IEEE 830, 1998.

Proyecto:

ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA

AMAZÓNICA”

Ficha del documento

Fecha Revisión Autor Verificado dep. Calidad.

30/10/2015 Edinson Paul Ruiz Salinas

1 Introducción

Este documento es una Especificación de Requisitos Software (ERS) para el Sistema de información para la gestión de cursos de doctorado. Esta especificación se ha estructurado basándose en las directrices dadas por el estándar IEEE Práctica Recomendada para Especificaciones de Requisitos Software ANSI/IEEE 830, 1998.

1.1 Propósito

El presente documento tiene como propósito definir las especificaciones funcionales, no funcionales para el desarrollo de un sistema de información que permitirá gestionar distintos procesos administrativos y académicos. Éste será utilizado por estudiantes, profesores y directivos.

1.2 Alcance

Esta especificación de requisitos está dirigida al usuario del sistema, para continuar con el desarrollo de aplicaciones educativas sobre la institución y para profundizar en la automatización de ésta, la cual tiene por objetivo principal el gestionar los distintos procesos administrativos (Matriculas, Curso, Temarios, Aulas, Horarios, Tutores, Notas Académicas).

1.3 Personal involucrado

Nombre Paul Ruiz Salinas

Rol Analista, diseñador y programador

Categoría Profesional Ingeniería en Sistemas

Responsabilidad Análisis de información, diseño y programación del SIS-I

Información de contacto [email protected]

1.4 Definiciones, acrónimos y abreviaturas

Nombre Descripción

Usuario Persona que usará el sistema para gestionar procesos

SIS-I Sistema Informático para Gestionar Cursos de Doctorado

ERS Especificación de Requisitos Software

RF Requerimiento Funcional

RNF Requerimiento No Funcional

FTP Protocolo de Transferencia de Archivos

1.5 Referencias

Título del Documento Referencia

Standard IEEE 830 - 1998 IEEE

1.6 Resumen

Este documento consta de tres secciones. En la primera sección se realiza una

introducción al mismo y se proporciona una visión general de la especificación de recursos del sistema.

En la segunda sección del documento se realiza una descripción general del

sistema, con el fin de conocer las principales funciones que éste debe realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles.

Por último, la tercera sección del documento es aquella en la que se definen

detalladamente los requisitos que debe satisfacer el sistema.

2 Descripción general

2.1 Perspectiva del producto

El sistema SIS-I será un producto diseñado para trabajar en entorno web, lo que permitirá su utilización de forma rápida y eficaz.

2.2 Características de los usuarios

Tipo de usuario Administrador

Formación Cualquiera

Actividades Control y manejo del sistema en general

Tipo de usuario Docente (Doctor)

Formación Educador

Actividades Facilitar el proceso de aprendizaje

Tipo de usuario Estudiante

Formación Profesional en cualquier área

Actividades Participación activa en cursos

2.3 Restricciones

Interfaz para ser usada con internet.

Uso de Dominio (X)

Lenguajes y tecnologías en uso: HTML, JAVA.

Los servidores deben ser capaces de atender consultas concurrentemente.

El sistema se diseñará según un modelo cliente/servidor.

El sistema deberá tener un diseño e implementación sencilla, independiente de la plataforma o del lenguaje de programación.

.

2.4 Suposiciones y dependencias

Se asume que los requisitos aquí descritos son estables

Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos antes indicados para garantizar una ejecución correcta de la misma

3 Requisitos específicos

Requerimientos Funcionales

3.1 Gestionar Profesor: Se encarga de gestionar el ingreso o registrar al profesor que ingresa a la institución, el responsable de hacerlo en este caso es la secretaria, permitiendo realizar el registro de los datos personales de acuerdo a las características de la persona, así como también tendrá acceso a modificar, buscar y eliminar.

No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad

R1 Inserción Ingreso de datos del

profesor

Id_profesor

Debe ser un numero entero autoincrementar,

no debe ser nulo

Alta

Cedula, Nombre, apellido, genero, ciudad, estado

civil, fecha de nacimiento, teléfono, titulo 3er nivel,

especialidad

No debe ser nulos

R2 Modificación Modificación de los datos

del profesor Datos R1 Trabaja con R1 Alta

R3 Eliminación Eliminación de Datos del

profesor Datos R1 Para eliminar se necesita el ID del profesor. Baja

R4 Buscar Consulta de los Datos del

profesor

Cedula, Nombre, apellido, genero, ciudad, estado

civil, fecha de nacimiento, teléfono, titulo 3er nivel,

especialidad

Trabaja con R1 Media

3.2 Gestionar Estudiante: Permite el ingreso de los datos del estudiante, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.



estudiante

Id_estudiante


no debe ser nulo

Alta

Cedula, Nombre, apellido, fecha de nacimiento

No debe ser nulos


Id_tutor Debe ser un numero entero, no debe ser valor

nulo, es código proviene de la tabla tutor.


del estudiante Datos R5 Trabaja con R5 Alta


estudiante Datos R5 Para eliminar se necesita el ID del estudiante. Baja


estudiante Cedula, Nombre, apellido, fecha de nacimiento Trabaja con R5 Media

3.3 Gestionar Doctor: Permite el ingreso de los datos del Doctor, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R9 Inserción Ingreso de datos del doctor

Id_doctor


no debe ser nulo

Alta Cedula, Nombre, apellido, género, ciudad, estado

civil, fecha de nacimiento, teléfono, titulo de

doctorado, catedra.

No debe ser nulos

Id_cursos Debe ser un numero entero, no debe ser valor

nulo, es código proviene de la tabla cursos.


del doctor Datos R9 Trabaja con R9 Alta


doctor Datos R9 Para eliminar se necesita el ID del doctor. Baja


doctor

Cedula, Nombre, apellido, titulo de doctorado,

catedra

Los datos pueden ser consultado por nombre,

apellido, titulo de doctorado y catedra Media

3.4 Gestionar Universidad: Permite el ingreso de los datos de la Universidad, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R13 Inserción Ingreso de datos de la

universidad

Id_universidad


no debe ser nulo

Alta

Nombre, rector

No debe ser nulos


de la universidad Datos R13 Trabaja con R13 Alta


la universidad Datos R13

Para eliminar se necesita el ID de la

Universidad. Baja

R16 Buscar Consulta de los Datos de

Universidad Datos R13 Trabaja con R13 Media

3.5 Gestionar Departamento: Permite el ingreso de los datos del Departamento, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.



departamento

Id_departamento


no debe ser nulo

Alta Nombre No debe ser nulos

Id_Universidad

Debe ser un numero entero, no debe ser valor

nulo, es código proviene de la tabla

Universidad.


del departamento Datos R17 Trabaja con R17 Alta



departamento Datos R17

Para eliminar se necesita el ID del

departamento. Baja


departamento Nombre Los datos pueden ser consultados por nombre Media

3.6 Gestionar Áreas: Permite el ingreso de los datos del Área, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R21 Inserción Ingreso de datos del área

Id_area


no debe ser nulo


Id_Departamento



Departamento.


del área Datos R21 Trabaja con R21 Alta


área Datos R21 Para eliminar se necesita el ID del Área. Baja


área Nombre Los datos pueden ser consultados por nombre Media

3.7 Gestionar Becas: Permite el ingreso de los datos de la Beca, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.



R25 Inserción Ingreso de datos de la Beca

Id_beca


no debe ser nulo

Alta

Nombre, promoción, cuantía No debe ser nulos


de la Beca Datos R25 Trabaja con R25 Alta

R27 Eliminación Eliminación de Datos de la

Beca Datos R25 Para eliminar se necesita el ID de la Beca. Baja

R28 Buscar Consulta de los Datos de la

Beca Nombre, promoción

Los datos pueden ser consultados por nombre,

promoción Media

3.8 Gestionar Requisitos: Permite el ingreso de los requisitos, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R29 Inserción Ingreso de los requisitos

Id_requsitos


no debe ser nulo

Alta

Requisito1, requisito2, requisito3 No debe ser nulos

R30 Modificación Modificación de los

requisitos Datos R29 Trabaja con R25 Alta

R31 Eliminación Eliminación de los

requisitos Datos R29 Para eliminar se necesita el ID de requisitos. Baja

R32 Buscar Consulta de los Requisitos R29 Trabaja con R29 Media

3.9 Gestionar Solicitud: Permite el ingreso de la solicitud, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R33 Inserción Ingreso de la solicitud

Id_solicitud


no debe ser nulo

Alta

Número de la solicitud

No debe ser nulos

Id_estudiante



Estudiante.

Id_beca


nulo, es código proviene de la tabla Beca.

Id_ aprobados



aprobados.

R34 Modificación Modificación de la

solicitud Datos R33 Trabaja con R33 Alta

R35 Eliminación Eliminación de la solicitud Datos R33 Para eliminar se necesita el ID de la solicitud. Baja

R36 Buscar Consulta de la solicitud R33 Trabaja con R33 Media

3.10 Gestionar Aprobados: Permite el ingreso de los aprobados, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R37 Inserción Ingreso de aprobados Id_aprobados


no debe ser nulo

Alta


Fecha de aprobado Día, mes y año

R38 Modificación Modificación de aprobados Datos R37 Trabaja con R37 Alta

R39 Eliminación Eliminación de aprobados Datos R37 Para eliminar se necesita el ID de aprobados. Baja

R40 Buscar Consulta de aprobados Datos R37 Trabaja con R37 Media

3.10 Gestionar Tutor: Permite el ingreso del tutor, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R41 Inserción Ingreso de tutor

Id_tutor


no debe ser nulo

Alta

Id_doctor Debe ser un numero entero, no debe ser valor

nulo, es código proviene de la tabla Doctor

R42 Modificación Modificación de tutor Datos R41 Trabaja con R41 Alta

R43 Eliminación Eliminación de tutor Datos R41 Para eliminar se necesita el ID de tutor. Baja

R44 Buscar Consulta de tutor Datos R41 Trabaja con R41 Media

3.11 Gestionar Programa de Doctorado: Permite el ingreso del programa de doctorado, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R45 Inserción Ingreso del programa de

doctorado Id_prog_doct


no debe ser nulo

Alta


Nombre No debe ser nulos

R46 Modificación Modificación del programa

de doctorado Datos R45 Trabaja con R45 Alta

R47 Eliminación Eliminación del programa

de doctorado Datos R45

Para eliminar se necesita el ID de programa

de doctorado. Baja

R48 Buscar Consulta del programa de

doctorado Datos R45 Trabaja con R45 Media

3.12 Gestionar Promoción: Permite el ingreso de la promoción, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R49 Inserción Ingreso de la promoción

Id_promoción


no debe ser nulo

Alta Numero de promoción No debe ser nulos


nulo, es código proviene de la tabla Cursos

Id_prog_doct


nulo, es código proviene de la tabla Programa

de doctorado


promoción Datos R49 Trabaja con R49 Alta

R49 Eliminación Eliminación de la

promoción Datos R49 Para eliminar se necesita el ID de promoción. Baja

R49 Buscar Consulta del programa de

doctorado Datos R49 Trabaja con R49 Media

3.13 Gestionar Aula: Permite el ingreso del aula, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R50 Inserción Ingreso del aula

Id_aula


no debe ser nulo

Alta

Numero aula No debe ser nulos

R51 Modificación Modificación del aula Datos R50 Trabaja con R50 Alta

R52 Eliminación Eliminación del aula Datos R50 Para eliminar se necesita el ID de aula. Baja

R53 Buscar Consulta del aula Datos R50 Trabaja con R50 Media

3.14 Gestionar Cursos: Permite el ingreso del curso, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R54 Inserción Ingreso del curso

Id_curso


no debe ser nulo

Alta

Nombre, fecha de inicio, fecha de fin, hora del curso No debe ser nulos

R55 Modificación Modificación del curso Nombre, fecha de inicio, fecha de fin, hora del curso Trabaja con R50 Alta

R56 Eliminación Eliminación del curso Datos R50 Para eliminar se necesita el ID de curso Baja

R57 Buscar Consulta del curso Nombre Los datos pueden ser consultados por nombre Media

3.15 Gestionar Temas: Permite el ingreso de los temas, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R58 Inserción Ingreso de los temas

Id_curso


no debe ser nulo




R59 Modificación Modificación de los temas Nombre Trabaja con R50 Alta

R60 Eliminación Eliminación de los temas Datos R50 Para eliminar se necesita el ID de temas Baja

R61 Buscar Consulta de los temas Nombre Los datos pueden ser consultados por nombre Media

3.16 Gestionar Acta de Notas: Permite el ingreso de las notas de cada estudiante, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria y el docente podrán realizar estas operaciones.


R62 Inserción Ingreso del acta de notas

Id_acta_notas


no debe ser nulo

Alta Número del acta


no debe ser nulo

Notas No debe ser nulo



R63 Modificación Modificación del acta de

notas Datos R58 Trabaja con R50 Alta

R64 Eliminación Eliminación del acta de Datos R58 Para eliminar se necesita el ID de actas de Baja


notas nota

R65 Buscar Consulta de actas de notas Datos R58 Trabaja con R58 Media

3.17 Gestionar Matriculas: Permite el ingreso de la matrícula de cada estudiante, conjuntamente con sus características, modificación, eliminación y consulta. La secretaria podrán realizar estas operaciones.


R66 Inserción Ingreso de la matrícula

Id_matricula


no debe ser nulo

Alta

Fecha de matrícula Día, mes, año

Valor No debe ser nulo

Id_promocion



promoción

Id_estudiante Debe ser un numero entero, no debe ser valor

nulo, es código proviene de la tabla estudiante


matrícula Datos R62 Trabaja con R50 Alta

R68 Eliminación Eliminación de la

matrícula Datos R62

Para eliminar se necesita el ID de actas de

nota Baja

R69 Buscar Consulta de la matrícula Estudiante Los datos pueden ser consultados por

estudiante Media

Requerimientos No Funcionales.

Identificación del requerimiento:

RNF01

Nombre del Interfaz del sistema.

Requerimiento:

Características: El sistema presentara una interfaz de usuario sencilla para que sea de fácil manejo a los usuarios del sistema.

Descripción del requerimiento:

El sistema debe tener una interfaz de uso intuitiva y sencilla.

Prioridad del requerimiento: Alta


RNF02

Nombre del Requerimiento:

Ayuda en el uso del sistema.

Características: La interfaz del usuario deberá de presentar un sistema de ayuda para que los mismos usuarios del sistema se les faciliten el trabajo

en cuanto al manejo del sistema.


La interfaz debe estar complementada con un buen sistema de ayuda (la administración puede recaer en personal con poca

experiencia en el uso de aplicaciones informáticas).



RNF03


Mantenimiento.

Características: El sistema deberá de tener un manual de instalación y manual de usuario para facilitar los mantenimientos que serán realizados por

el administrador.


El sistema debe disponer de una documentación fácilmente actualizable que permita realizar operaciones de mantenimiento con el

menor esfuerzo posible.



RNF04


Diseño de la interfaz a la característica de la web.

Características: El sistema deberá de tener una interfaz de usuario, teniendo en cuenta las características de la web de la institución.


La interfaz de usuario debe ajustarse a las características de la web de la institución, dentro de la cual estará incorporado el sistema

de gestión de procesos y el inventario.



RNF05


Desempeño

Características: El sistema garantizara a los usuarios un desempeño en cuanto a los datos almacenado en el sistema ofreciéndole una confiabilidad a

esta misma.


Garantizar el desempeño del sistema informático a los diferentes usuarios. En este sentido la información almacenada o registros

realizados podrán ser consultados y actualizados permanente y simultáneamente, sin que se afecte el tiempo de respuesta.



RNF06


Nivel de Usuario

Características: Garantizara al usuario el acceso de información de acuerdo al nivel que posee.


Facilidades y controles para permitir el acceso a la información al personal autorizado a través de Internet, con la intención de

consultar y subir información pertinente para cada una de ellas.



RNF07


Confiabilidad continúa del sistema.

Características: El sistema tendrá que estar en funcionamiento las 24 horas los 7 días de la semana. Ya que es una página web diseñada para la carga de datos y comunicación entre usuarios.


La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 días por 24 horas, garantizando un esquema adecuado que permita la posible falla en cualquiera de sus componentes, contar con una contingencia, generación de alarmas.



RNF08


Seguridad en información

Características: El sistema garantizara a los usuarios una seguridad en cuanto a la información que se procede en el sistema.


Garantizar la seguridad del sistema con respecto a la información y datos que se manejan tales sean documentos, archivos y

contraseñas.


3.1 Requisitos comunes de las interfaces

.

3.1.1 Interfaces de usuario

La interfaz con el usuario consistirá en un conjunto de ventanas con botones, listas y campos de textos. Ésta deberá ser construida específicamente para el sistema propuesto y, será visualizada desde un navegador de internet.

3.1.2 Interfaces de hardware

Será necesario disponer de equipos de cómputos en perfecto estado con las siguientes características:

Adaptadores de red.

Procesador de 1.66GHz o superior.

Memoria mínima de 1Gb.

Mouse.

Teclado.

3.1.3 Interfaces de software

Sistema Operativo: Windows 7 o superior.

Explorador: Mozilla o Chrome.

3.1.4 Interfaces de comunicación

Los servidores, clientes y aplicaciones se comunicarán entre sí, mediante protocolos estándares en internet, siempre que sea posible. Por ejemplo, para transferir archivos o documentos deberán utilizarse protocolos existentes (FTP u otros convenientes).

Anexo 2

Estimación del Proyecto de Software para determinar el tiempo, costo y

esfuerzo mediante puntos de función

Proyecto:


AMAZÓNICA”

Puntos de Función

Es una métrica que permite traducir en un número el tamaño de la funcionalidad que brinda

un producto de software desde el punto de vista del usuario, a través de una suma ponderada

de las características del producto.

Componentes:

EI: Procesos en los que se introducen datos y que suponen la actualización de cualquier

archivo interno.

EO: Procesos en los que se envía datos al exterior de la aplicación.

EQ: Procesos consistentes en la combinación de una entrada y una salida, en el que la entrada

no produce ningún cambio en ningún archivo y la salida no contiene información derivada

ILF: Grupos de datos relacionados entre sí internos al sistema.

EIF: Grupos de datos que se mantienen externamente.

CÁCULO DE LOS PUNTOS DE FUNCIÓN

Ficheros Lógicos Internos (ILF)

ILF DET RET COMPLEJIDAD

Profesor 10 2 Baja

Estudiante 4 1 Baja

Doctor 10 2 Baja

Universidad 2 1 Baja

Departamento 1 1 Baja

Área 1 1 Baja

Becas 3 1 Baja

Requisitos 3 1 Baja

Solicitud 1 1 Baja

Aprobados 1 1 Baja

Programa de Doctorado 1 1 Baja

Promoción 1 1 Baja

Aula 1 1 Baja

Cursos 4 2 Baja

Actas de Notas 2 1 Baja

Matricula 2 1 Baja

Entradas (EI)

EI DET FTR COMPLEJIDAD

Ingreso de Persona 24 3 Alta

Actualización de Persona 21 3 Alta

Eliminación de Persona 1 3 Baja

Ingreso de Universidad 2 1 Baja

Actualización de Universidad 1 1 Baja

Eliminación de Universidad 1 1 Baja

Ingreso de Departamento 1 1 Baja

Actualización de Departamento 1 1 Baja

Eliminación de Departamento 1 1 Baja

Ingreso de Areas 1 1 Baja

Actualización de Areas 1 1 Baja

Eliminación de Areas 1 1 Baja

Ingreso de Becas 3 1 Baja

Actualización de Becas 3 1 Baja

Eliminación de Becas 1 1 Baja

Ingreso de Requisitos 3 1 Baja

Actualización de Requisitos 3 1 Baja

Eliminación de Requisitos 1 1 Baja

Ingreso de Solicitud 1 1 Baja

Actualización de Solicitud 1 1 Baja

Eliminación de Solicitud 1 1 Baja

Ingreso de Aprobados 1 1 Baja

Actualización de Aprobados 1 1 Baja

Eliminación de Aprobados 1 1 Baja

Ingreso de Programa de Doctorado 1 1 Baja

Actualización de Programa de Doctorado 1 1 Baja

Eliminación de Programa de Doctorado 1 1 Baja

Ingreso de Promoción 1 1 Baja

Actualización de Promoción 1 1 Baja

Eliminación de Promoción 1 1 Baja

Ingreso de Aula 1 1 Baja

Actualización de Aula 1 1 Baja

Eliminación de Aula 1 1 Baja

Ingreso de Cursos 4 1 Baja

Actualización de Cursos 4 1 Baja

Eliminación de Cursos 1 1 Baja

Ingreso de Actas de Notas 2 1 Baja

Actualización de Actas de Notas 2 1 Baja

Eliminación de Actas de Notas 1 1 Baja

Ingreso de Matricula 2 1 Baja

Actualización de Matricula 2 1 Baja

Eliminación de Matricula 1 1 Baja

Salidas (EO)

EO DET

FTR

COMPLEJIDAD

Salida en pantalla aprobados 2 1 Baja

Salida en Impresora de aprobados 2 1 Baja

Salida en pantalla de notas 4 2 Baja

Salida en Impresora de notas 4 2 Baja

Salida en Pantalla de Matricula 2 1 Baja

Salida en Impresora de Matricula 2 1 Baja

Consultas (EQ)

EQ DET

FTR

COMPLEJIDAD

Salida en Pantalla de Datos Persona 24 2 Alta

Salida en Pantalla de Becas 3 1 Baja

Salida en Pantalla de datos del curso 4 1 Baja

Salida en Pantalla de Notas 5 1 Baja

Salida en Pantalla Matricula 12 2 Media

PUNTOS DE FUNCION SIN AJUSTAR (PFSA)

PARAMETRO COMPLEJIDAD NUMERO X PESO Total

ILF

ALTA 0 X 15 0

MEDIA 0 X 10 0

BAJA 16 X 7 112

EIF

ALTA 0 X 10 0

MEDIA 0 X 7 0

BAJA 0 X 5 0

EI

ALTA 2 X 6 12

MEDIA 0 X 4 0

BAJA 40 X 3 120

EO

ALTA 0 X 7 0

MEDIA 0 X 5 0

BAJA 6 X 4 24

EQ

ALTA 1 X 6 6

MEDIA 1 X 4 4

BAJA 3 X 3 9

Total 287

Obtención de los Factores de Complejidad.

Valor Significado del valor

0 Sin influencia, factor no presente

1 Influencia insignificante, muy baja

2 Influencia moderada o baja

3 Influencia media, normal

4 Influencia alta, significativa

5 Influencia muy alta, esencial

Factores de Complejidad (FC) 0-5

Comunicación de Datos. 2

Rendimiento 2

Frecuencia de transacciones 1

Requisitos del manejo del usuario final 1

Procesos complejos 1

Facilidad de mantenimiento 2

Portabilidad 2

Funciones distribuidas 0

Gran carga de trabajo 0

Entrada on-line de datos 1

Actualizaciones on-line 1

Utilización con otros sistemas 0

Facilidad de cambio 1

Facilidad de operación 2

Factores de complejidad (FC) 16

Calculo de los puntos de función ajustados

PFSA= Puntos de Función sin Ajustar

PFA= Puntos de Función Ajustado

FC= 16

PFA = PFSA * (0,65 + (0.01 * FC))

PFA = 287*(0,65 + (0.01*16))

PFA = 232,47

Cantidad de Líneas de Código

SLOC = Líneas de Código Fuente

Size = PFSA*SLOC/UFP

Size = 287*34(Visual C++)/1000

Size(SLOC)= 9758

Size = 9758/1000

Size (KLOD)= 9,75

Estimation del Esfuerzo Requerido

a b c d

Orgánico 3,2 1,05 2,5 0,38

Semiacoplado 3,0 1,12 2,5 0,35

Empotrado 2,8 1,20 2,5 0,32

Esta ecuación calcula el esfuerzo nominal para un proyecto expresado en Meses-persona

(PM).

PM = Esfuerzo dado en Personas por mes:

El factor de escala B explica el ahorro o gasto relativo de escala.

La constante A se le ha asignado un valor de 3,2.

PM = a * Tamañob * FAE PM= 3,2*(9.75)

1.05 * 0.53508480

PM= 18,70 personas/mes

Costo:

Costo = PM * Costo mensual persona

Costo = 18,70 * 1000

Costo = 18.700

Calculo del Tiempo de Desarrollo

T = c * Esfuerzod

T = 2,5 * (18,7)0,38

T = 7,6 Meses

Calculo de Productividad (PR)

PR = SLOC/PM

PR = 9758/18.7

PR = 521,81 sloc/personas mes

Calculo Personal Promedio (P)

P = PM/T

P = 18,7/7,6

P = 2,46 Personas

Resultados

Esfuerzo (PM) = 18,7 persona/mes

Tiempo(T) = 7,6 Meses

Productividad (PR) = 521,81 sloc/pers mes

Personal Promedio (P) = 2,46 Personas

Conclusión

Según los resultados se necesitarán un equipo de 3 personas trabajando alrededor de 8 meses,

pero como la restricción es de 4 meses incrementamos a 6 el número de personas.

1 Jefe de proyecto

2 Analista

2 Programador

1 Responsable de calidad

ANEXO 3

FASE: INICIO

Identificación de todos los involucrados del proyecto

Proyecto:

ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR

CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA AMAZÓNICA”

Fase: Inicio

1. Se identificaron a todos los involucrados del proyecto:

Mentalizadores: director y co-director del proyecto

Usuarios: docentes y Alumnos.

Beneficiarios: comunidad politécnica y sociedad en general.

Desarrollador: estudiante egresado de la carrera de Ingeniería en Sistemas

2. Se realizaron reuniones de trabajo entre los mentalizadores y el desarrollador mediante las cuales se definirá la visión que tendría el SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA AMAZÓNICA”, el mismo que debería ser orientado a la web para un fácil acceso por parte de los beneficiarios, y diseñado para que se adapte a la cultura organizacional de la Politécnica Amazónica.

3. Por medio de reuniones, en las que participaran los mentalizadores, algunos de los futuros usuarios y el desarrollador, se establecieron los requerimientos funcionales

ANEXO 4

FASE: ELABORACIÓN

DIAGRAMA CONCEPTUAL DEL PROBLEMA

Proyecto:



Cardinalidades:

Uno a Uno

Uno a Muchos

Muchos a Muchos

ANEXO 5

CASOS DE USO EXTENDIDO

Proyecto:


AMAZÓNICA”

CASO DE USO: Gestionar Profesor

ACTORES: Secretaria

TIPO: Principal

PROPÓSITO: Ingresar

DESCRIPCIÓN

GENERAL:

La iteración comienza cuando el actor desea ingresar

datos

REFERENCIAS: R1

FLUJO PRINCIPAL

Acción del Autor Respuesta del Sistema

1. El actor selecciona en el menú

ingresar registros

2. Se activa los cuadros de textos

con la respectiva información

solicitada.

3. El actor ingresa los datos

solicitados

4. El sistema valida los datos

ingresados.

5. El actor guarda los datos ingresados


ingresados y los guarda,

posteriormente envía el mensaje

de datos guardado exitosamente.

FLUJO ALTERNO

3.1 El actor cancela el ingreso de nuevo registro y cierra la ventana.

6.1 Faltan campos obligatorios por llenar. Se indica el campo faltante a llenar

CASO DE USO: Gestionar Estudiante

ACTORES: Docente

TIPO: Principal

PROPÓSITO: Modificar los datos personales del estudiante

DESCRIPCIÓN

GENERAL:

La iteración comienza cuando el actor desea ingresar

modificar los datos

REFERENCIAS: RF6

FLUJO PRINCIPAL


1. El actor selecciona en el menú

Estudiante y selecciona modificar

2. El sistema llena los cuadros de

textos con la respectiva

información para la

modificación.

3. El actor realiza la modificación

respectiva

4. El sistema valida que no exista

código de cedulas repetidos y

permite la modificación.

5. El actor graba la modificación

respectiva.

6. El sistema valida datos

ingresados y presenta un

mensaje de proceso finalizado.

7. El actor guarda los datos ingresados


ingresados y los guarda,

posteriormente envía el mensaje

de datos guardado exitosamente.

FLUJO ALTERNO

3.1 El actor cancela el proceso a modificar y cierra la ventana.

CASO DE USO: Gestionar Doctor

ACTORES: Secretaria

TIPO: Secundario

PROPÓSITO: Eliminar Doctor

DESCRIPCIÓN

GENERAL:

La iteración comienza cuando el actor desea

eliminar datos

REFERENCIAS: R11

FLUJO PRINCIPAL


1. El actor selecciona en el menú la

opción doctor y luego presiona

eliminar doctor

2. El sistema presenta un mensaje

de advertencia si está seguro de

eliminar el pedido.

3. El actor confirma la eliminación.

4. El sistema valida y elimina los

datos del doctor y presenta un

mensaje de proceso realizado.

FLUJO ALTERNO

1.1 El actor presiona eliminar doctor sin antes haber seleccionado los datos a

eliminar. El sistema no realiza proceso alguno.

3.1 El actor cancela el proceso eliminar

CASO DE USO: Gestionar Cursos

ACTORES: Secretaria

TIPO: Primario

PROPÓSITO: Consultar Información sobre los cursos

DESCRIPCIÓN

GENERAL:

La iteración comienza cuando el actor desea

consultar información

REFERENCIAS: R57

FLUJO PRINCIPAL


1. El actor ingresa el nombre del curso

y luego presiona la opción de

búsqueda, luego presiona buscar.

2. El sistema presenta los

resultados de la búsqueda.

FLUJO ALTERNO

1.1 El actor ingresa datos equivocados según el criterio de la búsqueda y decide

cambiarlo.

2.1 El actor cancela la búsqueda y cierra la ventana

ANEXO 6

DIAGRAMAS DE CASOS DE USO

Proyecto:


AMAZÓNICA”

Módulo de Gestión de Profesor

Módulo de Gestión de Estudiante

Módulo de Gestión de Doctor

Módulo de Gestión de Universidad

Módulo de Gestión de Becas

Módulo de Gestión de Tutor

Módulo de Gestión de Cursos

Módulo de Gestión de Actas de Notas

Módulo de Gestión de Matrícula

ANEXO 7

DIAGRAMAS DE CLASES

Proyecto:



ANEXO 8

DIAGRAMA ENTIDAD RELACIÓN

Proyecto:


AMAZÓNICA”

ANEXO 9

DICCIONARIO DE DATOS

Proyecto:


AMAZÓNICA”

# ENTIDADES ATRIBUTOS DESCRIPCIÓN 1 Universidad Id_universidad

Nombre_universidad

Rector_universidad

Mantiene información

de universidad

2 Departamento Id_depart

Nom_depart


del departamento

3 Áreas Id_areas

Nom_areas


del área

4 Profesor_areas Areas_id_areas

Profesor_id_prof


compacta de la tabla

área con la de profesor

5 Persona Id_persona

Profesor_id_prof

Estudiante_id_estud

Cursos_id_cursos


de persona

6 Profesor Id_prof

Nom_prof

Apell_prof

Genero_prof

Ciudad_prof

Estado_civil_prof

Fecha_nacimi_prof

Telef_prof

Titulo_3erNivel_prof

Especialidad_prof


del profesor

7 Estudiante Id_estud

Nom_estud

Apell_estud

Fecha_nacimi_estud

Tutor_id_tutor


del estudiante

8 Doctor Id_doctor

Nom_doctor

Apell_doctor

Genero_doctor

Ciudad_doctor

Estado_civil_doctor

Fecha_nacimi_doctor

Telefono_doctor

Nombre_titulo_doctorado_doctor

Catedra_doctor

Cursos_id_cursos


del doctor

9 Solicitud Id_solici

Numero_solici

Estudiante_id_estud

Beca_id_beca

Aprobados_id_aprobados


de todas las solicitudes

10 Aprobados Id_aprobados

Fecha_aprobados


de las becas aprobadas

11 Requisito_solicitud Solicitud_id_requisitos

Requisitos_id_requisitos



requisito con la de

solicitud

12 Requisitos Id_requisitos

Requisito1_requisito




de todos los requisitos

necesarios

13 Beca Id_beca

Nombre_beca

Promoción_beca

Cuantia_beca


de las becas

14 Tutor Id_tutor

Doctor_id_doctor


del tutor

15 Matricula Id_matri

Fecha_matri

Valor_matri

Promoción_id_promocion

Estudiante_id_estud


de las matriculas

generadas

16 Nota Id_nota

Nota1_nota

Nota2_nota

Nota3_nota

Matricula_id_matri

Acta_nota_id_acta_nota


de todas las notas

17 Acta Notas Id_acta_nota

Numero_acta_nota

Nota_acta_nota

Cursos_id_curso


de todas las notas, con la

nota final

18 Cursos Id_curso

Nombre_curso

Fecha_inicio_curso

Fecha_fin_curso

Hora_curso


de los cursos

19 Temas Id_tema

Nombre_tema

Cursos_id_curso


de los temas

20 Promoción Id_promocion

Numero_promocion

Cursos_id_curso

Programa

doctorado_id_prog_doct


de las promociones

21 Promoción_aula Promoción_id_promocion

Aula_id_aula



promoción con la de

aula

22 Aula Id_aula

Numero_aula


de las aulas

23 Programa Doctorado Id_prog_doct

Nombre_prog_doct


del programa de

doctorado

ANEXO 10

DBASE DE DATOS

Proyecto:



UNIDAD ACADÉMICA DE INGENIERÍA CIVIL CARRERA DE...

Documents

Transcript of UNIDAD ACADÉMICA DE INGENIERÍA CIVIL CARRERA DE...