UNIVERSIDAD NACIONAL DE HUANCAVELICA

FACULTAD DE INGENIERÍA ELECTRÓNICA Y SISTEMAS

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“SISTEMA WEB PARA DEPENDENCIA DE EXTENSIÓN CULTURAL Y

PROYECCIÓN SOCIAL DE LA ESCUELA PROFESIONAL DE INGENIERÍA DE
SISTEMAS”

CURSO :

TALLER DE INGENIERIA DE SOFTWARE

DOCENTE :

GILMER MATOS VILA

INTEGRANTES :

 QUISPE GARCIA, Yda

 RAVELO CCANTO, Katerin Kemberlin
 VALENCIA MATAMOROS, Amner
 PUETES HUAMANCAJA, Luis Alberto
 GUTIERRES BOLAÑOS, Jhanet Kely

CICLO : VII

HUANCAVELICA - PERÚ
2022

1
 INTRODUCCIÓN

El proyecto desarrollado que se presentara a continuación se encuentra destinado a la

Dependencia de extensión cultural y proyección social de la Escuela Profesional Ingeniería
de Sistemas, viendo la situación en el que el encargado de la Dependencia registra la
información en una hoja Excel, por ello decidimos que en el curso de “ Taller de ingeniería
de Software” se desarrollará un software web para ayudar al encargado de la Dependencia
para que realice una mejor administración de sus actividades.

Esta problemática se viene dando Desde años anteriores que hasta la actualidad se
sigue viendo esta dificultad en donde no existe registros de los anteriores encargados de la
Dependencia, el software que se desarrollará se solucionarán problemas como mejor
control de los grupos creados en la dependencia, control de reportes y demás actividades,
Siendo este software amigable y de uso fácil para el encargado de la Dependencia. Desde la
recopilación de requerimientos del usuario hasta la publicación del software web, en el
maquetado y diseño de la parte visual se usarán colores suaves y cálidos, mientras que en el
funcionamiento se tratará de integrar todas las funciones necesarias para el uso óptimo de la
Dependencia de extensión cultural y proyección social.

La metodología que se usará en el proceso de desarrollo del software web será la

metodología Scrum, porque es una metodología ágil y flexible para gestionar el desarrollo
de la página web. Se basa en construir primero la funcionalidad de mayor valor para el
usuario y en los principios de inspección continua, adaptación, autogestión e innovación.
Con el afán de hacer más entendible el proyecto. Y con leves variaciones a gusto del
programador para adaptarnos a futuros cambios que se quiera reemplazar o añadir en el
software web.

2
 CAPÍTULO I

PLANTEAMIENTO METODOLÓGICO

1.1. El Problema

1.1.1 Realidad problemática:

En la escuela profesional de ingeniería de sistemas se vio la problemática de
que en muchas ocasiones se pide realizar reportes y al responsable se le dificulta
hacer dichos reportes ya que en ocasiones no cuenta con los documentos presentados
por partes de los grupos.

La Dependencia es importante por cuanto permite registrar quienes a los

grupos de estudiantes que desean realizar proyección social, responsabilidad social o
extensión cultural, se necesita automatizar este proceso con ayuda de la tecnología
para solucionar los problemas que se dan hoy en día.
1.1.2 Realidad de la organización
El encargado de la dependencia de la EPIS hoy en día utiliza un libro Excel en
donde apunta la información general; nombre del grupo, integrantes, estado, cantidad
de estudiantes, entre otros.

1.2. Objetivos

2.1.1 Objetivo General

Diseñar y desarrollar un software web que permita al encargado de la
Dependencia de extensión cultural y proyección social automatizar sus procesos de
registro de información concerniente a las actividades de esta misma.
2.1.2 Objetivos Específicos
 Analizar todo el proceso actual que involucra a la Dependencia de
extensión cultural y proyección social.

3
  Recolectar todos los requerimientos manifestados por el encargado del
área de la Dependencia de extensión cultural y proyección social para
mejorar y automatizar la gestión de sus procesos.
 Diseñar una interfaz intuitiva y amigable para el uso del aplicativo
 Diseñar una base de datos con un modelo entidad relación que permita
almacenar toda la información que se ingrese desde el software web.
 Identificación y autentificación a usuarios.

1.3. Limitaciones del Proyecto

1.3.1 Temporal
Este proyecto iniciará entre el 12 de mayo del 2022 y el 22 de julio del 2022.

1.3.2 Espacial
El proyecto se desarrollará para la dependencia de EC, PS y SC

1.3.3 Conceptual
La delimitación conceptual de este trabajo es la metodología SCRUM.

4
 CAPÍTULO II

