Post on 20-Sep-2018
transcript
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:
egiprui@hotmail.com
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/
16
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 egiprui@hotmail.com
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R5 Inserción Ingreso de datos del
estudiante
Id_estudiante
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
Cedula, Nombre, apellido, fecha de nacimiento
No debe ser nulos
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
Id_tutor Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla tutor.
R6 Modificación Modificación de los datos
del estudiante Datos R5 Trabaja con R5 Alta
R7 Eliminación Eliminación de Datos del
estudiante Datos R5 Para eliminar se necesita el ID del estudiante. Baja
R8 Buscar Consulta de los Datos del
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R9 Inserción Ingreso de datos del doctor
Id_doctor
Debe ser un numero entero autoincrementar,
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.
R10 Modificación Modificación de los datos
del doctor Datos R9 Trabaja con R9 Alta
R11 Eliminación Eliminación de Datos del
doctor Datos R9 Para eliminar se necesita el ID del doctor. Baja
R12 Buscar Consulta de los Datos del
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R13 Inserción Ingreso de datos de la
universidad
Id_universidad
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
Nombre, rector
No debe ser nulos
R14 Modificación Modificación de los datos
de la universidad Datos R13 Trabaja con R13 Alta
R15 Eliminación Eliminación de Datos del
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R17 Inserción Ingreso de datos del
departamento
Id_departamento
Debe ser un numero entero autoincrementar,
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.
R18 Modificación Modificación de los datos
del departamento Datos R17 Trabaja con R17 Alta
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R19 Eliminación Eliminación de Datos del
departamento Datos R17
Para eliminar se necesita el ID del
departamento. Baja
R20 Buscar Consulta de los Datos del
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R21 Inserción Ingreso de datos del área
Id_area
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta Nombre No debe ser nulos
Id_Departamento
Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla
Departamento.
R22 Modificación Modificación de los datos
del área Datos R21 Trabaja con R21 Alta
R23 Eliminación Eliminación de Datos del
área Datos R21 Para eliminar se necesita el ID del Área. Baja
R24 Buscar Consulta de los Datos del
á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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R25 Inserción Ingreso de datos de la Beca
Id_beca
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
Nombre, promoción, cuantía No debe ser nulos
R26 Modificación Modificación de los datos
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R29 Inserción Ingreso de los requisitos
Id_requsitos
Debe ser un numero entero autoincrementar,
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R33 Inserción Ingreso de la solicitud
Id_solicitud
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
Número de la solicitud
No debe ser nulos
Id_estudiante
Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla
Estudiante.
Id_beca
Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla Beca.
Id_ aprobados
Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R37 Inserción Ingreso de aprobados Id_aprobados
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R41 Inserción Ingreso de tutor
Id_tutor
Debe ser un numero entero autoincrementar,
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R45 Inserción Ingreso del programa de
doctorado Id_prog_doct
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R49 Inserción Ingreso de la promoción
Id_promoción
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta Numero de promoción No debe ser nulos
Id_cursos Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla Cursos
Id_prog_doct
Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla Programa
de doctorado
R49 Modificación Modificación de la
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R50 Inserción Ingreso del aula
Id_aula
Debe ser un numero entero autoincrementar,
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R54 Inserción Ingreso del curso
Id_curso
Debe ser un numero entero autoincrementar,
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R58 Inserción Ingreso de los temas
Id_curso
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta Nombre No debe ser nulos
Id_cursos Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla Cursos
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R62 Inserción Ingreso del acta de notas
Id_acta_notas
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta Número del acta
Debe ser un numero entero autoincrementar,
no debe ser nulo
Notas No debe ser nulo
Id_cursos Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla Cursos
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
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
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.
No. R Tipo Descripción Datos Restricciones – Observaciones Prioridad
R66 Inserción Ingreso de la matrícula
Id_matricula
Debe ser un numero entero autoincrementar,
no debe ser nulo
Alta
Fecha de matrícula Día, mes, año
Valor No debe ser nulo
Id_promocion
Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla
promoción
Id_estudiante Debe ser un numero entero, no debe ser valor
nulo, es código proviene de la tabla estudiante
R67 Modificación Modificación de la
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
Identificación del requerimiento:
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.
Descripción del requerimiento:
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).
Prioridad del requerimiento: Alta
Identificación del requerimiento:
RNF03
Nombre del Requerimiento:
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.
Descripción del requerimiento:
El sistema debe disponer de una documentación fácilmente actualizable que permita realizar operaciones de mantenimiento con el
menor esfuerzo posible.
Prioridad del requerimiento: Alta
Identificación del requerimiento:
RNF04
Nombre del Requerimiento:
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.
Descripción del requerimiento:
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.
Prioridad del requerimiento: Alta
Identificación del requerimiento:
RNF05
Nombre del Requerimiento:
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.
Descripción del requerimiento:
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.
Prioridad del requerimiento: Alta
Identificación del requerimiento:
RNF06
Nombre del Requerimiento:
Nivel de Usuario
Características: Garantizara al usuario el acceso de información de acuerdo al nivel que posee.
Descripción del requerimiento:
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.
Prioridad del requerimiento: Alta
Identificación del requerimiento:
RNF07
Nombre del Requerimiento:
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.
Descripción del requerimiento:
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.
Prioridad del requerimiento: Alta
Identificación del requerimiento:
RNF08
Nombre del Requerimiento:
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.
Descripción del requerimiento:
Garantizar la seguridad del sistema con respecto a la información y datos que se manejan tales sean documentos, archivos y
contraseñas.
Prioridad del requerimiento: Alta
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:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA
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:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR
CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA AMAZÓNICA”
Cardinalidades:
Uno a Uno
Uno a Muchos
Muchos a Muchos
ANEXO 5
CASOS DE USO EXTENDIDO
Proyecto:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA
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
6. El sistema valida los datos
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
Acción del Autor Respuesta del Sistema
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
8. El sistema valida los datos
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
Acción del Autor Respuesta del Sistema
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
Acción del Autor Respuesta del Sistema
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:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA
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:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR
CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA AMAZÓNICA”
ANEXO 8
DIAGRAMA ENTIDAD RELACIÓN
Proyecto:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA
AMAZÓNICA”
ANEXO 9
DICCIONARIO DE DATOS
Proyecto:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA
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
Mantiene información
del departamento
3 Áreas Id_areas
Nom_areas
Mantiene información
del área
4 Profesor_areas Areas_id_areas
Profesor_id_prof
Mantiene información
compacta de la tabla
área con la de profesor
5 Persona Id_persona
Profesor_id_prof
Estudiante_id_estud
Cursos_id_cursos
Mantiene información
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
Mantiene información
del profesor
7 Estudiante Id_estud
Nom_estud
Apell_estud
Fecha_nacimi_estud
Tutor_id_tutor
Mantiene información
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
Mantiene información
del doctor
9 Solicitud Id_solici
Numero_solici
Estudiante_id_estud
Beca_id_beca
Aprobados_id_aprobados
Mantiene información
de todas las solicitudes
10 Aprobados Id_aprobados
Fecha_aprobados
Mantiene información
de las becas aprobadas
11 Requisito_solicitud Solicitud_id_requisitos
Requisitos_id_requisitos
Mantiene información
compacta de la tabla
requisito con la de
solicitud
12 Requisitos Id_requisitos
Requisito1_requisito
Requisito2_requisito
Requisito3_requisito
Mantiene información
de todos los requisitos
necesarios
13 Beca Id_beca
Nombre_beca
Promoción_beca
Cuantia_beca
Mantiene información
de las becas
14 Tutor Id_tutor
Doctor_id_doctor
Mantiene información
del tutor
15 Matricula Id_matri
Fecha_matri
Valor_matri
Promoción_id_promocion
Estudiante_id_estud
Mantiene información
de las matriculas
generadas
16 Nota Id_nota
Nota1_nota
Nota2_nota
Nota3_nota
Matricula_id_matri
Acta_nota_id_acta_nota
Mantiene información
de todas las notas
17 Acta Notas Id_acta_nota
Numero_acta_nota
Nota_acta_nota
Cursos_id_curso
Mantiene información
de todas las notas, con la
nota final
18 Cursos Id_curso
Nombre_curso
Fecha_inicio_curso
Fecha_fin_curso
Hora_curso
Mantiene información
de los cursos
19 Temas Id_tema
Nombre_tema
Cursos_id_curso
Mantiene información
de los temas
20 Promoción Id_promocion
Numero_promocion
Cursos_id_curso
Programa
doctorado_id_prog_doct
Mantiene información
de las promociones
21 Promoción_aula Promoción_id_promocion
Aula_id_aula
Mantiene información
compacta de la tabla
promoción con la de
aula
22 Aula Id_aula
Numero_aula
Mantiene información
de las aulas
23 Programa Doctorado Id_prog_doct
Nombre_prog_doct
Mantiene información
del programa de
doctorado
ANEXO 10
DBASE DE DATOS
Proyecto:
ANÁLISIS DE UN SISTEMA INFORMÁTICO PARA GESTIONAR
CURSOS DE DOCTORADO PARA LA ESCUELA “POLITÉCNICA AMAZÓNICA”