UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ

FACULTAD DE INGENIERÍA DE SISTEMAS

IMPLEMENTACIÓN DEL MODULO DE REGISTRO SIN TUPA DEL

SISTEMA DE TRAMITE DOCUMENTARIO EN LA OFICINA DE
ADMINISTRACION DOCUMENTARIA DE LA UNIVERSIDAD NACIONAL
DEL CENTRO DEL PERÚ UTILIZANDO LA METODOLOGÍA SCRUM

PLAN DE PRÁCTICAS PRE – PROFESIONALES

PRESENTADO POR:
Ramos Contreras, Sherly Diana

ASESOR:
Ing. Olivera Meza, José

HUANCAYO – PERÚ
2017
 ÍNDICE
CAPITULO I .................................................................................................................................... 9
DESCRIPCIÓN DE LA EMPRESA ...................................................................................................... 9
1.1. DATOS GENERALES DE LA EMPRESA “ UNIVERSIDAD NACIONAL DEL CENTRO DEL
PERÚ” 9
1.2. Descripción de la Oficina de Administración Documentaria ...................................... 9
1.3. Descripción del Sistema de Registro de Datos Actual ................................................. 9
CAPITULO II ................................................................................................................................. 11
MARCO TEÓRICO ......................................................................................................................... 11
2.1. SELECCIÓN DEL ENTORNO DE PROGRAMACIÓN ....................................................... 11
2.1.1. ENTERPRISE ARCHITECT...................................................................................... 11
2.1.2. UML ..................................................................................................................... 11
2.1.3. BIZAGI.................................................................................................................. 12
2.1.4. MOTOR DE BASE DE DATOS ............................................................................... 12
2.1.5. HERRAMIENTA IDE ............................................................................................. 12
2.1.6. LENGUAJE DE PROGRAMACIÓN ......................................................................... 12
2.2. METODOLOGÍA ........................................................................................................... 12
2.2.1. METODOLOGÍA SCRUM ...................................................................................... 12
CAPITULO III ................................................................................................................................ 16
APLICACIÓN DE LA METODOLOGÍA ........................................................................................... 16
3.1. MODELADO DEL NEGOCIO ......................................................................................... 16
3.2. ESTIMACIÓN DE LOS RECURSOS REQUERIDOS .......................................................... 17
3.2.1. RECURSOS HUMANOS ........................................................................................ 17
3.2.2. SOFTWARE .......................................................................................................... 18
3.3. REALIZACIÓN DE CASO DE USO .................................................................................. 18
3.3.1. CASO DE USO DEL NEGOCIO................................................................................... 18
3.3.2. CASO DE USO DEL SISTEMA................................................................................ 18
3.4. IDENTIFICACION DE LOS REQUERIMIENTOS .............................................................. 19
3.4.1. REQUERIMIENTOS FUNCIONALES ...................................................................... 19
3.4.2. REQUERIMIENTOS NO FUNCIONALES ................................................................ 20
3.5. PRODUCT BACKLOG .................................................................................................... 21
3.6. PLANIFICACION ........................................................................................................... 23
3.7. SELECCION DE LOS SPRINT ......................................................................................... 24
3.8. DISEÑO DE LA INTERFAZ ............................................................................................. 27
3.8.1. LOGIN DE INGRESO ............................................................................................. 27
3.8.2. INGRESO DE DATOS ............................................................................................ 27
 3.9. IMPLEMENTACIÓN DEL SISTEMA DE TRAMITE DOCUMENTARIO ............................ 28
3.9.1. PLAN DE CAPACITACION..................................................................................... 29

Tabla de Ilustraciones

Figura 1/Herramienta Enterprise Architect ........................................................................ 11