MARCO TEORIOCO

Bases teóricas relacionados al tema

2.1 Aplicación Web

Las aplicaciones web son una herramienta que se codifica en un lenguaje que
es soportado por los navegadores y que se ejecuta en los mismos. Es decir, son una
clase de software que puedes usar accediendo a cierto servidor web a través de
Internet o de una Intranet por medio de un navegador que ejecutará la aplicación, las
aplicaciones web se ejecutan en un servidor web todo lo que haces en ellas se procesa
y almacena en el interior de una base de datos por medio de un navegador. De esta
forma, no es necesario que las instales en tu ordenador o dispositivo móvil. Las
aplicaciones web están especialmente diseñadas para almacenar datos en la nube.
Esta información se mantiene almacenada en los servidores web y cuando necesitas
utilizarla la aplicación envía esos datos a tu ordenador o a tus dispositivos móviles.

2.2 Frontend
Front End es la parte de una aplicación que interactúa con los usuarios, es
conocida como el lado del cliente. Básicamente es todo lo que vemos en la pantalla
cuando accedemos a un sitio web o aplicación: tipos de letra, colores, adaptación para
distintas pantallas (RWD), los efectos del ratón, teclado, movimientos,
desplazamientos, efectos visuales… y otros elementos que permiten navegar dentro
de una página web. Este conjunto crea la experiencia del usuario. Como hemos dicho,
el desarrollador front end se encarga de la experiencia del usuario, es decir, en el
momento en el que este entra a una página web, debe ser capaz de navegar por ella,
por lo que el usuario verá una interfaz sencilla de usar, atractiva y funcional. Un
desarrollador front end debe conocer los siguientes lenguajes de programación:
HTML5, CSS3, JavaScript, Jquery, Ajax.

2.3 Backend
Cuando hablamos de “Back end” nos referimos al interior de las aplicaciones
que viven en el servidor y al que a menudo se le denomina “el lado del servidor”. El
5
 back end del sitio web consiste en un servidor, una aplicación y una base de datos. Se
toman los datos, se procesa la información y se envía al usuario. Los desarrolladores
de Front end y Back end suelen trabajar juntos para que todo funcione correctamente.
Un desarrollador Back end debe tener amplios conocimientos de los siguientes
lenguajes: frameworks y los tipos de base de datos. No siendo necesario conocer
todos los lenguajes, pero sí entender y saber trabajar con algunos de ellos. [Link] ,
PHP, Python, Ruby, [Link], Java, MySQL, SQL Server, PostgreSQL, Oracle,
MongoDB.

2.4 Frameworks
Es un entorno de trabajo con una estructura conceptual y tecnológica de
asistencia definida, normalmente, con artefactos o módulos concretos de software,
que puede servir de base para la organización y desarrollo de software. Típicamente,
puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre
otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de
un proyecto, además es un conjunto estandarizado de conceptos, prácticas y criterios
para enfocar un tipo de problemática particular que sirve como referencia, para
enfrentar y resolver nuevos problemas de índole similar.

2.5 UML
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un
lenguaje de modelado visual común y semántica y sintácticamente rico para la
arquitectura, el diseño y la implementación de sistemas de software complejos, tanto
en estructura como en comportamiento. UML tiene aplicaciones más allá del
desarrollo de software, p. ej., en el flujo de procesos en la fabricación. Es comparable
a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En
general, los diagramas UML describen los límites, la estructura y el comportamiento
del sistema y los objetos que contiene. UML no es un lenguaje de programación, pero
existen herramientas que se pueden usar para generar código en diversos lenguajes
usando los diagramas UML. UML guarda una relación directa con el análisis y el
diseño orientados a objetos.

6
2.6 CSS
Es una tecnología usada por muchos sitios web para crear páginas visualmente
atractivas, interfaces de usuario para aplicaciones web como Firefox. Es un lenguaje
que se encarga de diseñar y presentar páginas web, como luce ante una visita a la
página, También funciona junto al lenguaje HTML, que ayuda en el contenido de la
página.

2.7 Bootstrap
Es un Framework creado por Twitter que permite el desarrollo de aplicaciones
web. Es simple y ligero y es compatible solo con los archivos CSS y un JS. Está
basado en HTML5, CSS y jQuery.

Si la arquitectura está basada en [Link] es compatible con todos los

navegadores. El complemento JQuery puede validar datos de entrada, tablas, gráficos
y formularios. Abierto al público en 2011 bajo la licencia Apache.

2.8 MVVM
El patrón Model-View-ViewModel (MVVM) nos ayuda a separar la lógica de
negocios de la interfaz de usuario, facilitando las pruebas, mantenimiento y la
escalabilidad de los proyectos. MVVM, con Data Binding en Android, tiene los
beneficios de facilitar las pruebas y el modularidad, reduciendo a su vez la cantidad
de código que tenemos que escribir para conectar vista + modelo.

Cuando creamos una aplicación, a todos nos gustaría tener nuestro código
limpio y organizado, para que cualquier otro desarrollador tenga una más rápida
comprensión del mismo.

2.9 HTML
Es un lenguaje de marcado de hipertexto que no es considerado un lenguaje de
programación debido a que en este no se pueden crear funcionalidades dinámicas
para la aplicación web, por el contrario, solo te permite organizar o formatear textos
en un navegador al igual que un documento de Word.

7
 Fue creado con la finalidad de generar formato para publicar textos
referenciados en línea y de esa manera poder acceder a ellas desde cualquier lugar,
para ello creó etiquetas que podemos definirlas como componentes básicos de una
página web.

2.10 PHP
PHP es un lenguaje de programación destinado a desarrollar aplicaciones para
la web y crear páginas web, favoreciendo la conexión entre los servidores y la
interfaz de usuario. Entre los factores que hicieron que PHP se volviera tan popular,
se destaca el hecho de que es de código abierto.

Es de código abierto, no hay restricciones de uso vinculadas a los derechos. El

usuario puede usar PHP para programar en cualquier proyecto y comercializarlo sin
problemas.

Está en constante perfeccionamiento, gracias a una comunidad de

desarrolladores proactiva y comprometida.

PHP generalmente es definido como un lenguaje del lado del servidor. Esto
significa que se aplica en la programación que tiene lugar en el servidor web
responsable de ejecutar la aplicación o, más a menudo, en un sitio web.

El código PHP se ejecuta en el servidor que, al leer los comandos, puede

activar todos los elementos funcionales y la interfaz visual del sitio web.

2.11 Scrum
Es un proceso de gestión de recursos humanos que permite reducir la
complejidad en el desarrollo de tareas. La gerencia trabaja en conjunto con un equipo
de trabajo, los cuales desarrollan soluciones en plan de una lista de requisitos
obtenidos y clasificados en historias de usuario que explican de forma clara las
funcionalidades que deberá poseer el sistema una vez termine el tiempo de desarrollo
de una tarea (Sprint). Para ello esta metodología se basa en las siguientes
herramientas.

8
 ● Sprint: Es un cuadro donde se detalla el tiempo fijo que tomará la
realización de una o un grupo de requerimientos.
● Sprint Planning: Son reuniones diarias desarrolladas para definir las labores
que se desarrollarán durante el transcurso del día.
● Sprint Review: Se realiza después de realizado el sprint, con el fin de
evaluar el avance del proyecto y evaluar el backlog en conjunto con los
stakeholders.
● Sprint Retrospective: Es un evento en el cual participan todos los miembros
del equipo de scrum, en este se evalúan temas como la comunicación,
procesos, herramientas, entre otros con el fin de obtener un plan de mejora
sobre el cual trabajar para las siguientes tareas.
● Product Backlog: Es una lista donde se detallan todas las actividades a
realizar durante el desarrollo del proyecto ya que esta se encuentra
conformada por todos los requerimientos del product owner así como
también de los stakeholders, además aquí se detallan las prioridades que se
tendrán.
● Sprint Backlog: Es la suma de todos los elementos del backlog elegidos para
un sprint.

Además de estas herramientas, tenemos que mencionar a los participantes del

equipo de scrum:

● Propietario del producto (Product owner): Es una persona escogida por

conocer profundamente el tema y ambiente del área que busca el producto a
desarrollar, de esta persona depende el éxito o fracaso del proyecto, ya que
al conocer la realidad de los clientes se debe de encargar de transmitir los
requisitos necesarios para que el producto desarrollado pueda cumplir con
las expectativas al 100%.
● Scrum master: Es la persona que conoce a fondo la metodología y busca
guiar al equipo de desarrollo en el cumplimiento de tareas y roles durante el
tiempo de desarrollo del proyecto: Esta persona se encarga de guiar en el

9
 desarrollo del product backlog, sprint backlog, sprints y demás hasta la
elaboración del sprint final culminando el proyecto de forma satisfactoria.
● Development team: Son personas técnicas que se encargan de desarrollar el
producto final y comparten la responsabilidad del trabajo.
● Stakeholders: Son todos los interesados (empleados, clientes, proveedores,
etc) que estarán involucrados con el producto al final de su desarrollo y cuya
opinión cuenta para mejorar ciertas interfaces, tareas o funciones que deberá
cumplir el software.