Figura 2/Definición UML ................................................................................................... 11
Figura 3/ Proceso de la iteración ....................................................................................... 13
Figura 4/ SCRUM Ficha Sinoptica ....................................................................................... 15
Figura 5/MAPA DE PROCESO DE LA OFICINA DE ADMINISTRACION DOCUMENTARIA .......... 16
Figura 6/ Proceso del Sprint .............................................................................................. 24
 RESUMEN

El presente proyecto consiste en desarrollar e implementar el módulo de

registro sin tupa del Sistema de Tramite Documentario para descentralizar
las actividades operativas de la Oficina de Administración Documentaria
de la Universidad Nacional del Centro del Perú.

El proyecto se sustenta en la corriente teórica de metodologías agiles de

desarrollo de software y respetara los estándares establecidos, utilizando
como marco de trabajo la metodología SCRUM. El sistema desarrollado es
capaz de mantener, de una manera distribuida, el proceso de recepción y
tráfico de documentos entre las otras oficinas pertenecientes la
Universidad Nacional del Centro del Perú y entidades externas
solicitantes, que permite realizar sus actividades operativas (registro,
consulta, verifica) ingresando al portal oficial de la UNCP logrando mejorar
la calidad del servicio ofrecido a los usuarios.

Además de aplicar una metodología de desarrollo, capaz de estructurar,

planificar y controlar el proceso de desarrollo con un software más ágil y
eficiente siguiendo las recomendaciones de las reuniones diarias el cual se
orientó a cumplir los requerimientos exigidos del personal.
 INTRODUCCIÓN

El siguiente proyecto tiene por finalidad presentar una solución web

dirigida a la problemática actual en la Oficina de Administración
Documentaria de la Universidad Nacional del Centro del Perú. La solución
propone descentralizar y hacer más ágil el proceso de recepción y envío
de documentos a la oficina destino cumpliendo con los requerimientos
exigidos por el personal experto. Este proyecto se divide en tres capítulos.

En el primer capítulo describe la Universidad Nacional del Centro del Perú

y la Oficina de Administración Documentaria, las actividades que realiza y
detalles de la situación actual; además la situación actual del sistema de
registro de datos (Excel).

En el segundo capítulo se explica el marco teórico, la selección del entorno

de programación; describe las herramientas a utilizar como: motor de
base de datos, lenguaje de programación, herramienta de diseño, y una
breve explicación de la metodología SCRUM.

En el tercer capítulo se presenta el desarrollo del proyecto, aplicando la

metodología, describiendo las iteraciones identificadas según las
prioridades de los requerimientos; realizando actividades como:
modelado de negocio, casos de uso, estimación de recursos, identificación
de requerimientos y realización del product backlog; además de la
selección de los sprints e implementación del sistema.
 JUSTIFICACIÓN

Considerando el proceso de administración documentaria que realiza

la Universidad Nacional del Centro del Perú se ha visto por
conveniente implementar el módulo de registro sin tupa del sistema
de tramite documentario utilizando la metodología SCRUM el cual
facilitara los procesos que se lleven a cabo con el fin de optimizar el
intercambio de información entre oficinas.
OBJETIVOS
OBJETIVOS GENERALES:

 Implementar el módulo de registro sin tupa del Sistema de Tramite

Documentario para facilitar los procesos de dicha oficina.

OBJETIVOS ESPECÍFICOS:

 Mejorar la eficiencia de atención en recepción – administración

documentaria.
 Mejorar con la fluidez de documentos entre oficinas.
 Eficiencia en la atención de consultas.

METAS ALCANZADAS:
 CAPITULO I

DESCRIPCIÓN DE LA EMPRESA

1.1. DATOS GENERALES DE LA EMPRESA “ UNIVERSIDAD NACIONAL DEL CENTRO

DEL PERÚ”
Es una universidad pública peruana ubicada en Huancayo, su fundación marcó
el corolario al esfuerzo arduo y tesonero de 36 comunidades campesinas de la
región andina. Su primer rector fue Javier Pulgar Vidal.
 Tipo: Universidad Pública
 Fundación: 16 de diciembre de 1959 (57 años)
 Dirección: Av. Mariscal Castilla, 3909, Huancayo
 Teléfono: (064) 481062
 Rector/a: Dr. Moisés Vásquez Caicedo Ayras
 Estudiantes: 10.022 (2007)