CAPÍTULO III

DESARROLLO DEL SISTEMA WEB

3.1 Roles del Proyecto

3.1.1 Definición de roles del proyecto

Tabla 1
Definición de Roles

DEFINICIÓN DE ROLES DEL PROYECTO

Ing. GILMER MATOS VILA

Scrum Master
Amner, VALENCIA MATAMOROS

Ing. GILMER MATOS VILA Product Owner

Alberto, PUENTES HUAMANCAJA

Diseñador
Amner, VALENCIA MATAMOROS

Katerin, RAVELO CCANTO Testeador

Yda, QUISPE GARCIA Analista

10
 SCRUM MASTER: Este personaje es el encargado de administrar el proceso de
desarrollo del proyecto, generar confianza entre el equipo de trabajo, se encarga de
la planificación, realiza seguimiento y reportes del avance del proyecto.

 Realiza la planificación de las actividades del proyecto.

 Mantener una buena comunicación con el product owner.
 Generar confianza entre el product owner y el development team.
 Ayuda al equipo de desarrollo a mantener la concentración en las tareas que
planearon realizar.
 Ayuda al equipo de desarrollo a ser autosuficiente.
 Remueve impedimentos que pudiesen existir.

PRODUCT OWNER: Se encarga de realizar la lista de funcionalidades que debe de

tener el producto, esto debido a que este papel es caracterizado por conocer de las
necesidades y requerimientos que debe de tener el sistema a desarrollar.

 Debe de conocer las necesidades de la organización.

 Es el encargado de maximizar el valor entregado escogiendo cual sprint
debe de ser entregado con prontitud.
 Debe asegurarse de que exista una lista con las tareas que se realizarán
durante la realización del trabajo (Product Backlog).
3.2 Análisis Del Requerimiento Del Sistema

3.2.1 Requerimientos funcionales del software web

Tabla 2
Requerimientos Funcionales

REQUERIMIENTOS FUNCIONALES
ID Requisitos

RF1 El Software deberá tener un inicio de sesión (administrador, usuarios)

El software deberá registrar proyectos (Extensión Cultural, Proyección Social
RF2
y Servicio Social)

11
 El software deberá permitir crear un usuario y contraseña para usuarios como
RF3
(Asesor, Estudiante)
RF4 El software deberá recepcionar informes de los grupos inscritos

RF5 El software deberá mostrar un listado de grupos inscritos

El software deberá contar con la ficha para evaluar la inscripción de
RF6
proyectos
RF7 El software deberá contar con la ficha para evaluar los proyectos finales
El software deberá contará con las fichas de los anexos de acuerdo al
RF8
reglamento
RF9 El software deberá permitir hacer reportes de los proyectos

3.2.2 Requerimientos no funcionales del software web

Tabla 3
Requerimientos No Funcionales

REQUERIMIENTOS NO FUNCIONALES
Producto Organización Externos
La información ubicada en
La aplicación debe ser funcional El sistema debe ser la base de datos del sistema
en los navegadores siguientes: desarrollado utilizando el debe ser únicamente
web Chrome, Firefox e Internet lenguaje de programación resguardada por la EPIS y
Explorer. PHP no ser liberada para
entidades externas
La metodología a emplear
La aplicación debe tener una
para el desarrollo ágil del El sistema no debe mostrar
interfaz intuitiva de colores
software es el Scrum información que no se le
sencillos, con un acabado simple
solicite de usuarios externos
El sistema tendrá un mensaje de El sistema debe ser El sistema no revelará datos
bienvenida cuando el usuario desarrollado utilizando las personales de los usuarios
inicie sesión correctamente. herramientas CASE registrados.
Interfaz intuitiva de selección
simple y disposición de colores
estáticos y simples

12
3.3 Historias de Usuario

Las historias de usuario son compilaciones de requisitos del sistema que son
expresados con un lenguaje común y no muy extenso. Estas son descritas por las
personas que harán uso del software y que desean esa característica en el producto
final.

Prioridades en el Negocio: Será medido en función al rango de: alta, media y

baja.

Tabla 4
Historia de Usuario 1

Historia de Usuario

Número: 1 Usuario: Responsable de la Dependencia

Nombre Historia: Creación de Acceso (Login)

Prioridad en Negocio: Riesgo en Desarrollo:
Alta Media
Puntos estimados: 7 horas Sprint Asignado: 1

Programador responsable: PUENTES, HUAMANCAJA, Alberto

Descripción:
COMO responsable de la Dependencia
QUIERO un inicio de sesión
PARA poder tener mayor seguridad y poder acceder al software