1.2. Descripción de la Oficina de Administración Documentaria
La Oficina de Administración Documentaria de la UNCP es el área que
pertenece a secretaria general según el organigrama estructural y es la
encargada de administrar cada documento entrante a la institución y derivar a
sus respectivos destinos (facultades, oficinas, directores, decanato) para el flujo
constante de documentos.
OBJETIVOS:
 Gestionar con eficacia el direccionamiento estratégico institucional.
 Desarrollar las competencias del personal administrativo.
 Mejorar el proceso de recepción y atención.
 Mejorar la satisfacción de los usuarios.
 Contribuir al mejoramiento social de la zona de influencia.
1.3. Descripción del Sistema de Registro de Datos Actual
La Oficina de Administración Documentaria de la UNCP en este momento
realiza el registro de datos de los documentos entrantes a través de una base
de datos en el programa Excel con 7 campos (registro, fecha, documento,
remitente, dependencia del remitente, asunto y la oficina a donde pasa) todo el
registro es manual y por día.
 CAPITULO II

MARCO TEÓRICO

2.1. SELECCIÓN DEL ENTORNO DE PROGRAMACIÓN

2.1.1. ENTERPRISE ARCHITECT
Enterprise Architect es una herramienta de modelado y diseño visual basada en
OMG UML. La plataforma admite: el diseño y la construcción de sistemas de
software; modelar procesos comerciales; y modelado de dominios basados en la
industria. Las empresas y organizaciones lo usan no solo para modelar la
arquitectura de sus sistemas, sino también para procesar la implementación de
estos modelos en todo el ciclo de vida de desarrollo de aplicaciones.

Figura 1/Herramienta Enterprise Architect

2.1.2. UML

El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad; está respaldado por el Object Management
Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programación, esquemas de
bases de datos y compuestos.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.

Figura 2/Definición UML

 2.1.3. BIZAGI

Bizagi es una empresa de software privada establecida en 1989 con sede en el

Reino Unido y oficinas en Estados Unidos, España y América Latina. Su nombre
es un acrónimo de "negocios" y "agilidad".
La compañía diseña y desarrolla software empresarial para Business Process
Management (BPM). Sus tres productos forman la Bizagi BPM Suite.
Aplicaciones
Bizagi se puede usar para automatizar procesos y ha puesto a disposición un
conjunto de plantillas de procesos ejecutables que se pueden descargar desde
Bizagi. Las plantillas incluyen la Gestión del servicio de asistencia, la gestión del
proceso Six Sigma, la solicitud de préstamos personales, la suscripción de
pólizas de seguro, el proceso transaccional, entre otros.
2.1.4. MOTOR DE BASE DE DATOS
El motor de base de datos es Sql Server 2012.
2.1.5. HERRAMIENTA IDE
La herramienta IDE es html5.
2.1.6. LENGUAJE DE PROGRAMACIÓN
El lenguaje de programación es PHP.

2.2. METODOLOGÍA

La metodología que usaremos para desarrollar el proyecto será la metodología

SCRUM a continuación se muestra una breve descripción de ésta.

2.2.1. METODOLOGÍA SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto

de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final,

priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad,
la flexibilidad y la productividad son fundamentales.
En Scrum un proyecto se ejecuta en bloques temporales cortos y
fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos
equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión).
Cada iteración tiene que proporcionar un resultado completo, un incremento
de producto final que sea susceptible de ser entregado con el mínimo esfuerzo
al cliente cuando lo solicite.

Figura 3/ Proceso de la iteración

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que

actúa como plan del proyecto.

Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración.

Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la