Validación:
El Login que se realizará pedirá al usuario acceder al sistema con correo y contraseña
para así validar su autenticidad.

13
Tabla 5
Historia de Usuario 2

Historia de Usuario
Número: 2 Usuario: Responsable de la Dependencia

Nombre Historia: Registrar proyectos EC, PS y SS

Prioridad en Negocio: Riesgo en Desarrollo:
Alta Alta
Puntos estimados: 10 horas Sprint Asignado: 1
Programador responsable: PUENTES, HUAMANCAJA, Alberto y VALENCIA MATAMOROS,
Amner

Descripción:
COMO responsable de la Dependencia
QUIERO registrar los proyectos
PARA para tener un mejor registro de los proyectos

Validación:
El software deberá registrar proyectos: Nombre del Grupo, Titulo del Proyecto,
Modalidad, Línea, Integrantes, Asesor, Fecha de Inicio y Fecha de Finalización.

Tabla 6
Historia de Usuario 3

Historia de Usuario
Número: 3 Usuario: Estudiante y Asesor

Nombre Historia: Gestión de usuario y contraseña para usuarios

Prioridad en Negocio: Riesgo en Desarrollo:
Alta Alta
Puntos estimados:  6 horas Sprint Asignado: 2

Programador responsable: PUENTES, HUAMANCAJA, Alberto y RAVELO CCANTO, Katerin

14
 Descripción:
COMO administrador
QUIERO que los usuarios (Estudiante y Asesor) puedan crear usuarios
PARA que puedan acceder al sistema

Validación: El software permitirá generar usuario y contraseña para estudiantes y Asesor

Tabla 7
Historia de Usuario 4

Historia de Usuario
Número: 4 Usuario: Responsable de la Dependencia

Nombre Historia: Recepción de informes de grupos

Prioridad en Negocio: Riesgo en Desarrollo:
Alta Alta
Puntos estimados: 5 horas Sprint Asignado: 2

Programador responsable: PUENTES, HUAMANCAJA, Alberto y QUISPE GARCIA, Yda

Descripción:
COMO administrador
QUIERO poder recibir los informes de los grupos inscritos
PARA tener un registro de los reportes de los avances que se realizan en cada proyecto
activo.

Validación: El software contara con un módulo donde permita descargar el informe para
su revisión a través de un filtrado de Nombre de Grupo y Titulo del Proyecto

Tabla 8
Historia de Usuario 5

Historia de Usuario
Número: 5 Usuario: Responsable de la Dependencia

15
 Nombre Historia: Lista de grupos inscritos
Prioridad en Negocio: Riesgo en Desarrollo:
Alta Media
Puntos estimados:7 horas Sprint Asignado: 2
Programador responsable: PUENTES, HUAMANCAJA, Alberto y GUTIERREZ BOLAÑOS,
Jhanet

Descripción:
COMO responsable de la Dependencia
QUIERO visualizar una lista de los grupos inscritos
PARA poder usarlo en casos que se requiera

Validación: El Software deberá contar con un modulo donde contenga una tabla con la
lista de los grupos inscritos

Tabla 9
Historia de Usuario 6

Historia de Usuario

Número: 6 Usuario: Responsable de la Dependencia

Nombre Historia: Evaluación de inscripción de los proyectos

Prioridad en Negocio: Riesgo en Desarrollo:
Alta Alta
Puntos estimados:   8 horas Sprint Asignado: 3
Programador responsable: PUENTES, HUAMANCAJA, Alberto VALENCIA MATAMOROS,
Amner

Descripción:
COMO responsable de la Dependencia
QUIERO un módulo donde pueda evaluar la inscripción de los proyectos
PARA su aprobación

Validación: el software podrá contabilizar cuantos requisitos presentaron y luego se

aplicar la fórmula de calificación general para dar un veredicto

16
Tabla 10
Historia de Usuario 7

Historia de Usuario

Número: 7 Usuario: Responsable de la Dependencia

Nombre Historia: Evaluación de los proyectos finales

Prioridad en Negocio: Riesgo en Desarrollo:
Media Media
Puntos estimados:   8 horas Sprint Asignado: 3

Programador responsable: PUENTES, HUAMANCAJA, Alberto y RAVELO CCANTO, Katerin

Descripción:
COMO responsable de la Dependencia
QUIERO un módulo donde pueda evaluar la inscripción de los proyectos
PARA su aprobación

Validación: el software podrá contabilizar cuantos requisitos presentaron y luego se

aplicar la fórmula de calificación general para dar un veredicto

Tabla 11
Historia de Usuario 8

Historia de Usuario
Número: 8 Usuario: Responsable de la Dependencia

Nombre Historia: Fichas de los anexos de acuerdo con el reglamento

Prioridad en Negocio: Riesgo en Desarrollo:
Media Media
Puntos estimados:  4 hora Sprint Asignado: 4

Programador responsable: PUENTES, HUAMANCAJA, Alberto y QUISPE GARCIA, Yda

17
 Descripción:
COMO responsable de la Dependencia
QUIERO que las fichas de los anexos este en un módulo del estudiante
PARA facilitar a los estudiantes en encontrar los distintos anexos que corresponda

Validación: el software contará con un módulo de estudiante que contenga los diversos
anexos

Tabla 12
Historia de Usuario 9

Historia de Usuario
Número: 9 Usuario: Responsable de la Dependencia

Nombre Historia: Reportes de los proyectos

Prioridad en Negocio: Riesgo en Desarrollo:
Alta Alta

Puntos estimados: 8 horas Sprint Asignado: 4

Programador responsable: PUENTES, HUAMANCAJA, Alberto y GUTIERREZ

BOLAÑOS, Jhanet

Descripción:
COMO administrador
QUIERO poder realizar reportes de los proyectos
PARA usarlos en casos de los que se requiera

Validación: En el software contara con un modulo reportes donde se seleccionar las

fechas para generar el listado de los proyectos dentro de las fechas seleccionadas

3.4 Diagrama De Casos De Uso

18
Figura 1
Acceso (Login) y Gestión de Usuarios y Contraseñas

Figura 2

19
Registro de Grupos

20
 Figura 3

Recepción de Informes de Grupos

21
Figura 4
Lista de Grupos Inscritos y Generar Reportes

22
Figura 5
Evaluación de Inscripción de Proyectos

23
Figura 6
Evaluación de Proyectos Finales

24
Figura 7
Usuario Estudiante

Figura 8

25
Usuario Asesor

26
3.5 Diagrama De Secuencias

Figura 1

27
Usuario estudiante

28
Figura 2
Usuario encargado: Registro de grupo

Figura 3
Usuario encargado: Informe de grupo

29
Figura 4
Usuario encargado: Reporte

Figura 5
Usuario encargado: Evaluación final

30
Figura 6
Usuario encargado: Evaluación de inscripción

Figura 7
Usuario encargado: Envío de mensajes

31
Figura 8
Usuario asesor

32
 3.6 Diagrama De Clases

3.7 Lista de historias de usuario por orden de importancia (Backlog)

Backlog General

Nombre de la HU Historia de Usuario Prioridad

COMO responsable de la Dependencia

Creación de Acceso QUIERO un inicio de sesión Media
(Login)
PARA poder tener mayor seguridad y poder acceder
al software.

COMO responsable de la Dependencia

Registrar proyectos EC,
QUIERO registrar los proyectos Alta
PS y SS
PARA para tener un mejor registro de los proyectos

COMO administrador
Gestión de usuario y
QUIERO que los usuarios (Estudiante y Asesor)
contraseña para Alta
puedan crear usuarios
usuarios
PARA que puedan acceder al sistema

COMO responsable de la Dependencia

Recepción de informes QUIERO poder recibir los informes de los grupos

inscritos Alta
de grupos
PARA tener un registro de los reportes de los
avances que se realizan en cada proyecto activo.

Lista de grupos COMO responsable de la Dependencia Media

33
 QUIERO visualizar una lista de los grupos inscritos 
inscritos
PARA poder usarlo en casos que se requiera 

COMO responsable de la Dependencia

Evaluación de
QUIERO un módulo donde pueda evaluar la
inscripción de los Alta
inscripción de los proyectos
proyectos
PARA su aprobación

COMO responsable de la Dependencia

Evaluación de los QUIERO un módulo donde pueda evaluar los Alta
proyectos finales proyectos

PARA su aprobación

COMO responsable de la Dependencia

Fichas de los anexos de QUIERO que las fichas de los anexos este en un
acuerdo con el módulo del estudiante Media
reglamento
PARA facilitar a los estudiantes en encontrar los
distintos anexos que corresponda

COMO administrador
Reportes de los proyectos QUIERO poder realizar reportes de los proyectos  Alta

PARA usarlos en casos de los que se requiera

3.8 Sprint del Equipo

HORAS DE
JORNADA DÍAS DE
TRABAJO DEL SEMANAS A TOTAL DE
LABORAL TRABAJO
EQUIPO SCRUM PROYECTO TRABAJAR HORAS
DISPONIBLE (SEMANA)
(DÍA)

VALENCIA MATAMOROS, Amner 4 horas 2 horas 3 días 2 semanas 12 horas