lista de requisitos priorizada del producto o proyecto. El equipo pregunta al
cliente las dudas que surgen y selecciona los requisitos más prioritarios que se
compromete a completar en la iteración, de manera que puedan ser
entregados si el cliente lo solicita.

2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista

de tareas de la iteración necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de manera conjunta y los
miembros del equipo se auto asignan las tareas.

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo).
Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración,
obstáculos que pueden impedir este objetivo) para poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso adquirido.
En la reunión cada miembro del equipo responde a tres preguntas:

 ¿Qué he hecho desde la última reunión de sincronización?

 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo

pueda cumplir con su compromiso y de que no se merme su productividad.

 Elimina los obstáculos que el equipo no puede resolver por sí mismo.

 Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos

(para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o
re planifican los objetivos del proyecto para maximizar la utilidad de lo que se
desarrolla y el retorno de inversión.

Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración.
Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los

requisitos completados en la iteración, en forma de incremento de producto
preparado para ser entregado con el mínimo esfuerzo. En función de los
resultados mostrados y de los cambios que haya habido en el contexto del
proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su
manera de trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El
Facilitador se encargará de ir eliminando los obstáculos identificados.

Figura 4/ SCRUM Ficha Sinoptica

 CAPITULO III

APLICACIÓN DE LA METODOLOGÍA

3.1. MODELADO DEL NEGOCIO

Figura 5/MAPA DE PROCESO DE LA OFICINA DE ADMINISTRACION DOCUMENTARIA

 3.2. ESTIMACIÓN DE LOS RECURSOS REQUERIDOS

3.2.1. RECURSOS HUMANOS

SCRUM
MASTER

ANALISTA DISEÑADOR PROGRAMADOR PRUEBAS

INTEGRANTE ROL DESCRIPCION

Este rol normalmente lo cumple una persona de parte

Oficina General del cliente que conozca a fondo las necesidades y pueda
proporcionar la información necesaria en el momento
de Sistemas de PROPIETARIO DEL preciso.
Información y PRODUCTO Representa a todos los interesados en el producto final.
Comunicación
• Financiación del proyecto
• Requisitos del sistema
Responsable del proceso, cumplir la meta y resolver los
problemas. Así como también, de asegurarse que el
proyecto se lleve a cabo de acuerdo con las prácticas,
valores y reglas de Scrum y que progrese según lo
Ing. Rusel SCRUM MASTER previsto.
Interactúa con el cliente y el equipo. Coordina los
encuentros diarios, y se encarga de eliminar eventuales
obstáculos.

La persona encargada de analizar la situación actual y

Analista sobre todo ver que se realicen los requerimientos y
necesidades en el sistema.
.Ramos Un rol muy importante al tener que diseñar como
Diseñador debería ser el nuevo sistema que se quiere implementar
Contreras
Diana de acorde a las necesidades.
EQUIPO Encargado de realizar con mayor cuidado el sistema con
.Laura Caleni Programador varios programas que se requieran usar para finalizar el
Elizabeth sistema con satisfacción.
Es el tiempo que se requiere para ver con mayor
Pruebas exactitud las fallas que se presenten una vez que el
sistema se implementado e interactúe con los usuarios
interesados.
.Personal de la Son todas las personas (usuarios) que interactúen con el
Oficina de sistema y todas las acciones que se deban tomar para
INTERESADOS mejorar el proceso de trámite documentario.
Administración
Documentaria
 3.2.2. SOFTWARE

TIPO NOMBRE
Desarrollo PHP
Java Scrip, Csc3, Html5
Edición Documentaria Microsoft Office 2013
Sistema Operativo Microsoft Windows 8
Base de Datos SQL Server 2012

3.3. REALIZACIÓN DE CASO DE USO

3.3.1. CASO DE USO DEL NEGOCIO
class Modelo de casos de uso

CONSULTAR
SISTEMA

ADMINISTRADOR REGISTRA
DOCUMENTO

PERSONAL RECEPCION

ALUMNO
CONSULTAR
REGISTRO

PERSONAL RECEPCION

CONSULTAR ESTADO

EGRESADOS INTERESADO

CONSULTAR
REGISTRO

PERSONAL MENSAJERIA

TRABAJADORES

3.3.2. CASO DE USO DEL SISTEMA

uc Modelo de casos de uso

Sistema de Trámite Documentario

REGISTRA
DOCUMENTO PERSONAL RECEPCION

PERSONAL MENSAJERIA

CONSULTAR
REGISTRO

CONSULTA
JEFA DE LA OFICINA INFORMACION
SISTEMA ADMINISTRADOR
3.4. IDENTIFICACION DE LOS REQUERIMIENTOS
3.4.1. REQUERIMIENTOS FUNCIONALES
ADMINISTRADOR:

 El sistema permitirá al administrador hacer modificaciones si hay alguna

corrección que hacer, poder eliminar o agregar los tramites que sean

necesarios.

 El sistema tendrá un usuario y contraseña seguro (números y letras variados)

para el administrador.

 Si se trata de un nuevo miembro del equipo o interesados se creara un nuevo

usuario que permita acceder a este sistema

JEFA DE LA OFICINA:

 El sistema presentara todos los campos solicitados en un documento físico.

 El sistema presentara opciones para determinar el tipo de documento.

 El sistema contará con un usuario y contraseña seguro (números y letras

variados).

PERSONAL DE RECEPCION:

 El sistema permitirá al usuario autorizado el registro de nuevos documentos,

además de realizar consulta de sus datos.

 El usuario con rol personal de recepción solo tendrá permitido la consulta,

registro de documentos.

 El sistema presentará información sobre el control del estado de los

documentos entrantes.

 El Sistema permitirá realizar una consulta de datos no editables por cada

documento.

 El sistema contará con un usuario y contraseña seguro (números y letras

variados).
 PERSONAL DE MENSAJERIA

 El Sistema permitirá realizar consultas de todos los documentos y tramites

que sean necesarios para verificar su estado y/o lugar de encuentro.

 El sistema contará con un usuario y contraseña seguro (números y letras

variados).

 Se creara consultas indicando el estado del documento ingresado al sistema

como: en espera o aceptado por medio del número del documento o dato

personal del solicitante.

3.4.2. REQUERIMIENTOS NO FUNCIONALES

 El sistema incluirá herramientas que permitan compartir la información de la base

de datos a través ordenadores conectados a la misma red web.

 Se creara consultas indicando el estado del documento ingresado al sistema

como: en espera o aceptado por medio del número del documento o dato

personal del solicitante.

 El funcionamiento del sistema será dependiente de una conexión a internet.

 El sistema tendrá una interfaz amigable e intuitiva.

 Sera aprobada por el cliente o dueño, en ningún caso será una interfaz real,

simplemente un boceto de la misma para definir su estructura y la organización

del contenido.
3.5. PRODUCT BACKLOG

IDENTIFICADOR DESCRIPCION CONDICIONES DE SATISFACCION

OBJETIVO

A1  Crear el proyecto a través de un

formulario
Dar alta al  Al crear el proyecto me debe
permitir asignar miembros del
proyecto equipo.

A2  Se deberá indicar un nombre, una

descripción breve.
Creación de tareas  Asignar la tarea a un miembro del
equipo.

A3 Procesar tareas  Puede modificar el estado de una

tarea: en ejecución, pausa o
terminada.
A4 Acceso Director,  Al acceder al proyecto se le da
acceso a toda la información de
proyectos historias de usuario y tareas que
están relacionadas.
 Exportar informes con los datos
actuales.
A5 Asignación de  El administrador de la plataforma
puede asignar permisos para una
permisos entre funcionalidad concreta.
 El sistema permitirá al
roles de usuario
administrador hacer
modificaciones si hay alguna
corrección que hacer, poder
eliminar o agregar los tramites que
sean necesarios.
A6 Reuniones (scrum --------

diario)

A7 Sprint Backlog --------

IDENTIFICADOR DESCRIPCION CONDICIONES DE SATISFACCION
OBJETIVO

B1  Al acceder al sistema se deberá

comprobar que un usuario
Login de usuarios existente se ha identificado con su
usuario y su password.
 El sistema contará con un usuario y
contraseña seguro (números y
letras variados).
B2  Al crear un usuario tiene que estar
disponible su acceso
 Si se trata de un nuevo miembro
del equipo o interesados se creara
Crear usuarios
un nuevo usuario que permita
acceder a este sistema.

B3  Al retirarse un miembro del equipo

o interesados se deberá dar de baja
Dar de baja
a este y dejara de estar disponible
usuarios para ingresar al sistema.

B4  Se creara muchos procedimientos

que sean necesarios para realizar
un trámite documentario como los
oficios.
 Se asignara todos los campos que
Crear
sean necesarios para ingresar toda
procedimientos de
la información posible de estos
ingreso
oficios.
B5 Crear consultas de  Se creara consultas indicando el
solicitudes estado del documento ingresado al
mediante el sistema como: en espera o
número de aceptado por medio del número
documento del documento.
 El sistema deberá ser eficaz y
eficiente en cuanto a las consultas
de manera rápida para mejorar el
tiempo de espera del usuario.
B6 Definir y crear una  Sera aprobada por el cliente o
dueño, en ningún caso será una
interfaz real, simplemente un
 interfaz grafica boceto de la misma para definir su
estructura y la organización del
contenido.
 El sistema tendrá una interfaz
amigable e intuitiva.
B7 Tecnología y  El sistema incluirá herramientas
que permitan compartir la
herramientas información de la base de datos a
través ordenadores conectados a la
misma red web.
 Las conclusiones finales, como
resultado de los problemas o
dificultades que se haya obtenido
servirá para conocer el grado de
satisfacción del cliente.
 El sistema presentara opciones
para determinar el tipo de
documento.

3.6. PLANIFICACION

Podemos definir los sprint agrupando historias de usuario según su prioridad. La

siguiente tabla nos muestra las historias de usuario priorizadas hasta la fecha y
agrupadas por iteraciones o sprint hasta el sprint 4. El resto de historias
priorizadas ya no serán analizadas e incluidas en próximas revisiones del Product
Backlog.

N° SPRINT IDENTIFICADOR DESCRIPCION PRIORIDAD

OBJETIVO

Sprint 1 A1 Dar de alta al proyecto 1

A2 Creación de tareas 2

A3 Procesar tareas 3

A6 Reuniones (scrum diario) 4

Sprint 2 B1 Login de usuarios 5

 B2 Crear usuarios 6

B3 Dar de baja usuarios 7

B4 Crear procedimientos de ingreso 8

B5 Crear consultas de solicitudes mediante el 9

número de documento

Sprint 3 A4 Acceso Director, proyectos 10

A5 Asignación de permisos entre roles de 11

usuario

B6 Definir y crear una interfaz grafica 12

B7 Tecnologías y herramientas 13

3.7. SELECCION DE LOS SPRINT

Figura 6/ Proceso del Sprint

 PRIMER SPRINT

Esta primera iteración denominada “Sprint 1” recibe el nombre por el hecho de

la historia de usuario (A1) tratando las demás historias de usuario A2, A3 y A6.

Backlog Tarea Tipo Descripción Responsable Estimación

A1 Tarea 1 Implementación Iniciar con las labores del S.M. 15%

proyecto
A2 Tarea 2 Análisis y/o Analizar con cautela todas las S.M. 20%
Documentación acciones que se realizara para
el proyecto y asignación de
tareas a cada responsable.
A3 Tarea 3 Pruebas Realizar con cuidado cada tares Analista 30%
asignada a cada responsable. Diseñador
Programador
A6 Tarea 4 Pruebas Realización de reuniones S.M. 35%
constantemente para verificar
que todo marche bien y si se
requiere de alguna
modificación en las tareas se
tendrá que hacer.

 SEGUNDO SPRINT

En esta segunda iteración denominado “Segundo Sprint” vamos a tratar las

historias de usuario B1, B2, B3, B4 y B5. Como vemos en la tabla el número de
tareas respecto a la iteración anterior ha aumentado consideradamente.

Backlog Tarea Tipo Descripción Responsable Estimación

B1 Tarea 1 Codificación Se creara el campo de Login al Programador 15%

usuario para que sea de
manera segura el ingreso al
sistema.
B1 Tarea 2 Codificación Se restringirá en el campo de Programador 10%
contraseña al ingresar
obligadamente con números y
letras variadas.
B2 Tarea 3 Implementación Se creara a todas las personas Propietario 15%
relacionadas al sistema sus del Producto
usuarios y contraseñas para
que puedan acceder a este.
B3 Tarea 4 Implementación Se eliminara todos los usuarios Propietario 10%
de las personas que dejan de del Producto
laborar o relacionarse con el
sistema mediante el trabajo.
B4 Tarea 5 Codificación Se creara campos de acuerdo a Programador 20%
los requerimientos de los
usuarios en el sistema como
datos de las personas
solicitantes.
 B4 Tarea 6 Codificación Se creara campos como Programador
nombres, numero de
documento, de donde procede
el solicitante, a donde dirige
sus documento, que tipo de
procedimiento en el TUPA se
encuentra.
B5 Tarea 7 Codificación Se creara campos de consultas Programador 20%
de acuerdo al tipo de
documento
B5 Tarea 8 Codificación Se realizara la consulta Programador 10%
mediante el número de
documento que se introduce al
sistema.

 TERCER SPRINT
En esta última iteración considerada se va a tomar las historias de usuario A4,
A5, B6 y B7 para finalizar con las tareas.

Backlog Tarea Tipo Descripción Responsable Estimación

A4 Tarea 1 Análisis e Al ejecutar el proyecto la Propietario 20%

Investigación dirección general va a brindar del Producto
toda la información necesaria
que lo requiera el equipo
dirigido por el Scrum Master
A4 Tarea 2 Análisis e Al tener ya toda la información Analista 15%
Investigación necesaria a la mano se
analizara detalladamente
hacia qué actividad o acción ir
por cada responsable.
A5 Tarea 3 Documentación El administrador del sistema a Propietario 15%
y/o implementar asignara del Producto
Programación permisos especiales a las
personas responsables que
crean convenientes para
realizar algunas acciones en
caso que se ausente.
B6 Tarea 4 Diseño Se diseñara una interfaz Diseñador 20%
gráfica de acorde a los
requerimientos de los
interesados y relacionados al
sistema
B6 Tarea 5 Diseño El interfaz deberá ser amigable Diseñador 10%
e intuitiva

B7 Tarea 6 Implementación El sistema implementado Programador 20%

deberá contar con
herramientas como la web
para poder ingresar e
interactuar en todos los
procesos

3.8. DISEÑO DE LA INTERFAZ

3.8.1. LOGIN DE INGRESO

3.8.2. INGRESO DE DATOS

3.9. IMPLEMENTACIÓN DEL SISTEMA DE TRAMITE DOCUMENTARIO
 BIENVENIDA AL SISTEMA DE TRAMITE CON DATOS PERSONALES

 MENU DE LOS TIPOS DE REGISTRO

  FORMULARIO DEL REGISTRO SIN TUPA

 DATOS A RELLENAR EN EL FORMULARIO CON LISTAS DESPLEGABLES

3.9.1. PLAN DE CAPACITACION