RAVELO CCANTO, Katerin 6 horas 1 hora 3 días 2 semanas 6 horas

QUISPE GARCIA, Yda 6 horas 1 hora 3 días 2 semana 6 horas

34
PUENTES HUAMANCAJA, Luis Alberto 6 horas 2 horas 3 días 2 semanas 12 horas

GUTIERES BOLAÑOS, Jhanet Kely 6 horas 1 horas 3 días 2 semanas 6 horas

3.9 Planificación de los Sprint

Desarrollo del Sprint 1

SPRINT N° 1

FECHA DE 15/04/2022 FECHA DE 06/05/2022

INICIO CULMINACIÓN

06/05/2022 TIEMPO
REVISIÓN 25
ESTIMADO (días)

TAREAS A ● Historia de usuario N° 1: Creación de Acceso (Login)

DESARROLLAR ● Historia de usuario N°2: Registrar proyectos EC, PS y SS

Historia de usuario
N° 1: Creación de DESARROLLADORES Alberto, PUENTES HUAMANCAJA
Acceso (Login)
HISTORIAS DE
USUARIO Historia de usuario
N° 2: Registrar  PUENTES HUAMANCAJA, Alberto
DESARROLLADORES
proyectos EC, PS y  VALENCIA MATAMOROS, Amner
SS

Desarrollo del Sprint 2

SPRINT N°2

FECHA DE 06/05/2022 FECHA DE 15/06/2022

INICIO CULMINACIÓN

REVISIÓN 15/06/2022 TIEMPO 31

35
 ESTIMADO (días)

● Historia de usuario N° 3: Gestión de usuario y contraseña para usuarios

TAREAS A
● Historia de usuario N° 4: Recepción de informes de grupos
DESARROLLAR
● Historia de usuario N° 5: Lista de grupos inscritos

Historia de usuario
N° 3: Gestión de
usuario y DESARROLLADORES
contraseña para  PUENTES, HUAMANCAJA, Alberto
usuarios  RAVELO CCANTO, Katerin

Historia de usuario
HISTORIAS DE N° 4: Recepción de DESARROLLADORES  PUENTES, HUAMANCAJA, Alberto
USUARIO informes de grupos  QUISPE GARCIA, Yda

Historia de usuario
 PUENTES, HUAMANCAJA, Alberto
N° 5: Lista de DESARROLLADORES
 GUTIERREZ BOLAÑOS, Jhanet
grupos inscritos

Desarrollo del Sprint 3

SPRINT N°3

FECHA DE 15/06/2022 FECHA DE 10/07/2022

INICIO CULMINACIÓN

10/07/2022 TIEMPO
REVISIÓN 25
ESTIMADO (días)

TAREAS A ● Historia de usuario N° 6: Evaluación de inscripción de los proyectos

DESARROLLAR ● Historia de usuario N° 7: Evaluación de los proyectos finales

Historia de usuario
HISTORIAS DE
N° 6: Evaluación DESARROLLADORES  VALENCIA MATAMOROS, Amner
USUARIO de inscripción de  PUENTES HUAMANCAJA, Alberto
los proyectos

36
 Historia de usuario
N° 7: Evaluación
DESARROLLADORES
de los proyectos  RAVELO CCANTO, Katerin
finales  PUENTES HUAMANCAJA, Alberto

Desarrollo del Sprint 4

SPRINT N°4

FECHA DE 10/07/2022 FECHA DE 30/07/2022

INICIO CULMINACIÓN

30/07/2022 TIEMPO
REVISIÓN 20
ESTIMADO (días)

TAREAS A ● Historia de usuario N° 8: Fichas de los anexos de acuerdo con el reglamento

DESARROLLAR ● Historia de usuario N°9: Reportes de los proyectos

Historia de usuario
N° 8: Fichas de los
DESARROLLADORES
anexos de acuerdo  PUENTES HUAMANCAJA, Alberto
HISTORIAS DE con el reglamento  QUISPE GARCIA, Yda
USUARIO
Historia de usuario
N° 9: Reportes de DESARROLLADORES  PUENTES HUAMANCAJA, Alberto
los proyectos  GUTIERREZ BOLAÑOS, Jhanet

3.10 TaskBoard Inicial

3.10.1 TaskBoard
Se presenta el Taskboard de desarrollo inicial del proyecto con todas las
historias y la condición inicial de cada uno de los Sprint.

37
 TaskBoard Inicial

Inicio 12/04/2022 Nombre:

Fin 06/08/2022 Desarrollo del software

Historias de Usuario Pendiente En curso Hecho

HU1: Creación de Acceso (Login) X

Sprint N° 1
HU2: Registrar proyectos EC, PS y
X
SS

HU3: Gestión de usuario y

X
contraseña para usuarios

Sprint N° 2 HU4: Recepción de informes de

X
grupos

HU5: Lista de grupos inscritos X

HU6: Evaluación de inscripción de

X
los proyectos
Sprint N° 3
HU7: Evaluación de los proyectos
X
finales

HU8: Fichas de los anexos de

X
acuerdo con el reglamento
Sprint N° 4

HU9: Reportes de los proyectos X

TaskBoard Sprint 1

Inicio 12/04/2022 Nombre:

Fin 06/08/2022 Desarrollo del software

38
 Historias de Usuario Pendiente En curso Hecho

HU1: Creación de Acceso (Login) X

Sprint N° 1
HU2: Registrar proyectos EC, PS y
X
SS

HU3: Gestión de usuario y

X
contraseña para usuarios

Sprint N° 2 HU4: Recepción de informes de

X
grupos

HU5: Lista de grupos inscritos X

HU6: Evaluación de inscripción de

X
los proyectos
Sprint N° 3
HU7: Evaluación de los proyectos
X
finales

HU8: Fichas de los anexos de

X
acuerdo con el reglamento
Sprint N° 4

HU9: Reportes de los proyectos X

TaskBoard Sprint 2

Inicio 12/04/2022 Nombre:

Fin 06/08/2022 Desarrollo del software

Historias de Usuario Pendiente En curso Hecho

HU1: Creación de Acceso (Login) X

Sprint N° 1
HU2: Registrar proyectos EC, PS y
X
SS

39
 HU3: Gestión de usuario y
X
contraseña para usuarios

Sprint N° 2 HU4: Recepción de informes de

X
grupos

HU5: Lista de grupos inscritos X

HU6: Evaluación de inscripción de

X
los proyectos
Sprint N° 3
HU7: Evaluación de los proyectos
X
finales

HU8: Fichas de los anexos de

X
acuerdo con el reglamento
Sprint N° 4

HU9: Reportes de los proyectos X

TaskBoard Sprint 3

Inicio 12/04/2022 Nombre:

Fin 06/08/2022 Desarrollo del software

Historias de Usuario Pendiente En curso Hecho

HU1: Creación de Acceso (Login) X

Sprint N° 1
HU2: Registrar proyectos EC, PS y
X
SS

Sprint N° 2 HU3: Gestión de usuario y

X
contraseña para usuarios

HU4: Recepción de informes de X

grupos

40
 HU5: Lista de grupos inscritos X

HU6: Evaluación de inscripción de

X
los proyectos
Sprint N° 3
HU7: Evaluación de los proyectos
X
finales

HU8: Fichas de los anexos de

X
acuerdo con el reglamento
Sprint N° 4

HU9: Reportes de los proyectos X

TaskBoard Sprint 4

Inicio 12/04/2022 Nombre:

Fin 06/08/2022 Desarrollo del software

Historias de Usuario Pendiente En curso Hecho

HU1: Creación de Acceso (Login) X

Sprint N° 1
HU2: Registrar proyectos EC, PS y
X
SS

HU3: Gestión de usuario y

X
contraseña para usuarios

Sprint N° 2 HU4: Recepción de informes de

X
grupos

HU5: Lista de grupos inscritos X

Sprint N° 3 HU6: Evaluación de inscripción de X

los proyectos

41
 HU7: Evaluación de los proyectos
X
finales

HU8: Fichas de los anexos de

X
acuerdo con el reglamento
Sprint N° 4
HU9: Reportes de los proyectos X

CAPITULO III

42
 CONCLUSIÓN

Como conclusión el equipo N°7 del curso de Taller de Ingeniería de Software

piensa que el sistema web que se desarrolló para la dependencia de EC, PS, y SC fue
cansado y complicado, tratamos de hacerlo según nuestros medios además
agradecemos al Ing. Gilmer Matos por ser quien respondió a todas nuestras dudas
para conseguir los datos necesarios para desarrollar nuestro proyecto.

Por parte del software, se usaron Frameworks que eran poco conocidos por nosotros
haciendo de la investigación del mismo sea fundamental; la unión de las partes del
trabajo era un tema complicado, distinto a un software de escritorio. El cómo
implementar las historias de usuario fue tedioso, además de los diagramas UML pero
reconfortante al completar las historias de usuario y los Sprint en el tiempo
designado, ajustando tiempo muchas veces, pero llegando a la fecha establecida,
esperemos que el proyecto realizado sea de mucha ayuda para el encargado de la
dependencia y así no tenga carencia o problemas.

43